LJ.Rossia.org fork development.

установка Apache 1.3

Wed, 08 May 2024 16:23:51 GMT

Вот (урезанные) заметочки по компиляции Apache 1.3 и установке Livejournal. Жесть неописуемая.

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

* * *

Поднял mysql из репозитория,
apt-get install mysql-server
Поднять apache с LJR не удалось,
Can't locate Digest/SHA1.pm

пошел устанавливать, cpan Digest::SHA1
жалуется Net::SSLeay 1.49 must be installed for https support

поставил нужные пакеты:
curl -L http://cpanmin.us | perl - --sudo App::cpanminus
wget http://www.cpan.org/authors/id/C/CH/CHRISN/Net-SSLeay-1.90.tar.gz
cpanm Net-SSLeay-1.90.tar.gz
wget http://www.cpan.org/authors/id/S/SU/SULLR/IO-Socket-SSL-2.072.tar.gz
cpanm IO-Socket-SSL-2.072.tar.gz
жалоба поменялась
HTTP::Tiny failed with an internal error: SSL connection failed for cpan.org: SSL connect attempt failed error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
ничего с этим сделать не мог, хуле, но
cpanm -v Digest::SHA1
работает.

Нужные модули:
cpanm -v Digest::SHA1
cpanm -v XML::RSS
эта херня не поставилась из-за ошибки в установке File::Copy::Recursive
нашел более старую версию, все заработало
cpanm -v http://cpan.metacpan.org/authors/id/D/DM/DMUEY/File-Copy-Recursive-0.38.tar.gz
(начиная с 39-й там ошибка,
https://www.perlmonks.org/?node_id=1208054 )
еще походу ей нужен expat, apt-get install libexpat-dev
cpanm -v MIME::Words
cpanm -v XML::Simple
cpanm -v DBI
cpanm -v String::CRC32
cpanm -v Compress::Zlib
cpanm -v Unicode::MapUTF8

эта вылетает из-за теста
https://rt-cpan.github.io/Public/Bug/Display/60455/
https://www.perlmonks.org/?node_id=1208054
поставил через --force, хуле

cpanm -v Class::Autouse
cpanm -v Digest::HMAC_SHA1

теперь она жалуется на lj-inline.pl, пошел в
/home/lj-admin/lj/bin, сделал
export LJHOME=/home/lj-admin/lj/
cpanm -v Inline::C
(указания нашлись тут
https://www.perlmonks.org/?node_id=1094428 )
perl lj-inline.pl

cpanm -v GD::Simple
(тут ей нужно
apt-get install pkg-config
apt-get install libgd2-xpm-dev
)

cpanm -v XMLRPC::Lite
походу там не ставится SOAP::Lite
вылетает с ошибкой при тестинге, поставил его через
apt-get install libsoap-lite-perl

cpanm -v Image::Size
cpanm -v MIME::Lite
cpanm -v IO::WrapTie
cpanm -v DBD::mysql
cpanm -v Net::DNS
(тоже не поднялась, сделал
apt-get install libnet-dns-perl
)

Теперь она жалуется на
Can't locate object method "read_color_table" via package "GD::Image"
ей по факту нужна более старая версия модуля
поставил
cpanm -v http://cpan.metacpan.org/authors/id/L/LD/LDS/GD-2.56.tar.gz
через --force притом (один тест из 7 не работал)

* * *

Поставил старый gcc. Добавил

deb http://snapshot.debian.org/archive/debian/20070730T000000Z/ lenny main
deb-src http://snapshot.debian.org/archive/debian/20070730T000000Z/ lenny main
deb http://snapshot.debian.org/archive/debian-security/20070730T000000Z/ lenny/updates main
deb-src http://snapshot.debian.org/archive/debian-security/20070730T000000Z/ lenny/updates main

apt-get update
apt-get install gcc-3.4
apt-get install g++-3.4

альтернативы:
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-6
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-3.4 40 --slave /usr/bin/g++ g++ /usr/bin/g++-3.4
update-alternatives --config gcc

./configure жалуется на ненайденные файлы, надо сделать
export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LIBRARY_PATH
rm /usr/lib/gcc/x86_64-linux-gnu/3.4.6/libgcc_s.so # (это симлинк, который сломан)
ln -s /lib/x86_64-linux-gnu/libgcc_s.so.1 /usr/lib/gcc/x86_64-linux-gnu/3.4.6/libgcc_s.so

Не пошло, жалуется на ap_os_is_path_absolute, определенную 2 раза.
Редактировал файлы, не помогло. Скачал apache 1.3.1, он жалуется
на дважды определенный getline. Редактировал файлы, не помогло.
Очевидно, gcc 3.4 ебаный слишком новый, нужно постарше. Блядь.

* * *

Леня П. смог откомпилировать apache.
Вот его письмо:

Сейчас попробовал откомпилировать апаче 1.3.42 на anupet и
он скомпилировался. У меня в домашней директории.
Для этого я сделал:

1) LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LIBRARY_PATH
export LIBRARY_PATH
без этого не находилось crt1.o (и предположительно все остальные библиотеки)
отсюда https://askubuntu.com/questions/251978/cannot-find-crti-o-no-such-file-or-directory

2) заменил getline в трех файлах с помощью sed,
отсюда https://www.cambus.net/compiling-apache-1.3.x-on-modern-linux-distributions/

