О необходимости тестирования памяти

До недавнего времени верил, что для проверки планки памяти на живучесть достаточно один раз прогнать memtest86+ и можно ставить. Вот только после установки двух планок памяти (по гигу каждая) в комп, он начал спонтанно перезагружаться с завидной частотой.
Вернул старые планки (по 512MB) и все заработало как раньше. Две новые поставил на стенд и запустил memtest на бесконечное тестирование. После одного прогона нашло одну ошибку при битовых операциях. Решил поменять планки местами. До ухода домой успело проверить два раза и не нашло ни одной ошибки - оставил на ночь. Утром из девяти повторений теста нашло две ошибки в процессе выполнения третьего.
Вот сейчас сижу и думаю, что может быть причиной "плавающей" ошибки при работе с памятью. На перегрев не похоже - стенд стоит без корпуса и прекрасно охлаждается. Возможно память глючит на максимальной частоте, но в компе, где она приводила к ребутам, планки работали на пониженной частоте (планки A-Data DDR400, работали как DDR333).

Восстановление битого раздела

Начало истории тут
В субботу вечером остановил все, что использует битый раздел. Потом создал образ с тома LVM и загрузил на отдельную машинку.

root@server # dd if=/dev/vg/badlv of=/mnt/tmp/badlv.bin bs=8M
root@server # smbclient -N //rescue/share
> lcd /mnt/tmp
> put badlv.bin

Там раздел монтировался через loop в read-only режиме.

root@rescue # mount -o ro,acl,loop /mnt/share/badlv.bin /mnt/tmp

На сервере создал раздел с XFS того же размера и запустил rsync с примонтированного образа на сервер.

root@server # lvcreate -n newlv -L50G vg
root@server # mkfs.xfs /dev/vg/newlv
root@server # mount /dev/vg/newlv /mnt/repaired
root@rescue # rsync -aAz /mnt/tmp/ server:/mnt/repaired

Утром в воскресенье меня ждала пачка сообщений о том, что на новом разделе XFS закончилось место и копирование накрылось медным тазом. Перед повторным запуском добавил 20GB к емкости раздела и расширил том и снова запустил rsync.

root@server # lvresize -L+20G /dev/vg/newlv
root@server # xfs_growfs /mnt/repaired

На этот раз копирование заняло все воскресенье и часть ночи понедельника, но данные успешно перенеслись, за исключением пары битых атрибутов ACL (скорее всего попытка их чтения на сервере и приводила к kernel panic)

Kernel panic debug

На днях отлаженный скрипт бэкапа начал рапортовать об обрыве связи в процессе создания бэкапа. Происходило это в произвольный момент времени ночью.
Очевидно, что сбой вызывал процесс бэкапа, ведь нагрузка на дисковую подсистему создается много большая, чем при штатной работе сервера днём. В пользу сбоев дисковой системы говорил и тот факт, что не было сообщения об ошибке в системных журналах. Т.е. вероятнее всего имею дело с kernel panic. На сервере стоит опция panic=30 - при панике ядра через 30 секунд произойдет автоматическая перезагрузка сервера.
После некоторых раздумий выработал несколько решений:

• Отключить опцию panic=30 и утром посмотреть что за сообщение будет на экране. У этого подхода есть минус, если сообщение окажется больше одного экрана, то не получится его посмотреть целиком.
  
• Собрать null-модемный кабель и загрузить систему с перенаправлением системной консоли в последовательный порт, а для отлова сообщения об ошибке использовать отдельную машину, подключенную к null-модемному кабелю.
  
• Случайно нагуглил еще один подход. Он состоит в загрузке дополнительного модуля netconsole, который выполняет роль null-модемного кабеля через IP сеть. Сообщение передается в UDP пакетах и чтобы его смотреть достаточно использовать netcat.

Выбрал последний подход. Загрузил модуль с параметрами:

modprobe netconsole netconsole="src-port@src-ip/src-iface,dst-port@dst-ip/dst-mac"

У себя на компьютере запустил netcat nc -l -u -p dst-port, где заменил src-/dst- константы на соответствующие параметры. Утром меня ждало сообщение о сбое в модуле reiserfs. Проверка радздела на 70GB заняла более полутора часов, причем мое терпение лопнуло, после начала проверки семантики FS, после проверки BTREE структуры. Впереди еще предстоит починка FS и спасение данных, но мое отношение к reiserfs здорово переменилось, теперь подумываю о миграции на XFS/JFS.
Для себя сделал вывод, что иметь нуль-модемный кабель + свободный COM-порт на соседней машинке - это must-have для любого сисадмина.

Сокрытие версии апача и php в ответе сервера.

Понадобилось скрыть версии апача и php в ответе сервера. С ходу нагуглил решение для апача и php. Себе помечу как памятку.

Apache
ServerTokens ProductOnly
ServerSignature Off

PHP
expose_php = Off

Редактирование SMTP заголовков в postfix

Встала задача удалять часть smtp заголовков из письма, навскидку ничего не предумалось, так что нужный ответ нашел тут. Вкратце:

в /etc/postfix/main.cf пишется

header_checks = regexp:/etc/postfix/header_checks

в /etc/postfix/header_checks пишется

/^Received:.*\[192\.168\.0\.[0-9]/      IGNORE

делается postmap /etc/postfix/header_checks и затем postfix reload

Проверка сертификата FTP сервера.

Довелось проверить валидность сертификата на FTP сервере. Раньше такого не делал, так что полез курить ман по openssl. Получись так:

openssl s_client -connect ftp.site.com:21 -starttls ftp

Вообще отличная дока по практическому применению openssl есть тут

On-Line проверка по урлу.

Понадобился on-line инструмент, чтобы проверять страницу по урлу. Пока нашел только от DrWeb