19 заметок с тегом

Troubleshooting

Ctrl + ↑ Позднее

Отладка с помощью WinDbg

31 июля 2013, 11:36

По наводке с Хабра нашёл интересный бложик: http://kate-butenko.blogspot.ru/

Там рассказывается о простых приёмах поиска причин разного рода проблем, вроде блокировок ресурсов, высокой загрузки процессора, утечек памяти, а также про анализ аварийных дампов.

Troubleshooting   Windows

Хранение серверных конфигов в SVN

13 декабря 2012, 17:11

Настраивал хранение freebsd-шных конфигов в SVN. Обнаружилось небольшое западло. Маааленькое такое. В результате которого если ты закрыл консоль, то больше к серваку не подключишься :-)

Причиной является то, что при операции svn commit после добавления всех конфигов в репозиторий, svn делает меняет права на конфигурационные файлы. В частности, добавляет права на чтение для ssh-ключей хоста сервера. Вот для этих файлов, иными словами: /etc/ssh_host_dsa_key, /etc/ssh_host_rsa_key и /etc/ssh_host_ecdsa_key. После чего система отказывается принимать новые соединения по ssh, мотивируя это тем, что:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_rsa_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_rsa_key
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_dsa_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_ecdsa_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key

И если своевременно не принять меры по устранению и недопущению, может получиться казус. Пока ssh-консоль открыта, есть некоторый шанс. Нужно вернуть права на ключи обратно, запретив чтение группе и другим. А в идеале — вернуть вообще все уехавшие права с файлов каталога /etc и всех подкаталогов, так как модификации прав подверглись все файлы.

Сделать это можно, воспользовавшись силой данного нам природой мозга и утилитой freebsd-update. У неё есть параметр IDS, который ревизует систему на предмет соответствия прав, структур каталогов и хэшей системных файлов тем, которые должны быть в системе искаропки. Нам же нужны только права доступа на файлы, а на хэши на текущем историческом этапе чхать. Поэтому делаем раз:

server# freebsd-update IDS | awk '/permissions/{ print $8" "$1 }' | xargs -t -L 1 chmod

Утиля долго думает, сверяется с Большим Братом в интернетах, а затем начинает генерировать отчёт, в котором английском по чёрному написано, на каком файле какие права стоят, а какие должны быть. Аккуратно выкусываем awk'ом строчки со словом permissions, который также извлекает 8 и 1 колонки (это права и имя файла соответственно), а утиля xargs доделывает всё остальное, вызывая chmod и подставляя ему результат работы предыдущего конвейера. В итоге эта команда проходится по всем файлам в каталоге /etc, возвращая им правильные права.

Стоит также отметить, что в /usr/local/etc/, которые я тоже сложил в SVN, права тоже поедут. Но там менее критично всё это, по крайней мере, не приведёт к потере управления удалённым сервером. А в идеале, надо делать отчёт с помощью утилиты mtree по правам доступа всех файлов, а после svn add / svn commit возвращать их с помощью этой же mtree обратно. Потому как после каждого commit'a права на закоммиченные файлы будут приводиться в соответствие с umask. Наверное, в идеале стоит написать какую-то обёртку для svn commit, которая будет затем возвращать права на файлы обратно. Либо пойти по пути asvn и реализовать хранение разрешений для файла в репозитории с помощью properties, а при коммите их перечитывать и делать chmod на файлы. А то западло получается...

FreeBSD   Subversion   Tips&Tricks   Troubleshooting

Бьётся файл при передаче по http

23 октября 2012, 20:51
Мерял тут скорость внутри конторских VPN-каналов, путём передачи 100-мегабайтного файла по http, с Apache22 на FreeBSD. Обнаружил необъяснимое — при передаче файла на винду качается кусок файла случайного размера (от 2.5 до 18 мегабайт) и потом передача рвётся. Клиент считает, что файл скачан полностью, в логах апача никаких ошибок. При этом перед началом закачки размер файла определяется правильно.

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