Правда, компилятор на [...] почему-то gcc version 3.4.6 (Debian 3.4.6-5)
то есть довольно старый... видимо ты его поставил на новый Debian?

* * *

Я скопировал apache из директории Лени в
~lj-admin/SOURCES/ , сделал perlbrew use perl-5.8.9
и поставил компилироваться mod-perl, который
там по соседству уже был. Mod-perl стал жаловаться
на неустановленные модули перла, я поставил cpanm
curl -L http://cpanmin.us | perl - --sudo App::cpanminus
и их установил (нужно
HTML::HeadParser LWP::UserAgent
но они тянут за собой целую толпу).
Смотреть, что там происходит, можно так:
tail -f .cpanm/build.log
также потребовалось
ln -s /usr/lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/3.4.6/
ln -s /usr/lib/x86_64-linux-gnu/crtn.o /usr/lib/gcc/x86_64-linux-gnu/3.4.6/
потому что компилятор я менять на 6.3 пока не стал

Все равно не работает, жалуется на
cc1: error: unrecognized command line option "-Werror=declaration-after-statement"
cc1: error: unrecognized command line option "-Wpointer-sign"
ну ок, перейду на более новый gcc, хуле
update-alternatives --config gcc

Установил apache+modperl в /usr/local/apache/
вроде ок. Походу для установки SOAP::Lite
понадобились заголовки openssl, пришлось понижать
версию libssl и массово удалять пакеты из дебиана,
потому что иначе libssl-dev не устанавливался;
в итоге хуище установилось таки.

* * *

Comments

Apache compression

Fri, 14 Mar 2008 09:42:14 GMT

Я тут заметил, что при обращениях к LJR (и веротяно ко всему ленину) не используется сжатие. Mozilla морально готова пользоваться gzip compression и соответствующие запросы в Accept-Endodings прописывает. Насколько я понимаю - это надо где-то в настройках апача прописать, но я не очень компетентен в данном вопросе.

PS: http://www.websiteoptimization.com/speed/tweak/compress/

Comments

Mon, 13 Nov 2006 09:55:59 GMT

