part1 -Load balancing Web cluster with nginx apache2 php5 mysql glusterfs drbd heatbeat pacemaker nfs lvm on ubuntu 12.04 LTS

vladimir simeonov
06/02/2013

Кратък коментар отностно защитни стени – възможно, дори желателно, е да се реализира защитна стена преди клиентските връзки към DNS, Nginx сървърите, както и мрежду Tier 1, Tier 2.

На слой 2 работят единствено apache2 workers, които обработват заявките и връщат обратно съдържание, тук могат да се инсталират Php5, perl, python, и само и единствено mysql-client. Отново с цел консистентност на съдържанието, конфигурациите на apache2, файловете със скриптове (/var/www/) се предоставят от NFS дял, който се хоства заедно с MySQL DBs на Слой 3.

Тук се реализират следните неща:

  • Apache2
  • PHP5, MySQL-client, Perl, Python, etc.
  • NFS
  • LVM

Желателно е да има отново защитна стена между слой 2 и слой 3.

Слой 3 се състои от нодове, част от Pacemaker+Heartbeat Failover Cluster, като репликацията на файловите структури и данни е чрез DRBD. Слой 2 се свързва като NFS/MySQL client, към Cluster IP, като pacemaker следи и се грижи да предостави ресурсите от node-а в standby режим, когато Heartbeat установи, че активният node e offline.

Обобщен списък с технологии на слой 3:

  • Heartbeat
  • Pacemaker
  • DRBD
  • MySQL Server
  • NFS Server
  • LVM

След описване на топологията, следва кратка абстракция:

  1. Няма да намерите инструкция по инсталацията на ОС Ubuntu Server 12.04
  2. Машините в тестовата среда, която ще опишем детайлно се намират в една обща мрежа, като с изключение на Tier3, където не е желателно да се поставят Node-овете в отделни мрежи, другите слоеве могат да бъдат сегментирани, чрез Firewall/IPS/Router.
  3. Таблицата показва необходимите ресурси, имена на хостове и адреси:

За улеснение всички машини имат 30-50GB хард диск, като по време на инсталацията всички дялове са върху LVM.

Започваме изграждането от Tier3:

t3-node1/t3-node2 –

/etc/hosts

127.0.0.1       localhost

10.167.0.31     t3-node1

10.167.0.32     t3-node2

# The following lines are desirable for IPv6 capable hosts

::1     ip6-localhost ip6-loopback

fe00::0 ip6-localnet

ff00::0 ip6-mcastprefix

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

t3-node1 –

/etc/network/interfaces

auto lo

iface lo inet loopback

# The primary network interface

auto eth0

iface eth0 inet static

address 10.167.0.31

netmask 255.255.255.0

network 10.167.0.0

broadcast 10.167.0.255

gateway 10.167.0.1

# dns-* options are implemented by the resolvconf package, if installed

dns-nameservers 10.162.0.10

dns-search intercard.bg

auto eth1

iface eth1 inet static

address 10.136.6.31

netmask 255.255.255.0

t3-node2 –

/etc/network/interfaces

auto lo

iface lo inet loopback

# The primary network interface

auto eth0

iface eth0 inet static

address 10.167.0.32

netmask 255.255.255.0

network 10.167.0.0

broadcast 10.167.0.255

gateway 10.167.0.1

# dns-* options are implemented by the resolvconf package, if installed

dns-nameservers 10.162.0.10

dns-search intercard.bg

auto eth1

iface eth1 inet static

address 10.136.6.32

netmask 255.255.255.0

Интерфейс eth0 е главният интерфейс, чрез който машините ще комуникират с другите сървъри. eth1 е резрвиран единствено за комуникация на DRBD!

Инсталираме необходимите пакети:

t3-node1/t3-node2 –

apt-get install -y heartbeat pacemaker nfs-kernel-server mysql-server drbd8-utils build-essential psmisc xfsprogs

aptitude remove apparmor

Спираме автоматичното стартиране на NFS/DRBD/MySQL:

t3-node1/t3-node2 –

service nfs-kernel-server stop

service postgresql-8.4 stop

service mysql stop

update-rc.d -f nfs-kernel-server remove

update-rc.d -f mysql remove

update-rc.d -f drbd remove

sed -i -e “/^start on/d” /etc/init/mysql.conf

sed -i -e “/^stop on/d” /etc/init/mysql.conf

Конфигурираме Heartbeat:

cat <<EOF > /etc/heartbeat/ha.cf

logfacility daemon

keepalive 2

deadtime 15

warntime 5

initdead 120

udpport 694

bcast eth0

auto_failback on

node t3-node1

node t3-node2

use_logd yes

crm respawn

ping_group internal 10.167.0.1 10.162.0.10

deadping 12

EOF

Подменете адресите от група Internal с адреси на рутер или dns сървър, които да служат за witness в случай, че двата Nodes изгубят връзка помежду си, но продължат да работят – “split brain”.

Възможно е при по – специална конфигурация на мрежата, забраняваща broadcasting, да се наложи промяна на bcast eth0 с

ucast eth0 10.167.0.32

ucast eth0 10.167.0.31