[Thu Sep 27 12:31:48 2012] [info] [client 10.0.7.1] (12)Cannot allocate memory: core_output_filter: writing data to the network

Беглый поиск привёл на сайт Apache, где нашёлся такой текст:

Invalid argument: core_output_filter: writing data to the network
Apache uses the sendfile syscall on platforms where it is available in order to speed sending of responses. Unfortunately, on some systems, Apache will detect the presence of sendfile at compile-time, even when it does not work properly. This happens most frequently when using network or other non-standard file-system.

Symptoms of this problem include the above message in the error log and zero-length responses to non-zero-sized files. The problem generally occurs only for static files, since dynamic content usually does not make use of sendfile.

To fix this problem, simply use the EnableSendfile directive to disable sendfile for all or part of your server. Also see the EnableMMAP, which can help with similar problems.


Что в переводе означает, что Apache используется системный вызов sendfile на тех платформах, где он доступен, чтобы увеличить скорость ответа клиенту. К сожалению, на некоторых система апач определяет наличие этого вызова во время компиляции (т. е. сборки самого апача) даже если этот вызов в системе реально не работает надлежащим образом. Обычно это происходит при использовании сетевых или иных нестандартных файловых систем. Симптомы этой проблемы включают в себя вышеприведённый текст в логах и нулевой ответ на запрос файлов ненулевой длины. Проблема обычно возникает при передаче статических файлов, динамический контент не использует sendfile. Чтобы решить эту проблему, используйте директиву EnableSendfile, чтобы выключить использование вызова SendFile. Также почитайте про EnableMMAP, которая может помочь при сходных проблемах.

Выключил в итоге в конфиге апача EnableSendfile и EnableMMAP. Это помогло, но осадочек остался... Потому как файло лежит на обычном локальном разделе диска. Или UFS считается для апача недостаточно стандартной?

СМС-оповещения

13 апреля 2012, 13:12
У нас на фре трудится система мониторинга Zabbix. Обо всяких критических события, типа пропадания питания или неожиданной перезагрузки серверов хотелось бы, чтобы оповещения приходили на СМС заинтересованным лицам. Выкопал я у товарища старый бесхозный мобильник Motorola L6 и вознамерился его использовать. Чтобы не искать кабель, который, как водится, может ещё и не подойти, решил его сразу по bluetooth подключить. Долго курил мануалы, прописывал ключи и включал автоматический доступ на Мотороле с компа, чтобы она не запрашивала каждый раз подверждение. Вроде заработало. Написал скрипт для автоматического запуска rfcomm_sppd, которая создавала виртуальный COM-порт через bluetooth, через который, в свою очередь, комплект smstools отправлял сообщения.

Тока вот этот виртуальный COM-порт, через который работал rfcomm_sppd, постоянно отваливался. И каждый раз требовался танец с бубном, чтобы всё это опять заработало, причём каждый раз я не мог понять, почему такие же действия две минуты назад никакого эффекта не давали. Удалось выяснить, что выключение/включение голубого зуба на телефоне позволяло в течение пары минут запустить скрипт и тогда порт появлялся. Но сегодня не помогло даже это. Руками запускаю rfcomm_sppd с нужными ключами — порт есть. Делаю то же самое скриптом — connection refused. В конце концов меня это задрало.

Я с горя взял обычный провод USB-miniUSB, оставшийся от павшего смертью храбрых внешнего HDD, и подключил им телефон к серваку с FreeBSD. Оценил обстановку в логах. Обстановка гласила:

Apr 13 12:25:11 proxy root: Unknown USB device: vendor 0x22b8 product 0x4902 bus uhub2
Apr 13 12:25:11 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2
Apr 13 12:32:57 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2 (disconnected)
Apr 13 12:33:05 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2
Apr 13 12:33:05 proxy root: Unknown USB device: vendor 0x22b8 product 0x4902 bus uhub2


Попандос, думаю — ugen2.3. Это значит, что фря устройство видит, но как с ним работать — не знает, драйвера нет. Полазил по интернетам. Рекомендуют запускать модуль ucom. Ок, пробуем:

# kldload ucom
kldload: can't load ucom: No such file or directory


Нету модуля, значит. Та же петрушка с рекомендованным модулем umodem. Лезем сначала в /usr/src/sys/modules/usb/ucom, и делаем там
# make
# make install clean


Потом то же самое в каталоге /usr/src/sys/modules/usb/umodem

Потом грузим модули:
# kldload ucom
# kldload umodem


Перетыкаем кабель в телефоне, палим логи:

Apr 13 12:46:38 proxy kernel: ugen2.2: <Motorola Inc.> at usbus2
Apr 13 12:46:38 proxy kernel: umodem0: <Motorola Inc. Motorola Phone (L6), class 2/0, rev 1.10/0.01, addr 2> on usbus2
Apr 13 12:46:38 proxy kernel: umodem0: data interface 1, has CM over data, has no break
Apr 13 12:46:38 proxy kernel: ugen2.2: <Motorola Inc.> at usbus2 (disconnected)
Apr 13 12:46:38 proxy kernel: umodem0: at uhub2, port 1, addr 2 (disconnected)
Apr 13 12:48:01 proxy kernel: ugen2.2: <Motorola Inc.> at usbus2
Apr 13 12:48:01 proxy kernel: umodem0: <Motorola Communication Interface> on usbus2
Apr 13 12:48:01 proxy kernel: umodem0: data interface 1, has CM over data, has no break


Ну круто, umodem нашёл телефон. В системе появился порт /dev/cuaU0 (не путать с COM1, который /dev/cuau0 — разница в регистре в имени). Это и есть искомый COM-порт для коммуникации с телефоном. Прописываем его в конфиге демона smsd из комплекта smstools, и получаем щастье! И никаких хитрых процедур и скриптов запуска по голубому зубу. Остаётся только прописать загрузку этих двух модулей в /boot/loader.conf, чтобы оно автоматом грузилось при старте системы.
Bluetooth   FreeBSD   Troubleshooting   Zabbix

Настройка MikroTik под Корбину

19 января 2011, 15:40
Поскольку грёбаная корбина извращённо создаёт pptp/l2tp соединения, с настройкой их интернета НЕ под виндой перманентно возникают грабли. Из-за того, что корбина в качестве дальнего конца туннеля подставляет адрес их VPN-сервера, каковой и делается шлюзом по умолчанию, то при подъёме туннеля пакеты VPN пытаются идти не по локалке, как должны, а внутри самого туннеля. Из-за этого соединение рвётся. Я с этим научился бороться на FreeBSD с помощью статических маршрутов к VPN-серверам и правки на ходу шлюза по умолчанию после подъёма соединения.

В конторе купили маршрутизаторы MikroTik RB750. Мега-вещь, кстати. И надо их как-то настроить, чтобы они раздавали интернет корбиновский в офисе. Но сходу фокус не прокатил, в силу описанных выше причин. Поиск по интернету привёл к очень толковой методичке, разработанной неким ООО «Виджет-Про». За что выражаю им благодарность перед строем с занесением в карму.

От себя добавлю, что нужно также в настройках dhcp-клиента на WAN-интерфейсе убрать галку «Add default route», иначе в системе получалось два машрута по умолчанию, и хотя VPN не отваливался, но интернета всё равно не было.

Ошибка при обращении к компу по SMB, указав его DNS-псевдоним, а не NetBIOS-имя

28 апреля 2010, 23:26
Создаём в DNS псевдоним mega-comp.domain.tld для компьютера \\comp, пишем в командной строке: ping mega-comp.domain.tld и видим, что всё чотко пингуется. Затем пытаемся обратиться к нему по NetBIOS: \\mega-comp.domain.tld, и получаем облом в виде сообщения: «Не удалось подключиться к сети из-за существования совпадающих имен. Измените имя компьютера на Панели управления и повторите попытку

Это официальная бага, признана Microsoft'ом, и они божатся, что исправили её ещё начиная в Win2k SP3. Однако эти грабли всплыли и на сервере с Win2k8. Лечится прописыванием у компа \\comp в реестре следующего параметра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\DisableStrictNameChecking=1


