вторник, 21 февраля 2012 г.

IPMI на Etegro

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

MySQL, падающий каждые 10 сек

Сабж. Неск. битриксовых баз + плесковая. Более менее юзается одна.
Делаешь tail -f лога - там регулярно валится:

120221  9:54:20 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
......
......
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 81536 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x5a0a570
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x40d53fb0, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
(nil)
New value of fp=0x5a0a570 failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...

thd->query at 0x5a48970 = INSERT INTO b_stat_searcher_hit(DATE_HIT, SEARCHER_ID, URL, URL_404, IP, USER_AGENT, HIT_KEEP_DAYS, SITE_ID) VALUES (now(), 2, 'http://www.xxx.ru:80/forum/index.php?print=Y&PAGE_NAME=profile_view&UID=1690', 'N', '66.249.66.68', 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)', null, 's1')
thd->thread_id=2
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Посмотрел - в базе половина таблиц в myisam, половина в innodb. По-дефолту почему-то стоит myisam. Поменял дефолный тип хранилища на иннодб, заальтерил в таблицах движок на иннодб.
Посмотрел по логу - везде фигурирует b_stat_searcher_hit.
Прогнал mysqlcheck - табла рефералов  битая.
В общем, дропнул обе и создал заново, запретив юзерам апдейты при помощи innodb_force_recovery=2.

База падать перестала.

ЗЫ
Собственно, к чему клоню - проблема вызывалась двумя закосяченными весьма второстепенными табличками, но мускуль своим варнингом:
"It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware."
морально настраивал на проблемы иного характера. Вспомнилась расшифровка одного из блюскриновых варнингов лет 5 назад.
Общий смысл того кода был - проблема связана либо с операционной системой, либо памятью, либо с процом, либо с дисками, либо с чипсетом, либо ещё какие-то хардварные проблемы.

Почта США тоже косячит

Уехала 1 февраля моя посылка из шипито. 2 числа попала на сортировку usps в ЭлЭй сити, и ппц, как в воду канула.. Это при том, что обычто коробки проходили через Лос-Анжелес максимум 2 дня и улетали к нам. До России, к слову, все добирались от 4 до 9 дней.
К 18 февраля я потерял всякую надежду на то, что всё само собой разрулится, написал в шипито. Сергей С. (кто с шипито работает, знает, о ком я) по-русски ответил, что надо ждать 30 дня с отправки и писать на розыск.
Я подумал, что посылку просто завернули из-за того, что в декларации были слова "epoxy" и "paint". "Paint" много всяких, но не в баллонах.
Обидно, короче, стало - и коробка весьма недешёвая, и в России этого хозяйства, типа "magic sculpey", нет. А если кто и привозит - разлетается в момент.
И тут внезапно коробочка затрекалась у нас на импорте.
Т.е. посылка шла ~ 18 дней, а у USPS есть нормативы по доставке экспрессов. + факт эксорта не протрекался.
Так что, не только наши косячат )
У коллеги в декабре коробка перед отправкой изъездила всю Калифорнию аж 3 раза )

Ладно, главное, чтобы теперь наши не 18 дней везли, а побыстрее )

суббота, 11 февраля 2012 г.

Про блоги

Уже не раз ловлю себя на том, что мне сложно найти что-то из старых постов. Забыл где-то тэг поставить и всё..
В общем, идея в тематическом разделении блога на несколько частей. Линуксы, фряхи, жуниперы и прочее вынести в технический блог, а ваху с красками, терминаторами и Альфа легионами - в вхшный. Остальное тут оставить.
Тогда будет легче что-то найти. Но разгребать пока некогда.

А ещё шаблон пора сменить, этот поднадоел уже.

EXT3-fs error: unlinked inode

Стало время от времени появляться:
Feb  7 00:03:03 xxx kernel: EXT3-fs error (device sda8): ext3_lookup: unlinked inode 11848061 in dir #17097522
Feb  7 00:03:03 xxx kernel: Aborting journal on device sda8.
Feb  7 00:03:03 xxx kernel: EXT3-fs error (device sda8): ext3_lookup: unlinked inode 11848060 in dir #17097522
Feb  7 00:03:03 xxx last message repeated 3 times
Feb  7 00:03:03 xxx kernel: ext3_abort called.
Feb  7 00:03:03 xxx kernel: EXT3-fs error (device sda8): ext3_journal_start_sb: Detected aborted journal
Feb  7 00:03:03 xxx kernel: Remounting filesystem read-only
Спустя некот.время - от неск.мин до часа - сервак вис, выкидывая:

Feb  7 00:25:54 xxx kernel: Pid: 27096, comm: repquota Not tainted 2.6.18-194.17.4.el5 #1
Feb  7 00:25:54 xxx kernel: RIP: 0010:[<ffffffff88055c3d>]  [<ffffffff88055c3d>] :ext3:ext3_journal_start_
sb+0x0/0x46
Айноды всё время одни и те же.
Нашёл баг: https://bugzilla.redhat.com/show_bug.cgi?id=494927

Собственно, предложенное решение - пересборка журнала:
umount /dev/sda8
tune2fs -O ^has_journal /dev/sda8
e2fsck -fy -C 0 /dev/sda8
tune2fs -j /dev/sda8
mount /dev/sda8
помогло.

понедельник, 6 февраля 2012 г.

Харденинг

Надо пробовать чуток укрепить хостинги...

1. Сетевой стек. Посмотрим, что будет, если сделать:
net.ipv4.tcp_max_syn_backlog=2048
net.ipv4.tcp_synack_retries=3
net.ipv4.tcp_fin_timeout=20
По идее, сможем больше синов держать, быстрее закрывать те, что так и не открыты до конца и быстрее прибивать закрываемые.

2. limit_conn с $binary_remote_addr для всех виртуал хостов. Штучек 16 должно хватить.
Так же можно попробовать ставить rate с айпишника, но может вызвать эээ.. огорчение у некот. клиентов. Ещё наверно имеет смысл разграничить по числу коннектов на один виртуал хост вообще, но тоже может вызвать неадекватную реакцию.

Что бы ещё сделать?

chkconfig и systemctl

Заметил, что в новой Федоре стопать/стартовать, включать/выключать сервисы стало несколько иначе, чем раньше:

Вместо:
service sshd start
теперь принято:
systemctl start sshd.service

Вместо:
chkconfig sshd on
надо делать:
systemctl enable sshd.service

Хотя пока и то, и другое работает, хотя при команде chkconfig дергается соотв. systemctl

Собственно, тут небольшая памятка по systemd:
http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet

среда, 1 февраля 2012 г.

EX4200: JunOS upgrade

Надо обновить ось на juniper ex4200. Стоит совсем старая 10.0, надо вкатить свежую 11.4Предположим, что мы его сбросили to factory:
На панелке свича находим в меню раздел обслуживания, там нашли фактори и подтвердили сброс.
Потом выставили дату и рутовый пароль (в cli):

set date 201202011053
set system root-authentication plain-text-password

Зацепились миникомом, настройка:
Serial Device      : /dev/ttyS0
Lockfile Location     : /var/lock
Callin Program      :
Callout Program      :
Bps/Par/Bits       : 9600 8N1
Hardware Flow Control : No
Software Flow Control : No

Качаем инсталлер отсюда:
http://www.juniper.net/support/products/junos/dom/11.4/#sw
а именно вот это:
https://download.juniper.net/software/junos/11.4R1.6/jinstall-ex-4200-11.4R1.6-domestic-signed.tgz
и лодер:
https://download.juniper.net/software/junos/specials/jloader/jloader-ex-3242-11.3I20110326_0802_hmerge-signed.tgz

Сначала накатывается новый загрузчик, зачем это надо - описано тут:
http://www.juniper.net/alerts/viewalert.jsp?actionBtn=Search&txtAlertNumber=PSN-2011-03-201&viewMode=view
потом ребут и накатывается сам инсталлер.

зашли, настроили один порт - чтобы скачать всё.
я всё хозяйство к себе качал, по scp заливаю на свич. Заливать надо именно в /var/tmp, иначе при установке придётся соснуть хцов из-за нехватки места.

cd /var/tmp scp xxx@192.168.48.33:~/Downloads/jloader-ex-3242-11.3I20110326_0802_hmerge-signed.tgz .
scp xxx@192.168.48.33:~/Downloads/jinstall-ex-4200-11.4R1.6-domestic-signed.tgz .

ставим загрузчик:
cli
request system software add jloader-ex-3242-11.3I20110326_0802_hmerge-signed.tgz
request system reboot

Если установка зафейлилась - гуглим. Скорее всего либо дата кривая, либо джунос саааавсем старый.

Теперь инсталлер:
cd /var/tmp
cli
request system software add jinstall-ex-4200-11.4R1.6-domestic-signed.tgz
request system reboot

При загрузке видим:
Copyright (c) 1996-2011, Juniper Networks, Inc.
All rights reserved.
Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
JUNOS 11.4R1.6 #0: 2011-11-15 10:57:04 UTC