Bappoy's blog

Нижний Новгород в погодном апплете Gnome

bappoy — Mon, 06 Feb 2012 08:28:29 +0000

Для того, чтобы наблюдать погоду в верхней панели, всю жизнь тщательно вбивал координаты нашего нижегородского аэропорта (ICAO: UWGG) в /usr/share/libgweather/locations.xml, т.к. в списке городов Нижнего Новгорода нет и не было, а при вводе “nizh” показывался только Nizhnevartovsk. На прошлой неделе решил окончательно разобраться с этим вопросом и обнаружил, что вместо Нижнего Новгорода нужно искать Стригино — поселок в черте города, поделившийся названием с аэропортом.

Политическая позиция

bappoy — Fri, 02 Dec 2011 11:44:47 +0000

Пойду 4 декабря голосовать против партии “Единая Россия” по следующим причинам:

1. Государственная дума — место для политических дискуссий;
2. Партия, которая:
— имеет своей целью обеспечение беспрепятственного прохождения абсолютно любых законопроектов в государственной думе;
— монополизировала и фактически подменила собой власть;
— законодательно обеспечила большинство в последующих думах при отсутствии фактической поддержки среди населения;
— без стеснения использует административный ресурс для обеспечения своей поддержки на выборах, явно нарушая законодательство, и ей сходит это с рук;
— указывает в своих заслугах то, что она, являясь властью, и так должна делать;
— грозит лишением федеральных денег целых регионов за то, что часть их населения не поддерживает;
— в начале своих федеральных и региональных списков указывает людей, которые заведомо не будут и не могут быть депутатами, а иногда даже и не являются членами этой партии —

не должна иметь большинство в Думе.

3. Коррупция, fail’ы космической программы, провалы конкурсов на поставки военной техники союзникам, провал совместных тихоокеанских учений с Индией, слабость внешней политики, сомнительная олимпиада — всё это тоже заслуги Единой России.

Сходите на выборы и явно выразите свое мнение, иначе неявно ваш голос отойдет этой партии.

Пересборка ruby gem на примере hiredis в FreeBSD

bappoy — Sun, 06 Nov 2011 17:30:18 +0000

Для тех админов, кому ~~лень~~ некогда копаться во внутренностях ruby и гуглить невнятные ошибки, но надо срочно поставить ruby gem, отсутствующий в портах. В моем случае — hiredis (ruby обвязка для одноименной библиотеки доступа к БД redis). Установка методом

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, делаем порт и далее действуем по правилам.

Как я однажды тупил два дня на ровном месте

bappoy — Tue, 18 Oct 2011 09:17:45 +0000

В преддверии первой годовщины последнего осеннего перевода часов в России вспомнился один факап трехлетней давности (начало 2008 года). Я тогда занимался починкой статистики посещаемости на одном региональном сайтике, который я поддерживал по дружбе.

У них было два сервера, один в интернете показывал контент посетителям, а второй располагался в офисе и содержал интерфейс администрирования сайта. Все хозяйство работало под 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 и все счастливы, а я немного прокачал скилл профайлинга.

Комфортная работа в Midnight Commander

bappoy — Thu, 08 Sep 2011 13:28:49 +0000

Многие мои коллеги принципиально игнорируют Midnight Commander, предпочитая работать в командной строке. Мотивируют это целым рядом причин, начиная с “нортон коммандер устарел еще в 1995 году” и заканчивая “я юниксоид с 1970 года и без всяких mc прекрасно управляюсь в консоли”. Конечно же, это дело вкуса, и можно (и нужно!) настроить консоль под себя так, чтобы она летала со скоростью мысли: на помощь приходят команда alias, сочетание Ctrl+R, описание команды shopt в builtins(1), пакет bash_completion или его аналоги, ряд мелких хаков, наподобие такого, или альтернатива в виде zsh, в конце концов.

Однако визуалам типа меня удобнее постоянно иметь перед глазами списки файлов и папок, а не помнить, какой файл где находится и что здесь есть еще. Кроме того, пользуясь исключительно командами cd и ls --color, можно легко проглядеть что-нибудь ненужное, типа оставшихся от vim бэкапов в текущем каталоге (если бэкапы нужны, см :help backupdir) или папок с именем из пробела.

Конечно, сначала mc производит немного гнетущее впечатление, но если разобраться и привыкнуть, то может оказаться, что даже с конфигурацией из коробки он очень облегчает жизнь разработчика и системного администратора. Поделюсь собственными хитростями, используемыми каждый день. За кадром осталось еще множество интересных фич, типа кастомной раскраски файлов в панели, смены цветовой схемы на черно-зеленую, сниппетов в редакторе mcedit, настраиваемых VFS, но поскольку я ими не пользуюсь, то ничего про них не скажу. Примеры их настроек и использования можно посмотреть в /etc/mc и в /usr/share/mc.

Сначала полезные мелочи, для многих очевидные.

