Howto
sqlgrey problem
Привет,
Преди няколко седмици обнових мейл сървъра ми към версия debian 8 jessie. Всичко работеше, но днес забелязах следния проблем във /var/log/mail.log
:
Jan 26 11:00:57 alpha postfix/smtpd[10642]: warning: premature end-of-input on private/policy while reading input attribute name Jan 26 11:00:58 alpha postfix/smtpd[10642]: warning: premature end-of-input on private/policy while reading input attribute name Jan 26 11:00:58 alpha postfix/smtpd[10642]: warning: problem talking to server private/policy: Success
Оказа се проблем със sqlgrey-a (sqlgrey problem). Вчера обновявах пакетите на сървъра и видях, че rsyslog се обнови. При самото му обновяване възникна проблем за който вече писах в serverfault.com.
След това обновяване се оказа, че sqlgrey не работи и даде следната грешка при стартиране :
root alpha # /etc/init.d/sqlgrey restart Restarting postfix greylisting daemon (sqlgrey): sqlgreyno connection to syslog available - unix dgram connect: Connection refused at /usr/share/perl5/Net/Server/Log/Sys/Syslog.pm line 70.
В крайна сметка успях да оправя проблема, след като премахнах rsyslog и на негово място инсталирах syslog-ng. Предполагам, че има някакъв бъг в новата версия на rsyslog, заради който greylisting сървиса не искаше да тръгне.
Folder and file permission in linux
Днес се сблъсках с нещо доста интересно – а именно : трябваше да сменя правата на всички папки в определена директория на 755 и на всички файлове в нея на 644. По принцип масово използвам chmod -R когато се наложи да правя нещо подобно, но тук условието беше по-особенно. За целта се разрових в нета, и открих как се прави и затова го пиша и тук в блога, защото смятам че е доста полезно и ценно!
Folder and file permission in linux
Ето и принципа :
За смяна на правата само на директории
find /var/www/dir/ -type d -exec chmod 755 {} \;
За смяна на правата само на файлове
find /var/www/dir/ -type f -exec chmod 644 {} \;
Така всички поддиректории във /var/www/dir/
станаха с права 755 , а всички файлове с права 644!
Debian 8 amavis problem
Здравейте и за много години!
Наложи ми се да правя ъпгрейд на един от главните ми сървъри, който беше с debian 7 и вече е с 8-ца 🙂
Всичко мина долу-горе добре, обаче изникна проблем с amavis-a. Проблема се изразяваше в следното : самият amavisd демон не искаше да тръгва, и съответно в логове се виждаше това :
Starting amavisd: syntax error at /usr/sbin/amavisd-new line 1921, near "$pn qw(DEBUG INFO NOTICE WARNING ERR CRIT ALERT EMERG)" syntax error at /usr/sbin/amavisd-new line 1923, near "$prio : LOG_WARNING" syntax error at /usr/sbin/amavisd-new line 1929, near "}" syntax error at /usr/sbin/amavisd-new line 1937, near "}" syntax error at /usr/sbin/amavisd-new line 1943, near "}" syntax error at /usr/sbin/amavisd-new line 1963, near "}" syntax error at /usr/sbin/amavisd-new line 1978, near "}" syntax error at /usr/sbin/amavisd-new line 1987, near "}" syntax error at /usr/sbin/amavisd-new line 1990, near "}" Can't use global @_ in "my" at /usr/sbin/amavisd-new line 1995, near "= @_" /usr/sbin/amavisd-new has too many errors. (failed).
Тук проблема се оказа от новата версия на perl , и остарелия amavis ( който беше инсталиран ръчно, чрез make && make install
). След обновяване през apt-get install amavis
самият процес тръгна, обаче взе да плюе следното в mail.log-a:
Jan 4 11:10:45 alpha amavis[25842]: (25842-02-6) (!)WARN save_info_final: sql exec: err=1054, 42S22, DBD::mysql::st execute failed: Unknown column 'rseqnum' in 'field list' at (eval 96) line 172. Jan 4 11:10:46 alpha amavis[25838]: (25838-02-5) (!)WARN save_info_final: sql exec: err=1054, 42S22, DBD::mysql::st execute failed: Unknown column 'rseqnum' in 'field list' at (eval 96) line 172. Jan 4 11:10:46 alpha amavis[25838]: (25838-02-5) (!!)ERROR sql_storage: too many retries on storing final, info not saved
Тук пък в крайна сметка се оказа, че след версия 2.7 трябвало да се добавят 3 полета в таблица msgrcpt
и едно в таблица msgs
. Това става лесно:
ALTER TABLE msgrcpt ADD rseqnum integer DEFAULT 0 NOT NULL; ALTER TABLE msgrcpt ADD content char(1) DEFAULT ' ' NOT NULL; ALTER TABLE msgrcpt ADD is_local char(1) DEFAULT ' ' NOT NULL; ALTER TABLE msgs ADD originating char(1) DEFAULT ' ' NOT NULL;
– взаймствано инфо от тук.
И така, в крайна сметка проблема ми с пощенския сървър се оправи и всичко работи както преди 🙂
WordPress X-Olaf header
Привет,
Преди няколко дни от WordPress.org обявиха че са станали официален Olaf провайдър. Сигурно за повечето хора това едва ли ще значи нещо интересно, но за такива като мен които обичат да гледат header-ите на страниците – това определено бе нещо готино.
Става дума за следното :
curl -Is wordpress.org | grep X-Olaf X-Olaf: ⛄
Аз също го сложих на root.bg :
И ето и как става схемата за да се направи WordPress X-Olaf header:
Трябва да създадем файл наречен custom-functions.php
в директорията wp-content/themes/името-на-нашия-шаблон/
със следното съдържание:
< ?php function olaf_provider() { header( 'X-Olaf: ⛄' ); } add_action( 'init', 'olaf_provider' );
Общо взето това е 🙂
Може да се тества с curl -I http://vashiqt-sait.com
и ако всичко е ок , трябва да излезе X-Olaf header-a 🙂
Весели празници!
PS. На терминала на ubuntu и през PuTTy картинката на Olaf не се показва коректно – нямам представа защо, обаче на Mac-a е 6 🙂