Автоматическая перезагрузка debian.

cron

Спасибо, запланировать reboot в определенное время, сейчас попробую.

Не смог пройти мимо. 1. Электрики 2. Энергосбыт - это для случая если много серверов распределенных на разных площадях. Оба варианта рабочие, проверено многолетней практикой. Но есть минус, что первый что второй вариант не смотря на наличие упс может привести к порче оборудования.

Ну это да, есть такие варианты, только каждый день работают.

Можно нанять специальнообученного человека, который будет тыкать кнопку на системнике.

# shutdown -r 18:00

При старте

Проблема решил путем настройки планировщика cron.

Но зачем, Карл?

В смысле, у вас идеально работают сервера, без лагов и зависаний?

У меня да. (На самом деле вру, недавно всплыл мелкий баг cifs, только хард ребут спасал, но это явно не ваш вариант). Необходимости в софт ребуте за свою практику не могу припомнить.

Обычно да, а если дохнут, то ребут не помогает...

Сервер вообще ребутать только по особым случаям. У меня ребутался, когда железо меняли. До этого тоже из-за железа. 571 дней до последнего ребута было.

Если нет апаратных проблем, то без лагов и проблем.

Что у Вас за сервера (апаратная часть) и какой софт крутится?

Память ECC? Чем мониторите нагрузку на сервер?

Ну в принципе логично, если все нормально настроено, походу вы правы. В основном сейчас работаю с VPN, openvpn, так же была необходимость в сервере приложений Jboss, тут-то я и встретил несколько проблем, но позже понял почему. Суть а том, что я использую в основном VPS и для своих целей, по рабочим сервера как-то проблем нет, там уже было все сделано нормально, когда я пришел, а так экспериментирую для знаний и опыта. А случай был в том, что есть сервер ОЗУ 256Мб, ЦП 2Ггц, сначала поставил OpenVpn, потом туда еще LAMP и еще что-то, смотрю что все начинает зависать, я в SSH еле вхожу, начал мониторить, использую glances, информативный мониторинг и вижу, что ОЗУ уже было 20 МБ, к тому времени еще SWAP подключил, хорошо VPS на SSD, ну тут тоже все начало заполняться. Так что на опыте узнал, что надо ставить и смотреть одновременно. Что касается перезагрузки, то мне почему-то казалось, что это необходимо делать каждый день, ну сейчас опять опытным путем понял обратное. А чем вы пользуетесь для мониторинга?

571 дней до последнего ребута было.

А обновление ядра?

Для обновления ядра без перезагрузки ksplice

cron

Для мониторинга централизировано отдельний сервер Zabbix с информированием по смс. Иногда monit.

У Вас 256 озу - маловато. Увеличить временно есть возможность?

Я не про то, что можно использовать. Я про то, что непосредственно используется.

ksplice как бы денег стоит, причем немалых ($2000-$5000). Далеко не у каждой компании это окупится.

А обновление ядра?

А зачем?

А зачем?

Чтобы потом не создавать треды на лоре «меня сломали, как вычистить малварь с сервера?».

1. Вы много помните серьезных уязвимостей именно в ядре, которые приводили бы к «меня сломали, как вычистить малварь с сервера?» ?
2. Вам мама не рассказывала что бывают сервера которые в инет не смотрят?
3. А папа не говорил - работает не трогай?
ЗЫ У меня есть несколько небольших почтарей, которые работают на родном ведре (патрик не любит ядра обновлять) хрен знает сколько лет. Вот блина почему малварь не прет? Не подскажите?

1. Вы много помните серьезных уязвимостей именно в ядре, которые приводили бы к «меня сломали, как вычистить малварь с сервера?» ?

Я чаще вижу RCE через любой «мы же запускаем это от пользователя, все нормально», после чего радостно повышают привилегии.

2. Вам мама не рассказывала что бывают сервера которые в инет не смотрят?

А вам про внутренних нарушителей?

3. А папа не говорил - работает не трогай?

В ИБ этот принцип не работает.

ЗЫ У меня есть несколько небольших почтарей, которые работают на родном ведре (патрик не любит ядра обновлять) хрен знает сколько лет. Вот блина почему малварь не прет? Не подскажите?

А дядя Вася всю жизнь на машине пьяный ездит. Вот блина почему до сих пор живой и никого не сбил? Не подскажите?

Из того, что проблема обходила стороной до этого момента, не следует, что она будет обходить и далее.

Вы много помните серьезных уязвимостей именно в ядре, которые приводили бы к «меня сломали, как вычистить малварь с сервера?» ?

Вы так и не ответили на этот вопрос.

А вам про внутренних нарушителей?

А почему у вас внутренние нарушители имеют доступ к серверам, причем такой который может привести к уязвимости?

В ИБ этот принцип не работает.