Если параметра нет, его нужно создать.

После этого можно перезагрузить сервер, ну или перезапустить службы «Сервер» и «Рабочая станция».
2008   Tips&Tricks   Troubleshooting   Windows

CryptoPro и ошибка c000021a

11 октября 2009, 21:54
Клиент поведал страшную историю про то, как к кабелю от мобильника с разъмом mini-USB попытались подключить флэшку. У него там два кабеля торчало — USB-удлинитель и этот самый кабель от мобильника, и девачка-бухгалтер их перепутала и вместо удлинителя попыталась вонзить mini-USB в разъём флэшки. Винда сказала «Кря!», а может даже и «Гав!», и повисла. После перезагрузки все увидели красивый синий экран с надписью:

STOP: c000021a { ****
Windows Logon Process ****

0x0000005 (0x000000000x00000000)


Там где звездочки — непечатное. Не в смысле матерное, а в смысле кодировка битая :-) При этом в безопасном режиме винда грузилась.

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

Ну то есть, понятно было, что падает winlogon.exe, и что падает он из-за сбоя в каком-то драйвере или библиотеке, которые он пытается всосать при загрузке. Но каком? Это вопрос.

В результате выяснилось, что виной всему драйвер КриптоПро — CProCtrl. Отключение его посредством загрузки в безопасном режиме и выносом этого драйвера из системы с помощью Autoruns от Руссиновича дало совершенно магический эффект — винда стала грузиться в нормальном виде.

Что снесло крышу до этого нормально работавшему драйверу — вопрос архи-тёмный. На этот счёт существуют разные мнения. Тут вот перечислены некоторые из них. Часть камрадов предполагает, что оно конфликтует с NOD32, часть утверждает, что на томах FAT32 драйвер КриптоПро без SP3 не работает. Я разбираться особо не стал, времени-то уже 4-ый час утра. Поэтому вынес NOD32, всё равно он не обновлялся, и сконвертил диски в NTFS, затем вернул предварительно экспортированную ветку с параметрами драйвера в реестр обратно. Всё заработало. Хотя это архи-странно, факт.
Tips&Tricks   Troubleshooting   Windows   XP

Установка XP на ноут без CD и дисковода

20 апреля 2009, 21:54
Попросил меня один товарищ переставить ему винду на ноуте. У него английская стоит, а английского он не знает. Ноут — HP Omnibook 500. Теоретически, привод и флопик в этом ноуте есть, но в док-станции. Отдельно ноут и док-станция работают, а вместе — хрен, ноут не запускается, будучи подключенным к док-станции.

Городить огород с загрузкой по сети или ещё чем-нибудь подобным мне не хотелось (и, блин, совершенно напрасно, как показали дальнейшие события!), поэтому я решил по-быстрому всё сделать — вытащить винт из этого ноута, и поставить в свой ровер, отформатировать там всё, начать инсталляцию винды, а после текстовой фазы установки переткнуть винт обратно.

Дальше под катом Сказано — сделано. Вынимаю винты из обоих ноутов, ставлю винт из омнибука к себе. Загружаюсь с BartPE, размечаю акронисом диск, перезагружаюсь с установочного компакта русской XP, прохожу текстовый этап установки, при перезагрузке проверяю, что всё путём и инсталляция пойдёт дальше, жму Ctrl-Alt-Del, выключаю ноут, вынимаю из него винт и ставлю винт на родину — в омнибук. Включаю омнибук и получаю БОЛЬШОЙ БОЛТ! На омнибуке инсталлятор винды не грузится.

И тут началось нетрадиционное порно с элементами BDSM и скотоложества... Что я только не делал. Форматировал этот винт в FAT16, FAT32, создавал разные конфигурации разделов и файловых систем. Везде было одно и то же — пока винт загрузочный в MS DOS — с него омнибук грузится. Копирую инсталлятор винды, запускаю его из ДОСа прямо на омнибуке, инсталляция проходит первый этап копирования файлов, после перезагрузки получаем БОЛТ. Либо омнибук глухо зависает без всяких сообщений, лиоб NTLDR is missing.