Если до mc по каким-то причинам не доходят коды кнопок Fn, их можно заменить Esc-n. А Alt, иногда перехватываемый панелью меню, успешно заменяется кнопкой Esc
Режим просмотра файлов «Full file list» лучше, чем «Short file list». При желании можно добавить туда показ прав на объекты файловой системы, например:
```
half type name | size | mtime | mode:3
```
Панели подсказок над и под командной строкой внизу и меню сверху можно отключить в Options — Layout, будет больше пространства для списка файлов. Заодно там можно включить отображение свободного места в текущем разделе — очень полезно для нетбуков с мелкими экранами
При навигации по списку файлов сочетание Ctrl+S перекидывает на файл, начинающийся с вводимых символов
Alt+Y перекидывает в предыдущую папку. Иногда это бывает полезно при восстановлении после ошибки «The shell is already running the command», за все время существования mc ставшей его визиткой
Встроенный редактор ужасен. В ~/.bashrc добавьте строчку export EDITOR=vim, а в пункте меню Options — Configuration снимите галку «Use internal editor». Точно так же можно использовать переменную окружения PAGER=view для просмотра файлов (опция «Use internal view»)
Alt+I покажет текущую папку в противоположной панели, а Alt+O — папку под курсором, а если под курсором файл, то родительскую.
Начиная с ветки midnight commander 4.7.1, в меню сортировки появилась сортировка по версиям, она работает точно так же, как ls -v, т.е. показывает список 1.2.1, 1.2.2, 1.2.10 именно в этом порядке, а не в алфавитном (1.2.1, 1.2.10, 1.2.2). Сам делал :).
Ctrl+X c — просмотр и редактирование прав на файл
Ctrl+X d — три варианта сравнения двух каталогов: быстрое (по спискам файлов), по размерам (то же самое, только с учетом размеров), полное (по содержимому файлов)
Alt+C — быстрый переход в нужную папку без изменения командной строки. По Esc-Tab показывает список подстановки (в командной строке mc Esc-Tab тоже иногда работает)
По Ctrl+\ имеется многоуровневое меню быстрого доступа к папкам, в т.ч. и через FTP и SSH. При желании его можно отредактировать вручную в ~/.mc/hotlist

На данный момент самой полезной фичей для меня является пользовательское меню. Про него я уже писал пару раз (1, 2), сейчас расскажу более подробно.

Я поддерживаю несколько сайтов под mod_perl, и после изменений в коде startup.pl необходимо перезапускать процесс apache, свой для каждого сайта. Каждый сайт находится в /home/sites/sitename, а конфиг apache для этих сайтов — в /usr/local/apache/conf/httpd-sitename.conf.

Когда мне надоело вручную писать /usr/local/apache/bin/apachectl-sitename restart после каждого изменения, в ~/.mc/menu добавились строчки:

s Restart apache for sitename
   sudo /usr/local/apache/bin/apachectl-sitename restart

Первая строка задаёт быструю клавишу и название пункта меню, а все за ней следующее — команду, в которой можно использовать ряд макро-подстановок:

%f — имя файла под курсором, %x — расширение, %b — имя файла без расширения
%d — каталог в активной панели, %D — каталог в неактивной панели
%t — выбранные файлы в активной панели, %T — в неактивной

и т.д.

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

+= d /home/sites/sitename | f httpd-sitename.conf
s Restart apache for sitename
   sudo /usr/local/apache/bin/apachectl-sitename restart

Первый символ “=” означает начало условия, при котором пункт меню становится активным по умолчанию (при вызове меню курсор уже стоит на этом пункте, так что остаётся только нажать Enter); если перед ним стоит +, то пункт появляется в меню только при выполнении этого условия. Следующий символ — тип условия, например:

f шаблон — имя файла соответствует шаблону (если в начале файла меню не указана опция shell_patterns=0, то под шаблоном имеется в виду шелл-шаблон, в противном случае — регулярное выражение)
d шаблон — текущий каталог соответствует шаблону
t type — то, что под курсором, имеет тип:
- n не является директорией
- r обычный файл
- d каталог
- l ссылка
- c последовательное устройство
- b блочное устройство
- f FIFO
- s сокет
- x исполняемый файл
- t отмеченный файл
Различные типы можно комбинировать, например, t rdl означает файл, каталог или ссылку
остальные тесты можно подсмотреть в упомянутой справке

Условия можно комбинировать и объединять, например:

# если находимся в папке /home/sites/sitename и под курсором — файл .sql, показать этот пункт меню
+= d /home/sites/site_name & f *.sql
S import sql-file to database sitedb
   mysql sitedb < %f

Таким образом, приведенный ранее кусок означает “если находимся в каталоге сайта или стоим на конфигурационном файле apache для него, показать команду перезапуска сервера и встать на нее курсором”.

Остальное — дело фантазии и техники. Достаточно подумать о том, какие рутинные действия выполняются достаточно часто, и просто автоматизировать их.

Теоретические основы HTTP LiveStreaming для iPod, iPhone и iPad

bappoy — Thu, 21 Jul 2011 11:59:45 +0000

Пару недель назад в свободное от основной работы время безуспешно пытался подружить Adobe Flash Media Server с iPhone и iPad посредством Red5, установленного на FreeBSD. Не получилось (не встал xuggler, а без него не заработал mpeg-ts), но ссылки остались.

Спецификации iPhone и iPad, из которых следует, что поддерживаются профили H.264 Main Profile Level 3.1 и Simple с аудио AAC-LC до 160 Kbps, 48 кГц

HTTP Live Streaming с точек зрения:

… Apple (теория), best practices. Все можно реализовать стандартными (?) средствами Mac Os X.
… разработчиков JW Player (JW Player — HTML5/Flash плеер, умеющий воспроизводить как классические потоки RTP/RTSP, так и HTTP LiveStreaming)
… разработчиков erlyvideo

A Review of HTTP LiveStreaming — подробный разбор технологии в сравнении с RTP/RTSP и Adobe Flash Media. Изначально этот обзор был опубликован на сайте автора, но по каким-то причинам файл отсутствует и доступен только в кэше гугла.

Конвертация Unix-style путей в UNC в Midnight Commander

bappoy — Sat, 25 Jun 2011 11:19:14 +0000

Тестовые релизы нашего продукта мы выкладываем в шару \\fs\testing, а готовые сборки и обновления для клиентов — в \\fs\release. У меня эти шары примонтированы соответственно как /mnt/testing и /mnt/release, и при составлении писем о выпуске релиза приходится вручную менять пути вида /mnt/testing/product/version_major/version_minor на \\fs\testing\product\…

Однажды мне это надоело и я добавил такую запись в ~/.mc/menu:

