gem install hiredis

не работает, т.к. где-то внутри жестко зашито название утилиты make, а FreeBSD-версия /usr/bin/make серьезно отличается по синтаксису от GNU Make, который все привыкли использовать, поэтому в STDERR сыпятся ошибки:

# gem install hiredis
Fetching: hiredis-0.4.1.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing hiredis:
	ERROR: Failed to build gem native extension.

        /usr/local/bin/ruby18 extconf.rb
"Makefile", line 11: Missing dependency operator
"Makefile", line 21: Need an operator
"Makefile", line 22: Missing dependency operator
"Makefile", line 33: Need an operator
"Makefile", line 43: Need an operator
"Makefile", line 44: Need an operator
"Makefile", line 82: Need an operator
"Makefile", line 86: Need an operator
"Makefile", line 88: warning: duplicate script for target "hiredis-example-ae" ignored
"Makefile", line 89: Need an operator
make: fatal errors encountered -- cannot continue
creating Makefile

make
cc -I. -I/usr/local/lib/ruby/1.8/amd64-freebsd8 -I/usr/local/lib/ruby/1.8/amd64-freebsd8 -I. -I/usr/include -fPIC -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC -I/usr/local/lib/ruby/gems/1.8/gems/hiredis-0.4.1/vendor/hiredis -c connection.c
cc -I. -I/usr/local/lib/ruby/1.8/amd64-freebsd8 -I/usr/local/lib/ruby/1.8/amd64-freebsd8 -I. -I/usr/include -fPIC -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC  -I/usr/local/lib/ruby/gems/1.8/gems/hiredis-0.4.1/vendor/hiredis -c hiredis_ext.c
cc -I. -I/usr/local/lib/ruby/1.8/amd64-freebsd8 -I/usr/local/lib/ruby/1.8/amd64-freebsd8 -I. -I/usr/include    -fPIC -I/usr/include -O2 -pipe -fno-strict-aliasing -fPIC  -I/usr/local/lib/ruby/gems/1.8/gems/hiredis-0.4.1/vendor/hiredis -c reader.c
cc -shared -o hiredis_ext.so connection.o hiredis_ext.o reader.o -L. -L/usr/local/lib -Wl,-R/usr/local/lib -L. -L/usr/lib  -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic /usr/local/lib/ruby/gems/1.8/gems/hiredis-0.4.1/vendor/hiredis/libhiredis.a -Wl,-soname,hiredis_ext.so   -Wl,-R -Wl,/usr/local/lib -L/usr/local/lib -lruby18  -lcrypt -lm -L/usr/lib  -rpath=/usr/lib:/usr/local/lib -pthread
cc: /usr/local/lib/ruby/gems/1.8/gems/hiredis-0.4.1/vendor/hiredis/libhiredis.a: No such file or directory
*** Error code 1

Stop in /usr/local/lib/ruby/gems/1.8/gems/hiredis-0.4.1/ext/hiredis_ext.

Gem files will remain installed in /usr/local/lib/ruby/gems/1.8/gems/hiredis-0.4.1 for inspection.
Results logged to /usr/local/lib/ruby/gems/1.8/gems/hiredis-0.4.1/ext/hiredis_ext/gem_make.out

GNU-версия make в freebsd называется gmake. Чтобы исправить вызов make в gem’е, пришлось его пересобрать. Вот полная версия установки пакета:

$ mkdir ~/hiredis && cd ~/hiredis
$ gem fetch hiredis  # в текущем каталоге появляется файл hiredis-0.4.1.gem
Downloaded hiredis-0.4.1
$ gem unpack hiredis-0.4.1.gem
Unpacked gem: '/home/bvk/hiredis/hiredis-0.4.1'
$ gem spec  hiredis-0.4.1.gem > hiredis.spec # извлекли спецификацию gem'а, по которой будем собирать пакет
$ cd hiredis-0.4.1
# тут в ext/hiredis_ext/extconf.rb нужно поменять "make static" на "gmake static",
# а в Rakefile "make clean" на "gmake clean"
# собираем пакет
$ gem build ../hiredis.spec
WARNING:  description and summary are identical
  Successfully built RubyGem
  Name: hiredis
  Version: 0.4.1
  File: hiredis-0.4.1.gem
# устанавливаем
$ sudo gem install hiredis-0.4.1.gem
Building native extensions.  This could take a while...
Successfully installed hiredis-0.4.1
1 gem installed
Installing ri documentation for hiredis-0.4.1...
Installing RDoc documentation for hiredis-0.4.1...

Теперь внимательно читаем porters handbook, делаем порт и далее действуем по правилам.