( echo -ne “auth 1\n1 sha1 “; \
dd if=/dev/urandom bs=512 count=1 | openssl md5 ) \
> /etc/ha.d/authkeys.

chmod 600 /etc/ha.d/authkeys

service heartbeat start

t3-node1/t3-node2 –

Създаваме дяловете, които ще се репликират чрез DRBD

lvcreate -n nfs -L 15G t3-node1

lvcreate -n mysql -L 15G t3-node1

Създаваме ресурсните дялове в DRBD

cat <<EOF > /etc/drbd.d/r0.res

resource r0 {

protocol C;

syncer {

rate 11M;

}

startup {

wfc-timeout 15;

degr-wfc-timeout 60;

}

net {

cram-hmac-alg sha1;

shared-secret “ieGobe9Ohwo5Ahv4aida”;

}

on t3-node1 {

device /dev/drbd0;

disk /dev/t3-node1/nfs;

address 10.136.6.31:7788;

meta-disk internal;

}

on t3-node2 {

device /dev/drbd0;

disk /dev/t3-node2/nfs;

address 10.136.6.32:7788;

meta-disk internal;

}

}

cat <<EOF > /etc/drbd.d/r1.res

resource r1 {

protocol C;

syncer {

rate 11M;

}

startup {

wfc-timeout 15;

degr-wfc-timeout 60;

}

net {

cram-hmac-alg sha1;

shared-secret “ooviPh7Sozezee4vughe”;

}

on t3-node1 {

device /dev/drbd1;

disk /dev/t3-node1/mysql;

address 10.136.6.31:7789;

meta-disk internal;

}

on t3-node2 {

device /dev/drbd1;

disk /dev/t3-node2/mysql;

address 10.136.6.32:7789;

meta-disk internal;

}

}

стартираме репликацията:

drbdadm create-md r0

drbdadm create-md r1

service drbd start

t3-node1 –

избираме t3-node1 за primary, спрямо който ще се репликира t3-node2. на този етап няма значение кой от двата хоста ще изберем:

drbdadm primary r0

drbdadm primary r1

Проверяваме статуса на репликацията:

cat /proc/drbd

drbd-overview

Създаваме файлова система и монтираме дяловете:

mkfs.xfs /dev/drbd0

mkfs.xfs /dev/drbd1

mkdir /srv/nfs

mkdir /srv/mysql

t3-node1/t3-node2-

Конфигурираме NFS/MySQL server:

sed -i -e “s/NEED_SVCGSSD=/NEED_SVCGSSD=no/” /etc/default/nfs-kernel-server

sed -i -e “s/NEED_GSSD=/NEED_GSSD=no/” /etc/default/nfs-common

echo NEED_IDMAPD=yes >> /etc/default/nfs-common

sed -i -e “s/\#bind-address.*/bind-address 10.167.0.55/” /etc/mysql/my.cnf

Подменете 10.167.0.55 с виртуален адрес, който да се взима от node-а който е в активен режим.

t3-node1 –

Монтираме файловите системи на t3-node1, за да преместим mysql базата и да я свържем към /var/lib/mysql

mount /dev/drbd0 /srv/nfs/

mount /dev/drbd1 /srv/mysql/