+ d /mnt/
p   Copy path in windows format to clipboard
    pwd|perl -ne 's|^/([^/])|//\1|g; s|/mnt/(products\|testing)|/fs/\1|g; s|/|\\|g;print'|xclip &

Теперь, если текущий каталог в Midnight Commander начинается на “/mnt/”, в меню F2 появляется пункт “Convert path to windows format”, при активации которого в буфер обмена помещается “правильный” UNC-путь к текущему каталогу.

О том, почему в Windows используются неправильные слэши, можно узнать из этой статьи.

Заметка из черновиков годовой давности, сейчас выкладываю другие релизы в другие шары :)

Пакетная система Debian: низкоуровневая работа с deb-пакетами

bappoy — Fri, 22 Oct 2010 12:30:30 +0000

Формат deb-пакета

Краеугольный камень пакетной системы Debian — это deb-пакет (см. deb(5)), представляющий из себя архив формата ar, внутри которого содержится три файла:
1. debian-binary — текстовый файл, содержащий версию формата deb-пакета, в данный момент это 2.0. Программы, работающие с deb-пакетами, должны читать только первую строку этого файла и не падать, если минорная версия вдруг поменяется (например, станет 2.1).
2. control.tar.gz — служебная информация о пакете, скрипты, вспомогательные файлы (см deb-control(5)). Должен содержать только файлы, единственная папка, которая может присутствовать — “.” (текущая директория). В этот архив обязательно должен входить файл control, его минимальное содержимое рассмотрим чуть ниже.
3. data.tar — собственно файлы, устанавливаемые в систему. Чаще всего этот файл сжат каким-нибудь архиватором (поддерживаются расширения .gz, .xz, .bz2, .lzma), чаще всего в архивах встречается data.tar.gz.

Указанный порядок следования файлов в архиве обязателен. Если в этом архиве требуется разместить еще какие-нибудь файлы (не представляю, зачем это может кому-нибудь понадобиться), они должны находиться перед data.tar.gz, т.е. последний файл в архиве всегда data.tar. Но если сообщество когда-нибудь решит добавить в формат deb еще файлы, они будут помещены после data.tar.

Файл control в архиве control.tar.gz описывает назначение, версию и зависимости пакета, его формат более-менее подробно описан в deb-control(5). Пересказывать всю справку сейчас не буду, опишу лишь минимальное содержимое, необходимое для взаимодействия с инфраструктурой dpkg:

Package: имя пакета
Version: строка версии (при выборе политики назначения версий следует придерживаться deb-version(5))
Maintainer: John Doe <johndoe@foo.com> (человек, поддерживающий пакет, а не автор программы)
Description: короткое описание пакета
 Длинное описание,  на несколько строк. Каждая строка, входящая в
 длинное описание,  должна начинаться с пробела

Работа с пакетами средствами ar

Теоретически данной информации должно быть достаточно, чтобы собрать простейший пакет “на коленке” и установить его в систему. Пусть наш пакет (назовем его test) просто добавляет в систему файл /usr/share/example-content/test со строчкой “test”. Сделаем архив data.tar.gz со структурой папок и единственным файлом, а также файлик debian-binary:

$ mkdir -p usr/share/example-content/
$ echo test > usr/share/example-content/test
$ tar czf data.tar.gz usr
$ echo 2.0 > debian-binary

Создадим файл control со следующим содержанием:

$ cat control
Package: test
Version: 1.0
Maintainer: Dummy Maint <dummy@example.org>
Description: test package
 Test package created on my own knees.
$ tar czf control.tar.gz control

Теперь соберем все воедино:

$ ar -qS test-1.0.deb debian-binary control.tar.gz data.tar.gz

В текущем каталоге должен появиться файл test-1.0.deb. Его “физическое” содержимое можно просмотреть с помощью следующей команды:

$ ar t test-1.0.deb
debian-binary
control.tar.gz
data.tar.gz

Посмотреть файл debian-binary:

$ ar p test-1.0.deb debian-binary
2.0

Посмотреть список файлов в пакете:

$ ar p test-1.0.deb data.tar.gz|tar -tzf -
usr/
usr/share/
usr/share/example-content/
usr/share/example-content/test

Посмотреть содержимое файла control:

$ ar p test-1.0.deb control.tar.gz |tar -O -xzf - control
Package: test
Version: 1.0
Maintainer: Dummy Maint <dummy@example.org>
Description: test package
 Test package created on my own knees.

Можно установить этот пакет и убедиться, что файл /usr/share/example-content/test успешно создан, но лучше этого не делать, поскольку из-за недостатка информации в control в пакетной системе может появиться мусор:

$ sudo dpkg -i test-1.0.deb
Selecting previously deselected package test.
(Reading database ... 97631 files and directories currently installed.)
Unpacking test (from test-1.0.deb) ...
Setting up test (1.0) ...

Работа с пакетами средствами dpkg-deb

Все вышеописанное позволяет управляться с deb-пакетами на самом низком уровне, не имея под рукой ничего, кроме стандартных средств Unix (доподлинно известно, что программа ar входила в состав первых Unix 1970х годов). Однако, как несложно догадаться, есть и более высокоуровневые способы создания пакетов и изучения их содержимого. В частности, если уж так необходимо поковыряться с пакетом на низком уровне, все вышеописанные действия настоятельно рекомендуется выполнять с помощью утилиты dpkg-deb(1).

Создание пакета средствами dpkg-deb

Минимальный формат вызова команды dpkg-deb для построения пакета следующий:

dpkg-deb -b исходная_папка

Все, что находится в исходной папке, кроме директории DEBIAN, помещается в data.tar.gz. Содержимое DEBIAN будет использовано для создания control.tar.gz, в частности, будет прочитан и проанализирован файл control и в случае каких-либо ошибок (отсутствует одно из необходимых полей или эти поля имеют неправильные значения) пакет просто не будет создан. Процесс создания нашего тестового пакета с нуля теперь выглядит так (в последней команде предполагается, что в текущей папке остался файл control от сборки пакета средствами ar):

