Подписал нашу контору на два комплекта LinuxFormat на год. Вообще, журнал очень интересный, получше Cosmopolitan-а будет ;)
Интерфейс управления подпиской достаточно толковый, требуется минимум телодвижений, даже если подписываться на юридическое лицо. В понедельник распечатал и отнес в бухгалтерию счет, а сегодня журналы уже притаранил СПСР с курьером. Красота!
2008-02-21
2008-02-20
user там, user здесь...
одно время CGI запускался из-под пользователя alexey. теперь - из-под пользователя ctrlsh... нелегко жить в эпоху перемен (с)
2008-02-19
начальник, дай виртуалки, ну ДАЙ!
Ну, вот я и напоролся на капитальные ограничения на хостинге от Masterhost.
Если зайти через SSH, то ulimit -a покажет такую картину:
Если зайти через SSH, то ulimit -a покажет такую картину:
core file size (blocks, -c) 0
data seg size (kbytes, -d) 131072
file size (blocks, -f) 1048576
max locked memory (kbytes, -l) 16384
max memory size (kbytes, -m) 65536
open files (-n) 128
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 16384
cpu time (seconds, -t) 600
max user processes (-u) 96
virtual memory (kbytes, -v) 196608
core file size (512-blocks, -c) 0
data seg size (kbytes, -d) 32768
file size (512-blocks, -f) 2097152
locked memory (kbytes, -l) 6144
max memory size (kbytes, -m) 65536
open files (-n) 32
stack size (kbytes, -s) 6144
cpu time (seconds, -t) 15
max user processes (-u) 64
virtual mem size (kbytes, -v) 65536
sbsize (bytes, -b) unlimited
2008-02-16
Swig It!
Продолжаем пытки хостинга, теперь нужно исхитриться и подключить c++ - либу к Perl. Делается это, конечно же, при помощи swig. К сожалению, на хостинге я его найти не смог, пришлось качать и ставить самому
Вкратце:
Некоторое удивление я испытал, запуская в домашнем каталоге make. Иногда он мне отвечает Permission denied. Перавя и естественная реакция - ls -la /usr/bin/make, дабы увидеть, что воистину +x. Потом начинаю перебирать дебаговые ключи -v, -dA: с каким-то из них make запускается. Понять, почему иногда я вижу Permission denied, не смог (где же ты, strace?).
Важные узелки на память:
Вкратце:
- качаем wget-ом исходники в ~/distro,
- tar -xzf tarball.tar.gz -C ~/usr/local
- cd ~/src/swig-xxx и ./configure --prefix ~/usr/local
- make install
- export PATH=$PATH:/home/user1234/usr/local/bin
Некоторое удивление я испытал, запуская в домашнем каталоге make. Иногда он мне отвечает Permission denied. Перавя и естественная реакция - ls -la /usr/bin/make, дабы увидеть, что воистину +x. Потом начинаю перебирать дебаговые ключи -v, -dA: с каким-то из них make запускается. Понять, почему иногда я вижу Permission denied, не смог (где же ты, strace?).
Важные узелки на память:
- компилировать C с ключем -fPIC
- для создания .so использовать g++ -shared -o desination.so
- при запуске LD_LIBRARY_PATH должен указывать туда, где лежит .so
2008-02-14
Запустить скрипт Perl или умереть
Решил наконец решить задачу подсчета и проверки контрольных сумм файлов, входящих в наш дистрибутив. Типа контроль целостности инсталляции. Работа заняла около 15 минут чистого времени (Perl, при наличии Digest::MD5 - все тривиально, сами понимаете).
И тут я задумался: как же все это будет запускаться на машине клиента, под Windows, где Perl-а и нет в помине?! Лицензия ActivePerl запрещает распространять его дистрибутив, да если даже это и делать - из пушки по муравьям (с). И начал я искать способ конвертнуть Perl-скрипт в .exe.
Как ни странно, в теории оказалось есть несколько способов:
В итоге... PerlApp - платный, надо качать PerlStudio PRO, крякать и т.п. Ну никак не соответствует духу свободного ПО. Perl2exe - мало того, что платный, так и еще и требует положить дохрена dll-ек из дистрибутива к себе (утомительная итерационная игра с сомнительным результатом). А PAR для ActivePerl не возможен - судя по странице успешных компиляций содержимого CPAN, pp просто не поддерживается на Windows, т.к. в этой сточке горит веселая надпись "failed". Что-то мне кажется, ActiveState лукавит: ну кто станет поддерживать бесплатное решение, которое конкурирует с их же собственным платным?!..
Короче... Решил все на С написать! Кстати, в рекомендации rfc1321 и исходничек есть. Правда, особенно разбираться, как правильно подключать C-исходник к C++ в MSVC я не стал, поправил md5.h по своему разумению.
А правильнее все-таки было бы с Perl-ом...
И тут я задумался: как же все это будет запускаться на машине клиента, под Windows, где Perl-а и нет в помине?! Лицензия ActivePerl запрещает распространять его дистрибутив, да если даже это и делать - из пушки по муравьям (с). И начал я искать способ конвертнуть Perl-скрипт в .exe.
Как ни странно, в теории оказалось есть несколько способов:
В итоге... PerlApp - платный, надо качать PerlStudio PRO, крякать и т.п. Ну никак не соответствует духу свободного ПО. Perl2exe - мало того, что платный, так и еще и требует положить дохрена dll-ек из дистрибутива к себе (утомительная итерационная игра с сомнительным результатом). А PAR для ActivePerl не возможен - судя по странице успешных компиляций содержимого CPAN, pp просто не поддерживается на Windows, т.к. в этой сточке горит веселая надпись "failed". Что-то мне кажется, ActiveState лукавит: ну кто станет поддерживать бесплатное решение, которое конкурирует с их же собственным платным?!..
Короче... Решил все на С написать! Кстати, в рекомендации rfc1321 и исходничек есть. Правда, особенно разбираться, как правильно подключать C-исходник к C++ в MSVC я не стал, поправил md5.h по своему разумению.
А правильнее все-таки было бы с Perl-ом...
2008-02-08
Итак, что надо для того, чтобы на хостинге от Masterhost заработал TWiki?
1) Поправить TWiki.pm так, чтобы не генерировалось \n\n перед Content-Length
2) Не использовать для шифрования паролей crypt. Я выбрал md5.
3) Очень долго мучился с кодировками, помогло отрубание нафиг WSYWSIG плугина. Думаю, это никак с хостингом не связано.
1) Поправить TWiki.pm так, чтобы не генерировалось \n\n перед Content-Length
2) Не использовать для шифрования паролей crypt. Я выбрал md5.
3) Очень долго мучился с кодировками, помогло отрубание нафиг WSYWSIG плугина. Думаю, это никак с хостингом не связано.
Tab в Firefox-е
Сегодня случайно по привычке нажал TAB в Firefox-е и обнаружил, что он работает в строке ввода URI приблизительно так же, как и в lookup командной строке bash.
Вернулся, проверил еще раз. Точно, работает! Правда, он работает, как lookup в командном режиме vim.
Почему я раньше этого не замечал?..
Вернулся, проверил еще раз. Точно, работает! Правда, он работает, как lookup в командном режиме vim.
Почему я раньше этого не замечал?..
2008-02-07
Многоязычность в TWiki
Я использую ForUserLanguagesPlugin, который позволяет на одной странице держать и оригинальный текст, и переводы. Именно из-за этого я его и взял на вооружение, на мой вкус одна страница удобнее 10-ти, когда вносишь изменения оригинал и перевод перед глазами одновременно. Да, еще не надо дублировать всякие элементы, если они перевода не требуют (например, фото какого-нибудь hardware-оборудования).
Плугин довольно примитивен, и там есть пара недочетов. Первый - не работает инсталляционный скрипт. С этим все просто - руками рассовываем файлы по каталогам, ставим пермишены. Вторая проблема посложнее: при выборе языка плугин опирается на переменную LANGUAGE, которая сохраняется в сессии. В отсутствие таковой будет установлен дефолтовый английский (lib/TWiki/Plugins/ForUserLanguagesPlugin.pm, sub initPlugin):
$ul = TWiki::Func::getSessionValue( 'LANGUAGE' ) || 'en';
Но ведь хочется-то, чтобы было сразу на том языке, который нам понятен! Представьте себе ситуацию: заходите вы на wiki, там все по-анлгицки. Но справа вверху язык уже выбран - русский! Для того, чтобы получить русский вывод от этого плагина, надо переключиться на любой другой язык и обратно. Толко тогда getSessionValue( 'LANGUAGE' ) вернет 'ru'.
И я задумался, как это сделать без промежуточной переадресации, поскольку что-то менять в TWiki-скриптах меня пугало. Я подумал, что логичнее всего прислушаться к браузеру (так делает и сам TWiki, когда выбирает язык интерфейса пользователя) и вот, что в итоге получилось:
my $lang_det = TWiki::Func::getSessionValue( 'LANGUAGE' );
unless ($lang_det) {
my $accept_language = $ENV{HTTP_ACCEPT_LANGUAGE};
if ( $accept_language =~ /^\w+$/ ) {
$lang_det = $accept_language;
}
if ( $accept_language =~ /^\*$/ ) {
$lang_det = 'en';
}
if ( $accept_language =~ /,/ ) {
($lang_det) = $accept_language =~ /^(\w+?)/;
}
unless ($lang_det) {
$lang_det = 'en';
}
}
$ul = $lang_det;
Конечно, это далеко от совершенства, но работает для MSIE7, Netscape Navigator 9, Firefox 2, Mozilla 1.7.x. Ну и если будете совершенствовать, загляните в RFC2616 :)
Плугин довольно примитивен, и там есть пара недочетов. Первый - не работает инсталляционный скрипт. С этим все просто - руками рассовываем файлы по каталогам, ставим пермишены. Вторая проблема посложнее: при выборе языка плугин опирается на переменную LANGUAGE, которая сохраняется в сессии. В отсутствие таковой будет установлен дефолтовый английский (lib/TWiki/Plugins/ForUserLanguagesPlugin.pm, sub initPlugin):
$ul = TWiki::Func::getSessionValue( 'LANGUAGE' ) || 'en';
Но ведь хочется-то, чтобы было сразу на том языке, который нам понятен! Представьте себе ситуацию: заходите вы на wiki, там все по-анлгицки. Но справа вверху язык уже выбран - русский! Для того, чтобы получить русский вывод от этого плагина, надо переключиться на любой другой язык и обратно. Толко тогда getSessionValue( 'LANGUAGE' ) вернет 'ru'.
И я задумался, как это сделать без промежуточной переадресации, поскольку что-то менять в TWiki-скриптах меня пугало. Я подумал, что логичнее всего прислушаться к браузеру (так делает и сам TWiki, когда выбирает язык интерфейса пользователя) и вот, что в итоге получилось:
my $lang_det = TWiki::Func::getSessionValue( 'LANGUAGE' );
unless ($lang_det) {
my $accept_language = $ENV{HTTP_ACCEPT_LANGUAGE};
if ( $accept_language =~ /^\w+$/ ) {
$lang_det = $accept_language;
}
if ( $accept_language =~ /^\*$/ ) {
$lang_det = 'en';
}
if ( $accept_language =~ /,/ ) {
($lang_det) = $accept_language =~ /^(\w+?)/;
}
unless ($lang_det) {
$lang_det = 'en';
}
}
$ul = $lang_det;
Конечно, это далеко от совершенства, но работает для MSIE7, Netscape Navigator 9, Firefox 2, Mozilla 1.7.x. Ну и если будете совершенствовать, загляните в RFC2616 :)
2008-02-01
Сутки пытался развернуть TWiki на мастерхосте, но так и не смог.
При обращении к bin/view/TWiki/WebHome сервер упорно выдает ошибку HTTP 502/ Bad Gateway. При этом заголовки выглядят очень забавно: если вывод успешен, я вижу:
HTTP/1.1 200 OK
Date: Thu, 31 Jan 2008 12:55:38 GMT
Content-Type: text/html; charset=ISO-8859-1
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=5
Server: Apache
Cache-Control: max-age=0
Expires: Thu, 31 Jan 2008 12:55:36 GMT
А в случае ошибки -
HTTP/1.1 502 Bad Gateway
Server: nginx/0.5.18
Date: Thu, 31 Jan 2008 12:54:32 GMT
Content-Type: text/html
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=5
Особенно интересна строка заголовка Server... Погуглив, нашел, что это мегасервер ngnix, и видимо через него балансируется нагрузка на виртуальный хостинг на машине (там FreeBSD 6).
Я повторил запрос уже с консоли хостинга (lynx - незаменимый текстовый браузер! памятка: не забыть поставить памятник разработчикам и пристрелить тех, кто утверждал, что текстовый браузер - это глупость), и снова полюбовался на 502/Bad Gateway.
Сослаться на собственную тупость не могу: развернуть TWiki на домашней машине под Debian 4.0 заняло ровно 7 минут.
Написал в поддержку... Первым ответом у меня тактично поинтересовались, смотрел ли я error_log и где находится скрипт. Я пояснил, а дальше в ответ - тишина.
И только я собрался звонить и голосом озвучивать свою проблему (ибо прошло более 4 суток с момента моего второго письма), я, чтобы не выглядеть идиотом, решил на всякий случай проверить, существует ли глюк до сих пор. Оказалось - уже поправили! А на следующий день пришел ответ, такого содержания:
Приносим извинения за задержку с ответом.
Исправления должны быть таковы:
--- lib/TWiki.pm.orig Tue Feb 5 20:36:07 2008
+++ lib/TWiki.pm Tue Feb 5 20:49:33 2008
@@ -603,7 +603,7 @@
# - too 5.8 dependent
# my $len = do { use bytes; length( $text ); };
my $len = length($text);
- $hdr =~ s/\n$/Content-Length: $len\n\n/s if $len;
+ $hdr =~ s/^(.*?)$/Content-Length: $len\n$1/s if $len;
} else {
$hdr = '';
}
В принципе, круто. Дело в том, что я смотрел на \n\n перед строкой Content-Length, но... это работало под Debian и я подумал, что так и надо. А зря... \n\n отделяет заголовки от контента, и я это великолепно знал...
Короче, засчитываем 1 балл в пользу техподдержки Мастерхост.
При обращении к bin/view/TWiki/WebHome сервер упорно выдает ошибку HTTP 502/ Bad Gateway. При этом заголовки выглядят очень забавно: если вывод успешен, я вижу:
HTTP/1.1 200 OK
Date: Thu, 31 Jan 2008 12:55:38 GMT
Content-Type: text/html; charset=ISO-8859-1
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=5
Server: Apache
Cache-Control: max-age=0
Expires: Thu, 31 Jan 2008 12:55:36 GMT
А в случае ошибки -
HTTP/1.1 502 Bad Gateway
Server: nginx/0.5.18
Date: Thu, 31 Jan 2008 12:54:32 GMT
Content-Type: text/html
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=5
Особенно интересна строка заголовка Server... Погуглив, нашел, что это мегасервер ngnix, и видимо через него балансируется нагрузка на виртуальный хостинг на машине (там FreeBSD 6).
Я повторил запрос уже с консоли хостинга (lynx - незаменимый текстовый браузер! памятка: не забыть поставить памятник разработчикам и пристрелить тех, кто утверждал, что текстовый браузер - это глупость), и снова полюбовался на 502/Bad Gateway.
Сослаться на собственную тупость не могу: развернуть TWiki на домашней машине под Debian 4.0 заняло ровно 7 минут.
Написал в поддержку... Первым ответом у меня тактично поинтересовались, смотрел ли я error_log и где находится скрипт. Я пояснил, а дальше в ответ - тишина.
И только я собрался звонить и голосом озвучивать свою проблему (ибо прошло более 4 суток с момента моего второго письма), я, чтобы не выглядеть идиотом, решил на всякий случай проверить, существует ли глюк до сих пор. Оказалось - уже поправили! А на следующий день пришел ответ, такого содержания:
Приносим извинения за задержку с ответом.
Исправления должны быть таковы:
--- lib/TWiki.pm.orig Tue Feb 5 20:36:07 2008
+++ lib/TWiki.pm Tue Feb 5 20:49:33 2008
@@ -603,7 +603,7 @@
# - too 5.8 dependent
# my $len = do { use bytes; length( $text ); };
my $len = length($text);
- $hdr =~ s/\n$/Content-Length: $len\n\n/s if $len;
+ $hdr =~ s/^(.*?)$/Content-Length: $len\n$1/s if $len;
} else {
$hdr = '';
}
В принципе, круто. Дело в том, что я смотрел на \n\n перед строкой Content-Length, но... это работало под Debian и я подумал, что так и надо. А зря... \n\n отделяет заголовки от контента, и я это великолепно знал...
Короче, засчитываем 1 балл в пользу техподдержки Мастерхост.
Подписаться на:
Сообщения (Atom)