LJ.Rossia.org fork development.'s Journal
[Most Recent Entries]
[Calendar View]
[Friends]
Below are the 11 most recent journal entries recorded in
LJ.Rossia.org fork development.'s LiveJournal:
Wednesday, May 8th, 2024 | 1:15 pm [tiphareth]
 |
установка Apache 1.3 Вот (урезанные) заметочки по компиляции 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.gzcpanm Net-SSLeay-1.90.tar.gz wget http://www.cpan.org/authors/id/S/SU/SULLR/IO-Socket-SSL-2.072.tar.gzcpanm 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 не устанавливался; в итоге хуище установилось таки.
* * * | Monday, July 20th, 2020 | 11:12 pm [mironovd]
 |
Disclaimer. Просьба не путать это сообщество с ljr_todo@lj и с ljr_bugs@lj. Здесь не рассматриваются жалобы/просьбы пользователей, а, напротив, обсуждаются внутренние проблемы движка и методы его улучшения. Необходимыми условиями для вступления являются знание исходного кода LJ и/или хороший опыт программирования на Perl и прочие полезные знания/умения (например, администрирование/настройка RDBMS). | Thursday, July 19th, 2012 | 10:51 pm [mironovd]
 |
Задачи, связанные с перестройкой движка LJR. 1. Сделать возможность использования различных БД. Очень хочется, чтобы была возможность использовать Postgres, Firebird/IB, MaxBD (бывший SAP, сейчас разрабатывается Mysql.com), Ingress (сейчас уже opensource). Необходимо привести все запросы в соответствие с SQL92/SQL99 ( nit, можешь просмотреть и выделить несовместимые?). 2. Отказаться от использования memcached. Заменит его какой-нибудь другой, работающей, системой кэширования данных. Или выкинуть нафиг совсем... 3. Избавиться от артефактов перехода со старой схемы БД , как уже описанная ранее мной проблема с юзерпиками. 4. Изменить пакет отправки почты с MIME::Lite на что-нибудь разумное. 5. Проверить работоспособность с Apache2. 6. Wiki-markup система взамен <lj>-tag. (На мой взгляд, переход на wiki-markup благотворно повлияет на все проблемы с <lj>/<ljr>-tag) Эти задачи являются довольно приоритетными и стоит ими заниматься. ... А не переписать ли все это на Ruby??? | Friday, March 14th, 2008 | 12:39 pm [kouzdra]
 |
Apache compression Я тут заметил, что при обращениях к LJR (и веротяно ко всему ленину) не используется сжатие. Mozilla морально готова пользоваться gzip compression и соответствующие запросы в Accept-Endodings прописывает. Насколько я понимаю - это надо где-то в настройках апача прописать, но я не очень компетентен в данном вопросе. PS: http://www.websiteoptimization.com/speed/tweak/compress/ | Monday, November 13th, 2006 | 12:53 pm [kouzdra]
 |
| Friday, July 29th, 2005 | 11:22 pm [kouzdra]
 |
Я в каком-то виде довел до ума свой вариант lj-gate. Там причесан код (как мне кажется - довольно аккуратно) и избавлено от затеи с -10 минут (и фиксированного сдвига по времени). Ставить это сейчас не стоит, собака еще молодая, но я был бы признателен, если бы компетентные товарищи посмотрели на это дело и решили, что с этим делать дальше и стоит ли чего-то делать. Известные проблемы: в режиме только гейтования все должно быть хорошо, но если пользователь запостит в LJ-шный дневник постиннг руками - вероятно будут проблемы с backdate. Так же syncitems идейно правилен (с ним логика куда прозрачнее), но видимо нежелателен по соображеням эффективности. Ну и возможны глюки. Я бы не стал это сейчас посылать, но я завтра на несколько дней опять отваливаю и мне хотелось бы хотя бы минимального feedback'a. Upd:Кстати - тормозит гейт, скорее всего, потому что он каждые 10 минут должен опросить все трансляции, а сделать это кроме как тупо спросив про каждую, никак невозможно. Я думаю, что это и жрет основное время - постит любой человек гораздо реже. То есть у человека максимум 5 постингов в день - а запросов на него выдается за день почти 6*24=144. Так что syncitems вероятно можно и не выкидывать. А вот если дополнить функциональность syncitems возможностью спросить сразу про пачку пользователей я думаю, проблема вполне решится (его еще бы не помешало и нотификацией о удалениях дополнить - о новых комментах он вроде сообщает, хотя дока и утверждает, что это не реализовано). ( README из архива ) | 7:15 pm [tiphareth]
 |
Итак, поставили наконец server-status, и все стало гораздо яснее. Вот типичный слепок со статуса (типичный за последние сутки - я его перегружаю постоянно) ( Read more... )И что видно из сего? А видно то, что 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 дневников, видимо, можно у нас и без всякой оптимизации запустить; просто не хочется ждать, когда начнутся проблемы. Такие дела Миша Current Mood: blankCurrent Music: Fly Pan Am - Dans Ses Cheveux Soixante Circuits | Sunday, July 24th, 2005 | 4:00 pm [kouzdra]
 |
Я сейчас с подачи yushi@lj переписываю lj-gate. Что делаю - помимо "причесывания" кода, пересаживаю его на syncitems, там все можно сделать куда корректнее, чем сейчас, в частности - update и delete там явно отличатся от create. И, безусловно, надо выкидывать этот страх с -10 минут, а просто запоминать в базе время последней синхронизации, отданное syncitems (он отдает именно реальное время события, а не дату для постинга) и от него и плясать в следующий раз. Единственный вопрос - что делать с новыми пользователями - можно либо стартовать от текущей даты, либо копировать дневник с самого начала. Второе, наверное, не очень хорошо, хотя можно сделать параметром. Сейчас я вынужден уехать на несколько дней - так что, если не горит, - не трогайте его сильно. | Wednesday, July 20th, 2005 | 11:20 pm [mironovd]
 |
Кстати, может быть, отрубить возможность включать lj_fif@lj во френды? Смысла то в этом нет... Хотя вреда пока тоже. UPD: а вред понял: от него действительно FOAF сильно перекашивает. | 11:18 pm [mironovd]
 |
OpenID на помойку... Вердикт, похоже, таков. Брэд опять сделал изменение, все стало немедленно криво. Работать с ним невозможно. ИМХО, это дело стоит пока отключить. Нафиг. Иначе пользователи будут вопить. Подождем стейбла. | Saturday, July 16th, 2005 | 11:39 pm [mironovd]
 |
Существует теперь специальная привилегия 'create_protected_com', созданная специально для того, чтобы обходить запрет на создание сообществ с запрещенными именами. Сделано хаком в community/create.bml и добавлением информации о привилегии в базу. |
|