LINUX.ORG.RU

Администрирование Linux на лету


0

0

Одной из основных причин, по которой компании запускают UNIX сервера, является их стабильность. При аккуратном администрировании такой сервер не приходится перезапускать в течение очень долгого времени. Более того, выполнение администраторских задач, даже на уровне ядра, может выполняться на лету, сохраняя стабильность сервера. Вам может понадобиться перезапустить сервер при апгрейде оборудования или если кто-нибудь оборвет питающий провод, однако большую часть администрирования можно выполнять без этого. Эта статья включает подсказки и советы для выполнения различных административных задач и изменения вашей системы без перезагрузки.

>>> Подробности

★★★

Проверено: Pi ()

Re: Администрирование Linux на лету

"The Web site cannot be found" Хм...

Ip0 ★★★★ ()

Re: Администрирование Linux на лету

Статья действительно хорошая и хорошо оформлена - будет что по дороге домой почитать)

Ip0 ★★★★ ()

Re: Администрирование Linux на лету

Америку открыли. Может быть полезно разве что новичкам: принять к сведению, что есть такая вещь sysctl.

const86 ★★★★★ ()

Re: Администрирование Linux на лету

ibm молодцы!

webster ()

Re: Администрирование Linux на лету

Еще бы про kexec написали.

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

Один вопрос не совсем в тему по поводу безопасности: есть ли какой-то способ при загрузке, пока не начали исполняться юзерские кронтабы, указать где-то в /proc порты свыше 1024, которые также нельзя занимать? А то, например, если я перезапускаю PostgreSQL, который как известно на 5432 порту, в маленький промежуток между тем, как сервис остановился и будет заново запущен, кто-то из юзеров может спокойно запустить свою службу на этом порту. Я конечно понимаю, что для локальных подключений лучше использовать UNIX-сокеты, а для удаленных - SSL, но все же неприятно, если у тебя порт на твоей машине уведут.

true ()

Re: Администрирование Linux на лету

>Администрирование Linux на лету

с КПК в руке с 50 этажа

>или если кто-нибудь оборвет питающий провод

речь об админке для зоопарка?

anonymous ()

Re: Администрирование Linux на лету

>Файловая система /proc - это одна из величайших особенностей Linux

Ужос. Вызывающе неверная, да?

paul7 ()
Ответ на: Re: Администрирование Linux на лету от true

Re: Администрирование Linux на лету

В сисцтл есть параметр, который говорит, с какого порта надо открывать исходящие коннекты. А если ты хочешь запретить биндиться на порты 1024+, то ИМХО в морг