Капец, как я там извращался. Винт между ноутами за всё время порева я переставил раз не менее 50, снося разделы и создавая их заново. Смеха ради даже создавал разделы с помощью FreeBSD. Вот кстати фря стала и запустилась на омнибуке без вопросов, у меня уже начала появляться мысль, что товарищу будет проще освоить KDE, чем мне поставить ему на ноут винду... :-) Протрахался, короче, с 10 утра воскресенья до 3 ночи понедельника. Результат нулевой.

Наутро встал, почитал, что на мой вопрос по этому поводу пишут в ЖЖ. Ничего путного не обнаружил. Стал думать.

В общем, вскрытие показало, что больной умер от вскрытия, омнибук криво определяет CHS-геометрию своего винта. Ну, не то, чтобы совсем криво — сама по себе предлагаемая им конфигурация CHS вполне рабочая, но она не такая, какая написана на винте, хотя размер винта при такой геометрии совпадает с правильной. А мой ноут определяет конфигурацию правильно, в полном соответствии с тем, что указано на лейбле на самом винте. И форматирует разделы исходя из своей правильно геометрии. Пока мы в ДОСе — это особой роли не играет. Но как только на этапе первой перезагрузки управление передаётся загрузочному сектору виндового инсталлятора BOOTSECT.DAT, ему сносит крышу, и он либо виснет, либо жалуется, что не может найти ntldr, хотя он железно лежит в корне диска C:, где ему и положено быть.

Выставление прямой геометрии вручную в БИОСе омнибука не дают ничего — он виснет наглухо даже при попытке грузануть DOS. Понять, что грабли связаны с тем, какую геометрию пытается подсунуть винту ноут, я смог только тогда, когда настроил сетевую загрузку через PXE и попытался загрузить омнибук с нескольких своих ремонтных образов дискет. Так вот, при любых параметрах, даже самых прямых, но отличающихся от «Auto» при загрузке DOS омнибук вис даже при загрузке через сеть. И выводилась интересная надпись: Int13 08 failed. Не помню, что за функция 08, но судя по всему, с прямой геометрией этот BIOS работать не будет.

В итоге я выставил определение винта в «Auto», сделал дискету с Partition Magic 8, загрузил омнибук по сети, разбил PM винт, отформатировал на самом омнибуке с его кривым биосом, криво определяющим геометрию, потом переставил винт на свой ноут, переписал инсталлятор XP на винт, вернул винт обратно и загрузившись ещё раз по сетке с чистым DOS'ом и smartdrive'ом, запустил установку XP. Файлы копируются, первая перезагрузка, затаили дыхание... И о чудо! Оно грузится и продолжает установку, ссучара бацильная, скока крови попил! Вот так человеческий разум в очередной раз победил бездушную технику :-)
Troubleshooting   Windows   XP   Железо

При обновлении XP не устанавливается IE7

5 апреля 2009, 11:21
Обновлял тут у одного клиента XP через интернет. Всё вроде прошло успешно, затем последним шагом качается IE7, начинает ставиться и... получает облом. «Не удалось установить обновление такое-то». Код ошибки, который при этом выдаётся, ничего вразумительного не дал, кроме того, что удалось найти статью в Microsoft KB, которая помимо совершенно бесполезных сведений содержала информацию о том, что в процессе установки и обновления ведётся более подробный лог. Который, в случае IE7, лежит в \Windows\ie7_main.log.

Изучение этого лога выявило ошибку:

INFO: Installer Process exit code: 0x000003f5

Вот поиск по коду ошибки 0x000003f5 принёс гораздо больше. Нашлись сведения, что так пагубно на систему может повлиять установка Adobe Acrobat 9. Удаление акробата и зачистка реестра в ветках HKLM/Software/Adobe и HKCU/Software/Adobe, с последующей перезагрузкой помогли — IE7 нормально установился.
Troubleshooting   Windows   XP