Все пропало! Ничего не работает! Опять! Опять разбираться, гуглить, терять время. А время, как известно – это деньги. Чтож, не буду вдаваться в подробности и рассказывать почему возникает эта ошибка, но расскажу как быстро ее исправить. Метод не единственный, но абсолютно рабочий, и требует минимум временных затрат.

Итак, что мы имеем. Систему linux Debian с установленным Freeradius сервером. Однака поддержка perl не работает, вы выдает следующую ошибку:
radius:/etc/freeradius# /etc/init.d/freeradius start
Starting FreeRADIUS daemon: freeradius Can't load '/usr/lib/perl/5.10/auto/Data/Dumper/Dumper.so' for module Data::Dumper: /usr/lib/perl/5.10/auto/Data/Dumper/Dumper.so: undefined symbol: Perl_sv_cmp at /usr/lib/perl/5.10/XSLoader.pm line 70.
at /usr/lib/perl/5.10/Data/Dumper.pm line 36
Compilation failed in require at /etc/freeradius/example.pl line 30.
BEGIN failed--compilation aborted at /etc/freeradius/example.pl line 30.

Чтож, запустить freeradius достаточно просто. Попробуйте выполнить такой вызов:
LD_PRELOAD=/usr/lib/libperl.so freeradius -X
Если все заработало, то осталось изменить стартовые скрипты, и задача решена.
Если же сервер не запустился, почитайте последние строки вывода, и исправьте ошибки.

Для нормальной загрузки freeradius сервера нам потребуется поправить всего 1 файл:
/etc/init.d/freeradius
откройте его и найдите строки:
case "$1" in
start)
log_daemon_msg "Starting $DESCR" "$PROG"
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $PROGRAM -- $FREERADIUS_OPTIONS || ret=$?
log_end_msg $ret
exit $ret
;;
А теперь замените строку:
start-stop-daemon –start –quiet –pidfile $PIDFILE –exec $PROGRAM — $FREERADIUS_OPTIONS || ret=$?
на
LD_PRELOAD=/usr/lib/libperl.so start-stop-daemon –start –quiet –pidfile $PIDFILE –exec $PROGRAM — $FREERADIUS_OPTIONS || ret=$?

должно получиться следующее:
case "$1" in
start)
log_daemon_msg "Starting $DESCR" "$PROG"
LD_PRELOAD=/usr/lib/libperl.so start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $PROGRAM -- $FREERADIUS_OPTIONS || ret=$?
log_end_msg $ret
exit $ret
;;
Чтож, сохраняем изменения, и радуемся.

Знаю, что многие маньяки, да и я сам такой, частенько для отправки сообщений с сервера используют exim, postfix, sendmail, что-то еще. Но, согласитесь, что отправки писем использовать такие решения – это все равно, что микроскопом гвозди забивать… Для таких целей есть замечательный пакет ssmpt.

Конфиг ssmpt предельно прост и понятен. Рассмотрим его /etc/ssmtp.ssmtp.conf
# Пользователь, который получает всю почту для userids < 1000
# Сделайте пустым для отключения перезаписи, или укажите пользователя.
# А также вы можете указать нужный е-майл на который будет
# приходить почта для root.
root=postmaster
# имя SMTP сервера через который следует отправлять почту.
# Обычно mailhosts является именем mail.domain.com
mailhub=mail.domain.com
# Пример для SSL соединения
# mailhub=mail.domain.com:465
# От кого якобы должна приходить почта?
#rewriteDomain=
# Полное имя машины
hostname=web.domain.com
# Are users allowed to set their own From: address?
# YES - Allow the user to specify their own From: address
# NO - Use the system generated From: address
FromLineOverride=NO
# Использовать SSL/TLS при подключении к SMTP серверу.
#UseTLS=YES
# Использовать SSL/TLS сертификат для аутентификации на SMTP сервере.
#UseTLSCert=YES
# Используйте этот сертификат RSA.
#TLSCert=/etc/ssmtp/ssmtp.pem
# Получить отладочную информацию в логах
#Debug=YES

Как видите, конфиг простой и понятный. В данном случае, мы указали, что вся исходящая почта будет уходить на сервер mail.domain.com. Если для отправки почты через ваш почтовый сервер нужно авторизация, то ssmtp справится и с этой задачей. Просто добавьте в конфиг параметры authuser и authpass.

Обратите внимание на /etc/ssmtp/revaliases, ssmtp поддерживает реверсивные алиасы.
/etc/ssmtp/revaliases
# sSMTP aliases
#
# Format: local_account:outgoing_address:mailhub
#
# Example: root:your_login@your.domain:mailhub.your.domain[:port]
# where [:port] is an optional port number that defaults to 25.

Удачи

