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

До недавнего времени верил, что для проверки планки памяти на живучесть достаточно один раз прогнать 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

WScript.exe: There is no script engine for file extension ".vbs"

Сегодня устанавливал на одной машинке 3-й сервис пак для винды и наткнулся на проблему с запуском VBS скриптов. У меня есть скриптик, который я когда-то нашел в сети и немного переделал под свои нужды. Этот скрипт понижает приоритет службы "Automatic Windows Updates" до LOW и тем самым избавляет пользователей от тормозов при в первый минут 10 после загрузки компа.

В этой системе файл выглядел как неизвестный и не был ассоциирован с wscript.exe. При попытке выполнить его как wscript.exe wuauserv.vbs выскакивала ошибка, что 'There is no script engine for file extension ".vbs"'

Для решения проблемы нужно найти файлик %WINDIR%\inf\wsh.inf и в контектном меню выбрать "Install". После этого проблемы с запуском .vbs прошли.

Код wuauserv.vbs

Const BELOW_NORMAL = 16384
Const LOW = 64
Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colServices = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_Service where name='wuauserv'")
For Each oService in colServices
    Set colProcesses = objWMIService.ExecQuery( _
        "SELECT * FROM Win32_Process where ProcessId=" & oService.ProcessId )
    For Each oProcess in colProcesses
        ErrCode = oProcess.SetPriority(LOW)
    Next
Next

Проделки yum.

Всегда считал, что софт, считающий себя умнее человека - вреден, сегодня лишний раз убедился в этом.
Вчера несколько часов настраивал почту (postfix + sasl + courier-imap + courier-authlib + mysql) на новом сервере (CentOS 5.4 x86_64). Из коробки такая схема не работает, так что пришлось пересобрать часть пакетов. Провозился часов пять, пока настроил и перенес данные со старого сервера, еще раз проверил хождение почты и пошел домой.
Сегодня с утра решил проверить логи:

postfix/smtpd[14124]: fatal: unsupported dictionary type: mysql
postfix/qmgr[14310]: fatal: unsupported dictionary type: mysql

Полез проверять логи yum - ночью запустилось обновление системы и часть моих пересобранныех пакетов было "обновлено". Вредитель нашелся в заданиях рутового крона, раньше вроде в cron.daily было. Чтобы поправить ситуацию в будущем добавил в /etc/yum.conf

[main]
...
exclude=postfix courier-authlib*

Обновление прошивки NEC Optiarc AD-7170A

Имеется DVD-RW резак NEC Optiarc AD-7170A с прошивкой версии 1.02. Симптомы: читает и пишет CD-R/RW, но редко читает и пишет только избранные DVD-R/RW. Перед тем как выбросить и купить новый (подумываю попробовать резаки от Lite-On), решил попробовать залить в него обновленную фирмварь. Новая прошивка вливается посредством binflash. Все команды выполняются от root. Проверяем что привод поддерживается прошивальщиком

# necflash -scan
Binflash - NEC version - (C) by Liggy and Herrie
Visit http://binflash.cdfreaks.com

List of supported devices:

Device   : /dev/hda
Vendor   : Optiarc
Model    : DVD RW AD-7170A
Firmware : 1.02

Сначала сохраняем старую версию прошивки

# necflash -v -dump old_firmware_1.02.bin /dev/hda

Новую версию прошивки я брал здесь На время заливки лучше включить режим PIO для сидюка

# hdparm -d0 /dev/hda

Теперь заливаем новую версию

# necflash -v -flash 105bt_orig.bin /dev/hda

После прошивки, перезагружаемся и смотрим результат

# necflash -scan
Binflash - NEC version - (C) by Liggy and Herrie
Visit http://binflash.cdfreaks.com

List of supported devices:

Device   : /dev/hda
Vendor   : Optiarc
Model    : DVD RW AD-7170A
Firmware : 1.05

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

ALSA в многопользовательской среде