У них было два сервера, один в интернете показывал контент посетителям, а второй располагался в офисе и содержал интерфейс администрирования сайта. Все хозяйство работало под FreeBSD 6.1 на очень стареньких машинах, на основном сервере был Pentium 3 и 384 мегабайта памяти (однако много лет назад о такой конфигурации можно было лишь помечтать). Apache 2.2.2 вёл лог посещений в режиме «combined», а по ночам всё накопленное за последние сутки обрабатывалось штатной программкой logresolve (преобразовывает IP-адреса посетителей в имена хостов) и копировалось в отдельный файл resolved.log. Затем офисный сервер забирал получившийся файл по HTTP (в целях безопасности все «альтернативные» способы обмена файлами решили не использовать) и парсил его awstats’ом. Такая вот нехитрая схемка. Но проработала она ровно два месяца до середины декабря 2006 года и перестала.

Кроме нескольких программных ошибок обнаружилось еще пара стратегических провалов. Во-первых, офисный сервер иногда отключался из-за проблем с электричеством, и лог не забирался вовремя, а на следующий день просто дополнялся; после двух-трёх пропущенных дней файл с логами разросся до таких размеров, что даже в сжатом виде слишком долго передавался бы по http, и забирающий скрипт просто отваливался по таймауту. Во-вторых, установленный там logresolve натурально портил логи: читал из строки первые 1024 байта, обрабатывал IP-адрес и печатал их в STDOUT, завершив переводом строки; затем читались следующие 1024 байта и т.д. В результате строки, содержащие, например, длинные реферрерские URL, оказались разбитыми на несколько строк по 1024 байта каждая, что, возможно, не имело значения для awstats, но крайне затрудняло дополнительную обработку такого лога.

В итоге с декабря 2006 года лог-файл увеличился в размерах до полутора гигабайт. Я решил, что лучше его разбить на месяцы и скормить эти месяцы парсеру поочерёдно, однако сначала нужно было разобраться с лишними разрывами строк. Быстренько набросал однострочник на sed, который удаляет лишние переводы строк, если в третьем поле не содержится даты.

Однако несмотря на то, что на как на небольших, так и на довольно больших отрывках resolved.log данный скриптик отрабатывал относительно нормально, из реального лога читались только первые 170 мегабайт с копейками и скрипт надолго зависал. Решил, что, возможно, чего-то не учёл из-за малого опыта написания такого рода сценариев на sed, и переделал тот же самый алгоритм на perl и c — безуспешно: после прочтения первых 170 мегабайт ничего не происходило.

my $b='';
while(<>){
        chomp;
        if(/\[[0-9]+\/[a-zA-Z]+\/[0-9:]+\ \+0300\]/){
                print "$b\n";
                $b=$_;
        } else {
                $b.=$_
        }
}
print "$b\n";

Я несколько раз прогнал эти скрипты через valgrind с максимальными проверками утечек, избавился от некоторых ошибок, в конце концов перечитал кучу документации по freebsd на тему возможных ограничений на размер процесса в памяти (хотя больше восьми килобайт программа в памяти не занимала) и т.д. В общем, на два дня выпал из жизни, проводя это время в отладке…

В конце концов нашел причину моих мучений: в регулярном выражении, определявшем признак начала записи лога, была жестко прописана временная зона +0300, тогда как при переходе на летнее время она изменялась на +0400. Поэтому, когда цикл доходил до марта 2007 года, несколько сотен тысяч строк до следующего октября просто пропускались, а поскольку сервер был медленный, то на Ctrl+C и kill -TERM скрипты реагировали не сразу, и тем создавалось ощущение зависания.

После того, как я исправил этот регэксп, всё пошло как по маслу: скормил awstats’у старые логи, прикрутил logrotate, научил скрипты забирать статистику через scp; параллельно крону поставил anacron, благодаря чему забор и анализ логов стал производиться ежедневно вне зависимости от того, включен ли «офисный» сервер в 4 часа 15 минут утра. А потом и вовсе уговорил начальство поставить внешние счетчики. Теперь там стоит google analytics и все счастливы, а я немного прокачал скилл профайлинга.

По сравнению с предыдущей деятельностью сменилось вроде бы немногое — базовый дистрибутив поменялся с Fedora на Debian, PostgreSQL — на MySQL (с удивлением узнал, что хранимые процедуры в MySQL появились только начиная с 5.0, а подзапросы тут и сейчас кривоваты), PHP4 на PHP5 (exceptions рулят), плюс ко всему в окне стало видно небо и две трубы :) Но рабочее окружение пришлось слегка модифицировать. Поначалу были предпосылки к тому, чтобы перейти обратно на Windows, но, попробовав что-то серьёзно там поделать, я понял, что в операционнойп системе без родного клиента ssh и человеческого терминала я жить не смогу, плюнул и остался на Ubuntu 8.10. К тому же мне выдали новый компьютер (Athlon 64 X2 вместо Pentium 4) с двухголовой Nvidia GeForce 8500 GT (вместо интегрированного i815), и после перетыкания жесткого диска XP просто перестала загружаться.

