Debian OpenLogo

Миналия ден един приятел ми писа че имал проблем с Debian server-a си. По точно не му пазел сессиите повече от 30 минути независимо колко се настройва session.gc_maxlifetime. В общи линии проблема е че Debian са решили да пренапишат поведението на сесиите като вместо garbage collector-а се стартира един cron на всяка 9-та и 39-та минута който почиства старите сесии. Тои се намира в /etc/cron.d/php5

като цяло семпличък скрипт който стартира от своя страна  /usr/lib/php5/maxlifetime и в него се намира променливата колко време да е живота на кукито който е 1440 секунди или 24 минути 😉 От тук нататък има 2 варианта или да се спре крон-а и по този начин се прекратява автоматичното чистене което може по късно да се пренастрой от php.ini или направо в самия скрипт да се промени продължителноста на живота на сесиите с променливата max. Аз лично предпочитам втория вариант. Доста по чист е като цяло но има и недостатък – ако се презапише файлът промените ни ще се изгубят което си е неприятен факт.

ps. Сега като се замисля вероятно ако се дефинира друго място където да се съхранява сеиината информация чрез самото php би трябвало да излезе извън обхвата на скрипта и по този начин да се използва пак по нормален сесията без да прекъсва грубо.


ini_set('session.gc_maxlifetime', 14400);
 ini_set('session.gc_probability', 1);
 ini_set('session.gc_divisor', 100);
 session_save_path(APP_PARENT_DIR . '/sessions');

Enhanced by Zemanta

Днес ще разказвам за неволите си около един сървър със Suhosin patch и как Debian Sqeeze се справя с него. Сега да започнем малко по отдалече. Когато си инсталирате php през пакетната система на Debian (stable за другите не мога да кажа как е още) задължително ви се инсталира и suhosin mod към него. Имах проблеми с едни плу-кадърно написана php система и взех кардиналното решение вместо да правя дебъг на системата и да връщам репорт на разработчика да разкарам кръпката за сигурност и така да си спестя главоболията. Общо взето смело мога да кажа че това е било едно от най глупавите ми решения взимани някога. Най напред премахвам модула на php5-suhosin рестартирам web server-a и опа греда – patch-a все още е зареден. След много кратко проучване откривам, че пакета е компилирах и с пача директно в кода което ще рече че няма изключване или премахване освен ако не се прекомпилира кода наново без пача. Решавам че ще го дръпna и прекомпилирам до deb пакет. Речено сторено правя си apt-get source php5 дърпа ми се настоящия сорс код, разпакетирва се и прочие. Тука идеалната ми идея да сваля сорса на пакета да премахна пача и да го компилирам отново до дебиански пакет плюс една две малки оптимизации по компилацията. Речено сторено – премахнах ненужния пач от debian/patches/suhosin.patch премахнах го да не играе и в debian/patches/series. До тук всичко ясно и без проблеми. След това пускам да се компилира пакета с debuild и както очаквах ми изгърмя компилацията заради липсващи хедъри. Естествено че ще има такива липси – все пак съм с debian netinstall. Поправям набързо глупостта си пускам наново компилацията, в един момент отново премира само, че със странна грешка в Zend/zend_stream.h или .c не помня точно (ако ми се занимава може по късно да проверя точно кой файл и на кой ред гърмеше). След известно недоумяване какво се случва и защо аджеба гърми в Zend ядрото – където не би трябвало да гърми по никаква причина и едно малко по дълго проучване откривам че тоя проблем е относително рядък и няма много сигнали за него. Подозирам че някоя от кръпките в сорса не е наред но сега нямам нерви за да го проверявам. Хммммм странно супер странно. Почти реших да си компилирам чисто php но реших да пробвам огледалата на dotdeb да видим там какво ще се случи. Там компилацията умря заради някакви странни зависимости но подмина проблемите в основната част. Което от своя страна е разбираемо нямаше ги те 30-40 кръпки който бяха в стабилния пакет. След няколко дълги и неуспешни опита ми писна и сви свалих ванила пакета и го компилирах с почти debian-ски опции с идеята да пренапише настоящата ми инсталация и като се инсталират нови пакети от хранилката да може да има поведение на пакет инсталиран от хранилището (вероятно поредното не обособно разумно решение). Както очаквах без всички кръпки инсталацията мина гладко. Това е изхода на config.nice файлът ми:


#! /bin/sh
#
# Created by configure

