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

Версия 1.0, 27 декември 2007

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

Адрес за кореспонденция: 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. Задаване на домейните, които ще бъдат обслужвани локално от концентраторите
  9. Проверка в LDAP директорията за наличието на ldap потребител, с чиито права ще бъдат четени конфигурациите по обработка на електронната поща
  10. Създаване на ldap потребител за достъп до конфигурациите по обслужване на електронната поща, дефинирани в LDAP директорията
  11. Смяна на паролата на потребителя, с чиито права sendmail чете информация от LDAP директорията
  12. Стартиране, рестартиране и спиране на услугата sendmail
  13. Създаване на шаблон за деклариране на пощенски псевдоним (alias) в LDAP директорията
  14. Преглед на съдържанието на отделен псевдоним (alias) в директорията
  15. Прочит на всички псевдоними в директорията и търсене на стойности на атрибути в списъка от псевдоними
  16. Модифициране на пощенски псевдоним (alias) - премахване и/или прибавяне на пощенски адреси към псевдоним
  17. Премахване на пощенски псевдоним от LDAP директорията
  18. Създаване на шаблон за разрешаване на транспортирането на електронна поща за домейн (access)
  19. Преглед на разрешенията за транспорт описани в LDAP директорията
  20. Модифициране на разрешение за транспорт на пощата за домейн
  21. Премахване на разрешение за транспорт от LDAP директорията
  22. Създаване в LDAP директорията на запис за маршрутизиране на електронната поща за домейн
  23. Модифициране на запис за маршрутизиране на електронната поща за домейн
  24. Премахване на запис за маршрутизиране на електронната поща за домейн

 

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 сървър е:

/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. Задаване на домейните, които ще бъдат обслужвани локално от концентраторите.

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

Списъкът с домейни, писмата за които ще се обслужват локално (привидно само, защото ще се обслужват само адреси-псевдоними), се задават във файла /etc/mail/local-host-names:

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

# service sendmail condrestart

 

9. Проверка в LDAP директорията за наличието на ldap потребител, с чиито права ще бъдат четени конфигурациите по обработка на електронната поща.

Тази проверка се извършва преди стартирането на услугата sendmail в режим на пощенски концентратор и е в духа на добрата практика по проверка на конфигурационните параметри преди стартирането на която и да е услуга.

Всеки концентратор за електронна поща има свой индивидуален потребител в LDAP директорията. Обикновено за стойност на uid атрибута се използва пълното квалифицирано име на хост. За да се провери дали потребител със съответния dn е наличен в LDAP директорията, може да се използва следната схема на запитвания:

Разбира се, за друга система, различна от двата пощенски концентратора на СУ, запитването ще включва конкретния uid. Ако потребител не е наличен в директорията, той трябва да бъде създаден.

 

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

За да бъде създаден ldap потребителя е необходимо:

Шаблонът за въвеждане на потребителя в LDAP директорията има следния вид и структура:

Стойността на атрибута userPassword най-лесно се генерира чрез инструмента slappasswd

Инструментът slappasswd е част от пакета openldap-servers в пакетната колекция на дистрибуциите на Red Hat и техните производни. Не е добра идея да се съвместяват върху една система два ldap сървъра (в случая OpenLDAP и Fedora Directory Server). Възможно е поради невнимание те да бъдат включени заедно и това да доведе до конфликт между двата сървъра за използването на стандартния ldap порт (389/tcp). Заради тази опасност се препоръчитва пакета openldap-servers да се инсталира върху работната станция на оператора, паролата да се генерира в хеш вид там и чак след това да се пренесе на шблона върху директорийния сървър.

Генерирането на парола с инструмента slappasswd става по следната проста схема:

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

Диалоговото меню след изпълнение на този команден ред и извеждането на резултата имат следния примерен вид:

New password:
Re-enter new password:
{SSHA}65ExQB8IUOuRo4umESN3KDg0yJ+RNrrn

Последният ред (за примера {SSHA}65ExQB8IUOuRo4umESN3KDg0yJ+RNrrn) представлява хеш стойността на въведената чрез диалога парола.

ВНИМАНИЕ! Паролата, чиято хеш стойност е зададена като стойност на атрибута userPassword, трябва да е описана в явен (нехеширан вид) в съответния файл за съхранение на паролата върху пощенския концентратор.

 