Да и в убунте из-за того, что всё железо, кроме жесткого диска, полностью новое, возникли некоторые проблемы, в частности, зависал Xorg (и тянул за собой клавиатуру) при двух подглюченных мониторах. Решение в конце концов свелось к перенастройке сети и установке драйверов от nvidia (драйвер nv из xorg почему-то не захотел нормально работать):

1. загрузился в single mode
2. отключил запуск сервиса gdm:

sudo update-rc.d gdm remove

3. в /etc/udev/rules.d/70-persistent-net.rules в строчке, относящейся к старой сетевой карте, поменял mac-адрес на новый:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:92:15:61:33", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

4. перезагрузился, убедился, что сеть доступна (пришлось сходить к админам и попросить их также поменять mac-адрес в настройках корпоративного DHCP на новый)
5. установил свежий (на тот момент) комплект драйверов от nvidia:

sudo apt-get install nvidia-glx-173 # (последняя на момент установки версия nvidia-glx)
sudo mv /etc/X11/xorg.conf /etc/X11/xorg.`date "+%Y%m%d%H%m%S"`.conf
sudo nvidia-xconfig # создался новый xorg.conf

6. загрузился в графическую оболочку (service gdm start), запустил nvidia-settings, включил TwinView в режиме «растягивания» рабочего стола на два монитора 1280×1024 (получилось разрешение 2560×1024)
7. вернул автозапуск gdm:

update-rc.d gdm defaults

Продолжение следует.

1802: Unauthorized network card is plugged in - Power off and remove the miniPCI network card.

Расследование этого факта привело на страницу Problem with unauthorized MiniPCI network card, откуда я узнал, что в биосе ноутбуков Thinkpad «зашит» белый список PCI-ID’ов Mini PCIe-устройств, явно разрешённых к использованию, все остальные устройства запрещены. Все разрешённые устройства выпущены под маркой Lenovo и стоят в полтора-два раза дороже, чем их немаркированные аналоги. Как разъясняет справочный центр Lenovo, это вызвано тем, что во избежание порчи эфира сочетание карты и антенны должно быть сертифицировано FCC (североамериканская федеральная комиссия по связи) или аналогичной организацией в других странах, и Lenovo не может гарантировать, что какой попало адаптер будет соответствовать этим требованиям. Поэтому официальный совет по избавлению от этой ошибки: выкиньте свой адаптер и купите правильный втридорога.

Неофициальные способы обойти хитрых IBM-овцев перечислены на вышеупомянутой странице. Вариантов несколько: добавить PCI ID устройства в bios, модифицировать PCI ID на самом устройстве (речь идёт о subvendor id), использовать несколько вариантов программ для изменения пары байтов в биосе, отключающих проверку по белому списку… В итоге сработало простое перетыкание адптера в соседний слот: видимо, проверка PCI ID работает только для одного слота.

После перетыкания ноутбук включился, но на этом приключения не кончились :) Выяснилось, что при любом состоянии переключателя wifi в логи выводится сообщение, подобное следующему:

Dec 20 20:20:56 hostname kernel: ipw3945: Radio Frequency Kill Switch is On:
Dec 20 20:20:56 hostname kernel: Kill switch must be turned off for wireless networking to work.

При этом в файле /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/rf_kill содержится число 2, что означает «залочено железом». Т.е. карточка считает, что wifi выключен и отказывается работать, и никакие хоткеи, включающие wifi, тут не помогут.

Решение в виде грязного хака нашлось на той же странице: необходимо чем-нибудь заклеить 20 контакт карточки бумажкой, чтобы она не получала сигналов о состоянии переключателя wifi, которые, видимо, не доставляются во второй слот. Действительно, судя по распиновке Mini PCI express, 20 пин зарезервирован и вполне может использоваться для сигнализации о включении/выключении функциональности wifi.

Мы заклеили этот 20 контакт кусочком первой попавшейся липкой бумажки, и всё прекрасно работает. Надолго ли?..

Upd. Пока писал, забыл, чего сказать-то хотел :) Мораль сей басни такова: подумайте дважды, прежде чем Thinkpad брать — готовы ли вы модные рюшечки поменять на понятные, но нервирующие заносы производителя и потенциально обрести проблемы на пустом месте?