LINUX.ORG.RU

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


0

0

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

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

★★★

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

Ответ на: комментарий от SteepZ

>Все работает.. норм статья, про /proc в 2.4.x

Честное слово не открывалась ссылка>.<

Ip0 ★★★★
()

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

Ip0 ★★★★
()

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

const86 ★★★★★
()
Ответ на: комментарий от const86

спасибо, полезная статься для новичков (меня)

anonymous
()

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

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

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

true
()

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

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

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

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

anonymous
()
Ответ на: комментарий от true

А не давай им открывать прослушивающие сокеты - не холопское это дело.

anonymous
()

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

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

paul7
()
Ответ на: комментарий от true

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

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

Sabitov
()
Ответ на: комментарий от true

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

WFrag ★★★★
()
Ответ на: комментарий от WFrag

Ага, и сервис от рута держать запущенным чтоли? :)

Deleted
()

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

anonymous
()
Ответ на: комментарий от paul7

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

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

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

stassats ★★★★
()
Ответ на: комментарий от true

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

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

spirit ★★★★★
()

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

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

anonymous
()
Ответ на: комментарий от Deleted

лутше 2.6 с udev ;-)

А по статье - там man proc. Низачот.

myhand
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

mokhin
()
Ответ на: комментарий от Adjkru

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

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от true

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

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

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

proforg
()
Ответ на: комментарий от proforg

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

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

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

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

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

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

true
()
Ответ на: комментарий от true

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

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

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

proforg
()
Ответ на: комментарий от true

>apt-get upgrade squid

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

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

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

kvit
()

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

низачет!

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