Въвеждането на съдържанието на шаблоните в LDAP директорията, става по следния начин:

 

11. Смяна на паролата на потребителя, с чиито права sendmail чете информация от LDAP директорията.

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

Инструментът slappasswd е част от пакета openldap-servers в пакетната колекция на дистрибуцията Red Hat Enterprise Linux и производните й. Не е добра идея да се съвместяват върху една система два ldap сървъра (в случая OpenLDAP и Fedora Directory Server). Възможно е поради невнимание те да бъдат включени заедно и това да доведе до конфликт между двата сървъра за използването на стандартния ldap порт (389/tcp). Заради тази опасност се препоръчитва пакета openldap-servers да се инсталира върху работната станция на оператора, паролата да се генерира в хеш вид там и чак след това да се пренесе на шблона върху директорийния сървър.

Генерирането на парола с инструмента slappasswd става по следната проста схема:

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

Диаловото меню след изпълнение на този команден ред и извеждането на резултата имат следния примерен вид:

New password:
Re-enter new password:
{SSHA}65ExQB8IUOuRo4umESN3KDg0yJ+RNrrn

Последният ред (за примера {SSHA}65ExQB8IUOuRo4umESN3KDg0yJ+RNrrn) представлява хеш стойността на въведената чрез диалога парола.

След като хеша на паролата бъде пресметнат, неговата стойност заменя старата в съответния dn запис. Това става като се изготви шаблон и неговото съдържание се въведе в директорията чрез инструмента ldapmodify. За примера се предполага, че съдържанието на шаблона ще бъде запазено във файла change-pass.ldif:

dn: cn=mailhost,ou=accounts,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
changetype:modify
replace: userPassword
userPassword: {SSHA}65ExQB8IUOuRo4umESN3KDg0yJ+RNrrn

За реалния случай, вместо mailhost, в полето cn трябва да се сложи реалното име на хоста, за чиито потребител се сменя паролата. Например ns.uni-sofia.bg, ady.uni-sofia.bg и др.

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

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

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

ВНИМАНИЕ! Паролата, чиято хеш стойност е зададена като стойност на атрибута userPassword, трябва да е описана в явен (нехеширан вид) в съответния файл за съхранение на паролата върху пощенския концентратор. Това означава, че освен смяната й в LDAP директорията, тя трябва да бъде сменена и в съотвения локален системен файл.

 

12. Стартиране, рестартиране и спиране на услугата sendmail.

За да може услугата sendmail да се стартира при зареждане на системата, трябва да се изпълни:

# chkconfig sendmail on

Операциите по ръчно стартиране, рестартиране и спиране на услугата sendmail могат да се обобщят така:

 

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

Описаният по-долу примерен шаблон създава псевдонима aliasname@domain.tld. Всяко електронно писмо до aliasname@domain.tld ще бъде изпратено до всички пощенски адреси, описани като стойност на атрибута sendmailMTAAliasValue, в примера това са info@example.com, help@domain.tld и admin@nodomain.tld. Този псевдоним ще е валиден за всички сървъри за поща, които са в клъстера от конфигурации UniSofiaMTAServer.

dn: sendmailMTAKey=aliasname@domain.tld,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
objectClass: sendmailMTA
objectClass: sendmailMTAAlias
objectClass: sendmailMTAAliasObject
sendmailMTAAliasGrouping: aliases
sendmailMTACluster: UniSofiaMTAServer
sendmailMTAKey: aliasname@domain.tld
sendmailMTAAliasValue: info@example.com
sendmailMTAAliasValue: help@domain.tld
sendmailMTAAliasValue: admin@nodomain.tld

След като шаблонът бъде създаден, е добре съдържанието да се запази във файл (за примера по-долу файла е с име alias.ldif) и след това да се въведе в директорията. Това става чрез командния ред (изпълнен върху локалната за директорийния сървър система):

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

Ще бъде изискано въвеждането на паролата за uid=adminname,ou=admins,o=uni-sofia.bg и ако то е успешно, новият псевдоним ще стане част от дървото за пощенската услуга. Псевдонимът влиза в сила веднага след въвеждането му в директорията и не е нужна никаква интервенция върху Sendmail.

 

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

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

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

 

15. Прочит на всички псевдоними в директорията и търсене на стойности на атрибути в списъка от псевдоними.

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