Подготовка структуры:

$ mkdir -p test-1.1/usr/share/example-content/ test-1.1/DEBIAN
$ echo test 1.1 > test-1.1/usr/share/example-content/test
$ sed 's/Version: 1.0/Version: 1.1/g' control > test-1.1/DEBIAN/control

Попытаемся собрать пакет:

$ dpkg-deb -b test-1.1
warning, in file 'test-1.1/DEBIAN/control' near line 5 package 'test':
 missing architecture
dpkg-deb: building package `test' in `test-1.1.deb'.
dpkg-deb: warning: ignoring 1 warnings about the control file(s)

Несмотря на отсутствие важного, но не необходимого поля Architecture, был создан пакет test-1.1.deb. Добавим поле и пересоздадим пакет:

$ sed -i "1a \
Architecture: all" test-1.1/DEBIAN/control
$ dpkg-deb -b test-1.1
dpkg-deb: building package `test' in `test-1.1.deb'

Еще одна немаловажная деталь. Как правило, в названии файла пакета указывается его архитектура, а команда dpkg-deb -b назвала файл по имени папки, из которой он был создан. Если бы папка называлась ololo, то мы получили бы ololo.deb. Чтобы файл пакета автоматически именовался в формате имя-версия-архитектура, при вызове dpkg -b необходимо указывать папку, куда будет положен итоговый архив, например, текущую. Тогда все компоненты имени файла будут извлечены из control:

$ cp -R test-1.1 ololo
$ dpkg -b ololo
dpkg-deb: building package `test' in `ololo.deb'.
$ dpkg -b ololo .
dpkg-deb: building package `test' in `./test_1.1_all.deb'.

Теперь всё относительно нормально, продолжаем изучение возможностей dpkg-deb на примере нового пакета.

Получение информации о пакете

Узнать версию формата deb, размер пакета и содержимое файла control:

$ dpkg -I test_1.1_all.deb
 new debian package, version 2.0.
 size 644 bytes: control archive= 259 bytes.
     160 bytes,     6 lines      control
 Package: test
 Architecture: all
 Version: 1.1
 Maintainer: Dummy Maint <dummy@example.org>
 Description: test package
  Test package created on my own knees.

Список файлов, устанавливаемых в систему (кроме служебных):

$ dpkg -c test_1.1_all.deb
drwxr-xr-x bvk/bvk           0 2010-10-22 13:21 ./
drwxr-xr-x bvk/bvk           0 2010-10-22 13:21 ./usr/
drwxr-xr-x bvk/bvk           0 2010-10-22 13:21 ./usr/share/
drwxr-xr-x bvk/bvk           0 2010-10-22 13:21 ./usr/share/example-content/
-rw-r--r-- bvk/bvk           9 2010-10-22 13:21 ./usr/share/example-content/test

Обратите внимание на владельца устанавливаемых файлов и каталогов: это не root, а некий пользователь. Чтобы исправить эту проблему, можно собирать пакеты из-под root’а, либо воспользоваться специальной утилитой fakeroot из одноименного пакета. Она перехватывает системные вызовы chmod(2) и stat(2) для файлов, и возвращает значения, как если бы файл принадлежал пользователю root. Небольшой пример:

$ id
uid=1000(bvk) gid=1000(bvk) ...
$ touch trololo
$ ls -l trololo
-rw-r--r-- 1 bvk bvk 0 2010-10-22 13:23 trololo
$ fakeroot ls -l trololo 
-rw-r--r-- 1 root root 0 2010-10-22 13:23 trololo

Думаю, принцип понятен. Пересоберем пакет еще более правильно:

$ fakeroot dpkg -b test-1.1 .
dpkg-deb: building package `test' in `test_1.1_all.deb'.
$ dpkg -c test_1.1_all.deb
drwxr-xr-x root/root         0 2010-10-22 13:25 ./
drwxr-xr-x root/root         0 2010-10-22 13:25 ./usr/
drwxr-xr-x root/root         0 2010-10-22 13:25 ./usr/share/
drwxr-xr-x root/root         0 2010-10-22 13:25 ./usr/share/example-content/
-rw-r--r-- root/root         9 2010-10-22 13:25 ./usr/share/example-content/test

Теперь наконец ок.

Можно получаить информацию о пакете в заданном формате:

$ dpkg-deb -W --showformat='${Package}-${Version}-${Architecture} (${Maintainer})\n' test_1.1_all.deb
test-1.1-all (Dummy Maint <dummy@example.org>)

Список полей, которые можно указать в –showformat, можно узнать из вывода команды dpkg-deb -I

Подать на STDOUT архив data.tar.gz из пакета (уже “разжатый”), может быть полезно для извлечения только некоторых файлов:

$ dpkg-deb --fsys-tarfile test-1.0.deb |tar -Ox usr/share/example-content/test
test

Перепаковка пакета

Пожалуй, теперь наступил момент применить свежеполученные знания на практике :) Часто возникает следующая проблема: из некоего источника поступил пакет с некорректными зависимостями, например, требуется устаревший пакет, отсутствующий в системе и всех репозиториях, но доподлинно известно, что другой, уже установленный пакет предоставляет нужную функциональность. В скачанном пакете требуется изменить файл control, убрав или исправив зависимость. Правильно было бы скачать и распаковать исходник пакета (apt-get source), произвести необходимые изменения в скриптах сборки, установить все необходимые для пересборки библиотеки и окружение и т.д. и т.п., но для частного использования (т.е. без распространения по репозиториям) достаточно просто распаковать пакет, изменить необходимые файлы и запаковать обратно. Проиллюстрирую последовательность действий на примере невинного пакета hello:

