Смотреть со звуком
И подумать: "А что я сделал для того, чтобы сохранить красоту этой планеты?"
Нотатки про Linux та корисні поради для системних адміністраторів
Смотреть со звуком
И подумать: "А что я сделал для того, чтобы сохранить красоту этой планеты?"
Posted in Misc.
rev="post-1201" 2 коментарі
– 23.04.2011
Когда возникает необходимость перенести какой-нибудь сервис с одного сервера на другой, иногда бывает сложно (или даже невозможно) сразу быстро переконфигурировать клиентов, работающих с этим сервисом, на использование нового IP-адреса. Эту проблему, конечно, проще всего было бы решить переносом старого IP-адреса на новый сервер, но если на старом сервере этот IP-адрес используется еще каким-нибудь другим сервисом, то данное решение не подходит. Поэтому в таком контексте часто возникает задача проброса портов, когда на старом сервере мы просто перенаправялем клиентов на новый сервер прозрачно и незаметно для последних. Один из вариантов решения такой задачи --- использование xinetd (extended Internet services daemon).
Пусть, для примера, у нового сервера будет IP-адрес 10.10.10.18, тогда конфиг xinetd будет примерно такой:
service redir8182
{
disable = no
type = UNLISTED
socket_type = stream
wait = no
user = nobody
group = nobody
protocol = tcp
port = 8182
redirect = 10.10.10.18 80
per_source = UNLIMITED
instances = UNLIMITED
cps = 10000 1
}
Это всё записываем в файл с именем redir8182 и кладём в директорию /etc/xinetd.d. В 3-ей строке мы говорим, что данный сервис активирован. В 4-й строке говорим, что данный сервис не является общеизвестным и не упоминается в файле /etc/services, следовательно xinetd не будет там его искать. Если опустить эту строку, то следует убедиться, что в файле /etc/services для нашего сервиса (redir8182) существует запись с указанием номера порта и при отсутствии такой записи добавить её. В 5-ой строке стоит stream, потому что сервис работает по протоколу TCP (для UDP следовало бы поставить dgram). В 6-ой строке указываем, что сервис является многопоточным (multi-threaded), то есть xinetd не будет ожидать завершения обработки n-го запроса, прежде, чем приступить к обработке (n+1)-го. В 7,8 строках указываем uid и gid порождаемых новыми подключениями процессов xinetd. Далее указываем протокол и порт, который слушает xinetd. В 11-ой строке указываем, что запросы нужно перенаправлять на хост 10.10.10.18 на порт 80. Последние 3 строки не обязательны, но они нужны для случаев, когда интенсивность запросов довольно велика и мы не хотим, чтобы xinetd стал узким местом (например, если пробрасываем порт mysql-сервера, который обслуживает сайт с посещаемостью в несколько тысяч хостов в минуту). Если их не указать, то будут использоваться значения по-умолчанию, указанные в xinetd.conf, которые могут быть совсем далеки от того, что мы ожидаем получить. Например, в случае с CentOS 5.5 настройки по-умолчанию (живут в /etc/xinetd.conf) такие:
cps = 50 10
instances = 50
per_source = 10
То есть к сервису разрешено не более 50-ти подключений в секунду (строка 1) (в случае превышения сервис временно отключается на 10 секунд), количество одновременных подключений --- не более 50-ти (строка 2) и с одного IP-адреса не более 10-ти одновременных подключений (строка 3).
О своей работе xinetd обычно пишет в /var/log/messages (и туда же пишет об ошибках в конфиге, если таковые имеются). Чтобы заставить его перечитать кофиг, следует послать ему сигнал SIGHUP. Также проброс портов можно построить с помощью iptables.
rev="post-1194" 1 comment
– 27.03.2011
Пособие для начинающих сотрудников суппорта датацентров. При необходимости перезагрузить сервер делать это следует в таком порядке:
Действия из пункта 3 имеет смысл пробовать только если в файле /etc/sysctl.conf имеется строчка
kernel.sysrq = 1
Именно такой порядок действий обусловлен тем, что при перезагрузке по питанию не происходит корректного завершения работы приложений, сохранения данных из оперативной памяти на диски, что часто приводит к нарушению целостности файловых систем, повреждению таблиц баз данных и прочим неприятностям, вплоть до неработоспособности сервера из-за невозможности загрузиться в штатном режиме. Поэтому перезагрузку по питанию следует использовать только в крайнем случае, когда других возможностей нет. Подробнее про sysrq можно почитать в википедии или
здесь.
Если известно, что одна или более файловых систем не находятся в состоянии clean (проверить можно командой dumpe2fs -h) и хочется избежать их автоматической проверки при следующей загрузке (что может занять даже несколько часов), следует сделать так:
touch /fastboot
Очень полезно для минимизации downtime сервера. После команды reboot или аналогичной на консоли появится сообщение "On the next boot fsck will be skipped". Проверялось на дистрибутиве CentOS. Файл /fastboot автоматически удалится при следующей загрузке ОС.
UPDATE от 2020-11-30. В CentOS 7 c systemd уже не работает магия с "touch /forcefsck" и dumpe2fs -c 1 (как было в более ранних версиях). При необходимости сделать принудительную проверку корневой файловой системы при следующей загрузке нужно добавить в параметры ядра fsck.mode=force (причем если файловая система содержит ошибки, с высокой вероятностью может еще понадобится и fsck.repair=yes).
Признаком того, что нужно добавить fsck.repair=yes, является наличие в логе вот такого:
Nov 30 10:46:29 srv.dom.com systemd-fsck[444]: sys: Inodes that were part of a corrupted orphan linked list found. Nov 30 10:46:29 srv.dom.com systemd-fsck[444]: sys: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Nov 30 10:46:29 srv.dom.com systemd-fsck[444]: (i.e., without -a or -p options) Nov 30 10:46:29 srv.dom.com systemd-fsck[444]: fsck failed with error code 4. Nov 30 10:46:29 srv.dom.com systemd-fsck[444]: Running request emergency.target/start/replace
Параметры ядра менять удобнее всего в файле /etc/sysconfig/grub, после редактирования которого следует выполнить команду
grub2-mkconfig -o /boot/grub2/grub.cfg
(если не используется UEFI). В последствии, после успешной загрузки узнать как всё прошло у fsck можно командой
journalctl --boot | grep systemd-fsck
Ну и дополнительно убедиться, что проверка таки состоялась, ещё можно с помощью dumpe2fs:
dumpe2fs -h /dev/sda2 | grep 'Last checked:' dumpe2fs 1.42.9 (28-Dec-2013) Last checked: Mon Nov 30 10:55:44 2020
rev="post-1190" 1 comment
– 08.03.2011
Адрес получателя нужно писать в правом нижнем углу, адрес отправителя – в левом верхнем углу конверта.
|
Порядок оформления адреса
Примеры:
А теперь немного offtopic-а :)
Posted in Misc.
rev="post-1188" No comments
– 08.03.2011