CFLAGS='-g -O2 -fPIC -Wall -fsigned-char -fno-strict-aliasing   -gstabs' \
CXXFLAGS='-g -O2' \
'./configure' \
'--with-apxs2=/usr/bin/apxs2' \
'--prefix=/usr/local/php5' \
'--disable-cgi' \
'--with-config-file-path=/etc/php5/apache2' \
'--with-config-file-scan-dir=/etc/php5/apache2/conf.d' \
'--build=x86_64-linux-gnu' \
'--host=x86_64-linux-gnu' \
'--sysconfdir=/etc' \
'--localstatedir=/var' \
'--mandir=/usr/share/man' \
'--disable-debug' \
'--with-regex=php' \
'--disable-rpath' \
'--disable-static' \
'--with-pic' \
'--with-layout=GNU' \
'--with-pear=/usr/share/php' \
'--enable-calendar' \
'--enable-fileinfo' \
'--enable-hash' \
'--enable-json' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sysvmsg' \
'--enable-bcmath' \
'--with-bz2' \
'--enable-ctype' \
'--without-gdbm' \
'--with-iconv' \
'--enable-exif' \
'--enable-ftp' \
'--enable-dbase' \
'--with-gettext' \
'--enable-mbstring' \
'--with-onig=/usr' \
'--with-pcre-regex' \
'--with-mysql=shared,mysqlnd' \
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' \
'--with-mysqli=shared,mysqlnd' \
'--enable-pdo=shared' \
'--with-pdo-mysql=shared,mysqlnd' \
'--with-pdo-odbc=shared,unixODBC,/usr' \
'--with-pdo-pgsql=shared,/usr/bin/pg_config' \
'--with-pdo-sqlite=shared,/usr' \
'--with-pdo-dblib=shared,/usr' \
'--enable-phar' \
'--enable-shmop' \
'--enable-sockets' \
'--enable-dom' \
'--enable-wddx' \
'--enable-tokenizer' \
'--with-zlib' \
'--with-kerberos=/usr' \
'--with-openssl=/usr' \
'--enable-soap' \
'--enable-zip' \
'--with-mhash=yes' \
'--with-exec-dir=/usr/lib/php5/libexec' \
'--with-system-tzdata' \
'--without-mm' \
'--with-readline=/usr' \
'--without-sybase-ct' \
'--without-sqlite' \
'--without-sqlite3' \
'--without-mssql' \
'--enable-pcntl' \
'--enable-inline-optimization' \
"$@"

Това е конфигурация близка до тази на компилацията на dotdeb. Като основаното и най важно е prefix опцията където ще се разполагат файловете с библиотеките на php. Него както и другите пъти ги коригирайте според вашата система така че да не се усети компилацията с промяна на пътищата.

Enhanced by Zemanta

Да движиш някакъв проект в който се програмира активно без контрол над версиите в днешно време е пълно безумие. Като цяло има множество опции bazaar , mercurial , git , svn . Така тука ако ще очаквате да обяснявам кой контрол над версиите е по добър и защо няма да е. При нас използваме git. Причини много – лесно се настройва, много е гъвкав, написан е от Линус Торвалдс за да обслужва Linux Kernel версиите, последното са поне 2 причини 😉 . Днес ми се наложи да създам ново хранилище, че се започна нов проект. Реално съм създавал малко хранилища и то преди много време когато са ни трябвали и съм забравил тънките моменто по това. Създавам хранилището блъснах няколко файла за първото съхранение всичко мина точно. Самата настройка на хранилището беше стандартна:


git init
echo "Short project's description" > .git/description
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git commit -a
touch .git/git-daemon-export-ok

В общи линии нищо което да не е наред. След това реших да тествам от отдалечена машина да съхраня съдържание и при опита да го push-на ми изгърмя с грозното съобщение:

Pushing to git://gitHost/project
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require ‘git reset –hard’ to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set ‘receive.denyCurrentBranch’ configuration variable to
remote: error: ‘ignore’ or ‘warn’ in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: ‘receive.denyCurrentBranch’ configuration variable to ‘refuse’.
To git://gitHost/project
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to ‘git://gitHost/project’

Така очевидно се опитвам да комитвам в главното дърво на проекта и софтуера вежливо ме режи. Като цяло нямам никакво намерение да правя допълнителен бранч понеже хората които участват по проектите са си ясни и ред други причини. Тука идва момента да отбележа че съм дефинирал много некадърно заглавието но това е друг момент. Като цяло решението на проблема е тривиално в .git/config на проекта ви трябва да добавите следната директива:


[receive]
denyCurrentBranch = false

След това всичко си идва на мястото.

http://www.youtube.com/watch?v=16bRiH5zfOY

Packet Tracer

Image via Wikipedia

Днес ми се наложи да демонстрирам една симулация през Cisco Packet Tracer на машина на която не беше инсталиран. В общи линии малоумщината е, че стимулатора на Cisco е за x86 машини а при мен машината беше x64. При опит за инсталация умира с грозното съобщение

Attempting to install package now
dpkg: error processing PacketTracer-5.3_3.i386.deb (–install):
package architecture (i386) does not match system (amd64)
Errors were encountered while processing:
PacketTracer-5.3_3.i386.deb

Общо взето всичко е очевидно Debian-ския пакет не иска да се инсталира защото е за друга архитектура. От тук нататък проблема е ясен dpkg + форсирано инсталиране за да байпаснем грешката за различна платформа. Bin-ския файл на инсталатора реално е само разархивиращ се архив който се разархивира в /tmp/selfextract.XXXXX папка където XXXXX е произволен низ. В тази директория се намира .deb файлът на Packet Tracer-a. Инсталацията се извършва с командата

dpkg -i --force-all /tmp/selfextract.XXXXX/PacketTracer-5.3_3.i386.deb

Естествено с root права.

Enhanced by Zemanta

Вчера след обновяване на версията на mysql, server-ът ми започна да ми крещи, че има табличка, която не е била затворена чисто и има нужда от поправка и прочие. Блах, коя ще е тая таблица, все пак са ми около 30-тина на тоя сървър. Единият вариант е да видите в log-овете какво пише по въпроса и да пуснете поправка на съответната таблица или другият вариант – далеч по-добрият – е да пуснете поправка, проверка и оптимизиране на всички таблици. За тази цел ще използвам mysqlcheck инструмента. Общо взето вариантите в случая са като и двете коменди са синонимни една на друга:


mysqlcheck -Aor -u root -p

mysqlcheck -u root -p --auto-repair --check --optimize --all-databases

Общо взето, която и от двете команди да използвате, ефектът ще е еднакъв – ароматична поправка, проверка  и оптимизация на всички таблици. След като напишете която и да е от двете команди, ще бъдете попитани за root паролата на mysql server-a ви.