А есть такой вопрос - такая фича LJ, как customview у нас есть?
(http://community.livejournal.com/howto/16676.html)

Или это какое-то нововведение LJ?

Comments

Fri, 29 Jul 2005 19:18:04 GMT

Я в каком-то виде довел до ума свой вариант lj-gate.

Там причесан код (как мне кажется - довольно аккуратно) и избавлено от затеи с -10 минут (и фиксированного сдвига по времени). Ставить это сейчас не стоит, собака еще молодая, но я был бы признателен, если бы компетентные товарищи посмотрели на это дело и решили, что с этим делать дальше и стоит ли чего-то делать.

Известные проблемы: в режиме только гейтования все должно быть хорошо, но если пользователь запостит в LJ-шный дневник постиннг руками - вероятно будут проблемы с backdate. Так же syncitems идейно правилен (с ним логика куда прозрачнее), но видимо нежелателен по соображеням эффективности. Ну и возможны глюки.

Я бы не стал это сейчас посылать, но я завтра на несколько дней опять отваливаю и мне хотелось бы хотя бы минимального feedback'a.

Upd:Кстати - тормозит гейт, скорее всего, потому что он каждые 10 минут должен опросить все трансляции, а сделать это кроме как тупо спросив про каждую, никак невозможно. Я думаю, что это и жрет основное время - постит любой человек гораздо реже. То есть у человека максимум 5 постингов в день - а запросов на него выдается за день почти 6*24=144.

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

README:
----------------------
lj-gate.pl - собственно главная программа
Util.pm - набор пользушных функций для работы с клиентским
протоколом LJ
LJDB.pm - набор функций для доступа к БД гейта
add.pl - переписан с использованием LJDB.pm

Изменения в формате БД:

добавлена колонка last_sync char (30) в таблицу rlj2lj.
Если в этом поле содержится NULL, в качестве времени
последний синхронизации берется текущий момент.

Соотвественно - должно быть достаточно ее создать
в таблице.

Другие изменения:пересажено на syncitems. Идеологически
это правильно, практически - вероятно добавит тормозов
(ибо каждая запись при этом берется отдельным запросом).

По-видимому, это надо херить, но сначала вероятно
есть смысл попробовать перелезть на плоский протокол.

Comments

Fri, 29 Jul 2005 18:13:47 GMT

Итак,
поставили наконец server-status,
и все стало гораздо яснее.
Вот типичный слепок со статуса
(типичный за последние сутки - я его
перегружаю постоянно)

Current Time: Friday, 29-Jul-2005 21:56:57 MSD
Restart Time: Friday, 29-Jul-2005 10:15:41 MSD
Parent Server Generation: 0
Server uptime: 11 hours 41 minutes 16 seconds
Total accesses: 115579 - Total Traffic: 478.7 MB
CPU Usage: u124.77 s5.48 cu.12 cs.05 - .31% CPU load
2.75 requests/sec - 11.7 kB/second - 4343 B/request
1 requests currently being processed, 11 idle servers

Srv	PID	Acc	M	CPU 	SS	Req	Conn	Child	Slot	Client	VHost	
0-0	15602	0/188/7683	_ 	3.08	47	50	0.0	0.61	33.40 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
1-0	15672	0/74/7570	_ 	1.47	11	72	0.0	0.41	30.07 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
2-0	15674	0/79/7573	_ 	1.50	149	13	0.0	0.29	29.41 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
3-0	15677	0/84/7577	_ 	1.86	29	48	0.0	0.39	31.02 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
4-0	15683	0/66/7558	W 	1.33	5	0	0.0	0.39	31.38 	129.234.4.1	lj.rossia.org	GET /server-status HTTP/1.0
 
5-0	15712	0/42/7535	_ 	0.96	23	2	0.0	0.27	29.11 	81.26.152.28	lj.rossia.org	POST /interface/flat HTTP/1.0
 
6-0	15733	0/32/7524	_ 	0.67	20	22	0.0	0.22	31.15 	81.26.152.28	lj.rossia.org	POST /interface/flat HTTP/1.0
 
7-0	15735	0/30/7025	_ 	0.30	23	13	0.0	0.10	29.29 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
8-0	15738	0/25/7021	_ 	0.47	36	13	0.0	0.17	31.46 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
9-0	15740	0/23/7015	_ 	0.48	31	52	0.0	0.14	29.33 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
10-0	-	0/0/6494	. 	9.81	489	14	0.0	0.00	26.46 	213.180.214.132	lj.rossia.org	GET /users/evolor/data/rss HTTP/1.1
 
11-0	-	0/0/6497	. 	10.39	327	1	0.0	0.00	25.02 	64.2.106.163	lj.rossia.org	GET /img/bluewhite/sidebarfade.gif HTTP/1.1
 
12-0	-	0/0/5996	. 	8.77	446	9	0.0	0.00	24.66 	213.180.214.132	lj.rossia.org	GET /users/tichy/data/rss HTTP/1.1
 
13-0	15623	0/149/5145	_ 	2.24	31	13	0.0	0.32	20.45 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
14-0	-	0/0/4992	. 	11.11	2266	1	0.0	0.00	20.13 	82.96.193.32	lj.rossia.org	GET /img/talk/none.gif HTTP/1.1
 
15-0	-	0/0/3997	. 	14.94	8907	6	0.0	0.00	18.21 	80.247.47.58	lj.rossia.org	GET /userpic/483/957 HTTP/1.1
 
16-0	-	0/0/2997	. 	8.02	8997	5	0.0	0.00	13.34 	217.15.150.143	lj.rossia.org	GET /userpic/1040/1757 HTTP/1.1
 
17-0	-	0/0/1997	. 	12.12	6548	1	0.0	0.00	8.35 	81.197.76.33	lj.rossia.org	GET /img/bluewhite/vline.gif HTTP/1.1
 
18-0	-	0/0/1499	. 	15.86	23305	50	0.0	0.00	7.36 	81.19.69.109	lj.rossia.org	POST /interface/xmlrpc HTTP/1.1
 
19-0	-	0/0/999	. 	11.18	23306	1	0.0	0.00	4.01 	213.180.193.193	lj.rossia.org	GET /js/x_core.js HTTP/1.1
 
Srv	Child Server number - generation
PID	OS process ID
Acc	Number of accesses this connection / this child / this slot
M	Mode of operation
CPU	CPU usage, number of seconds
SS	Seconds since beginning of most recent request
Req	Milliseconds required to process most recent request
Conn	Kilobytes transferred this connection
Child	Megabytes transferred this child
Slot	Total megabytes transferred this slot

И что видно из сего?

А видно то, что 95% из всех процессов Апача
(из которых каждый, я хочу отметить, жрет по
50 мегабайт) заняты совершенно не тем.
А именно:

1. Примерно половина грузят статику

2. 40% занимаются тем, что считывают
записи LJ через клиентский интерфэйс.
Эти 40% жрут вчетверо больше ресурсов,
чем все остальное вместе взятое.

3. Из оставшихся 10% половина грузят
жабий скрип.

Приоритетные направления оптимизации из этого
совершенно ясны: это

1. Перевод статики на другой сервер (на днях
я сие обеспечу, если никто не возражает)

2. Избавление lj-gate от /interface/xmlrpc
который, судя по всему, совершенно сломан.
Надо исправить его на /interface/plain
либо (если это не улучшит ситуации)
вообще заменить на прямое обращение
к базе.

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

А в целом - мы имеем (при 1863 пользователях)
load average 0.30. Это при том, что при 1-1.5
она работает идеально, а при 4-5 работает
без особых проблем (хотя и тормозит).
То есть 20000 дневников, видимо, можно
у нас и без всякой оптимизации запустить;
просто не хочется ждать, когда начнутся
проблемы.

Такие дела
Миша

Comments

Sun, 24 Jul 2005 11:54:42 GMT

Я сейчас с подачи yushi@lj переписываю lj-gate. Что делаю -
помимо "причесывания" кода, пересаживаю его на syncitems, там
все можно сделать куда корректнее, чем сейчас, в частности -
update и delete там явно отличатся от create. И, безусловно, надо выкидывать
этот страх с -10 минут, а просто запоминать в базе
время последней синхронизации, отданное syncitems (он отдает именно
реальное время события, а не дату для постинга) и от него
и плясать в следующий раз.

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

Сейчас я вынужден уехать на несколько дней - так что, если не горит,
- не трогайте его сильно.

Comments

Wed, 20 Jul 2005 19:13:06 GMT

Кстати, может быть, отрубить возможность включать lj_fif@lj во френды? Смысла то в этом нет...
Хотя вреда пока тоже.
UPD: а вред понял: от него действительно FOAF сильно перекашивает.

Comments

OpenID на помойку...

Wed, 20 Jul 2005 19:11:04 GMT

Вердикт, похоже, таков. Брэд опять сделал изменение, все стало немедленно криво. Работать с ним невозможно.
ИМХО, это дело стоит пока отключить. Нафиг. Иначе пользователи будут вопить.
Подождем стейбла.

Comments

Sat, 16 Jul 2005 19:32:06 GMT

Существует теперь специальная привилегия 'create_protected_com', созданная специально для того, чтобы обходить запрет на создание сообществ с запрещенными именами.
Сделано хаком в community/create.bml и добавлением информации о привилегии в базу.

Comments