Дядя, бы бредите про ИБ. Следую вашей логике, давайте будем обновлять ядра на космических станциях, атомных станциях и т.д. А что потом произойдет при обновлении нас ниибет ибо ИБ. Любое, абсолютно любое обновление привносит и свои баги для рабочей системы. Я об этом тут не раз писал. Я не буду спорить с необходимостью критических обновлений демонов которые просто необходимы. Но обновление ради обновления когда тебя это просто никаким образом не касается - лишняя трата времени, т.к. тебе как минимум прийдется протестить всю работу плюс еще потом долго будешь вылавливать всплывшие баги. (Как-то был случай когда из-за обновления поимел бооольшой головняк с откатом на старую версию)

Из того, что проблема обходила стороной до этого момента, не следует, что она будет обходить и далее.

Ответ неверный. Нэма багов с которых могли бы поиметь. Да, сами баги есть, но для моего случая они роли не играют. Надеюсь так понятнее.

Тогда и происходит.

А почему у вас внутренние нарушители имеют доступ к серверам

Использует корпоративную почту, которая «не смотрит в интернет» — вот тебе и готово.

обновление ради обновления когда тебя это просто никаким образом не касается

Скажи своему ИБшнику на работе о том, что накатить обновление, исправляющее LPE/DOS в ядре — это обновление ради обновления.

Использует корпоративную почту, которая «не смотрит в интернет» — вот тебе и готово.

Возвращаемся к вопросу. Приведите примеры проблем ядра которые при использовании почты приводили бы к взлому?

исправляющее LPE/DOS

Вопрос был выше.
ЗЫ Чей-то вы про атомный станции, и другие технологии слились?

Приведите примеры проблем ядра которые при использовании почты приводили бы к взлому?

Соль в том, что если у тебя поломают почтовый сервер, то в случае дырявого ядра тебя еще и порутают.

В шахматы играл? Попробуй, учит думать не только на один шаг вперед.

В шахматы играл? Попробуй, учит думать не только на один шаг вперед.

Именно поэтому я вам и писал «Нэма багов с которых могли бы поиметь. Да, сами баги есть, но для моего случая они роли не играют. Надеюсь так понятнее.» - я не рассматриваю каждый по отдельности.
И кстати (о чем здесь уже писал) в моей практике подконтрольные мне сервера ломали дважды, первый раз когда я сам был молодым раздолбаем, второй раз благодаря раздолбаю подавану.
ЗЫ И вы опять пропустили ответ про технологию. Предполагаю, что вы никогда с ней не сталкивались и вся ваша работа это только веб, почтарь, т.п. Тогда прощаю ваше не знание.

Именно поэтому я вам и писал «Нэма багов с которых могли бы поиметь. Да, сами баги есть, но для моего случая они роли не играют. Надеюсь так понятнее.» - я не рассматриваю каждый по отдельности.

Ты смотришь на тот момент, который есть у тебя сейчас, и не думаешь о том, какие уязвимости всплывут завтра. А они, вероятнее всего, всплывут.

И кстати (о чем здесь уже писал) в моей практике подконтрольные мне сервера ломали дважды, первый раз когда я сам был молодым раздолбаем, второй раз благодаря раздолбаю подавану.

Стоит говорить не о том, сколько раз твои сервера ломали, а о том, сколько раз ты это заметил.

И вы опять пропустили ответ про технологию.

Про какую технологию ответ я пропустил?

Ты смотришь на тот момент, который есть у тебя сейчас, и не думаешь о том, какие уязвимости всплывут завтра. А они, вероятнее всего, всплывут.

Я всетаки попрошу примеры (хоть один), то с чего я начинал. (Патрик не так часто ядра апдэйтит, следует задуматься почему )

Стоит говорить не о том, сколько раз твои сервера ломали, а о том, сколько раз ты это заметил.

Вот ровно столько сколько написал - два штука.

Про какую технологию ответ я пропустил?

«Атомные станции» и всякие другие «радости» АСУ*, АСД*, etc

Патрик не так часто ядра апдэйтит, следует задуматься почему

Ты что-то путаешь. Обновления безопасности на ядро прилетают также, как и в других дистрибутивах. http://www.slackware.com/security/viewer.php?l=slackware-security&y=2016&...

Вот ровно столько сколько написал - два штука.

Я о том, что ты заметил два раза. А сколько раз взломали в общем случае неизвестно.

«Атомные станции» и всякие другие «радости» АСУ*, АСД*, etc

И? В этих степях все также, но с поправкой на сертификацию, контролирующие органы etc.

Ты что-то путаешь. Обновления безопасности на ядро прилетают также, как и в других дистрибутивах.

Не так часто, как в других, посмотрите общий список.

Я о том, что ты заметил два раза. А сколько раз взломали в общем случае неизвестно.

Известно - два раза. Вы читать не умеете.

И? В этих степях все также, но с поправкой на сертификацию, контролирующие органы etc.

Вы точно к технологиям не имеете отношения. Если у меня рабочая «хреновина», которая работает с оборудованием, то как минимум я сам себе не позволю обновлять ядро и все остальное.

Известно - два раза.