$ aptitude download hello
Get:1 http://yum.fireground.ru/ubuntu/mirror/ maverick/main hello i386 2.5-1 [34.4kB]
Fetched 34.4kB in 0s (824kB/s)
# да-да, я сижу под убунтой и описываю debian
# распаковать содержимое пакета в папку hello (если не существует, будет создана):
$ dpkg-deb -x hello_2.5-1_i386.deb hello
# распаковать содержимое control.tar.gz в hello/DEBIAN
$ dpkg-deb -e hello_2.5-1_i386.deb hello/DEBIAN
# что-нибудь поменять в control, например, версию пакета:
$ sed -i 's/Version: .*$/Version: 2.5-1test/' hello/DEBIAN/control 
# собрать новый пакет:
$ fakeroot dpkg -b hello/ .
dpkg-deb: warning: 'hello//DEBIAN/control' contains user-defined field 'Original-Maintainer'
dpkg-deb: building package `hello' in `./hello_2.5-1test_i386.deb'.
dpkg-deb: warning: ignoring 1 warnings about the control file(s)

Пакет собран. Убедиться, в том, что в нем нет ошибок из-за немного нетрадиционного способа сборки, можно с помощью программы lintian:

$ sudo aptitude install lintian
...
$ lintian hello_2.5-1test_i386.deb
$ echo $?
0

Всё в порядке!

Об установке пакетов в систему, механизме зависимостей, структуре репозиториев и еще более правильных способах сборки пакетов читайте в следующих статьях :)

Проблема “SSL input filter read failed” и её решение

bappoy — Mon, 06 Sep 2010 13:06:03 +0000

Потратил половину своих выходных на выяснение причин неработоспособности прикрученного мной к одному апачу 2.2.16 модуля mod_ssl. Скрипт, вроде бы нормально работающий на 80 порту, напрочь отказывался работать через https, при этом выдавалась пустая страница, а в логах при перезапуске апача появлялась строчка, свидетельствующая лишь о том, что используется самоподписанный сертификат:

[warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)

Включив подробные логи (LogLevel debug), получил для каждого запроса на пару порядков больше информации, из которой наиболее полезным оказалось вот это:

[Sat Sep 04 20:43:54 2010] [debug] ssl_engine_io.c(1893): OpenSSL: I/O error,
5 bytes expected to read on BIO#8074a22e0 [mem: 8074e5000]
[Sat Sep 04 20:43:54 2010] [info] [client XX.XX.XX.XX] (70007)The timeout
specified has expired: SSL input filter read failed.

Безрезультатно промаявшись с этим еще пару часов, отправился спать с мыслью поставить потом nginx в качестве SSL-прокси.

В понедельник программисты посоветовали обратить внимание на .htaccess, в котором, в частности, активно эксплуатировался mod_rewrite и устанавливались настройки php. Временное удаление .htaccess вызвало ошибку 403 по нужному адресу (это был отличный результат, поскольку ранее никаких ошибок не выдавалось вообще). А отключение php_value error_reporting 0, приведшее к заполнению экрана ошибками PHP, окончательно развеяло все сомнения: проблема была вовсе не в mod_ssl, а в пользовательском скрипте; mod_ssl ничего не получал и возвращал ошибку.

Мораль на будущее: надо быть проще и искать корни очевидных ошибок на поверхности, а nginx все равно не помешает.

Note for english-speaking visitors with the same error from google: try to check your php scripts or other backends, they can fail and not return any data to mod_ssl

Следующий месяц в GNU date

bappoy — Tue, 31 Aug 2010 11:37:44 +0000

Если 31 августа спросить у GNU date, какой будет следующий месяц, результат будет немного странным:

$ date
Tue Aug 31 11:32:35 UTC 2010
$ date +"%Y-%m" --date "next month"
2010-10
$ date +"%Y-%m" --date "next month"
2010-10

Документация GNU date (см info date Relative items in date strings) специально обращает внимание на эту проблему и рекомендует вычислять следующий месяц не для сегодняшнего числа, а для 15 числа текущего месяца:

$ date +"%Y-%m" --date "$(date +%Y-%m-15) next month"
2010-09

Извлечение данных из виртуальных дисков VirtualBox

bappoy — Wed, 21 Jul 2010 15:51:42 +0000

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

К счастью, можно легко преобразовать vdi из динамического формата в статический с помощью многоцелевой утилиты vboxmanage, входящей в состав пакета virtualbox:

vboxmanage clonehd --variant static debian.vdi temp.vdi

Теперь у нас есть файл temp.vdi, внутри которого где-то присутствует образ искомой файловой системы; для ее корректного извлечения нужно вычислить смещение образа относительно начала файла. В половине найденных по запросу “mount vdi linux” статей рекомендуется использовать для этих целей утилиту vditool, предназначенную на самом деле для внутреннего тестирования функциональности виртуальных дисков в VirtualBox. Раньше бинарник vditool можно было отдельно скачать с сайта virtualbox.org, но теперь его там по понятным причинам нет (желающие могут скомпилировать его самостоятельно: vditool.cpp)

Мы, как всегда, пойдем другим путем и воспользуемся подручными средствами. Первые 512 байт нашего vdi-файла — его заголовок, в котором можно разобраться, воспользовавшись, например, этим мануалом или непосредственно описанием структуры заголовка vdi в исходниках VirtualBox. Из этих источников следует, что образ размечен следующим образом:
512 байт: заголовок
4 * N + X: карта мегабайтных блоков, здесь N — количество мегабайт в виртуальном жестком диске, а X — выравнивание получившегося числа до ближайшей верхней 512-байтной границы
512 + 4*N + выравнивание: смещение данных

Зная точный размер виртуального диска, можно легко вычислить смещение вручную:

$ vboxmanage showhdinfo f8e0de05-1419-405d-92d9-8358dc1e6bec
VirtualBox Command Line Management Interface Version 3.0.8_OSE
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

