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

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

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

Для более наглядного удаления/добавления дисков рекомендую использовать http://www.garloff.de/kurt/linux/rescan-scsi-bus.sh

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

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

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

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

ibm молодцы!

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

cтарикам тоже полезно освежить моСк

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оригинал статьи Administer Linux on the fly.

http://www.ibm.com/developerworks/library/l-adfly.html?S_TACT=105AGX99&S_... В конце статьи приводят ссылки на оригинал.

предлогаю заценить програмку для конфигурации параметров ядра

http://sourceforge.net/projects/kerneldigger/

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

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

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

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

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

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

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

Вот штатное решение от FreeBSD: http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/mac-portacl.html

В линухе тоже что-то подобное должно быть.

лутше 2.6 с udev ;-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>в debian точно :)

А apt-get upgrade squid ждет пару минут, пока сквид перезапустится?

>при апгрейде оборудования

http://lingvo.yandex.ru/en?text=upgrade&st_translate=1

>apt-get upgrade squid

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

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

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

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

низачет!