После первого несрабатывания карточки ни в коем случае не переходите к другому турникету. Я точно не знаю, как работает эта система, но в моем понимании все происходит примерно таким образом. Приложили карточку – началась транзакция, но прошла не успешно – турникет вас не пускает. Вот тут самый момент отменить транзакцию, но по каким-то соображениям этого не происходит! Далее еще раз прикладываем карту – новая транзакция не начинается, т.к. номер турникета не изменился. Опять не срабатывает. И так до тех пор, пока не сработает транзакция, и не загорится зеленый. А вот если мы не дождались зеленого, и перешли в другой турникет, то старая транзакция закроется (т.е. поездку спишут), и откроется новая (спишут еще одну поездку). Почему так происходит? Специально, или нет – это мы вряд ли узнаем. Будьте бдительны, и не попадайтесь на этот развод.

После 24 месяцев продолжительной разработки проект Debian рад сообщить о новой стабильной версии 6.0 (кодовое имя «Squeeze»). Debian 6.0 — это свободная операционная система, впервые представленная в двух вариантах. Наряду с Debian GNU/Linux, в этой версии добавлен Debian GNU/kFreeBSD в качестве «технологической пробы».

Вот такую замечательную новость я узрел, и сразу решил обновиться. Всегда хочется иметь stable релиз, и наконец уже забыть про использование бэкпортов… Но одно дело поставить систему на свежую машинку, и совсем другое – обновить рабочий сервер.
Как без потерь обновить мой Debian до нового релиза Debian 6.0 «Squeeze»?
Именно такой вопрос посетил меня сегодня. Ну и естественно это оказалось просто до безобразия, ну или почти

Первым делом я решил проверить, все ли нормально с зависимостями на моей системе. Я достаточно часто ставил «левые» пакеты, плюс самосбора полно. Поэтому, для избежания дальнейшего секаса, такая проверка была необходима, чего и вам советую. Сделать это достаточно просто. Для этого выполните:
apt-get update
apt-get -f install
Если есть ошибки – исправляйте, если нет, то все ок, и едем дальше.
Убедившись, что с зависимостями у меня все ровно, я решил удалить хвосты от старых пакетов. Можете считать меня извращенцем, но я делаю это так:
dpkg -l | grep -v «ii «
Выбираю все пакеты которые не ii, и удаляю их. Чаще всего весь этот хлам метится как ‘rc’
dpkg -P <список пакетов>
Чтож, теперь наша система готова обновляться. Но перед началом обновления, я вам настоятельно рекомендую полностью забакапить /etc т.к. в момент обновления некоторые конфиги могут пострадать

Для начала обновления нужно отредактировать список репозиториев откуда тянуть пакеты. У меня он (/etc/apt/sources.list) выглядит так:
deb http://ftp.de.debian.org/debian/ squeeze main non-free contrib
deb-src http://ftp.de.debian.org/debian/ squeeze main non-free contrib
deb http://security.debian.org/ squeeze/updates main non-free contrib
deb-src http://security.debian.org/ squeeze/updates main non-free contrib
Ну а теперь поехали обновлять:
apt-get update
apt-get install apt dpkg aptitude
Теперь у нас используется репозиторий squeeze, и мы смело можем перейти непосредственно к самому обновлению:
aptitude update
aptitude full-upgrade

Собственно таким методом я обновил более 10 серверов. Проблем при обновлении почти не возникло. Единственное, что пришлось править после обновления – это конфиги dovecot и mysql. В остальном все прошло гладко.

Удачи

Instructions:
Mouse controlled.

Instructions:
Mouse – aim & shoot.

Скрываем ошибки PHP от посетителей сайта
Для начала, давайте избавимся от вывода ошибок на экран, дабы не пугать пользователей. Да и вывод некоторых ошибок может проделать существенную брешь в безопасности вашего сайта. Для этого в свой .htaccess впишем следующие строки:
# Supress php errors
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off

Все, ошибки больше не отображаются в браузере, но теперь мы вообще не знаем об их существовании!

Включаем логирование ошибок PHP
Итак, мы отключили вывод ошибок в браузер, тем самым спрятав их от глаз пользователей, и теперь хотим залогировать все ошибочные вызовы в наших PHP скриптах. Для этого опять поправим наш .htaccess, и допишем в него следующие записи:
# Enable PHP error logging
php_flag log_errors on
php_value error_log /var/www/www.domain.com/logs/php_error.log

Измените путь к лог файлу в соответствии со своими требованиями, и проверьте права на запись. Возможно, вам придется создать этот файл руками и поставить на него права 755. Тут уж разбирайтесь сами, или поставьте права на файл 777, что крайне нежелательно.

Теперь можете проверить, как все это работает. Создайте PHP скрипт с ошибочным вызовом, выполните его в браузере. Убедитесь, что на экране браузера у вас нет ошибок. А после этого проверьте php_error.log