Обект на практическо използване в пощенската услуга на СУ "Св. Климент Охридски", са следните видове прочит и търсене:

 

16. Модифициране на пощенски псевдоним (alias) - премахване и/или прибавяне на пощенски адреси към псевдоним.

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

 

17. Премахване на пощенски псевдоним от LDAP директорията.

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

$ /usr/lib/mozldap/ldapdelete -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - "sendmailMTAKey=aliasname@domain.tld,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg"

След изпълнението на командния ред се изисква въвеждането на паролата за административния потребител.

 

18. Създаване на шаблон за разрешаване на транспортирането на електронна поща за домейн (access).

Пощенските концентратори на СУ "Св. Климент Охридски" приемат електронна поща за поддомейните на домейна uni-sofia.bg и я транспортират до съответните сървъри за поща, на които се намират кутиите на потребителите.

За да може всеки от концентраторите за поща на СУ да транспортира поща за даден домейн, въпросния домейн трябва да е описан изрично в базата с домейни, за които транспорт е допустим. Описанието става в LDAP директорията, като за всеки домейн се прави отделен запис за разрешение за транспорт.

По-долу е даден примерен шаблон за разрешаване за транспорт на домейна subdomain.uni-sofia.bg:

dn: sendmailMTAKey=to:subdomain.uni-sofia.bg,sendmailMTAMapName=access,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
objectClass: sendmailMTA
objectClass: sendmailMTAMap
objectClass: sendmailMTAMapObject
objectClass: top
sendmailMTAMapName: access
sendmailMTACluster: UniSofiaMTAServer
sendmailMTAKey: to:subdomain.uni-sofia.bg
sendmailMTAMapValue: RELAY

След като шаблонът бъде създаден, е добре съдържанието да се запази във файл (за примера по-долу файла е с име access-subdomain.ldif) и след това да се въведе в директорията. Това става чрез командния ред (изпълнен върху локалната за директорийния сървър система):

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

Ще бъде изискано въвеждането на паролата за uid=adminname,ou=admins,o=uni-sofia.bg и ако то е успешно, новото разрешение за транспорт ще стане част от дървото за пощенската услуга. Разрешението влиза в сила веднага след въвеждането му в директорията и не е нужна никаква интервенция върху Sendmail.

 

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

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

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

 

20. Модифициране на разрешение за транспорт на пощата за домейн.

За да се модифицира дадено разрешение за транспорт на поща на домейн, трябва да се състави шаблон, в който промените да бъдат нанесени и след това да се въведат в LDAP директорията. Модификациите в разрешението за транспорт се следните типове:

 

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

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

$ /usr/lib/mozldap/ldapdelete -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - "sendmailMTAKey=to:subdomain.uni-sofia.bg,sendmailMTAMapName=access,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg"

След изпълнението на командния ред се изисква въвеждането на паролата за административния потребител.

 

22. Създаване в LDAP директорията на запис за маршрутизиране на електронната поща за домейн.

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

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

dn: sendmailMTAKey=subdomain.uni-sofia.bg,sendmailMTAMapName=mailer,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bg
sendmailMTAMapValue: esmtp:mail.subdmomain.uni-sofia.bg
sendmailMTAKey: subdomain.uni-sofia.bg
sendmailMTACluster: UniSofiaMTAServer
sendmailMTAMapName: mailer
objectClass: sendmailMTA
objectClass: sendmailMTAMap
objectClass: sendmailMTAMapObject
objectClass: top

В този запис има два атрибута, чрез които се указва маршрутизацията на електронната поща:

 

23. Модифициране на запис за маршрутизиране на електронната поща за домейн.

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

 

 

24. Премахване на запис за маршрутизиране на електронната поща за домейн.

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

$ /usr/lib/mozldap/ldapdelete -D "uid=adminname,ou=admins,o=uni-sofia.bg" -w - "sendmailMTAKey=subdomain.uni-sofia.bg,sendmailMTAMapName=mailer,ou=sendmail,ou=smtp,ou=services,o=uni-sofia.bgg"

След изпълнението на командния ред се изисква въвеждането на паролата за административния потребител.

 

[Достъпност]

Съдържанието, публикувано в тази страница, може да се ползва при условията на "Creative Commons - Признание 2.5", освен ако в конкретния документ не е посочено друго.

Creative Commons - by, 2.5

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

Valid CSS! Valid XHTML 1.0 Strict