UUID:                 f8e0de05-1419-405d-92d9-8358dc1e6bec
Accessible:           yes
Description:
Logical size:         4095 MBytes
Current size on disk: 2637 MBytes
Type:                 normal (base)
Storage format:       VDI
In use by VMs:        debian (UUID: f1f8221a-6542-4dfe-9062-5397f429da4b)
Location:             /home/bvk/.VirtualBox/HardDisks/debian.vdi

(UUID нужного диска можно узнать из вывода команды vboxmanage list hhds). Здесь выравненное до 512 значение размера карты блоков равно 16384, а смещение данных — 16896.
А можно и вытащить смещение непосредственно из заголовка vdi. Например, вот начало моего четырёхгигового виртуального диска:

$ head -c 512 temp.vdi |hexdump  -C
00000000  3c 3c 3c 20 53 75 6e 20  56 69 72 74 75 61 6c 42  |< << Sun VirtualB|
00000010  6f 78 20 44 69 73 6b 20  49 6d 61 67 65 20 3e 3e  |ox Disk Image >>|
00000020  3e 0a 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |>...............|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  7f 10 da be 01 00 01 00  80 01 00 00 02 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000150  00 00 00 00 00 02 00 00  00 42 00 00 00 00 00 00  |.........B......|
00000160  00 00 00 00 00 00 00 00  00 02 00 00 00 00 00 00  |................|
00000170  00 00 f0 ff 00 00 00 00  00 00 10 00 00 00 00 00  |................|
00000180  ff 0f 00 00 ff 0f 00 00  db fa c4 c9 fd 13 ea 49  |...............I|
00000190  9e ae 4e 47 43 3f a0 3c  46 37 6c be e6 fd 02 40  |..NGC?.<f7l ....@|
000001a0  a7 63 44 3f 6e 3f 26 d8  00 00 00 00 00 00 00 00  |.cD?n?&.........|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001c0  00 00 00 00 00 00 00 00  0a 02 00 00 ff 00 00 00  |................|
000001d0  3f 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00  |?...............|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Жирным шрифтом выделены необходимые четыре байта offsetData по смещению 0×0158. Можно искать их визуально, помня о little-endian-порядке байт (в этом случае искомое значение равно 0×00004200), а можно воспользоваться простенькой командой:

$ head -c 348 temp.vdi |tail -c 4|perl -ne 'print unpack("L",$_),"\n"'
16896

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

Посмотрим, что находится по этому смещению. Сразу можно предположить, что там располагается начало образа жесткого диска, из этого следует, что первые 512 байт содержат mbr. Проверим:

$ dd if=temp.vdi bs=512 count=1 skip=$((16896/512))|file -
1+0 records in
1+0 records out
512 bytes (512 B) copied, 3.9397e-05 s, 13.0 MB/s
/dev/stdin: x86 boot sector; partition 1: ID=0x83, active, starthead 1,
startsector 63, 7903917 sectors; partition 2: ID=0x5, starthead 0, startsector
7903980, 481950 sectors, code offset 0x4c

Жесткий диск содержит 2 раздела: основной размером 3859 мегабайт, начинающийся с 63 сектора (1 сектор — 512 байт), и расширенный 235 мегабайт, отведенный установщиком Debian под swap (вот это сюрприз на виртуалке). Для очистки совести проверяем заголовок первого раздела:

$ dd if=temp.vdi bs=512 count=3 skip=$((16896/512+63))|file -
3+0 records in
3+0 records out
1536 bytes (1.5 kB) copied, 4.7716e-05 s, 32.2 MB/s
/dev/stdin: Linux rev 1.0 ext3 filesystem data,
UUID=5ac94027-bf6e-43bc-9c3e-8a7830fe4ff8 (needs journal recovery) (large files)

То, что надо! Осталось смонтировать. Несколько лет назад пришлось бы дополнительно извлекать все 7903917 секторов в отдельный файл и монтировать его, но сейчас можно просто указать смещение от начала файла как опцию mount (оставшиеся расширенный раздел и swap внутри него будут проигнорированы):

$ sudo mount -o loop,offset=$((16896+63*512)) temp.vdi mnt
$ ls mnt/
bin   cdrom  etc   initrd.img      lib         media  opt   root  selinux  sys  usr  vmlinuz
boot  dev    home  initrd.img.old  lost+found  mnt    proc  sbin  srv      tmp  var  vmlinuz.old

Задача решена, все свободны.

Линус Торвальдс о Eee PC

bappoy — Fri, 29 Jan 2010 11:49:40 +0000

В предыдущем посте — небольшая история о том, как в Linux была улучшена поддержка устройств экстра-маленького размера благодаря покупки Линусом Торвальдсом вышивальной машинки :) В письме Линуса в рассылку util-linux-ng@kernel.org было упомянуто, что для управления этой машинкой он использует Eee PC с Fedora 12 на борту. Как пользователь Eee PC 701g с почти двухлетним стажем, я заинтересовался и написал Линусу письмо с несколькими вопросами о его опыте использования этих компьютеров. Получилось мини-интервью, которое и предлагается вашему вниманию.

Q: Какие модели Eee PC Вы используете?
A: У меня их две штуки: 701 и 901.

Q: Это основной компьютер или один из дополнительных?
A: Нет, конечно же, это не основной компьютер. Atom тормозной как грех. Я считаю, что процессоры с прямым выполнением команд (in-order execution) — преступление против человечности, и я уверен в том, что если Intel не предпримет значительных шагов (т.е. сделает Atom out-of-order), ARM Cortex A9 захватит рынок low-end машин.

У меня есть пара нетбуков, потому что я люблю маленькие компьютеры и использую их в поездках. Но они никогда не могли бы служить основными машинами для разработки или чем-то вроде этого.