Дома пришлось создать жене отдельного пользователя, чтобы можно было пользоваться одним и тем же софтом и не мешать друг-другу настройками. Все нормально, но вот только неудобно переключаться на соседний сеанс, чтобы выключить музыку или фильм.
Недавно наткнулся на описание плагина softvol для alsa и решил его использовать. Схема работы проста: для каждого пользователя создается отдельный канал в программной громкостью и все они микшируются через dmix.

~/.asoundrc
pcm.!default {
    type            plug
    slave.pcm       "softvol"
}

pcm.softvol {
    type            softvol
    slave.pcm       "plug:dmix"
    
    control {
        name        "Andrey"
        card        0   
    }   
}

После первого использования появится отдельный канал (чтобы он стал доступен уже запущенным приложениям, их нужно перезапустить). Так выглядит alsamixer при работе двух пользователей:


Настройка канала микшера в приложениях:

~/.mplayer/config
ao=alsa
mixer-channel=Andrey

~/.mpdconf
audio_output {
   type       "alsa"
   device     "default"
}
mixer_type    "alsa"
mixer_device  "default"
mixer_control "Andrey"

Чтобы теперь разом отключить звук у другого пользователя достаточно повесить на хоткей amixer set Ann 0%

Повреждение FS на ядре под openvz

Поднял новый сервер под ALTLinux Server 4.0.1 (x86_64). Получился вполне приличный тазик, хоть и на десктопном железе:

CPU: AMD Phenom II X4 955
RAM: 8Gb DDR3
MB:  ASUS M4A77TD PRO
HDD: 4xSATA2 WDC WD2502ABYS

Не обошлось без ложки дегтя, гигабитная сетевушка побила файлы при передаче (не сошлась md5) - воткнул завалящийся realtek 8139. Для видео выбрал S3 Trio (это который PCI с одним метром оперативы =) ) На ночь поставил переноситься данные со старого сервера.
С утреца ждал неприятный сюрприз, рассыпались почти все файловые системы и процесс копирования данных накрылся медным тазом. После общения с альтовской багзилой и гуглежом, оказалось что я использую языческое ядро (2.6.18-ovz-smp-alt14 и 2.6.18-ovz-smp-alt26.M40.2 - пробовал оба) и мне следует срочно обратиться к использованию сборки с патчами от redhat (2.6.18-ovz-rhel-alt2.M40.4).
Хотя странно, как тогда глючное ядро вообще могло попасть серверный дистрибутив. Насчет изначальной глючности openvz ядер - верить отказываюсь, т.к. имею опыт с дебиановскими ядрами работа которых проблем не вызывает. К альту у меня вообще много претензий последнее время, начиная их недо-инсталятором. (последний раз ставил через графический режим, так вот дойдя в сетевых настройках до многострочного поля ввода (search domains) оттуда нельзя выбраться табом)

P.S. После смены ядра аптайм перевалил за 20 дней - полет нормальный.

Проблемы с сертификатами GoDaddy на Mac Safari

Недавно прислали по работе - под маковским safari не проверяет валидность сертификатов от GoDaddy, выкидывает ошибку вида



Чтобы это исправить, достаточно прописать SSLCertificateChainFile /path/to/gd_bundle.crt в конфиге сервера.

Проверка сертификата:

openssl verify -CAfile gd_bundle.crt -purpose sslserver site.crt

Неплохой Online SSL checker

ASUS M4A77TD PRO

Вчера наткнулся на ошибки при работе нового сервера.

APIC error on CPU0 40(40) - появляется под нагрузкой и может доходить до 300 штук за пол-часа. Помогло обновление ядра до 2.6.27-ovz и установка в BIOS "PNP OS installed - Yes".
После обновление ядра вылезла проблема с hwclock. hwclock --systohc --utc говорил, что /dev/rtc не найден, вместо него есть /dev/rtc0. После hwclock --rtc=/dev/rtc0 --systohc --utc часы обновились нормально.

Мой блог.

Наконец дошли руки, чтобы "привязать" свой домен к blogspot'у. Последние пол-года свободного времени становится все меньше, либо использовать я его стал абы как. Позже перенесу старые заметки и статьи, которые когда-то писал по разношерстным wiki.

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