В /etc/mail/sendmail.mc намираме следният ред:
dnl define(`SMART_HOST', `smtp.your.provider')dnl
и го корегираме на:
define(`SMART_HOST', `smtp.gmail.com')dnl

Следва компилация на направените промени:
# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
(Необходимо е пакета sendmail-cf да бъде инсталиран)

В /etc/mail/access добавяме реда с данните за аутентикация:
AuthInfo:smtp.gmail.com "U:username@gmail.com" "P:password" "M:PLAIN"

Следва отново “компилация” на направената промяна:
# makemap hash /etc/mail/access < /etc/mail/access

Всички домейни писмата, до които не трябва да се изпращат към smart host-а се описват в /etc/mail/local-host-names по един на ред:

loclahost
localhost.localdomain
hostmaster.kamenitza.org

И рестартиране на sendmail:
# /etc/init.d/sendmail restart

Не забравяйте да настроите sendmail да се стартира автоматично с операционната система:
# chkconfig sendmail on

Туй то

Нещо по-добро е репликирането на цяла файлова система на блоково ниво. Всяка една промяна върху диска се репликира моментално каквато и да е тя – и то без софтуерът, който ползва тази файлова система да разбере.

Удобен начин да се направи това в линукс е чрез DRBD. Тъй като репликацията е на много ниско ниво, не можем да репликираме отделни директории или файлове – работим с цели дискове или дялове (партишъни). Тъй като не всеки разполага със свободен диск/дял, който да ползва за репликацията, ще дам пример с “изкуствен” диск, създаден във файл върху текущата файлова система (loopback image). Т.е. правим един файл с размер 1GB, присъединяваме го като виртуален локален диск, правим му файлова система по желание и вече е в бизнеса

Създаваме файл с размер 1GB (на двата сървъра между, които ще репликираме):
# dd if=/dev/zero of=/root/disk.img bs=1M count=1024

Сега да го прилепим към локално устройство /dev/loop0:
# losetup /dev/loop0 /root/disk.img

Това до тук ще работи, но докато не рестартираме машината. За тази цел правим един init-скрипт, който да върши тази работа при стартиране на операционната система:

#!/bin/bash
# lofsd:         Loopback filesystem
#
# chkconfig:    - 10 80
# description:  Creates loopback device
DRBD_SRC="/root/disk.img"
DRBD_DEVICE="/dev/loop0"
LOSETUP_CMD="/sbin/losetup"
RETVAL=0
start() {
        echo "Connecting loop devices $DRBD_DEVICE"
        $LOSETUP_CMD $DRBD_DEVICE $DRBD_SRC
        RETVAL=$?
        return $RETVAL
}
stop() {
        echo "Releasing loop devices $DRBD_DEVICE"
        $LOSETUP_CMD -d $DRBD_DEVICE
        RETVAL=$?
        return $RETVAL
}
restart() {
    stop
    sleep 1
    start
}
case "$1" in
    start)
        start
    ;;
    stop)
        stop
    ;;
    restart)
        restart
    ;;
        *)
    echo "Usage: $0 {start|stop|restart}"
    exit 1
esac
exit $?
exit $RETVAL

Регистрираме скрипта като системна услуга и го активираме:

# chkconfig --add lofsd
# chkconfig lofsd on

До тук вече имаме един локален виртуален диск на /dev/loop0 и нищо повече. Сега е ред да инсталираме и самото DRBD:
# yum -y install drbd kmod-drbd

Конфигурационният му файл /etc/drbd.conf, е съвсем празен веднага след инсталацията, но има много добре коментиран примерен такъв в /usr/share/doc/drbd. Набързо спретвам следната конфигурация, която изглежда сложна само на пръв поглед (еднаква е и за двата сървъра):

global { usage-count no; }
resource repdata {
    protocol C;
    startup { wfc-timeout 0; degr-wfc-timeout     120; }
    disk { on-io-error detach; }
    net {  cram-hmac-alg "sha1"; shared-secret "ie74t6384"; }
    syncer { rate 10M; }
    on n1.kamenitza.org {
        device /dev/drbd0;
        disk /dev/loop0;
        address 10.0.0.1:7788;
        meta-disk internal;
    }
    on n2.kamenitza.org {
        device /dev/drbd0;
        disk /dev/loop0;
        address 10.0.0.2:7788;
        meta-disk internal;
    }
}

