LDAP базирано управление на пощенските концентратори на мрежата на СУ "Св. Климент Охридски"

Версия 2.2.1, 19 юни 2008

Веселин Колев, Софийски Университет "Св. Климент Охридски"

Адрес за кореспонденция: vesso AT vesselin.org

Първоизточник: http://www.vesselin.org

Лиценз на документа: CC Attribution-ShareAlike

 

 

Съдържание:

  1. Увод

  2. Инсталиране на пакетите на Sendmail

  3. Създаване на непривилигерован потребител sendmail

  4. Създаване на директория за опашката на sendmail

  5. Създаване на директория и файл за съхранение на статистиките

  6. Създаване на файл за съхранение на паролата за достъп до LDAP директорията

  7. Конфигурация на демона във файла /etc/mail/sendmail.mc и LDAP интеграция

  8. Изграждане на скелета на конфигурационното дърво за услугата sendmail в LDAP директорията

  9. Изграждане на скелета на конфигурационното дърво за пощенски концентратор

  10. Смяна на паролата в конфигурационното дърво за пощенски концентратор

  11. Изграждане на скелета на конфигурационното дърво за клъстер с конфигурации

  12. Логическа и йерархична схема на описанието на конфигурацията за управление на пощенските концентратори в LDAP директорията

  13. Указване на домейните, пощата за които ще бъде обработвана локално от концентраторите (на база име на концентратор)

  14. Указване на домейните, пощата за които ще бъде обработвана локално от концентраторите (на база име на конфигурационен клъстер)

  15. Извършване на промени в списъка с домейни, пощата за които е обработвана локално от концентраторите (на база име на концентратор)

  16. Извършване на промени в списъка с домейни, пощата за които е обработвана локално от концентраторите (на база име на конфигурационен клъстер)

  17. Създаване в LDAP директорията на пощенски псевдоним (alias) (достъпен на база пощенски концентратор)

  18. Създаване в LDAP директорията на пощенски псевдоним (alias) (достъпен на база клъстер на конфигурации)

  19. Преглед на декларираните в LDAP директорията псевдоними (alias

  20. Промяна на съдържанието на пощенски псевдоним и изтриване на пощенски псевдоним от LDAP директорията

  21. Указване в LDAP директорията на разрешение за транспорт (access) (на база пощенски концентратор)

  22. Указване в LDAP директорията на разрешение за транспорт (access) (достъпно на база клъстер от конфигурации)

  23. Преглед на декларираните в LDAP директорията разрешения за транспорт (access)

  24. Премахване от LDAP директорията на разрешение за транспорт (access)

  25. Деклариране в LDAP директорията на алтернативно транспортиране (mailertable) на поща за домейн (на база пощенски концентратор)

  26. Деклариране в LDAP директорията на алтернативно транспортиране (mailertable) на поща за домейн (достъпно на база клъстер от конфигурации)

  27. Преглед на декларациите в LDAP директорията за алтернативен транспорт (mailetable)

  28. Промяна и премахване от LDAP директорията на декларация за алтернативен транспорт (mailertable)

  29. Предишни версии на публикацията

 

1. Увод.

Управлението на Sendmail в ролята му на MTA (Mail Transport Agent) се извършва централизирано с помощта на свързването на демона sendmail към LDAP директорийна услуга.

Целта на този документ е да опише интеграцията на пощенските концентратори на Софийския Университет "Св. Климент Охридски" с LDAP директорията, в която са въведени параметрите на мрежовите услуги. Дадени са подробни описания на LDIF шаблоните, с които се извършва създаване, промяна и премахване на записи от LDAP директорията.

Всички описания по-долу са в контекста на използваната дистрибуция Red Hat Enterprise Linux (или нейните производни).

 

2. Инсталиране на пакетите на Sendmail.

За реализирането (инсталиране и конфигуриране) на пощенския концентратор в дистрибуцията Red Hat Enterprise Linux и производните й, са необходими два пакета: sendmail и sendmail-cf. Без пакетът sendmail-cf не е възможна последващата конфигурация на демона sendmail с използването на m4 интерпретация на макросния прототип на конфигурацията.

По подразбиране при инсталацията на дистрибуцията Red Hat Enterprise Linux или производните й, пакетът sendmail се инсталира по подразбиране, но това не касае пакета sendmail-cf. Последният трябва да бъде инсталиран допълнително. Най-добре е да се иницира процес на инсталиране и на двата пакета, а пакетния мениджър ще инсталира само тези, които не са инсталирани вече в системата:

# yum install sendmail sendmail-cf

 

3. Създаване на непривилигерован потребител sendmail.

Тази стъпка е абсолютно задължителна с оглед гарантиране сигурността на системата срещу пробиви, които има вероятност да се случат, ако процесите на sendmail се изпълняват с ефективните права на root. След като потребителят sendmail бъде създаден в системата, процесите на демона sendmail се стартират с правата на този потребител. По-точно е да се каже, че майчиният процес, който слуша на порт 25/tcp се изпълнява с ефективните права на root винаги, но при всяка нова сесия към този порт, майчиния процес създава дъщерен, който поема обслужването на сесията и именно дъщерния процес е с ефективни права на непривилигерования потребител sendmail.

Създаването на непривилигерования потребител sendmail следва следните стъпки (командни редове), които трябва да се изпълнят с права на root:

# useradd -g mail -s /sbin/nologin -d /dev/null -c "Sendmail Daemon User" sendmail

Забележка: В горния команден ред не е указан уникален номер на потребителя в системата и в този случай инструментът useradd ще избере първия незает числов идентификатор. Ако се налага да се спазва номерационен план в конкретната система и за потребителя sendmail е назначен определен числов идентификатор, стойността му трябва да се укаже с опцията -u. Например, ако за sendmail е заделен потребителски числов идентификатор 600, създаването на потребителя става чрез командния ред:

# useradd -u 600 -g mail -s /sbin/nologin -d /dev/null -c "Sendmail Daemon User" sendmail

 

4. Създаване на директория за опашката на sendmail.

При инсталация на пакета sendmail от RPM колекцията на дистрибуцията, "опашката" на демона sendmail се намира в директория /var/spool/mqueue. Собствеността върху нея е на root. Ако дъщерните процеси на демона се стартират с правата на непривилигерования потребител sendmail, а собствеността върху директорията е на root, то процесите няма да могат да извършват запис и четене в нея и услугата няма да функционира. Дори върху тази директория да бъдат зададени права за писане и четене от страна на непривилигерования потребител sendmail, то при актуализация на пакета sendmail собствеността на root върху /var/spool/mqueue отново ще бъде възстановена и това ще върне системата в начално състояние, в което процесите на демона не могат да четат и пишат в директорията и услуга няма да има.

За да се предотврати появата на подобен проблем, се използва една от възможностите на Sendmail за конфигурация, а именно да се укаже друга, различна от /var/spool/mqueue директория за "опашка". Преди да бъде направена конфигурационната опция, трябва да се създаде новата "опашка" и да се зададат съответните права и собственост върху нея:

# mkdir -p /storage/sendmail/var/spool/mail
# chmod 700 /storage/sendmail/var/spool/mail
# chown -R sendmail:mail /storage/sendmail/var/spool/mqueue

Забележка: Указаната директория е примерна. Нейното местоположение може да бъде променяно, като се отчитат особеностите на конкретната система, но това задължително трябва да бъде отчетено в конфигурационния файл на sendmail.

 

5. Създаване на директория и файл за съхранение на статистиките.

Макар и да не е задължително, е добре да се има поглед върху обема поща, която процесите на демона sendmail транслират (информация, която се показва с изпълнението на mailstats). По подразбиране тази информация се съхранява във файла /var/log/mail/statistics. За да не се влиза в конфликт със собствеността върху директорията /var/log/mail, е добре да се създаде алтернативна директория, в която да се съхранява файла със статистките. За целта се използва факта, че пълният път до файла със статистиките е конфигурационна опция за sendmail.

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

	# mkdir /storage/sendmail/var/log/mail
	# chmod 700 /storage/sendmail/var/log/mail
	# touch /storage/sendmail/var/log/mail/statistics
	# chown -R sendmail:mail /storage/sendmail/var/log/mail

Ако вече има наличен файл със статистики (например подразбиращия се /var/log/mail/statistics), информацията за които не трябва да се губи, преди да се стартира sendmail за работа по новата схема на привилегии файла може да се копира в /storage/sendmail/var/log/mail/ и да не се създава нов такъв с командата touch (както е описано в командните редове по-горе).

 

6. Създаване на файл за съхранение на паролата за достъп до LDAP директорията.

Четенето на информация от LDAP директорията става само и единствено чрез удостоверяване пред услугата LDAP. Удостоверяването е базирано на подаване на информация за dn на потребителя и парола му към директорийния LDAP сървър. Паролата трябва да се съхранява във файл, достъпен за прочит само от страна на непривилигерования потребител sendmail. В LDAP директорията тази парола се сравнява с тази за съответния пощенски концентратор. При смяна на паролата за концентратора в LDAP директорията, следва тази парола да бъде променена и във файла.

В пощенските концентратори на СУ, файлът с паролата за удостоверяването пред директорийния LDAP сървър е:

/storage/sendmail/etc/mail/sendmail-ldap.passwd

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

# touch /storage/sendmail/etc/mail/sendmail-ldap.passwd
# chmod 400 /storage/sendmail/etc/mail/sendmail-ldap.passwd
# chown sendmail:mail /storage/sendmail/etc/mail/sendmail-ldap.passwd

Забележка: Чак след като файлът бъде създаден и правата за достъп и собственост върху него бъдат установени, в него се описва паролата (във файла трябва да има един единствен ред и той да съдържа само и единствено символния низ с паролата).

 

7. Конфигурация на демона във файла /etc/mail/sendmail.mc и LDAP интеграция.

Описаната по-долу конфигурация покрива нуждите от конфигурационни опции на концентраторите за електронна поща ns.uni-sofia.bg и ady.uni-sofia.bg, но с малки модификации би могла да се използва и на произволен друг концентратор.

Текущият конфигурационен файл за пощенските концентратори на Софийския Университет изглежда така:

След като конфигурационният файл /etc/mail/sendmail.mc бъде създаден или променен, трябва от него да се получи същинската конфигурация, която sendmail демона чете при стартирането си:

# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

 

8. Изграждане на скелета на конфигурационното дърво за услугата sendmail в LDAP директорията.

Услугата sendmail се декларира като разклонение на конфигурационното дърво ou=smtp,ou=services,o=uni-sofia.bg.

За да се декларира нужното разклонение на конфигурационното дърво в LDAP директорията, се съставя следния шаблон (за примера се приема, че съдържанието му се намира във файла create-sednmail-tree.ldif):

dn: ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
ou: sendmail
objectClass: top
objectClass: organizationalunit

dn: ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
objectClass: organizationalUnit
objectClass: top
ou: clusters

dn: ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
objectClass: organizationalUnit
objectClass: top
ou: hosts

За да се въведе съдържанието на шаблона в директорията (за примера съдържанието е във файла create-sednmail-tree.ldif файла), може да се използва командния ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-sednmail-tree.ldif

За изпълнението на командния ред се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

След като бъде създаден описания в горния шаблон скелет на конфигурационното дърво на услугата sendmail, следва да се установят права за достъп до конфигурационната информация в дървото. Целта е да може информацията да бъде достъпвана само от оторизираните за това групи потребители. Права за запис в дървото на услугата трябва да имат само административните потребители. Права за прочит трябва да имат само потребителите, с чиито права процесите на демоните на sendmail ще четат информацията от LDAP директорията.

Установяването на ефективни права за достъп става чрез aci списък. По-долу е представен шаблона за описание на първоначалния филтър за достъп, който в последствие може да бъде и модифициран:

dn: ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
changetype: modify
add: aci
aci: (targetattr="*")(version 3.0; acl "Disable anonymous access to maps"; deny (all) (userdn!="ldap:///uid=*,ou=admins,o=uni-sofia.bg" and userdn!="ldap:///cn=*,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg" and userdn!="ldap:///uid=*,ou=administrators,ou=topologymanagement,o=netscaperoot");)
aci: (targetattr="*")(version 3.0; acl "Disable write access"; deny (write) (userdn!="ldap:///uid=*,ou=admins,o=uni-sofia.bg" and userdn!="ldap:///uid=*,ou=administrators,ou=topologymanagement,o=netscaperoot");)

Ако този шаблон се съдържа във файла create-aci.ldif, то въвеждането на съдържанието му в LDAP директорията става чрез следния команден ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-aci.ldif

За изпълнението на командния ред се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

Съдържанито на шаблона трябва да се тълкува така:

Трябва да се има предвид, че потребителят с dn cn="Directory Manager" има права за прочит и запис в цялото LDAP дърво, но въпреки това всички записи трябва да се извършват с правата на потребители, имащи локален административен достъп до съответната част на дървото, каквито са в конкретния случай тези от ou=admins,o=uni-sofia.bg.

 

9. Изграждане на скелета на конфигурационното дърво за пощенски концентратор.

Внимание: Изграждането на скелета на конфигурационното дърво за пощенски концентратор в LDAP директорията, може да бъде релизирано само, ако вече е наличен скелета на конфигурационното дърво на услугата sendmail. Въвеждането на скелета на конфигурационното дърво за пощенския концентратор става с административни права, т.е. с правата на потребител от групата с dn ou=admins,o=uni-sofia.bg.

По-долу е разгледано създаването на конфигурационното дърво за пощенския концентратор ns.uni-sofia.bg, но примерът може да бъде приложен и за произволен друг концентратор на електронна поща.

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

dn: cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
sendmailMTAHost: ns.uni-sofia.bg
objectClass: top
objectClass: person
objectClass: sendmailMTA
objectClass: organizationalPerson
cn: ns.uni-sofia.bg
sn: local host configuration
userPassword: {SSHA}etAdak3ASmE7UOQQF7E/mTgdPK7BmihN

dn: cn=aliases,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Aliases
objectClass: top
objectClass: groupofuniquenames
cn: aliases

dn: cn=maps,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
objectClass: top
objectClass: groupofuniquenames
cn: maps

dn: cn=access,cn=maps,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Access Map
objectClass: top
objectClass: groupofuniquenames
cn: access

dn: cn=domaintable,cn=maps,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Domaintable Map
objectClass: top
objectClass: groupofuniquenames
cn: domaintable

dn: cn=mailertable,cn=maps,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Mailertable Map
objectClass: top
objectClass: groupofuniquenames
cn: mailertable

dn: cn=virtusertable,cn=maps,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Virtusertable Map
objectClass: top
objectClass: groupofuniquenames
cn: virtusertable

Стойността на атрибута userPassword е паролата, чрез която локалния за концентратора sendmail демон ще се удостоверява пред директорийния сървър, за да може да чете информация от LDAP директорията, която го касае. Тази стойност е хеширана и нейното генериране може да стане с инструмента slappasswd от команден ред:

$ /usr/sbin/slappasswd -h {SSHA}

След изпълнение на командния ред по-горе и двукратното правилно въвеждане на паролата, пресметнания хеш ще бъде изведен като резултат. Той трябва да бъде копиран и въведен в съдържанието на шаблона по-горе. След като съдържанието бъде формирано окончателно, шаблонът трябва да бъде въведен в директорията. Ако съдържанието на шаблона се намира във файла create-hub.ldif, то въвеждането му в LDAP директорията може да стане в команден ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-hub.ldif

След правилното въвеждане на паролата за потребителя с dn uid=adminname,ou=admins,o=uni-sofia.bg, съхранения в шаблона скелет ще бъде въведен в LDAP директорията.

 

10. Смяна на паролата в конфигурационното дърво за пощенски концентратор.

Внимание: Смяната на паролата в скелета на конфигурационното дърво за пощенския концентратор става с административни права, т.е. с правата на потребител от групата с dn ou=admins,o=uni-sofia.bg.

За да бъде сменена паролата, следва да се изчисли хеша на новата парола и да се въведе на мястото на стария хеш в dn обекта на пощенския концентратор. Изчисляването на хеша на паролата става чрез инструмента slappasswd от команден ред:

$ /usr/sbin/slappasswd -h {SSHA}

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

По-долу е даден пример за изграждането на шаблон, чрез който да бъде сменена паролата за концентратора с dn обект cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg. В съдържанието на този шаблон като стойност на атрибута userPassword е поставен изчисления хеш за новата парола:

dn: cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
changetype: modify
replace: userPassword
userPassword: {SSHA}etAdak3ASmE7UOQQF7E/mTgdPK7BmihN

Ако съдържанието на шаблона е запазено във файла change-password.ldif, въвеждането му в директорията (т.е. смяната на паролата), става в команден ред съгласно примера:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -f change-password.ldif

След правилното въвеждане на паролата за потребителя с dn uid=adminname,ou=admins,o=uni-sofia.bg, промяната ще бъде въведена в LDAP директорията.

 

11. Изграждане на скелета на конфигурационното дърво за клъстер с конфигурации.

Внимание: Изграждането на скелета на конфигурационното дърво за клъстер с конфигурации в LDAP директорията, може да бъде релизирано само, ако вече е наличен скелета на конфигурационното дърво на услугата sendmail. Въвеждането на скелета на конфигурационното дърво за клъстер с конфигурации става с административни права, т.е. с правата на потребител от групата с dn ou=admins,o=uni-sofia.bg.

По-долу е разгледано създаването на конфигурационното дърво за клъстрера с конфигурации UniSofiaMTAServer, но примерът може да бъде приложен и за произволен друг клъстер от конфигурации на пощенски концентратори.

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

dn: cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
sendmailMTACluster: UniSofiaMTAServer
sn: main conf. cluster
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: sendmailMTA
cn: UniSofiaMTAServer

dn: cn=aliases,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Aliases
objectClass: top
objectClass: groupofuniquenames
cn: aliases

dn: cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
objectClass: top
objectClass: groupofuniquenames
cn: maps

dn: cn=access,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Access Map
objectClass: top
objectClass: groupofuniquenames
cn: access

dn: cn=domaintable,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Domaintable Map
objectClass: top
objectClass: groupofuniquenames
cn: domaintable

dn: cn=mailertable,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Mailertable Map
objectClass: top
objectClass: groupofuniquenames
cn: mailertable

dn: cn=virtusertable,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
description: Sendmail Virtusertable Map
objectClass: top
objectClass: groupofuniquenames
cn: virtusertable

След изпълнение на командния ред по-горе и двукратното правилно въвеждане на паролата, пресметнания хеш ще бъде изведен като резултат. Той трябва да бъде копиран и въведен в съдържанието на шаблона по-горе. След като съдържанието бъде формирано окончателно, шаблонът трябва да бъде въведен в директорията. Ако съдържанието на шаблона се намира във файла create-cluster.ldif, то въвеждането му в LDAP директорията може да стане в команден ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-cluster.ldif

След правилното въвеждане на паролата за потребителя с dn uid=adminname,ou=admins,o=uni-sofia.bg, съхранения в шаблона скелет ще бъде въведен в LDAP директорията.

 

12. Логическа и йерархична схема на описанието на конфигурацията за управление на пощенските концентратори в LDAP директорията.

Управлението на пощенските концентратори от гледна точка на конфигурационни параметри, се извършва на два слоя в съдържанието на LDAP директорията:

 

13. Указване на домейните, пощата за които ще бъде обработвана локално от концентраторите (на база име на концентратор).

Макар концентраторите за електронна поща на СУ "Св. Климент Охридски" да не изпълняват локална доставка (до потребителски пощенски кутии дефинирани в локалните системи), те обслужват пощенски домейни, в които има само и единствено псевдоними - списъци, в които са описани пощенски кутии на крайни получатели в други пощенски домейни. Ефектът от такава обработка на база псевдоними е такъв, че когато се изпрати електронно писмо до псевдоним (alias), то не се доставя локално от пощенския концентратор в кутия върху файловата система, а се разпраща до асоциираните към псевдонима пощенски кутии, които по правило са върху отдалечени сървъри за електронна поща.

Списъкът с домейни, писмата за които ще се обслужват локално (привидно само, защото ще се обслужват само адреси-псевдоними), се задава в LDAP директорията и е специфичен за всеки концентратор на поща или за клъстер от конфигурации на концентратори. Всеки един от концентраторите на поща, който трябва да обслужва локално пощата за домейни по гореописания начин, прочита списъка с домейните за които да извършва локална обработка при всяко стартиране или рестартиране на демона sendmail. Трябва да се има предвид, че този списък не е динамично читаем за всяко едно обработваемо писмо, и съдържанието му е валидно за една цяла работна сесия на Sendmail (между стартиране и спиране на демона sendmail). Това означава, че при всяка промяна на списъка с домейни за локално обслужване, върху засегнатите от това концентратори трябва да се рестартира демона sendmail на засегнатите от промяната концентратори.

По-долу е показан шаблон, с които се създава списък с домейни, подлежащи на локално обслужване от концентратора ns.uni-sofia.bg (с минимални промени в съдържанието, шаблона може да бъде приложен и за друг концентратор). Ако е спазвана рецептурата по изготвяне на записите в директорията и специално тези, касаещи пощенските концентратори, то би следвало създаването на списъка да се реализира с прибавяне на съответни класове и атрибути към вече съществуващите dn записи за концентраторите. По-долу е даден шаблона за прибавяне на списък с домейни за локално обслужване, който да важи за концентратора ns.uni-sofia.bg. Приема се, че шаблона е запазен във файла create-local-list.ldif:

dn: cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
changetype: modify
add: objectClass
objectClass: sendmailMTAClass
-
add: sendmailMTAClassName
sendmailMTAClassName: w>
-
add: sendmailMTAClassValue
sendmailMTAClassValue: ns.uni-sofia.bg
sendmailMTAClassValue: su.uni-sofia.bg

Чрез съдържанието на този шаблон трябва да се укаже на концентратора ns.uni-sofia.bg да обслужва локално електронната поща за домейните ns.uni-sofia.bg и su.uni-sofia.bg. Въвеждането на съдържанието в LDAP директорията, може да стане с изпълнение на командния ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -f create-local-list.ldif

За изпълнението му се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

Разбира се, използвания по-горе списък с домейни е примерен и той може да бъде променен съгласно нуждите за локална обработка на поща към момента. Както е споменато по-горе, след създаването на списък с домейни, чиято поща да се обработва локално, се налага рестартирането на демона sendmail на концентратора, който касае направената в директорията промяна:

# service sendmail condrestart

 

14. Указване на домейните, пощата за които ще бъде обработвана локално от концентраторите (на база име на конфигурационен клъстер).

Макар концентраторите за електронна поща на СУ "Св. Климент Охридски" да не изпълняват локална доставка (до потребителски пощенски кутии дефинирани в локалните системи), те обслужват пощенски домейни, в които има само и единствено псевдоними - списъци, в които са описани пощенски кутии на крайни получатели в други пощенски домейни. Ефектът от такава обработка на база псевдоними е такъв, че когато се изпрати електронно писмо до псевдоним (alias), то не се доставя локално от пощенския концентратор в кутия върху файловата система, а се разпраща до асоциираните към псевдонима пощенски кутии, които по правило са върху отдалечени сървъри за електронна поща.

Списъкът с домейни, писмата за които ще се обслужват локално (привидно само, защото ще се обслужват само адреси-псевдоними), се задава в LDAP директорията и е специфичен за всеки концентратор на поща или за клъстер от конфигурации на концентратори. Всеки един от концентраторите на поща, който трябва да обслужва локално пощата за домейни по гореописания начин, прочита списъка с домейните за които да извършва локална обработка при всяко стартиране или рестартиране на демона sendmail. Трябва да се има предвид, че този списък не е динамично читаем за всяко едно обработваемо писмо, и съдържанието му е валидно за една цяла работна сесия на Sendmail (между стартиране и спиране на демона sendmail). Това означава, че при всяка промяна на списъка с домейни за локално обслужване, върху засегнатите от това концентратори трябва да се рестартира демона sendmail върху засегнатите от промяната концентратори. Това са всички концентратори, които използват клъстера от конфигурации.

По-долу е показан шаблон, с които се създава списък с домейни, подлежащи на локално обслужване от концентраторите в конфигурационния клъстер UniSofiaMTAServer. Ако е спазвана рецептурата по изготвяне на записите в директорията и специално тези, касаещи декларирането на конфигурационния клъстер, то би следвало създаването на списъка да се реализира с прибавяне на съответни класове и атрибути към вече съществуващите dn запис за клъстера. По-долу е даден шаблона за прибавяне на списък с домейни за локално обслужване, който да важи за всички концентратори използващи конфигурационния клъстер UniSofiaMTAServer. Приема се, че шаблона е запазен във файла create-local-list.ldif:

dn: cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
changetype: modify
add: objectClass
objectClass: sendmailMTAClass
-
add: sendmailMTAClassName
sendmailMTAClassName: w
-
add: sendmailMTAClassValue
sendmailMTAClassValue: uni-sofia.bg
sendmailMTAClassValue: susi.uni-sofia.bg
sendmailMTAClassValue: vice-rector.uni-sofia.bg

Чрез съдържанието на този шаблон трябва да се укаже на концентраторите ползващи конфигурационния клъстер UniSofiaMTAServer, да обслужват локално електронната поща за домейните uni-sofia.bg, susi.uni-sofia.bg и vice-rector.uni-sofia.bg. Въвеждането на съдържанието в LDAP директорията, може да стане с изпълнение на командния ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -f create-local-list.ldif

За изпълнението му се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

Разбира се, използвания по-горе списък с домейни е примерен и той може да бъде променен съгласно нуждите за локална обработка на поща към момента. Както е споменато по-горе, след създаването на списък с домейни, чиято поща да се обработва локално, се налага рестартирането на демона sendmail върху всички концентратор, който касае направената в директорията промяна (всички използващи този клъстер от конфигурации):

# service sendmail condrestart

 

15. Извършване на промени в списъка с домейни, пощата за които е обработвана локално от концентраторите (на база име на концентратор).

Всички описани по-долу процедури са валидни само, ако преди това е бил деклариран списък с домейни за локално обслужване за съответния концентратор. За да се провери дали такъв списък съществува, трябва да се извърши търсене в LDAP директорията. Това може да стане чрез команден ред подобен на следния, чрез който се проверява наличието на списък за концентратора ns.uni-sofia.bg:

/usr/lib/mozldap/ldapsearch -h localhost -1 -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -b "cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg" '(&(sendmailMTAClassName=w)(sendmailMTAClassValue=*))' sendmailMTAClassValue

Разбира се, при изпълнението му ще се изиска въвеждането на паролата за потребителя с dn uid=adminname,ou=admins,o=uni-sofia.bg. В горния команден ред се предполага, че директорийния сървър е достъпен локално (localhost). Ако за концентратора има деклариран списък с домейни, базиран на името на концентратора, този списък ще бъде изведен след правилното въвеждане на паролата.

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

Както е споменато по-горе, след създаването или промяната на списък с домейни, чиято поща да се обработва локално, се налага рестартирането на демона sendmail на концентратора, който касае направената в директорията промяна:

# service sendmail condrestart

 

16. Извършване на промени в списъка с домейни, пощата за които е обработвана локално от концентраторите (на база име на конфигурационен клъстер).

Всички описани по-долу процедури са валидни само, ако преди това е бил деклариран списък с домейни за локално обслужване за съответния клъстер от конфигурации. За да се провери дали такъв списък съществува, трябва да се извърши търсене в LDAP директорията. Това може да стане чрез команден ред подобен на следния, чрез който се проверява наличието на списък за конфигурационния клъстер UniSofiaMTAServer:

/usr/lib/mozldap/ldapsearch -h localhost -1 -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -b "cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg" '(&(sendmailMTAClassName=w)(sendmailMTAClassValue=*))' sendmailMTAClassValue

Разбира се, при изпълнението му ще се изиска въвеждането на паролата за потребителя с dn uid=adminname,ou=admins,o=uni-sofia.bg. В горния команден ред се предполага, че директорийния сървър е достъпен локално (localhost).

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

След създаването или промяната на списък с домейни, чиято поща да се обработва локално, се налага рестартирането на демона sendmail на концентраторите, които касае направената в директорията промяна:

# service sendmail condrestart

 

17. Създаване в LDAP директорията на пощенски псевдоним (alias) (достъпен на база пощенски концентратор).

Внимание: Псевдонимите, декларирани по този начин, влизат в сила само за тези пощенски домейни, електронната поща за които се обработва локално от съответния концентратор. Създаването на пощенски псевдоним може да се извърши само от член на групата потребители описани в конфигурационното дърво ou=admins,o=uni-sofia.bg. Преди да се въведе даден псевдоним в директорията, трябва да се провери дали вече не е бил деклариран.

Атрибутите в dn обект, чрез които в LDAP директорията се изгражда пощенски псевдоним (alias), който да важи само за даден пощенски концентратор са:

За изграждане на псевдоним на база концентратор, следва да се имат предвид следните особености:

Минималното съдържание на шаблона, чрез който трябва да се създаде dn обект на псевдоним за съответния пощенски концентратор, може да има вида:

dn: cn=root@example.com,cn=aliases,cn=ady.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
sendmailMTAAliasValue: root@other-domain.tld
sendmailMTAAliasValue: root@some-domain.tld
sendmailMTAHost: ady.uni-sofia.bg
sendmailMTAKey: root@example.com
objectClass: top
objectClass: person
objectClass: sendmailmtaaliasobject
objectClass: sendmailMTAAlias
objectClass: sendmailMTA
sn: email alias
cn: root@example.com

Този шаблон би декларирал dn за пощенски псевдоним, чрез който електронната поща за root@example.com, ако бъде обработена локално от концентратора ady.uni-sofia.bg, ще бъде препратена до електронните пощенски адреси: root@some-domain.tld и root@other-domain.tld. Ако съдържанието на шаблона се намира във файла create-alias.ldif, то въвеждането му в директорията би станало чрез изпълнение на командния ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-alias.ldif

За изпълнението му се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

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

 

18. Създаване в LDAP директорията на пощенски псевдоним (alias) (достъпен на база клъстер на конфигурации).

Внимание: Псевдонимите, декларирани по този начин, влизат в сила само за тези пощенски домейни, електронната поща за които се обработва локално от концентраторите, които четат конфигурацията за съответния конфигурационен клъстер. Създаването на пощенски псевдоним може да се извърши само от член на групата потребители описани в конфигурационното дърво ou=admins,o=uni-sofia.bg. Преди да се въведе даден псевдоним в директорията, трябва да се провери дали вече не е бил деклариран.

Атрибутите в dn обект, чрез които в LDAP директорията се изгражда пощенски псевдоним (alias), който да важи само за концентраторите в даден клъстер от конфигурации са:

За изграждане на псевдоним на база концентратор, следва да се имат предвид следните особености:

Минималното съдържание на шаблона, чрез който трябва да се създаде dn обект на псевдоним за съответния клъстер от конфигурации е:

dn: cn=admnin@example.com,cn=aliases,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
sendmailMTAAliasValue: root@other-domain.tld
sendmailMTAAliasValue: root@some-domain.tld
sendmailMTACluster: UniSofiaMTAServer
sendmailMTAKey: root@example.com
objectClass: top
objectClass: person
objectClass: sendmailmtaaliasobject
objectClass: sendmailMTAAlias
objectClass: sendmailMTA
sn: email alias
cn: root@example.com

Този шаблон би декларирал dn за пощенски псевдоним, чрез който електронната поща за root@example.com, ако бъде обработена локално от концентраторите в конфигурационния клъстер UniSofiaMTAServer, ще бъде препратена до електронните пощенски адреси: root@some-domain.tld и root@other-domain.tld. Ако съдържанието на шаблона се намира във файла create-alias.ldif, то въвеждането му в директорията би станало чрез изпълнение на командния ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-alias.ldif

За изпълнението му се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

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

 

19. Преглед на декларираните в LDAP директорията псевдоними (alias).

Всички атрибути и техните стойности, намиращи се в dn обекти, част от конфигурационното LDAP дърво ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg, са обект на рестриктивен достъп и прочита им е възможен само от упълномощените за това потребители в LDAP директорията. Всяко търсене на псевдоним или прочит на атрибутите му, изисква удостоверяване пред LDAP сървър на директорията, със съответното ниво на привилегии. Права за прочит на стойности на атрибути от dn обекти в състава на споменатото конфигурационно LDAP дърво, имат следните потребители:

Прочитът може да обхване стойностите на всички атрибути и стойностите им, до прочит само на някои атрибути и стойностите им. За примерите по-долу се предполага, че удостоверяването пред LDAP директорийния сървър се извършва от името на потребител с dn uid=adminname,ou=admins,o=uni-sofia.bg, но може да се използва произволен друг dn от посочените по-горе групи потребители. Възможни са следните нива на преглед/търсене на декларирани псевдоними и прочит на атрибутите и стойностите в техните dn обекти:

 

20. Промяна на съдържанието на пощенски псевдоним и изтриване на пощенски псевдоним от LDAP директорията.

Внимание: Промяната на съдържанието на пощенски псевдоним може да се извърши само с ефективните права на административен потребител от дървото ou=admins,o=uni-sofia.bg. За да може един псевдоним да бъде променен или изтрит, той трябва да е наличен в директорията, т.е. трябва да се извърши предварителна проверка за наличието му.

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

Премахването на псевдоним от LDAP директорията се извършва с премахването на съответния dn обект на псевдонима. За целта може да се използва команден ред от вида:

$ /usr/lib/mozldap/ldapdelete -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - "cn=admnin@example.com,cn=aliases,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg"

След правилното изпълнение на горния команден ред, ще бъде изтрит dn обекта cn=admnin@example.com,cn=aliases,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg, с което от директорията ще бъде премахнат псевдонима admnin@example.com, касаещ концентраторите за поща, които използват конфигурационния клъстер UniSofiaMTAServer (освен ако няма дублираща декларация на база пощенски концентратор).

Направените промени влизат в сила веднага и не се налага рестартирането на демона sendmail.

 

21. Указване в LDAP директорията на разрешение за транспорт (access) (на база пощенски концентратор).

Внимание: Разрешението на транспорт на електронна поща за даден пощенски домейн, декларирано с примерите по-долу важи само за тези електронни писма за въпросния домейн, които се обработват от съответния концентратор, в конфигурацията на който е направена декларацията. Деклариране на разрешение за транспорт се извършва само от член на групата потребители, описани в конфигурационното дърво ou=admins,o=uni-sofia.bg. Преди да се въведе дадено разрешение за транспорт, трябва да се провери дали такова вече не е било декларирано.

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

Атрибутите в dn обекта, чрез които се изгражда разрешение за транспорт (access) в LDAP директорията, което да важи само за даден пощенски концентратор са:

Наименованието на dn обекта, чрез който се декларира разрешение за транспорт може да се илюстрира със следния пример. Ако трябва да се разреши транспортирането на пощата за домейна domain.uni-sofia.bg през пощенския концентратор ns.uni-sofia.bg, се изгражда dn обект с име cn=domain.uni-sofia.bg,cn=access,cn=maps,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg.

Примерен шаблон, чрез който се описва разрешението за транспорт на електронната поща за домейна domain.uni-sofia.bg през пощенския концентратор ns.uni-sofia.bg, би изглеждал по следния начин:

dn: cn=domain.uni-sofia.bg,cn=access,cn=maps,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
sendmailMTAKey: domain.uni-sofia.bg
sendmailMTAHost: ns.uni-sofia.bg
sendmailMTAMapValue: RELAY
sendmailMTAMapName: access
objectClass: top
objectClass: person
objectClass: sendmailmtamapobject
objectClass: sendmailMTAMap
objectClass: sendmailMTA
sn: Sendmail Relay Policy
cn: domain.uni-sofia.bg

Ако съдържанието на шаблона се намира във файла create-access.ldif, то въвеждането му в директорията би станало чрез изпълнение на командния ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-access.ldif

За изпълнението му се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

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

 

22. Указване в LDAP директорията на разрешение за транспорт (access) (достъпно на база клъстер от конфигурации).

Внимание: Разрешението на транспорт на електронна поща за даден пощенски домейн, декларирано с примерите по-долу важи само за тези електронни писма за въпросния домейн, които се обработват от концентраторите използващи съответния клъстер от конфигурации, за който е извършена декларацията. Деклариране на разрешение за транспорт се извършва само от член на групата потребители описани в конфигурационното дърво ou=admins,o=uni-sofia.bg. Преди да се въведе дадено разрешение за транспорт, трябва да се провери дали такова вече не е било декларирано.

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

Атрибутите в dn обекта, чрез които се изгражда разрешение за транспорт (access) в LDAP директорията, което да важи само за пощенските концентратори, използващи конфигурацията на клъстера от конфигурации са:

Наименованието на dn обекта, чрез който се декларира разрешение за транспорт, може да се илюстрира със следния пример. Ако трябва да се разреши транспортирането на пощата за домейна domain.uni-sofia.bg през пощенските концентратори, използващи клъстера от конфигурации UniSofiaMTAServer, се изгражда dn обект с име cn=domain.uni-sofia.bg,cn=access,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg.

Примерен шаблон, чрез който се описва разрешението за транспорт на електронната поща за домейна domain.uni-sofia.bg през пощенските концентратори, използващи клъстера от конфигурации UniSofiaMTAServer, би изглеждал по следния начин:

dn: cn=domain.uni-sofia.bg,cn=access,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
sendmailMTAKey: to:domain.uni-sofia.bg
sendmailMTACluster: UniSofiaMTAServer
sendmailMTAMapValue: RELAY
sendmailMTAMapName: access
objectClass: top
objectClass: person
objectClass: sendmailmtamapobject
objectClass: sendmailMTAMap
objectClass: sendmailMTA
sn: Sendmail Relay Policy
cn: domain.uni-sofia.bg

Ако съдържанието на шаблона се намира във файла create-access.ldif, то въвеждането му в директорията би станало чрез изпълнение на командния ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-access.ldif

За изпълнението му се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

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

 

23. Преглед на декларираните в LDAP директорията разрешения за транспорт (access).

Всички атрибути и техните стойности, намиращите се в dn обекти, част от конфигурационното LDAP дърво ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg, са обект на рестриктивен достъп и прочита им е възможен само от упълномощените за това потребители в LDAP директорията. Всяко търсене на dn обект, указващ разрешение за транспорт или прочит на атрибутите на обекта, изисква удостоверяване пред LDAP сървър на директорията, със съответното ниво на привилегии. Права за прочит на стойности на атрибути на dn обекти в състава на споменатото конфигурационно LDAP дърво, имат следните потребители:

Прочитът може да се разпростре от всички атрибути и стойностите им, до прочит само на някои атрибути и стойностите им. За примерите по-долу се предполага, че удостоверяването пред LDAP директорийния сървър се извършва от името на потребител с dn uid=adminname,ou=admins,o=uni-sofia.bg, но може да се използва произволен друг dn от посочените по-горе групи потребители. Възможни са следните нива на преглед/търсене на декларирани разрешения за транспорт и прочит на атрибутите и стойностите в техните dn обекти:

 

24. Премахване от LDAP директорията на разрешение за транспорт (access).

Внимание: Прeмахването на разрешение за транспорт може да се извърши само с ефективните права на административен потребител от дървото ou=admins,o=uni-sofia.bg. За да може едно разрешение за транспорт да бъде премахнато, то трябва да е налично в директорията и за него да има съответен dn обект, т.е. трябва да се извърши предварителна проверка за наличието му.

Изтриването на dn обект на разрешение за транспорт се извършва лесно от команден ред, ако се знае dn обекта, който съдържа разрешението. За целта може да се използва команден ред от вида:

$ /usr/lib/mozldap/ldapdelete -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - "cn=domain.uni-sofia.bg,cn=access,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg"

След успешното изпълнение на горния команден ред, от LDAP директорията ще бъде изтрито разрешението за транспорт за домейна domain.uni-sofia.bg, което е било декларирано в dn обекта cn=domain.uni-sofia.bg,cn=access,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg. Следователно пощенските концентратори използващи клъстера от конфигурации UniSofiaMTAServer, няма да обслужват вече поща за домейна domain.uni-sofia.bg (освен ако няма дублираща декларация на база пощенски концентратор, но тя би важала само за даден концентратор).

Направените промени влизат в сила веднага и не се налага рестартирането на демона sendmail.

 

25. Деклариране в LDAP директорията на алтернативно транспортиране (mailertable) на поща за домейн (на база пощенски концентратор).

Внимание: Декларирането в LDAP директорията на алтернативно транспортиране на поща за домейн, илюстрирано с примерите по-долу, важи само за тези електронни писма за въпросния домейн, които се обработват от съответния концентратор, в конфигурацията на който е направена декларацията. Самото деклариране може да се извършва само от член на групата потребители, описани в конфигурационното дърво ou=admins,o=uni-sofia.bg. Преди да се въведе декларацията в директорията, трябва да се провери дали такава вече не е била извършена.

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

Атрибутите в dn обекта, чрез които се указва алтернативен транспорт (mailertable) в LDAP директорията, който да важи само за даден пощенски концентратор са:

Наименованието на dn обекта, чрез който се декларира алтернативен транспорт на пощата за домейн, може да се илюстрира със следния пример. Ако трябва върху пощенския концентратор ns.uni-sofia.bg да се укаже транспортирането на пощата за домейна domain.uni-sofia.bg, по протокол esmtp, към сървър за поща с пълно квалифицирано име на хост smtp.domain.uni-sofia.bg, се изгражда dn обект с име cn=domain.uni-sofia.bg,cn=mailertable,cn=maps,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg.

Примерен шаблон, чрез който се описва алтернативния транспорт на електронната поща за домейна domain.uni-sofia.bg, би изглеждал по следния начин:

dn: cn=domain.uni-sofia.bg,cn=mailertable,cn=maps,cn=ns.uni-sofia.bg,ou=hosts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
sendmailMTAKey: domain.uni-sofia.bg
sendmailMTAHost: ns.uni-sofia.bg
sendmailMTAMapValue: esmtp:smtp.domain.uni-sofia.bg
sendmailMTAMapName: mailer
objectClass: top
objectClass: person
objectClass: sendmailmtamapobject
objectClass: sendmailMTAMap
objectClass: sendmailMTA
sn: Sendmail Mailer Policy
cn: domain.uni-sofia.bg

Ако съдържанието на шаблона се намира във файла create-mailer.ldif, то въвеждането му в директорията би станало чрез изпълнение на командния ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-mailer.ldif

За изпълнението му се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

Декларацията влиза в сила веднага след нейното успешно въвеждане в LDAP директорията, без да се налага рестартиране на sendmail.

 

26. Деклариране в LDAP директорията на алтернативно транспортиране (mailertable) на поща за домейн (достъпно на база клъстер от конфигурации).

Внимание: Декларирането в LDAP директорията на алтернативно транспортиране на поща за домейн, илюстрирано с примерите по-долу, важи само за тези електронни писма за въпросния домейн, които се обработват от пощенските концентратори, използващи съответният клъстер на конфигурации, за който е направена декларацията. Самото деклариране може да се извършва само от член на групата потребители описани в конфигурационното дърво ou=admins,o=uni-sofia.bg. Преди да се въведе декларацията в директорията, трябва да се провери дали такава вече не е била извършена.

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

Атрибутите в dn обекта, чрез които се указва алтернативен транспорт (mailertable) в LDAP директорията, който да важи само за даден пощенски концентратор са:

Наименованието на dn обекта, чрез който се декларира алтернативен транспорт на пощата за домейн, може да се илюстрира със следния пример. Ако трябва върху пощенските концентратори използващи клъстера от конфигурации UniSofiaMTAServer да се укаже транспортирането на пощата за домейна domain.uni-sofia.bg, по протокол esmtp, към сървър за поща с пълно квалифицирано име на хост smtp.domain.uni-sofia.bg, се изгражда dn обект с име cn=domain.uni-sofia.bg,cn=mailertable,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg.

Примерен шаблон, чрез който се описва алтернативния транспорт на електронната поща за домейна domain.uni-sofia.bg, би изглеждал по следния начин:

dn: cn=domain.uni-sofia.bg,cn=mailertable,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
sendmailMTAKey: domain.uni-sofia.bg
sendmailMTACluster: UniSofiaMTAServer
sendmailMTAMapValue: esmtp:smtp.domain.uni-sofia.bg
sendmailMTAMapName: mailer
objectClass: top
objectClass: person
objectClass: sendmailmtamapobject
objectClass: sendmailMTAMap
objectClass: sendmailMTA
sn: Sendmail Mailer Policy
cn: domain.uni-sofia.bg

Ако съдържанието на шаблона се намира във файла create-mailer.ldif, то въвеждането му в директорията би станало чрез изпълнение на командния ред:

$ /usr/lib/mozldap/ldapmodify -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - -a -f create-mailer.ldif

За изпълнението му се изисква въвеждането на паролата на административния протребител с dn uid=adminname,ou=admins,o=uni-sofia.bg (паролата ще бъде изискана в диалогово меню). Също така се предполага, че изпълнението на командния ред става локално върху системата, върху която се намира директорийния сървър (localhost).

Декларацията влиза в сила веднага след нейното успешно въвеждане в LDAP директорията, без да се налага рестартиране на sendmail.

 

27. Преглед на декларациите в LDAP директорията за алтернативен транспорт (mailetable).

Всички атрибути и техните стойности, намиращи се в dn обекти, част от конфигурационното LDAP дърво ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg, са обект на рестриктивен достъп и прочита им е възможен само от упълномощените за това потребители в LDAP директорията. Всяко търсене на dn, деклариращ алтернативен транспорт или прочит на атрибутите му, изисква удостоверяване пред LDAP сървър на директорията, със съответното ниво на привилегии. Права за прочит на стойности на атрибути от dn обекти в състава на споменатото конфигурационно LDAP дърво, имат следните потребители:

Прочитът може да се разпростре от всички атрибути и стойностите им, до прочит само на някои атрибути (и стойностите им). За примерите по-долу се предполага, че удостоверяването пред LDAP директорийния сървър се извършва от името на потребител с dn uid=adminname,ou=admins,o=uni-sofia.bg, но може да се използва произволен друг dn от посочените по-горе групи потребители. Възможни са следните нива на преглед/търсене на декларации за алтернативен транспорт на електронната поща за даден домейн, което е равносилно на прочит на атрибутите и стойностите в техните dn обекти:

 

28. Промяна и премахване от LDAP директорията на декларация за алтернативен транспорт (mailertable).

Внимание: Промяната и прeмахването на декларация за алтернативен транспорт за поща на домейн може да се извърши само с ефективните права на административен потребител от дървото ou=admins,o=uni-sofia.bg. За да може една декларация за алтернативен транспорт да бъде променена или премахната, тя трябва да е налична в директорията, т.е. за нея да има съответен dn обект, което означава, че трябва да се извърши предварителна проверка за наличието му.

Извършването на промени в направената в LDAP директорията декларация за алтернативен транспорт на електронната поща за даден домейн, биха били наложителни в следните случаи:

Изтриването на dn обект на декларацията за алтернативен транспорт се извършва лесно от команден ред, ако се знае името на dn обекта. За целта може да се използва команден ред от вида:

$ /usr/lib/mozldap/ldapdelete -h localhost -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - "cn=domain.uni-sofia.bg,cn=mailertable,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg"

След успешното изпълнение на горния команден ред, от LDAP директорията ще бъде изтрита декларацията за алтернативен транспорт на електронната поща за домейна domain.uni-sofia.bg, която е била декларирана в dn обекта cn=domain.uni-sofia.bg,cn=mailertable,cn=maps,cn=UniSofiaMTAServer,ou=clusters,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg. Следователно пощенските концентратори използващи клъстера от конфигурации UniSofiaMTAServer, няма да изпълняват алтернативен транспорт на поща за домейна domain.uni-sofia.bg (освен ако няма дублираща декларация на база пощенски концентратор).

Направените промени влизат в сила веднага и не се налага рестартирането на демона sendmail.

 

29. Предишни версии на публикацията.

 

Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис][TimeStamp]

Creative Commons - Признание 2.5 Valid CSS! Valid XHTML 1.0 Strict