701 слишком мелкий для того, чтобы быть полезным. Экран крошечный и у него непозволительно маленькое разрешение. Клавиатуру едва можно использовать. 901 намного лучше и мог бы быть неплохим помощником в поездках, но разрешение тоже слишком маленькое (9 дюймов нормально, но 1024×600 юзабельно только для смартфонов, а для лэптопов подошло бы как минимум 1366×768, как мне кажется)

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

ВНИМАНИЕ! Наверно, следует заметить, что мои требования могут быть завышенными по сравнению с требованиями многих других людей. Моя основная машина — Nehalem 3.2 GHz c 6 GB RAM и двумя быстрыми SSD-дисками от Intel. Поэтому мои представления о том, какая производительность может считаться “приемлемой”, могут не совпадать с представлениями других.

Q: какие задачи Eee PC помогает Вам выполнять?
A: Сейчас 701 работает тестовым стендом для совершенно различных вещей — я держу его поблизости в основном как 32-битный x86-стенд (все мои основные машины — x86-64, поэтому, если мне нужно проверить, что 32 бита еще работают, я использую 701).

901 я иногда использовал в поездках как лэптоп, и в основном он меня удовлетворял, но, откровенно говоря, существуют нормальные ноутбуки, которые намного-намного-намного лучше.

Например, я немного поигрался с машинами, основанными на CULV Core 2 Duo (вместо Atom) с экраном 1366×768 и внезапно обнаружил, что может быть намного более мощная (чем eeepc — прим.пер.) сборка. Она больше по размерам (10 дюймов), потребляет больше энергии, но оно того стоит.

Q: приобрели ли Вы эти нетбуки самостоятельно или они были подарены?
A: Оба Eee PC были подарены. 10″ CULV Core2 было самым достойным приобретением, на которое я потратил свои деньги.

Q: сколько времени Вы проводите перед этим нетбуком? Достаточен ли его размер для Вас?
A: См. выше. 701 и близко не стоял. 901 вполне пригоден к использованию, и если бы у него не было такое маленькое разрешение, он мог бы быть неплохим помощником в путешествиях.

Q: производились ли какие-нибудь аппаратные модификации?
A: в оба добавил памяти, вроде сейчас в обоих по 2 Гб (возможно, 701 был с 512 мегабайтами, и я проапгрейдил до гигабайта, слишком лениво проверять). И еще в оба добавил ПЗУ: в 701 — быструю SD-карточку (понятие “быстрая” тут весьма относительно, но для SD-карточки неплохой результат), в 901 — Mini-PCI SSD.

Мне нравятся high-end SSD (например, интеловские замены жестким дискам), но те, что используются в low-end нетбуках, страдают от ужасающе отвратительной скорости записи. Поэтому SSD в этих нетбуках, как правило, медленнее, чем реальные диски.

Q: и еще один, более общий вопрос. Как Ваше рабочее время распределено между кодированием и административной/политической/социальной деятельностью?
A: Сейчас кодирую очень мало. Практически всё время занято обсуждениями с другими разработчиками и внесением их изменений в ядро.

Линус Торвальдс о машинках для вышивания

bappoy — Fri, 29 Jan 2010 06:11:48 +0000

Часть первая.
На Рождество Санта Клаус подарил Туве Торвальдс машинку для вышивания. Среди прочих достоинств эта машинка имеет USB-интерфейс, по которому можно закачивать заранее приобретённые шаблоны вышивки в специальном закрытом формате. При подключении к компьютеру это чудо техники через минуту определяется как USB mass storage с файловой системой FAT12, при этом закачивание небольших файлов происходит очень долго и зачастую не приводит ни к каким результатам: о возникающих ошибках пользователю ничего не сообщается. Таково всё проприетарное ПО, — сетует Линус, — закрытые форматы, кривые прошивки, невнятные ошибки… Проблема предпросмотра шаблонов вышивок в формате PES на компьютере оказалась самой простой и теперь на git.kernel.org имеется специальная программа pesconvert для обслуживания вышивальных машинок.

Часть вторая.
Линус пишет письмо в рассылку util-linux-ng@vger.kernel.org с детальным описанием длительного процесса определения типов разделов и ФС на маленьком, медленном и подглючивающем блочном устройстве. После активного обсуждения (которое, несмотря на явную гиковость, можно читать как захватывающий детектив) было найдено несколько узких мест в утилите blkid, пытающейся определить более чем 50 типов файловых систем по их сигнатурам, что приводит к неоднократному чтению 69 килобайт с устройства, и в сумме объём прочитанных данных, с учётом упреждающего чтения, составляет около половины объёма всего устройства. Учитывая тот факт, что скорость обмена данными у этой штуки составляет 16 килобайт в секунду, простое определение единственного fat-раздела занимает около 30 секунд (всё это нужно для того, чтобы udev смог корректно примонтировать это устройство).

Совместными усилиями задержка была сведена к рекордному минимуму в полсекунды. Для этого Karel Zak (главный мейнтейнер util-linux-ng) добавил в blkid несколько опций, ограничивающих количество возможных ФС и объём читаемых данных для очень маленьких устройств (зачем пытаться определить raid на диске размером с полдискеты?), Линус немного оптимизировал кое-какие системные вызовы и теперь в ближайшем выпуске util-linux-ng будет заявлена поддержка очень маленьких дисков, а в ядре Linux, чем черт не шутит — частичная поддержка неких вышивальных машинок.

Часть третья последует, не пропустите.

Несколько ссылок по истории computer science

bappoy — Mon, 25 Jan 2010 12:06:44 +0000

Несколько месяцев назад заинтересовался причинами появления управляющих кодов ASCII в их нынешнем виде. Раскопки привели меня к первым терминалам в Multics, терминалы — к телетайпам, телетайпы — к телеграфным аппаратам. Тема чрезвычайно интересная, но полноценного поста у меня так и не вышло по разным причинам. Просто накидаю сюда ссылок для интересующихся (в основном на английском).