Няма да коментирам кой ред какво върши – вероятно само очевидните неща като, пътища до устройства и адреси ще трябва да редактирате – останалото е почти универсално. Все пак, ако се интересувате – разгледайте примерният drbd.conf, който е изключително добре коментиран. Когато приключите с конфигурацията – копирайте я и на вторият сървър.

Време е да инициализираме мета-данните (и на двата сървъра):

# drbdadm create-md repdata
v08 Magic number not found
v07 Magic number not found
v07 Magic number not found
v08 Magic number not found
Writing meta data...
initialising activity log
NOT initialized bitmap
New drbd meta data block sucessfully created.

Сигурно веднага ще опитате да стартирате услугата, но може да ударите стена:

# /etc/init.d/drbd start
Restarting all DRBD resourcesNo response from the DRBD driver! Is the module loaded?
Command '/sbin/drbdsetup /dev/drbd0 down' terminated with exit code 20
command exited with code 20
ERROR: Module drbd does not exist in /proc/modules

Ами това помага :
# modprobe drbd

След като сте стартирали сървиса (и на двата сървъра), можете да наблюдавате статуса на дисковия ресурс ето така:

# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03            11:30:17
 0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r---
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:1048508

Ако някой забелязва – и двете копия са вторични (secondary). Такива ще си останат, докато ние не изберем, кой да е водещият сървър и в неговия шел пуснем ето това:
# drbdadm -- --overwrite-data-of-peer primary repdata

Я да видим статуса:

# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03            11:30:17
 0: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---
    ns:16932 nr:0 dw:0 dr:19168 al:0 bm:1 lo:0 pe:4 ua:70 ap:0 oos:1031676
        [>....................] sync'ed:  2.0% (1031676/1048508)K
        finish: 0:00:59 speed: 16,832 (16,832) K/sec

Сякаш работи и вече тече репликация, а?
Остана да направим една файлова система на DRBD диска:
# mkfs -t ext3 /dev/drbd0

И да го монтираме (създайте директорията /mnt/disk и на двата сървъра, но го монтирайте само на първия):
mount /dev/drbd0 /mnt/disk

След приключване на репликацията, нещата изглеждат горе долу така:

# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:17
 0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
    ns:56 nr:1412 dw:1468 dr:21 al:2 bm:3 lo:0 pe:0 ua:0 ap:0 oos:0

Ами можем вече да го изпробваме. Копирайте някакви файлове на диска преди това.
Ръчно размонтираме и правим вторичен първият сървър (n1):
# umount /mnt/disk ; drbdadm secondary repdata

Сега отиваме на втория (n2) и правим следното:
# drbdadm primary repdata ; mount /dev/drbd0 /mnt/disk

И трябва да виждаме същите файлове, които преди това копирахме от сървър n1.

За да си улесним живота в бъдеще можем да редактираме и /etc/fstab, който до момента изглежда горе-долу така:

LABEL=/                 /                       ext3    defaults        1 1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sda2         swap                    swap    defaults        0 0

Добавяме следният ред най-долу:

/dev/drbd0              /mnt/disk               ext3    noauto          0 0

Така, че файлът да придобие този вид:

LABEL=/                 /                       ext3    defaults        1 1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-sda2         swap                    swap    defaults        0 0
/dev/drbd0              /mnt/disk               ext3    noauto          0 0

Цялата тази глезотия става изключително полезна, когато се съвмести с Heartbeat. Тогава в /etc/ha.d/haresources добавяме следният ред:

n1.kamenitza.org   drbddisk::repdata Filesystem::/dev/drbd0::/mnt/disk::ext3::rw

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