А статья меня расстроила :( я думал там что-то умное напишут :(((

Sabitov ()
Ответ на: Re: Администрирование Linux на лету от true

Re: Администрирование Linux на лету

Напиши рулезы iptables чтоб пакеты на 5432 порт уходили на порт < 1024 (ну и обратное правило) и вешай на этот порт PostrgeSQL :)

WFrag ★★★★ ()

Re: Администрирование Linux на лету

Я уже в который раз захожу по ссылкам на сайт IBM и обнаруживаю статьи на таком русском который я читать просто не могу. Было бы очень неплохо указывать и ссылку на неизвращенную версию на английском языке.

anonymous ()
Ответ на: Re: Администрирование Linux на лету от paul7

Re: Администрирование Linux на лету

>> Файловая система /proc - это одна из величайших особенностей Linux

> Ужос. Вызывающе неверная, да?

Linux, конечно, не единственный и не первый, где появился /proc, но все же это одна из особенностей, не везде он есть :)

stassats ★★★★ ()
Ответ на: Re: Администрирование Linux на лету от true

Re: Администрирование Linux на лету

> указать где-то в /proc порты свыше 1024, которые также нельзя занимать?
Попробуйте посмотреть в сторону accessfs:
http://www.olafdietsche.de/linux/accessfs/

По-моему там при конфигурации ядра можно вручную задать диапазон портов, для которых можно будет выставлять ограничения.

spirit ★★★★★ ()

Re: Администрирование Linux на лету

мой моск сломалсо на этом предложении:

> Значения по умолчанию нет и оно может быть, а может и не быть установлено.

anonymous ()

Re: Администрирование Linux на лету

ух ты, на IBM перевели статью 4-х летней давности

Adjkru ★★★★★ ()

Re: Администрирование Linux на лету

какой-то ibm.org.ru последнее время...

anonymous ()
Ответ на: Re: Администрирование Linux на лету от anonymous

Re: Администрирование Linux на лету

> статьи на таком русском который я читать просто не могу

Согласен. Статья полезная, а читать не хочется. Из чистого любопытства: можно узнать, кто переводчик? Обычно у ИБМ переводы на русский делают профессионалы, а тут переводчик не указан, а владение русским на уровне "идя на работу, у меня украли деньги"... После статьи есть форма, где можно добавить отзыв о статье. Я было собрался написать пару слов о качестве перевода, а потом раздумал, вдруг парня уволят.

mokhin ()
Ответ на: Re: Администрирование Linux на лету от Adjkru

Re: Администрирование Linux на лету

> ух ты, на IBM перевели статью 4-х летней давности

IBM-овцы открыли для себя ПРОМТ. Лучше позже, чем никогда.

anonymous ()

Re: Администрирование Linux на лету

Чем вам язык не понравился? Короткие предложения, никаких не нужных заплывов в высокие материи и всё по сути темы. Короче, мне статья понравилась, хоть и нифига в ней не понял. :(

anonymous ()
Ответ на: Re: Администрирование Linux на лету от true

Re: Администрирование Linux на лету

>> Есть одна проблема: если делать обновление пакетов по крону, демоны автоматически не перезапускаются. Так что если в апаче дырку исправили автоматом, перегрузить сервис придется вручную
почему ? всё зависит от постинсталл скриптов :)

>> а для удаленных - SSL, но все же неприятно, если у тебя порт на твоей машине уведут.
когда дело доходит до удаленных соединений БД - обычно
1) на машине с sql таких пользователей нет, так как там только sql :)
2) это обычно вполне себе trusted сеть и ssl там смысла не имеет, зачем лишний оверхед, к тому же если это не туннель, то стоимость установки соединения становится объективно немаленькой

хотя конечно совершенно разные бывают ситуации :)

proforg ()
Ответ на: Re: Администрирование Linux на лету от proforg

Re: Администрирование Linux на лету

>почему ? всё зависит от постинсталл скриптов :)

А в каких дистрах туда прописан перезапуск служб, желательно без разрыва текущих соединений?

>на машине с sql таких пользователей нет, так как там только sql :)

Не везде есть достаточная нагрузка, чтобы держать базу отдельно.

>это обычно вполне себе trusted сеть и ssl там смысла не имеет

Trusted сеть является таковой до тех пор, пока на всех машинах в сети админский доступ имеешь только ты, а другой человек подключиться к свитчу не может. При несоблюдении этих условий нужен SSL.

true ()
Ответ на: Re: Администрирование Linux на лету от true

Re: Администрирование Linux на лету

>> А в каких дистрах туда прописан перезапуск служб, желательно без разрыва текущих соединений?
по моему везде
в debian точно :)

без разырыва соединений - если это поддерживаеццо самим сервисом
из примеров - nginx, апгрейд пакета выполняется именно так

>> Trusted сеть является таковой до тех пор, пока на всех машинах в сети админский доступ имеешь только ты, а другой человек подключиться к свитчу не может. При несоблюдении этих условий нужен SSL.
не спорю, но тут главное с водой не выплеснуть ребёнка :)
зачастую прощще обеспечить это на уровне административных мер

proforg ()
Ответ на: Re: Администрирование Linux на лету от true

Re: Администрирование Linux на лету

>apt-get upgrade squid

Как вы думаете, что выполнит процитированная команда?

>ждет пару минут, пока сквид перезапустится?

Если он его рестартует при апгрейде, то да, будет ждать. А в чем проблема-то собственно? Если надо -- подождет, кому от этого хуже станет? В конце-концов, если на stable ветке делать апгрейд пакетов каждый день по крону, то кол-во обновляемых пакетов в среднем будет близко к нулю. Далеко не каждый день находят критические уязвимости/серьезные баги в сервисах, установленных на данной конкретной машине.

kvit ()

Re: Администрирование Linux на лету

Почитал статью, так и не понял, как менять ядро не перезагружаясь.

низачет!

GQ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.