Unix и его предшественники
Multicians.org — один из основных сайтов по предыстории Unix. В основном описывает различные аспекты ОС Multics (включая рекламную брошюру (4 Мб)), но содержит также массу сведений и о ранних вариантах Unix, и о CTSS.

Unix history — основной сайт по истории Unix.

Концепция иерархической файловой системы впервые была описана в 1965 году и сильно отличалась от ныне используемой. В частности, в качестве разделителя каталогово предлагалось использовать двоеточие, а на уровень выше можно было ссылаться как на *; у каждого файла присутствовал специальный атрибут TRAP, в котором можно было указать свою процедуру проверки прав доступа к этому файлу. Но уже в Multics реализация файловой системы значительно отличалась от данного проекта иной, а в Unix и вовсе приняла привычный нам вид.

The Evolution of the Unix Time-sharing System (Dennis M. Ritchie, 1979) — краткая история Unix, рассказанная одним из её создателей.

The Restoration of Early UNIX Artifacts — опыт восстановления файлов с древней ленты, содержащей один из самых первых релизов Unix. В конце документа несколько интересных ссылок.

Исходный код Unix — отсканированная распечатка тщательно прокомментированных ассемблерных кодов Unix. Датируется 1972 годом. 11 мегабайт.

Excavating ancient abbreviations in Linux — история происхождения некоторых аббревиатур, используемых в UNIX/Linux (для чтения оригинала требуется
регистрация, поэтому ссылка на кэш гугла).

Буду благодарен за PDF/DJVU версию книги “A quarter century of Unix” by Peter Salus :)

Терминалы
Коллекция информации о текстовых терминалах, отправная точка исследований.

Рассказ одного из создателей Multics о первых терминалах и опыте удалённой домашней работы (70-е годы, суперкрутые модемы на 1200 бод) (en)

Краткая история терминалов DEC (в т.ч. VT100)

Что такое “smart terminal” и чем он отличается от “dumb terminal”. В
основном тем, что умеет проверять пользовательский ввод уже на стороне терминала, а не передаёт его серверу.

Телеграф
К вопросу о возникновении телеграфа множество интересных сведений из истории телеграфной связи

История телеграфа в России

Телеграфное дело. Пособие для сержантов и старших специалистов войск связи — раритет :) Книжка 1946 года выпуска, доступно и понятно описывает теорию электротехники и электроники по состоянию на момент окончания Великой Отечественной войны, а также знакомит читателя с основными понятиями телеграфной связи.

Шпаргалка по созданию chroot-окружения в Debian средствами debootstrap

bappoy — Wed, 20 Jan 2010 10:49:45 +0000

Для тестирования различных версий нашего продукта (внутри — БД под управлением mysql и интерфейс к ней на PHP под Apache2) требуется быстро создавать многочисленные chroot-окружения на выделенном сервере и управляться с ними.

В базовой системе (lenny) оставляем только функционал, необходимый для управления всем хозяйством, лично мне необходимы mc, openssh, vim, bash_completion и иногда svn. Также неплохо поиметь где-нибудь (да хоть на этой же машине) кэширующий прокси для репозиториев debian, типа apt-proxy или apt-cacher, чтобы не создавать излишнюю нагрузку на региональные зеркала. У нас используется apt-cacher, работающий по адресу http://apt:3142.

Debootstrap — основная рабочая лошадка:

apt-get install debootstrap

debootstrap --include=mc,ssh,vim lenny /systems/lenny http://apt:3142/ftp.debian.org/debian/

Первый аргумент — название релиза, второй — путь, куда устанавливается система, третий — адрес репозитория. В опции –include через запятую указываются пакеты, которые необходимы, но не входят в минимальную базовую систему. Debootstrap выкачивает из репозитория и устанавливает минимальный набор пакетов, теоретически сразу после этого можно делать chroot /systems/lenny и переходить к работе, но осталась еще несколько немаловажных доделок:

Добавляем идентификатор системы, который будет отображаться в скобках в приглашении шелла (читай — bash), выполняемом в chroot-окружении:

echo lenny > /systems/lenny/etc/debian_chroot

Но работа в основном ведется от имени root, а в squeeze и sid у root’а в .bashrc переменная окружения PS1 переопределяется и этот идентификатор пропадает. Поэтому если делаем виртуалку squeeze, то строчку с PS1 в /root/.bashrc лучше закомментировать:

sed -i 's/^\(export PS1.*\)$/#\1/g' /systems/squeeze/root/.bashrc

Монтируем /dev/pts — виртуальную файловую систему, которая динамически создаёт файлы терминалов /dev/pts/X для каждого нового подключения; это необходимо для нормального функционирования многих программ, работающих с терминалом, в т.ч. скриптов postinst и config пакета mysql-server:

mount -t devpts devpts /systems/lenny/dev/pts

Монтируем /proc (реально proc в новом месте будет содержать ту же информацию, что и общесистемный /proc):

mount -t proc proc /systems/lenny/proc

Чтобы apt-get не ругался на неподписанные пакеты при установке, необходимо обновить файл Release.gpg, т.к. по умолчанию debootstrap его не устанавливает. Это проще всего сделать обновлением индексных файлов репозитория:

chroot /systems/lenny apt-get update

После этого уже можно делать chroot /systems/lenny, устанавливать и настраивать пакеты, запускать/останавливать сервисы и т.д. Главная проблема при этом — следить за тем, чтобы сервисы в разных chroot’ах не конфликтовали, пытаясь занять порт на одном IP-адресе. Обычно добавляются виртуальные сетевые интерфейсы и им назначаются виртуальные же IP-адреса, которые и указываются в настройках сервисов.

Disclaimer: данная заметка описывает мой персональный опыт и не претендует на полноту. Комментарии и дополнения приветствуются.