[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

И актуализирах ядрото с
yum upgrade

Към явно по-прилична компилация:
Linux xxx 2.6.18-274.7.1.el5.centos.plus #1 SMP Thu Oct 20 19:28:06 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

Проблема повече не се е появявал

При просто копиране на файловете ще получаваме грешки от сорта на:
rrd_graph() ERROR: This RRD was created on another architecture

Най-доброто, което може да се направи е базите данни да се експортират в XML формат, след това тези XML файлове да се копират и да се конвертират обратно в RRD.

Експортиране в XML:
for i in `find -name "*.rrd"`; do rrdtool dump $i > $i.xml; done

Конвертиране обратно в RRD:
for i in `find -name "*.xml"`; do rrdtool restore $i `echo $i | sed s/.xml//g`; done

Енжой

Squid поддържа много методи за уторизация на потребители, но най-лесен ми се струва NCSA. Ще дам пример със squid на CentOS 5.6 64bit.

Създаваме файла с потребителските имена и пароли:
# htpasswd -c /etc/squid/passwd user
Само ще попита за парола.

Модула ncsa_auth обикновено е инсталиран заедно със squid. Можете да проверите ето така:
# rpm -ql squid | grep ncsa_auth

Следните няколко реда се добавят в squid.conf:

auth_param basic program /usr/lib64/squid/ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Please authenticate!
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

Без ACL запис няма да минем естествено

acl ncsa_users proxy_auth REQUIRED
http_access allow ncsa_users

Необходим е рестарт на squid.

#!/bin/bash

#------Configuration

#Send alert to this email address
EMAIL="35988xxxxxxx@sms.mtel.net"

#Partition which should be monitored
PARTITION="/dev/md1"

#If free space is less than this value in KB - send email
SPACELIMIT=1000000

#How long to wait in minutes to send another email
REMINDTIMEOUT=120

#Time format used in the message
TIME=`date +"%d.%m.%y %H:%M"`

#The marker prevents sending of too many messages
#Must be unique for each partition monitored.
#Add different numbers at the end of the file name for each partition
MARKER="/tmp/freespacereached"

#------END of Configuration

if [ -f $MARKER ]; then
    MARKERAGE=$(($((`date +%s`-`stat -c %Z $MARKER`)) / 60))
else
    MARKERAGE=0
fi

if [ $MARKERAGE -gt $REMINDTIMEOUT ]; then
    rm -f $MARKER
fi

FREESPACE=`df | grep "$PARTITION" | awk '{ print $4}'`
# Prevent crash in case of wrong partition configuration or data extraction
FREESPACE=$((FREESPACE+0));

if [ $FREESPACE -lt $SPACELIMIT ]; then
    MSG="$TIME - Spacecheck WARNING! - $((FREESPACE/1024))MB available on $PARTITION"
    if [ ! -f "$MARKER" ]; then
        echo $MSG | mail $EMAIL
        touch $MARKER
    fi
else
    rm -f $MARKER
fi

Изпълнението на скрипта се предоставя на cron, като се създава конфигурационен ред, подобен на този:

0 9-21 * * * /scripts/spacecheck.sh

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

Ще споделя как може да се следи температурата на хард дисковете с негова помощ. Приемам, че сте конфигурирали snmpd правилно и демонът работи (за справка – тук).

В конфигурацията на демона – /etc/snmp/snmpd.conf добавяте това:

exec hdd1temp /root/hdd1temp.sh

Това е съдържанието на /root/hdd1temp.sh:

#!/bin/bash
/usr/sbin/smartctl -A /dev/sda | grep -i temperatur | awk '{print  $10}'

Задължително файлът да е изпълним (chmod +x …).

Рестарт на snmpd и нека проверим какво се случи:

# snmpwalk -v2c -c communitypass localhost UCD-SNMP-MIB::extOutput

Този пример със snmpwalk ще “изплюе” всички exec редове от snmpd.conf по ред на номерата им.

От тук нататък е въпрос на фантазия какво ще правите със събираните данни. Можете да си настроите аларма при превишаване на температурата с подходящ bash скрипт, както и да рисувате статистика с RRD или MRTG.

Ето така ще получите само конкретната стойност готова за по-нататъшна обработка:

# snmpwalk -v2c -Oqv -c communitypass localhost UCD-SNMP-MIB::extOutput.1

Примерът е от CentOS. За други дистрибуции файлът snmpd.conf може да е в друга директория, но останалото остава същото
Енджой!

Доставчик1:
закачен е към eth0
IP: 100.100.100.12/255.255.255.0
GW: 100.100.100.1

Доставчик2:
закачен е към eth1
IP: 200.200.200.56/255.255.255.0
GW: 200.200.200.1

Вътрешна мрежа:
закачена е към eth2
192.168.1.1/24

Транслиране на изходящия трафик през интерфейсите към Интернет доставчиците:
# iptables -t nat -A POSTROUTING -j MASQUERADE
Маскирането по този начин работи дори и IP адреса да е динамичен.

От тук нататък дали ще ползваме Доставчик1 или Доставчик2 зависи само от това кой шлюз по подразбиране ще оставим активен на рутера – 100.100.100.1 или 200.200.200.1.

Сега едно малко скрипт-роботче ще проверява през 5 минути (или колкото вие решите) дали има връзка към Интернет. Проверката ще става като пингва един от ДНС сървърите на OpenDNS 208.67.222.222 (може и ИП адреса на някой root-DNS да сложите, няма значение – нещо което е винаги винаги на линия). Механизъмът е устроен така, че ако не получи отговор, ще подмени шлюза с този на другия доставчик.

#!/bin/bash
GW1=100.100.100.1
GW2=200.200.200.1
CHECK_HOST=208.67.222.222

DEFAULT_GW=`ip route list | grep default | awk '{print $3}'`
if /bin/ping -n -c 5 $CHECK_HOST 1>/dev/null 2>/dev/null; then
  echo "Link OK"
else
  echo "Link down! Switching..."
  if [ $DEFAULT_GW==GW1 ]; then
    ip route del default
    ip route add default via $GW2
  else
    ip route del default
    ip route add default via $GW1
  fi
fi

Копирайте този скрипт в текстов файл, направете го изпълним (chmod +x filename) и го добавете в crontab за изпълнение през определено време.

В този пример и двата доставчика са еднакво предпочитани. Т.е. когато от Д1 отпадне и преминем на Д2 – ще останем на Д2 дори и след като Д1 възстанови нормална работа. И така докато ползваният в момента доставчик не отпадне.

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

За да променим алгоритъма за генериране на hash-ове пишем това:
# authconfig --passalgo=sha512 --update

Всички нови пароли ще бъдат в SHA512 формат.

Инсталация на антивирусната:
# yum install clamav clamav-milter

Редакция на /etc/clamav-milter.conf:

MilterSocket inet:7357
MaxFileSize 100M
AddHeader Replace
ReportHostname mx.kamenitza.org

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

Стартираме демоните на антивирусната:

#/etc/init.d/clamd start
#/etc/init.d/clamav-milter start

Ще се покаже съобщение, че вирусните дефиниции са стари. Задължително е да ги обновим:
#freshclam

Добра идея е това да го сложим в cron, за да опреснява периодично:
#crontab -e

И добавяме реда:
0 1 * * * /usr/bin/freshclam

Следва настройката на Postfix, така, че да “прекара” писмата през антивирусната.
Добавяне в /etc/postfix/main.cf:

smtpd_milters = inet:127.0.0.1:7357
milter_default_action = accept

В случай, че има конфигуриран и друг milter (както е при мен) – просто ги разделете със запетая:
smtpd_milters = inet:localhost:10027, inet:127.0.0.1:7357

Начин да проверите дали писмо е минало през антивирусната е като разгледате хедъра. Там ще видите нещо от сорта на:

X-Virus-Scanned: clamav-milter 0.96.5 at mx.kamenitza.org
X-Virus-Status: Clean

Изтегляне на dk-milter:
#rpm -Uvh http://www.topdog-software.com/oss/dk-milter/dk-milter-1.0.2-1.i386.rpm

Генериране на ключовете:

#/usr/share/doc/dk-milter-1.0.2/gentxt.sh

Където
е име по избор, аз използвах “mx”:
#/usr/share/doc/dk-milter-1.0.2/gentxt.sh mx kamenitza.org

Това ще генерира няколко файла:
mx.txt:
mx._domainkey IN TXT "g=; k=rsa; t=y; p=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMDcC/ip9pXcyRy6H9lw2Nl5aRjeg8KiIeL71tFsg+ja3P4Zm2aCCtjQevStFBKEAZG7cxIMY7mNdnum1dJj55cCAwEAAQ=="

mx.public:

-----BEGIN PUBLIC KEY-----
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMDcC/ip9pXcyRy6H9lw2Nl5aRjeg8Ki
IeL71tFsg+ja3P4Zm2aCCtjQevStFBKEAZG7cxIMY7mNdnum1dJj55cCAwEAAQ==
-----END PUBLIC KEY-----

mx.private:

-----BEGIN RSA PRIVATE KEY-----
MIIBOwIBAAJBAMDcC/ip9pXcyRy6H9lw2Nl5aRjeg8KiIeL71tFsg+ja3P4Zm2aC
CtjQevStFBKEAZG7cxIMY7mNdnum1dJj55cCAwEAAQJAE/Ov2V3cAM0CkVJAEUK3
bGg/Ey+R+gTD9LORGcFcNC6h21sClpYV0mrIS1PkXX1cUZgQ9jl/gFzAXORL2E56
IQIhAP8+HmAS8RT+dCOCnioWa2kSmkwmITHnCdePrHVYl6l9AiEAwW6Kyks76ecG
TT8nPegYObAMqokM9fF3XBp4nLcHgaMCIQCGoDYXSIZeI2QQgsl3u4GF1ykJNydV
Ed5wEzjMYCEGZQIgHIs6ceWuPrL3zBhgqxL/2CtxgwzcW8K5MV86oy2jLu8CIQDA
kXZ6SyJvhJsw3KwhLsKU4IKAu1VM/YLzkKaffWVYBw==
-----END RSA PRIVATE KEY-----

Преместете liчният ключ (mx.private) в /etc/mail/domainkeys. След това:
#chown dk-milter:dk-milter mx.private
#chmod 600 mx.private

След това добавете в DNS конфигурацията на зоната на домейна
_domainkey IN TXT "t=y; o=~"
Съдържанието на текстовия файл mx.txt също трябва да бъде добавено в DNS зоната на домейна.

Следва редактиране на /etc/sysconfig/dk-milter:

USER="dk-milt"
PORT="inet:10027@127.0.0.1"
SIGNING_DOMAIN="domain.tld"
SELECTOR_NAME="mx"
KEYFILE="/etc/mail/domainkeys/mx.private"
SIGNER=yes
VERIFIER=yes
CANON=simple
REJECTION="bad=r,dns=t,int=t,no=a,miss=r"
EXTRA_ARGS="-h -l -D"
MILTER_GROUP="mail"

Стартиране на демона:
#/etc/init.d/dk-milter start

И на края редакция на /etc/postfix/main.cf:

smtpd_milters = inet:localhost:10027
non_smtpd_milters = inet:localhot:10027

И рестартирате postfix.

За да се тества дали работи тази конфигурация изпратете празно писмо до test@dktest.jason.long.name.

Информацията за тази статия е синтезирана от http://jason.long.name/dkfilter/

1. Инсталиране на postgresql server:
#yum -y install postgresql-server

След стартиране на postgresql – продължаваме.
Създаване на потребител и база за postfix:

#su postgres
$psql
postgres=# create user postfix with password 'password';
postgres=# create database postfix owner postfix;
postgres=# \q
$exit

2. Инсталиране на Postfix с поддръжка на база данни.
Ако до сега сте имали инсталиран Postfix, той трябва да бъде деинсталиран:
#yum erase postfix

Редактира се /etc/yum.repos.d/CentOS-Base.repo:
В раздел [base] и [updates] се добавя реда:
exclude=postfix
В раздел [centosplus]:
enabled=1

Проверка дали пакета на Postfix с поддръжката на бази данни се “вижда”:

#yum list postfix
...
...
postfix.x86_64  2:2.3.3-2.1.centos.mysql_pgsql

Това, което ни трябва се вижда на края – “…mysql_pgsql”.
Инсталираме:
#yum -y install postfix

Това, което ни трбява в /etc/postfix/main.cf:

myhostname = mail.mydomain.tld
inet_interfaces = all
transport_maps = pgsql:/etc/postfix/transport.cf
virtual_alias_maps = pgsql:/etc/postfix/virtual.cf
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_minimum_uid = 5000
virtual_minimum_gid = 5000
virtual_mailbox_domains = pgsql:/etc/postfix/transport.cf
virtual_mailbox_base = /home/mail
virtual_mailbox_maps = pgsql:/etc/postfix/mailboxes.cf
virtual_mailbox_limit = 1073741824

Последния ред означава, че имаме лимит от 1GB на пощенска кутия.

/etc/postfix/transport.cf:

hosts = localhost
user = postfix
password = password
dbname = postfix
table = domain
select_field = transport
where_field = domain

/etc/postfix/virtual.cf

hosts = localhost
user = postfix
password = password
dbname = postfix
table = alias
select_field = goto
where_field = address

/etc/postfix/mailboxes.cf

hosts = localhost
user = postfix
password = password
dbname = postfix
table = mailbox
select_field = maildir
where_field = username

След като всички конфигурационни файлове са готови, стартираме демона:
#/etc/init.d/postfix start

3. Инсталиране на dovecot:
#yum -y install dovecot

В /etc/dovecot.conf:

auth default {
    mechanisms = plain
    passdb sql {
        args = /etc/dovecot-pgsql.conf
    }
    userdb sql {
        args = /etc/dovecot-pgsql.conf
    }
    socket listen {
        client {
            path = /var/run/dovecot/auth-client
            mode = 0660
            user = postfix
            group = postfix
        }
    }
}
first_valid_uid = 5000
first_valid_gid = 5000

/etc/dovecot-pgsql.conf:

driver = pgsql
connect = host=localhost dbname=postfix user=postfix password=password
default_pass_scheme = crypt
password_query = SELECT password FROM mailbox WHERE username='%u' AND active='1'
user_query = SELECT '/home/mail/'||maildir AS home, '/home/mail/'||maildir AS mail, 5000 as uid, 5000 as gid FROM mailbox WHERE username='%u' AND active='1'

Стартиране на dovecot:
#/etc/init.d/dovecot start

Поглеждаме в /var/log/maillog за евентуални грешки. Ако всичко е наред може би дори ще се вижда и поток от спам към несъществуващи пощенски кутии.

4. Postfixadmin
Инсталацията му се свежда до разархивирането на архива в папка достъпна през уеб и редакцията на config.inc.php, като в него единствено трябва да са попълни конфигурацията за достъп до базата данни.

След като създадем потребители чрез postfixadmin, те вече ще могат да получават поща, както и ще имат достъп до пощенските си кутии чрез IMAP/POP3.

5. Изпращане на електронна поща – SMTP
Елементарен начин това да стане е като се опишат мрежите, които е разрешено да релейват през този пощенски сървър в /etc/postfix/main.cf:
mynetworks = 127.0.0.0/8 192.168.0.0/24

Това не е най-сигурният метод, понеже не използва никаква идентификация на ниво потребител.
По-добрият вариант е потребителят да трябва да се идентифицира, за да изпрати успешно писмо.
Добавяме в /etc/postfix/main.cf следните няколко реда:

smtpd_sasl_type = dovecot
smtpd_sasl_path = /var/run/dovecot/auth-client
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Вече можете и да изпращате през този сървър

Добре ще е да сложим и елементарна спам-защита. Необхоримо е да преработим smtpd_recipient_restrictions записа в main.cf, така, че да се получи следното:

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    permit_mynetworks,
    permit_sasl_authenticated,
    check_client_access hash:/etc/postfix/whitelist,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client 0spam.fusionzero.com,
    reject_rbl_client bl.spamcannibal.org,
    reject_rbl_client blackholes.five-ten-sg.com,
    reject_rbl_client blackholes.intersil.net,
    reject_rbl_client dnsbl.sorbs.net,
    reject_rbl_client dnsbl-0.uceprotect.net,
    reject_rbl_client dnsbl-1.uceprotect.net,
    reject_unauth_destination

Като файлът /etc/postfix/whitelist съдържа хостове изпращащи поща, които не желаете да преминат през спам-филтрите. Обикновено това са пощенски сървъри на мързеливи администратори, които не отговарят на някое или всички изисквания за легитимно изпращане на поща. Ето примерно съдържание на файла:

212.39.90.88  OK
mbox.contact.bg  OK
sts-tech.com  OK
87.121.24.7  OK

Това е всичко необходимо за напълно работещ сървър с виртуални потребители. За въпроси – ползвайте коментарите. Скоро ще пусна статия как да подсигурим същият този сървър с помощта на SSL.

# yum -y install ushare

Следва бърза редакция на /etc/ushare.conf:

USHARE_NAME=My_Server
USHARE_IFACE=
USHARE_PORT=
USHARE_TELNET_PORT=
USHARE_DIR=/mnt/md1/files/Movies
USHARE_OVERRIDE_ICONV_ERR=
ENABLE_WEB=
ENABLE_TELNET=
ENABLE_XBOX=
ENABLE_DLNA=yes

И стартиране на услугата:
# /etc/init.d/ushare start

А ето така върху файловете:
find . -type f -exec chmod 644 {} \;