«Я не заметил, поэтому меня никто не сломал.»

Если у меня рабочая «хреновина», которая работает с оборудованием, то как минимум я сам себе не позволю обновлять ядро и все остальное.

Не стоит подгонять все под частный случай. Из того, что существует система, которую обновить невозможно, не следует, что не нужно обновлять другие.

1. Вы много помните серьезных уязвимостей именно в ядре, которые приводили бы к «меня сломали, как вычистить малварь с сервера?» ?

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2523

DOS и потенциальное RCE. Для этого надо, правда, чтобы к тачке был доступ из интернета. От конкретно этого можно защититься костылями типа -t raw A PREROUTING -p dccp -j NOTRACK, но сам факт наличия такой уязвимости показателен.

«Я не заметил, поэтому меня никто не сломал.»

Нет заметил.

Не стоит подгонять все под частный случай. Из того, что существует система, которую обновить невозможно, не следует, что не нужно обновлять другие.

Этот как вы выразились «частный случай» нехило по всему шарику работает. Вот еще вспомнилось, програматор имплатнируемых кардиостимуляторов, работает под «шапкой» 7.3 (не путайте с RHEL) вот вам бы хотелось что бы при обновлении ядра что-то сбойнуло и вам или вашим родным долбануло в сердце и вы/они умерли?

Всего один пример. Плюс решение тогда было простым, я помню ту историю с dccp и решалась она без обновления ведра.

Можно нанять специальнообученного человека, который будет тыкать кнопку на системнике.

Единственный самый правильный ответ в теме!

А всех тех кто написал «cron» щитаю нужно злостно забанить (за вредительство) :-)

ЕМНИП, была еще какая-то подобная уязвимость, связанная с conntrack и каким-то редким (или не очень) протоколом, которую открывали еще раньше.

А с dccp было весело - на убунте 10.04 модуль conntrack для его отслеживания уже был в дистрибутивном ядре, тогда как юзерспейсная утилита iptables еще не знала о существовании такого протокола. Пришлось переименовать модуль ядра, хорошо хоть что не был вкомпилен.

ЕМНИП, была еще какая-то подобная уязвимость, связанная с conntrack и каким-то редким (или не очень) протоколом, которую открывали еще раньше.

Вот тут емнип, решалось еще проще чем с dccp. Хотя могу гнать как троцкий. Но всетаки не припомню «ада и израиля».

на убунте

Уж простите, но не могу удержаться :) Это проблема вашей убунты :)

Уж простите, но не могу удержаться :) Это проблема вашей убунты :)

Ага, убунту я теперь обхожу стороной :)

Нет заметил.

То есть ты считаешь, что если ты не заметил взлома, то его и не было вовсе?

Этот как вы выразились «частный случай» нехило по всему шарику работает.

Что не мешает быть ему частным случаем.

вот вам бы хотелось что бы при обновлении ядра что-то сбойнуло и вам или вашим родным долбануло в сердце и вы/они умерли?

Нет, конечно нет. И также не хотелось бы умереть от того, что малварь проникла на программатор. И вообще я говорил о серверах, которые смотрят в сеть. Для объектов, до которых по сети не добраться, это не так актуально.

Ядро не такая страшная и зловещая штука, как может показаться. Можно даже модули ядра писать, которые без перекомпиляции будут работать на ядрах за последние 10 лет. А приложения можно и обновлением глибц сломать.

Да, уже увеличил до 1024МБ. Я всерьез задумался о необходимости мониторинга, сейчас как раз изучаю этот момент, zabbix мне вполне симпатизирует, на практике пока система обновляется, думаю это на долго, потом обязательно займусь установкой данного ПО.

Настолько свежо про обновление ведра, что добавлю для вас Kernel panic после перезагрузки

При обновлении критической части инфраструктуры стоит производить тестирование — я думаю, что это очевидно. Если простой 10-15 минут погоды не сыграет, то можно действовать и как ТС треда по ссылке.

А вообще всегда весело наблюдать, когда у любителей большого аптайма внезапно появляется острая необходимость в перезагрузке (питание, железо), и когда у них просто старта все остается в состоянии «загрузился, но не работает». Поэтому я ради профилактики иногда (после изменений) перезагружаю (то, что в данный момент можно) — чтобы убедиться, что после старта система не требует обслуживания.

Поэтому я ради профилактики иногда (после изменений) перезагружаю (то, что в данный момент можно) — чтобы убедиться, что после старта система не требует обслуживания.

Вот здесь я вас полностью поддерживаю, при серьезных изменениях и возможности всегда бутаю. По молодости не раз на грабли наступал когда командами что-то по наменяешь - работает, а после ребута неа и главное через полгода уже тяжело вспомнить что именно ты тогда делал.
ЗЫ Эх вспомнилось, вот были же времена когда усе в памяти помещалось, у мну так один вэб сервер на полторы html-ны полгода проработал с отъехавшим хардом, узнали только когда емнип понадобилось страничку поправить :)