mv /var/lib/mysql/* /srv/mysql/

rm -r /var/lib/mysql

ln -sf /srv/mysql /var/lib/mysql

chown mysql:mysql /srv/mysql/

chmod 700 /srv/mysql/

t3-node2-

Премахваме /var/lib/mysql и я свързваме към /srv/mysql

rm -r /var/lib/mysql

ln -sf /srv/mysql /var/lib/mysql

chmod 700 /srv/mysql/

chown mysql:mysql /srv/mysql/

t3-node1/t3-node2-

експортираме NFS дяла:

echo “/srv/nfs        10.167.0.21/32(rw,sync,nohide,no_subtree_check,no_root_squash)” >> /etc/exports

echo “/srv/nfs        10.167.0.22/32(rw,sync,nohide,no_subtree_check,no_root_squash)” >> /etc/exports

exportfs -ra

t3-node1-

Конфигурираме pacemaker единствено на хост t3-nod1, тъйкато конфигурацията се репликира:

crm configure property stonith-enabled=false

crm configure property no-quorum-policy=ignore

crm configure edit

node $id=”a1b1f5b0-de01-4e14-af3f-e64c8ab9d507″ t3-node2 \        attributes standby=”off”node $id=”c8a40634-bc26-4449-bada-95846d34a841″ t3-node1 \        attributes standby=”off”primitive drbd_mysql ocf:linbit:drbd \

params drbd_resource=”r1″ \

op monitor interval=”15s” role=”Master” \

op monitor interval=”16s” role=”Slave”

primitive drbd_nfs ocf:linbit:drbd \

params drbd_resource=”r0″ \

op monitor interval=”15s” role=”Master” \

op monitor interval=”16s” role=”Slave”

primitive fs_mysql ocf:heartbeat:Filesystem \

params device=”/dev/drbd/by-res/r1″ directory=”/srv/mysql” fstype=”xfs” \

op start interval=”0″ timeout=”60″ \

op stop interval=”0″ timeout=”120″

primitive fs_nfs ocf:heartbeat:Filesystem \

params device=”/dev/drbd/by-res/r0″ directory=”/srv/nfs” fstype=”xfs” \

op start interval=”0″ timeout=”60″ \

op stop interval=”0″ timeout=”120″

primitive ip1 ocf:heartbeat:IPaddr2 \

params ip=”10.167.0.55” nic=”eth0:1″ \

op monitor interval=”5s”

primitive ip1arp ocf:heartbeat:SendArp \

params ip=”10.167.0.55” nic=”eth0:1″

primitive mysql ocf:heartbeat:mysql \

params binary=”/usr/bin/mysqld_safe” config=”/etc/mysql/my.cnf” user=”mysql” group=”mysql” log=”/var/log/mysql.log” pid=”/var/run/mysqld/mysqld.pid” datadir=”/var/lib/mysql” socket=”/var/run/mysqld/mysqld.sock” \

op monitor interval=”30s” timeout=”30s” \

op start interval=”0″ timeout=”120″ \

op stop interval=”0″ timeout=”120″

primitive nfs lsb:nfs-kernel-server \

op monitor interval=”5s”

group HAServices ip1 ip1arp fs_nfs nfs fs_mysql mysql \

meta target-role=”Started”

ms ms_drbd_mysql drbd_mysql \

meta master-max=”1″ master-node-max=”1″ clone-max=”2″ clone-node-max=”1″ notify=”true”

ms ms_drbd_nfs drbd_nfs \

meta master-max=”1″ master-node-max=”1″ clone-max=”2″ clone-node-max=”1″ notify=”true”

colocation mysql_on_drbd inf: HAServices ms_drbd_mysql:Master

colocation nfs_on_drbd inf: HAServices ms_drbd_nfs:Master

order fs-mysql-before-mysql inf: fs_mysql:start mysql:start

order fs-nfs-before-nfs inf: fs_nfs:start nfs:start

order ip-before-arp inf: ip1:start ip1arp:start

order ip-before-ms-drbd-mysql inf: ip1:start ms_drbd_mysql:promote

order ip-before-ms-drbd-nfs inf: ip1:start ms_drbd_nfs:promote

order ms-drbd-mysql-before-fs-mysql inf: ms_drbd_mysql:promote fs_mysql:start

order ms-drbd-nfs-before-fs-nfs inf: ms_drbd_nfs:promote fs_nfs:start

property $id=”cib-bootstrap-options” \        dc-version=”1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c” \        cluster-infrastructure=”Heartbeat” \        expected-quorum-votes=”1″ \

stonith-enabled=”false” \

no-quorum-policy=”ignore”

rsc_defaults $id=”rsc-options” \

resource-stickiness=”100″

Информацията в син цвят не се променя. Редактирайте виртуалният адрес в червено.

Ако конфигурацията е правилна, то командата crm_mon, ще върне резултат подобен на:

Last updated: Wed Feb  6 17:37:27 2013

Last change: Wed Feb  6 11:15:52 2013 via crm_attribute on t3-node1

Stack: Heartbeat

Current DC: t3-node1 (c8a40634-bc26-4449-bada-95846d34a841) – partition with quorum

Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c

2 Nodes configured, 1 expected votes

10 Resources configured.

============

Online: [ t3-node1 t3-node2 ]

Resource Group: HAServices

ip1        (ocf::heartbeat:IPaddr2):       Started t3-node2

ip1arp     (ocf::heartbeat:SendArp):       Started t3-node2

fs_nfs     (ocf::heartbeat:Filesystem):    Started t3-node2

nfs        (lsb:nfs-kernel-server):        Started t3-node2

fs_mysql   (ocf::heartbeat:Filesystem):    Started t3-node2

mysql      (ocf::heartbeat:mysql): Started t3-node2

Master/Slave Set: ms_drbd_mysql [drbd_mysql]

Masters: [ t3-node2 ]

Slaves: [ t3-node1 ]

Master/Slave Set: ms_drbd_nfs [drbd_nfs]

Masters: [ t3-node2 ]

Slaves: [ t3-node1 ]

Можете да симулирате отпадане на nodes с командите:

crm node standby t3-node1

crm node online t3-node1

crm node standby t3-node2

crm node online t3-node2

и отново да следите статуса на клъстъра след всяка команда чрез crm_mon

reject_unverified_sender

vladimir simeonov
15/05/2012

Наскоро попаднах на досаден пощенски сървър, който отказваше да приеме писмо от [email protected], пради несъществуващ адрес. хм.. след като добавих alias към /dev/null започнах да се замислям за полезността на такава опция. и разбира се я имплементирах.

reject_unknown_recipient_domain,

reject_unauth_destination,

reject_unverified_recipient,

reject_rbl_client bl.spamcop.net,

reject_rbl_client zen.spamhaus.org,

check_policy_service unix:private/policy-spf,

warn_if_reject reject_unverified_sender,

permit

Предварително бях добавил проверка за unverified_recipient, тъйкато съм relay за няколко домейна до които не мога да достъпя списъка с потребители. това разбира се генерира досадни съобщения с които postfix проверява предварително дали получателя съществува.

След като добавих проверка за unverified_sender с тайна надежда да ме спаси от нигерииският спам за принцесата, започнах да следя логовете..

postfix/qmgr[9193]: 6B99A2B38109: from=<[email protected]>, size=237, nrcpt=1 (queue active)

Не се усеща спад в производителността и задръстване на queue, но след време..

Е получи се неприятен ефект, които си струва да се спомене.

1. Нигерииският спам не спря.. гадините ползват хакнати пощи в yahoo

2. започнах да попадам в румънските RBL на кармата. доста неприятно и логично.

Тъйкато postfix пробва да достави на подателя обратно съобщение от double-bounce, което разбира се е празно и единствено с цел да провери дали този подател съществува се получава обратен спам. Сървърите детектват postfix като източник на спам и реално попадам в honeypad-овете на RBL providers.

Като съвет – обмислете внимателно рисковете и плюсовете на този метод филтриране

postfix incoming and outgoing emails queue limit

vladimir simeonov
11/08/2011

инфо: http://www.policyd.org/

Защитата от спам през graylist, dns, rbl и т.н. е безполезна, когато източника на спам е потребител с валиден акаунт и инфектиран компютър, който изпраща хиляди съобщения през клиентска програма конфигурирана за достъп до пощенския сървър.

след поредната такава атака реших, че е време за крайни мерки, решението на които е policyd.

postfix policyd е perl (разбира се!) демон, който слуша на tcp порт. интегрира се в postfix като policy condition в sender/client/recipient restrictions.

Policyd поддържа и graylisting, но ако се ползва вградения в него graylist, то няма да може да се прилага ограничение на броя писма за потребителите на системата. Защо?

permit_mynetworks,

permit_sasl_authenticated,

check_client_access     mysql:$config_directory/mysql_virtual_client_access.cf,

check_client_access hash:/usr/local/etc/postfix/rbl-whitelist,

reject_unauth_pipelining,

reject_rbl_client zen.spamhaus.org,

        check_policy_service inet:127.0.0.1:10031,

permit

в случая permit_sasl_authenticated ще допусне потребителя да изпрати писмото си. greylist ще сработи само ако sender-a не е потребител.

ако преместим policyd преди permit_sasl_authenticated„ то greylist ще сработва за всички sender-и, което е неприятно за потребителите, които няма да могат да изпращат писмата веднага и ще получават грешки.

инсталацията:

apt-get install postfix-policyd

dbconfig-common

ще се опита да създаде база данни за работа на демона. препоръчително е да го конфигурирате по този начин.

алтернативно (променете текста в болд с друга парола):

1. mysql

create database postfix-policyd;

GRANT ALL ON postfix-policyd.* TO ‘pf-policyd’@’localhost’ IDENTIFIED BY ‘PASSW0rd‘;

flush privileges;

2. editor /etc/postfix-policyd.conf

MYSQLHOST=”localhost”

MYSQLDBASE=”postfix-policyd”

MYSQLUSER=”pf-policyd”

MYSQLPASS=”PASSW0rd

MYSQLOPT=””

FAILSAFE=1

DATABASE_KEEPALIVE=0

DEBUG=0

DAEMON=1

BINDHOST=127.0.0.1

BINDPORT=10031

PIDFILE=/var/run/postfix-policyd.pid

SYSLOG_FACILITY=”LOG_MAIL | LOG_INFO”

CHROOT=/

UID=5000

GID=5000

CONN_ACL=”127.0.0.1″

WHITELISTING=1

WHITELISTNULL=0

WHITELISTSENDER=1

WHITELISTDNSNAME=1

AUTO_WHITE_LISTING=1

AUTO_WHITELIST_NUMBER=500

AUTO_WHITELIST_NETBLOCK=0

AUTO_WHITELIST_EXPIRE=7d

BLACKLISTING=1

BLACKLISTDNSNAME=1

BLACKLIST_TEMP_REJECT=1

BLACKLIST_NETBLOCK=1

BLACKLIST_REJECTION=”Abuse. Go away.”

AUTO_BLACK_LISTING=0

AUTO_BLACKLIST_NUMBER=500

AUTO_BLACKLIST_EXPIRE=7d

BLACKLIST_HELO=1

BLACKLIST_HELO_AUTO_EXPIRE=2d

BLACKLISTSENDER=1

HELO_CHECK=1

HELO_MAX_COUNT=10

HELO_BLACKLIST_AUTO_EXPIRE=14d

HELO_AUTO_EXPIRE=7d

SPAMTRAPPING=1

SPAMTRAP_REJECTION=”Abuse. Go away.”

SPAMTRAP_AUTO_EXPIRE=7d

# we don’t want to use policyd’s greylist

GREYLISTING=0

GREYLIST_REJECTION=”Graylisted. Please try again later”

GREYLIST_X_HEADER=1

GREYLIST_HOSTADDR=3

TRAINING_MODE=0

TRAINING_POLICY_TIMEOUT=1d

TRIPLET_TIME=4m

OPTINOUT=0

OPTINOUTALL=0

TRIPLET_AUTH_TIMEOUT=30d

TRIPLET_UNAUTH_TIMEOUT=2d

SENDERTHROTTLE=1

SENDER_THROTTLE_SASL=0

SENDER_THROTTLE_HOST=1

QUOTA_EXCEEDED_TEMP_REJECT=1

SENDER_QUOTA_REJECTION=”Quota Exceeded.”

SENDER_SIZE_REJECTION=”Message size too big.”

SENDERMSGLIMIT=200

SENDERRCPTLIMIT=200

SENDERQUOTALIMIT=250000000

SENDERTIMELIMIT=1h

SENDERMSGSIZE=50240000

SENDERMSGSIZE_WARN=40

SENDERMSGSIZE_PANIC=190

SENDER_INACTIVE_EXPIRE=10d

RECIPIENTTHROTTLE=1

RECIPIENTMSGLIMIT=640

RECIPIENTTIMELIMIT=5h

RECIPIENT_QUOTA_REJECTION=”Quota Exceeded.”

RECIPIENT_INACTIVE_EXPIRE=31d

променете

SENDERMSGSIZE

SENDERMSGLIMIT

RECIPIENTMSGLIMIT

съответно с желания от вас лимит

3. editor /etc/postfix/main.cf

smtpd_sender_restrictions =
check_policy_service inet:127.0.0.1:10031, 

променете единствено това правило да започва по посоченият начин, т.е. добавете нов празен ред с посоченият текст.

/etc/init.d/postfix-policyd restart

проследте лога дали няма грешки

MTA for Mortals

vladimir simeonov
09/08/2011

Кое е най – важното за един пощенски сървър?? Да може да получава писма или да изпраща??

Вдигането на сървър за писма не се свежда единствено до инсталиране на демон за порт 25, 110, 143 и SSL. Безсмислено е да се прави, ако се окаже, че сървъра е обречен на блокиране и спам листи поради просто недомислие от страна на създателя му.

Макар и не писани, това са простите правила, които ако не спазите, ще ви поставят писмата във веченият junk:

1. статичен, реален и автономен ip адрес за вашият сървър. по възможност резервирайте адреса единствено за сървъра. съществуването на web на него, може да доведе до хакване на някой от не добре написаните сайтове и превръщане на системата в източник на спам.

2. IP адреса трябва да не фигурира в блок от адреси, които доставчика ви е резервирал за домашни потребители. в противен случай рискувате PBL, RBL листи като spamcop, spamhaus и др. да посочват адреса ви като заплаха за останалите mail сървъри, което автоматично означава отказани писма.

3. DNS!!! изнудете, принудете, дори ако трябва сменете доставчика си докато не постави PTR запис (обратен resolv) на IP адреса. ако PTR е към негов домейн, то трябва да сте сигурни, че правият запис съответства на обратния. Пример:

101.0.0.1 IN PTR mail.lordofdeath.net.

$ ORIGIN lorodfdeath.net.

mail IN A 101.0.0.1

ако доставчика не може да го направи, то накарайте го да постави PTR директно към вашият mail запис.

КРИТИЧНО Е да нямате два PTR записа за това IP!!!!

4. използвайте защитите от спам и fishing описани в другите постове и ще имате перфектният сървър!

системите за monitoring – лъжливото овчарче в ИТ системите

vladimir simeonov
08/08/2011

Фактите:

използването на система за мониторинг на ИТ интфраструктура е неизбежно събитие застигащо администратора и. съществуват много, твърде много решения за мониторинг, както безплатни, така и платени и всички те страдат от един общ недостатък – синдрома на лъжливото овчарче.

Не сте чували за него??

ОК – пример от реалният живот.

Ползвам скрипт, който архивира всяка вечер в последователност всички сървъри. и разбира се получавам емейл със статуса на архивирането, както и СМС за грешка. проблема е, че програмата за синхронизация много често свършва със грешка, която не е фатална. на третата вечер спрях дори да обръщам внимание на получените СМС-и.

аналогична е и ситуацията с мониторинговите системи. липсата на пинг за 10сек която системата може да детектне и да извести може никога да не се забележи. но администратор който получава постоянно нови и ниви известия за събитие което е отминало в даден момент спира да му обръща внимание.

система която в реално време известява за отпадането на свързаност и т.н. е напълно безмислена, ако това отпадане е за части от секундата или за време, през което не може да се извърши диагностика на проблема. а генерирането постоянно на такива съобщения е побъркващо.

изхода е един: отъврете се от такава система.. напишете си сами качествен скрипт, който да проверява обстойно системата ви; скрипт с интелект, който да пуска повторна проверка след няколко секунди, а не да вдига алармата за загуба на пинг.

в крайна сметка никой не вярва на лъжливото овчарче. една такава система е безсмислена и неефективна.

dovecot sieve and roundcube

vladimir simeonov
02/08/2011

Dovecot за разлика от Courier поддържа създаване на филтри за писмата на базата на SIEVE езика. Настоящето howto e 10min инструкция за подкарване на sieve под postfix, dovecot и roundcube

изисквания: dovecot 2.x, roundcube > 0.5

базирано на: http://wiki2.dovecot.org/Pigeonhole/ManageSieve/Configuration

http://bsdbased.com/2009/11/22/sieve-dovecot-lda-roundcube-howto

1. apt-get install dovecot-managesieved dovecot-sieve

2. сваляте roundcube plugin в папка plugins: http://www.tehinterweb.co.uk/roundcube/#pisieverules

3. editor managesieve/config.inc.php

редактирате първият ред така

$rcmail_config[‘managesieve_port’] = 2000;

4. editor config/main.inc.php

и добавяте managesieve към списъка с plugins

5. editor /etc/dovecot/dovecot.conf

редактирате реда protocols и добавяте sieve

6. editor /etc/dovecot/conf.d/90-plugin.conf

plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}

готово. трябва да имате работещ filter!

postfix backup mx server

vladimir simeonov
29/07/2011

Целта на резервния mail server е:

1. складиране на входящи писма, в случай че главният сървър отпадне.

2. разтоварване на главният сървър от спам 🙂

Важно:

  • за да не влиза спам през backup mx, е много важно спам защитата на backup mx да е настроена аналогично на главния. ако не се приложи това правило, то backup mx ще приема писмата от името на главният сървър и ще му ги препраща за доставка до users maildir.
  • главният сървър ще трябва да приема писмата от backup mx безрезервно, т.е. да му се доверява напълно. в противен случай, главният сървър ще генерира bounce до backup-а, който от своя страна ще се чуди какво да прави с това писмо, което е рапортувал за доставено на upstream mx-a.

конфигурацията е изключително проста:

1. в DNS добавяте втори MX запис:

IN MX 10 mail.lordofdeath.net.

IN MX 20 mail2.lordofdeath.net.

2. инсталирате postfix, postfix-policyd, postgrey на резервния mail2

*За да имате пълен толеранс и също така съвместимост съветвам MySQL сървърите на mail и mail2 да работят в режим на master-master replication поне за базите с които работят postfix, postfix-policyd

** http://www.howtoforge.com/mysql_master_master_replication – mysql master-master replication howto

ако вашият backup mx (mail2) ще backup-ва единствено и само 1 сървър, то можете да ползвате таблицата domains за списък с домейните които ще relay-ва към primary mx-a.

в случай, че правите primary mx сървър на един набор от домейни да бъде backup mx за други домейни, то ще трябва да създадете отделна таблица за relay domains.

CREATE TABLE IF NOT EXISTS `relays` (

`active` int(11) NOT NULL DEFAULT ‘1’,

`source` varchar(50) NOT NULL DEFAULT ”,

`destination` varchar(50) NOT NULL,

`created _by` text,

`c_date` date DEFAULT NULL,

PRIMARY KEY (`source`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8;

промени по конфигурацията на primary mx не са нужни, следващите конф. са за backup mx (mail2):

mail_owner = postfix

unknown_local_recipient_reject_code = 550

mynetworks_style = host

debug_peer_level = 2

biff = no

append_dot_mydomain = no

myhostname = mail2.lordofdeath.net.

myorigin = mail2.lordofdeath.net.

mynetworks = $config_directory/mynetworks

mydestination = $myhostname, localhost

alias_maps = hash:/etc/aliases

unknown_local_recipient_reject_code = 552

unknown_hostname_reject_code = 551

unknown_client_reject_code = 481

unknown_address_reject_code = 554

unknown_virtual_alias_reject_code = 556

unknown_virtual_mailbox_reject_code = 557

non_fqdn_reject_code = 581

strict_rfc821_envelopes = no

smtpd_delay_reject = yes

smtpd_helo_required = yes

smtpd_client_restrictions =

check_client_access     mysql:$config_directory/mysql_virtual_client_access.cf,

check_client_access     mysql:$config_directory/mysql_virtual_nordns_access.cf,

permit_mynetworks

smtpd_sender_restrictions =

check_client_access     mysql:$config_directory/mysql_virtual_client_access.cf,

check_client_access     mysql:$config_directory/mysql_virtual_nordns_access.cf,

permit_mynetworks,

reject_unknown_sender_domain,

reject_unknown_client

smtpd_recipient_restrictions =

check_client_access     mysql:$config_directory/mysql_virtual_client_access.cf,

check_client_access     mysql:$config_directory/mysql_virtual_nordns_access.cf,

permit_mynetworks,

reject_non_fqdn_recipient,

reject_non_fqdn_sender,

reject_unknown_sender_domain,

reject_unknown_recipient_domain,

reject_unauth_destination,

reject_rbl_client bl.spamcop.net,

reject_rbl_client zen.spamhaus.org,

check_policy_service unix:private/policy-spf,

check_policy_service inet:127.0.0.1:10023,

check_policy_service inet:127.0.0.1:10031,

permit

smtpd_helo_restrictions =

permit_mynetworks,

check_client_access     mysql:$config_directory/mysql_virtual_helo_access.cf,

reject_non_fqdn_hostname,

reject_invalid_hostname,

permit

relay_domains = mysql:$config_directory/mysql_virtual_relay_domains.cf

relay_recipient_maps= mysql:$config_directory/mysql_virtual_relay_mailboxes.cf
mysql:$config_directory/mysql_virtual_forwardings.cf

virtual_alias_domains =

virtual_mailbox_domains =

#virtual_alias_maps =

smtpd_sasl_auth_enable = no

message_size_limit = 55971520

virtual_mailbox_limit = 55971520

mailbox_size_limit = 55971520

maximal_queue_lifetime = 168h

bounce_queue_lifetime = 168h

#SPF

spf-policyd_time_limit = 3600s

mysql_virtual_relay_domains.cf 

user = vmail_client

password = P@ssw0rd

dbname = vmailsystem

table = relays

select_field = domain

where_field = domain

hosts = db1.lordofdeath.net

additional_conditions = and active = ‘1’

*** ако нежелаете да mail2 да прави проверка дали потребителя съществува, премахнете удебеленият текст за ‘relay_recipient_maps = ‘, но оставете самата директива.

mysql_virtual_relay_mailboxes.cf

user = vmail_clientpassword = P@ssw0rd

dbname = vmailsystem

table = users

select_field = ‘OK’

where_field = email

hosts = db1.lordofdeath.net

additional_conditions = and active = ‘1’

mysql_virtual_forwardings.cf

user = vmail_clientpassword = P@ssw0rd

dbname = vmailsystem

table = forwardings

select_field = ‘OK’

where_field = email

hosts = db1.lordofdeath.net

additional_conditions = and active = ‘1’

**** Тъйкато протокола за smtp повелява, че ако главният сървър не допуска писмото (graylist), сървъра, който се опитва да го изпрати, трябва да пробва с другите mx сървъри (backup mx-а), ако ползвате postfix-policyd, то трябва primary и backup mx сървърите да ползват еднаква конфигурация за postfix-policyd, но различни бази данни. това се налага от факта, че ако ползвате една база, то квотата за брой писма които едно IP може да прати за определен интервал, ще се достигне 2х по – бързо. пример:

mail.hostatme.com праща писмо до mail.lordofdeath.net, primary mx добавя запис в policyd db, писмото се graylist-ва. mail.hostatme.com праща същото писмо до mail2.lordofdeath.net. backup mx увеличава броя пъти за ip-то в записа на същата база.

друга причина за ползване на отделни таблици е ако ползвате graylist на policyd. при същия пример отгоре. primary mx ще добави запис, че е graylist-нал писмото. backup mx, ще види записа и ще го пропусне. но това не е повторен опит от страна на подателя, а просто обхождане на сървърите в опит да го достави. разбира се можете да поставите по – голям интервал на graylist след който да пропуска писмото, но това води до странични последствия като допълнитела латентност и забавяне на доставката, а и подателя може да обхожда сървърите с delay интервал.

Postfix on Ubuntu: autoconfig/autodiscovery Thunderbird and Outlook

vladimir simeonov
27/07/2011

Mozilla Thunderbird и Outlook поддържат autodiscovery/autoconfig за автоматично намиране настройките на сървъра. в този кратък пост ще обясня как да се настроят, така че без излишно усилие да можете да настройвате клиентите си да се закачат към вашия postfix mail server

за има на сървър съм използвал lordofdetah.net, подменете го със своят адрес.

никъде не се въвеждат пароли, променят се единствено полетата в bold

Thunderbird autoconfig:

source: https://wiki.mozilla.org/Thunderbird:Autoconfiguration

1. добавяте в DNS сървъра следния примерен запис:

autoconfig    IN   CNAME   mail.lordofdeath.net.

2. mkdir /var/www/mail

3. cd /var/www/mail/

4. editor config-v1.1.xml

<?xml version="1.0" encoding="UTF-8"?>

<clientConfig version="1.1">
  <emailProvider id="lordofdeath.net">
    <domain>lordofdeath.net</domain>
    <displayName>My Mail</displayName>
    <displayShortName>Mail</displayShortName>
    <incomingServer type="imap">
      <hostname>mail.lordofdeath.net</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-encrypted</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <incomingServer type="imap">
      <hostname>mail.lordofdeath.net</hostname>
      <port>143</port>
      <socketType>STARTTLS</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <incomingServer type="pop3">
      <hostname>mail.lordofdeath.net</hostname>
      <port>995</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <incomingServer type="pop3">
      <hostname>mail.lordofdeath.net</hostname>
      <port>110</port>
      <socketType>STARTTLS</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>
    <outgoingServer type="smtp">
      <hostname>mail.lordofdeath.net</hostname>
      <port>465</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
    <outgoingServer type="smtp">
      <hostname>mail.lordofdeath.net</hostname>
      <port>587</port>
      <socketType>STARTTLS</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
  </emailProvider>
</clientConfig>

5. ln -s config-v1.1.xml config-v1.xml

Outlook autodiscovery:

source: http://virer.net/info/ol-autodiscover/index.html

1. mkdir /var/www/autodiscover

2. editor /var/www/autodiscover/.htaccess

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} -s [OR]

RewriteCond %{REQUEST_FILENAME} -l [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^.*$ – [NC,L]

RewriteRule ^.*$ autodiscover.php [NC,L]

3. a2enmod rewrite

4. /etc/init.d/apache2 reload

5.  добавяте следния запис в DNS:

_autodiscover._tcp IN SRV 0 100 443 mail.lordofdeath.net.

ако нямате валиден сертификат за SSL, сменете 443 с 80

5.1 добавете и следният запис:

autodiscover IN A mail.lordofdeath.net.

6.  editor /var/www/autodiscover/autodiscover.php

<?php

//get raw POST data so we can extract the email address

$data = file_get_contents(“php://input”);

preg_match(“/\<EMailAddress\>(.*?)\<\/EMailAddress\>/”, $data, $matches);

//set Content-Type

header(“Content-Type: application/xml”);

?>

<?php echo ‘<?xml version=”1.0″ encoding=”utf-8″ ?>’; ?>

<Autodiscover xmlns=”http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006″>

<Response xmlns=”http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a”>

<Account>

<AccountType>email</AccountType>

<Action>settings</Action>

<Protocol>

<Type>POP3</Type>

<Server>mail.lordofdeath.net</Server>

<Port>995</Port>

<LoginName><?php echo $matches[1]; ?></LoginName>

<DomainRequired>off</DomainRequired>

<SPA>off</SPA>

<SSL>on</SSL>

<AuthRequired>on</AuthRequired>

<DomainRequired>off</DomainRequired>

</Protocol>

<Protocol>

<Type>IMAP</Type>

<Server>mail.lordofdeath.net</Server>

<Port>993</Port>

<DomainRequired>off</DomainRequired>

<LoginName><?php echo $matches[1]; ?></LoginName>

<SPA>off</SPA>

<SSL>on</SSL>

<AuthRequired>on</AuthRequired>

</Protocol>

<Protocol>

<Type>SMTP</Type>

<Server>mail.lordofdeath.net</Server>

<Port>465</Port>

<DomainRequired>off</DomainRequired>

<LoginName><?php echo $matches[1]; ?></LoginName>

<SPA>off</SPA>

<SSL>on</SSL>

<AuthRequired>on</AuthRequired>

<UsePOPAuth>on</UsePOPAuth>

<SMTPLast>on</SMTPLast>

</Protocol>

</Account>

</Response>

</Autodiscover>

За сега тестовете показаха успешно сработване с посочените настройки. Надавам се те да спестят излишно време на support техниците в разяснения..

* Outlook ще избере POP3 без да дава възможност за избор на потребителя. ако държите да ползвате IMAP, разместете Protocol секциите.

** Ако поставите IMAP преди POP3, UsePOPAuth няма да работи, ще трябва на ръка да се настрои Outgoing Server-> My server req. auth -> Use same as incoming

Удостоверителни вериги

vladimir simeonov
18/07/2011

Живееки в Балканска държава, по български стандарт всичко ни е циганско. Тъпите доставчици на УЕП имат хиляди безсмислени ROOT CA, Intermediate CA и така и не се сещат да ги съберат на един адрес, така че системните администратори като мен да могат с едно кликане да се справят с бъркоча им.

След гневния ми встъпителен коментар, ще посоча линкове за сваляне на съответните Root CA, за свое у чуждо улеснение.

Дано някой ден да доживеем въпросните кръвопиици да се сертифицират за добавяне в Trusted Root CA на основните browsers или поне да стъпи на родната почва европейски доставчик на услуги за електронен подпис.

Postfix Perl Dragon

vladimir simeonov
18/07/2011

Postfix е най – добрият пощенски агент, но без добра програмка за парсване на логовете му остава усещането за липса в душата на админа. Една такава липса ме глождеше дълго време докато не се заех с тежката задача да напиша скрипт, който да обхожда логовете и да ги вмъква в mysql. целият чалъм и пиниз се състои в това, че postfix като програма съставена от под програмки, които тръгват, извършват определена задача и изчезват; навързани на сложна логическа нишка си записват своите дейности в системния лог, без от него да може да се направи привидно смислена връзка. на отделни редове без последователност, в лога се натрупва информацията и обработката на входящи, изходящи писма, препращания и т.н. трябваха ми месеци докато стигна до нещо работещо..

скрипта е достигнал версията си 3.2 към момента на писане на поста, извървявайки дълъг път от оптимизации и промяна в логиката, пренаписвания..

може би скоро, когато имам повече свободно време ще го пренапиша отново с цел оптимизация.

малко за самия скрипт или фамилия от скриптове:

dragon_parser.pl е основният скрипт вършейки цялата работа по прочитане на лога и записване в базата данни.

dragon_cleaner.pl изчиства базата от стари записи, според оказания интервал.

dragon_sqlize.pl обира писмата от catchall кутия в postfix и ги импортва в MySQL. внимавайте с обема на писмата. за натоварен сървър не се препоръчва използването на скрипта.

dragon_pbs.pl е малко скриптче, което замества pop-before-smtp програмите. скрипта може да се пуска чрез pop-before-smtp файла, който се копира в /etc/init.d/

dragon_unhidepw.pl хваща паролите които courier-authdaemon записва в лога, и ги записва в ldap. като цяло върши работа единствено на мен, но нямаше в кой друг проект да го добавя.

единственото което трябва потребителя да направи за да работи скрипта е:

1. инсталира perl библиотеките описани в Readme

2. стартира ./install.sh скрипта

3. добави задачи в cron за стартиране на скриптовете в желан timeframe от него