Проблемы при компиляции sendmail.8.13.3, imap, pop3

11.1. Ошибка при компиляции: /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x145): In function `dlfcn_load':: undefined reference to `dlopen'
11.2. Ошибка при продключении к sshd: sshd re-exec requires execution with an absolute path
11.3. Предупреждение при первом подключении к sshd: The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.

1.Ошибки при компиляции sendmail 8.13.3
SUSE9.0, glibc-2.3.2, sendmail8.13.3, cyrus-sasl-2.1.15, bind-9.2.2, Berkeley db-4.1.25

Так как установка sendmail для меня дело не новое, я пытаюсь использовать ../sendmail/devtools/site.config.m4, успешно применявшийся при сборке sendmail версий 8.9.3, 8.10.x, 8.12.1 и 8.12.10.
APPENDDEF(`conf_sendmail_ENVDEF',`-DMILTER')
APPENDDEF(`confMAPDEF',`-DMAP_REGEX')
APPENDDEF(`confENVDEF',`-DSASL')
APPENDDEF(`conf_sendmail_LIBS',`-lsasl')
APPENDDEF(`confLIBDIRS',`-L/usr/local/lib/sasl/')
APPENDDEF(`confINCDIRS',`-I/usr/local/include/')

1. Первая ошибка, появившаяся на этапе компиляции, была такой:
cc -o t-event -L/usr/lib/sasl2/ t-event.o libsm.a   -lbind -lcrypt -lnsl -ldl
/usr/lib/gcc-lib/i586-suse-linux/3.3.1/../../../libbind.so: undefined reference to `pthread_getspecific'
/usr/lib/gcc-lib/i586-suse-linux/3.3.1/../../../libbind.so: undefined reference to `pthread_key_create'
/usr/lib/gcc-lib/i586-suse-linux/3.3.1/../../../libbind.so: undefined reference to `pthread_setspecific'
:collect2: ld returned 1 exit status
make[1]: *** [t-event] Error 1
make[1]: Leaving directory `/usr/src/sendmail-8.13.3/obj.Linux.2.4.21-99-default.i686/libsm'
make: *** [/usr/src/sendmail/obj.Linux.2.4.21-99-default.i686/libsm/libsm.a] Error 2

Файл libbind.so принадлежит резолверу из пакета bind-devel и находится в том же каталоге, что и файл libresolv.so, принадлежащий резолверу из glibc-devel. Как видно из сообщения, sendmail не хочет собираться с библиотекой резолвера из пакета bind.

В /usr/src/sendmail/RELEASE_NOTES есть несколько слов о том, что /usr/lib/libbind.a конфликтует с /usr/lib/libresolv.a, но это относится к sendmail старой версии 8.9.3 и к AIX 4.2.0:
"...AIX 4.2.0 or 4.2.1 may become updated by the fileset bos.rte.net level 4.2.0.2.
This introduces the softlink /usr/lib/libbind.a which should not be used.
It conflicts with the resolver built into libc.a.
"bind" has been removed from the confLIBSEARCH BuildTools variable.
Users who have installed BIND 8.X will have to add it back in their site.config.m4 file. ..."

В ../sendmail/sendmail/README по этому поводу говорится:
        "... NOTE ON LINUX & BIND: By default, the Makefile generated for Linux
         includes header files in /usr/local/include and libraries in
         /usr/local/lib. If you've installed BIND on your system, the header
         files typically end up in the search path and you need to add
         "-lresolv" to the LIBS line in your Makefile. Really old versions
         may need to include "-l44bsd" as well (particularly if the link phase
         complains about missing strcasecmp, strncasecmp or strpbrk).
         Complaints about an undefined reference to `__dn_skipname' in
         domain.o are a sure sign that you need to add -lresolv to LIBS.
         Newer versions of Linux are basically threaded BIND, so you may or
         may not see complaints if you accidentally mix BIND
         headers/libraries with virginal libc. If you have BIND headers in
         /usr/local/include (resolv.h, etc) you *should* be adding -lresolv
         to LIBS. Data structures may change and you'd be asking for a
         core dump..."

Предложенный вариант с добавлением -lresolv в confLIBS результата не дал.

В ../sendmail/devtools/README читаем:
confLIBSEARCH        db bind resolv 44bsd (значения по умолчанию)        Search for these libraries for linking with programs (теперь понятно, почему резолвер bind встревает первым).

И это сработало: добавляем в site.config.m4 строку:
PREPENDDEF(`confLIBSEARCH',`resolv')
и пересобираем sendmail.     Db в LIBSEARCH добавлять не нужно, в противном случае ключ -ldb при компиляции будет дублироваться.
Обращаю внимание, что нужно использовать именно макрос PREPENDDEF, который переписывает значение по умолчанию, а не макрос APPENDDEF, который добавляет к значениям по умолчанию новые значения.

Есть еще простой, но, наверное, не совсем тонкий способ решить проблему: ищем файлы libbind.* (/usr/lib) и временно переименовываем их или перемещаем их в другой каталог. Затем компилируем sendmail.

Еще один действенный способ для опытных пользователей: можно отредактировать файл ../sendmail/devtools/OS/Linux, добавив строку:
define(`confLIBSEARCH', `db resolv')
Тогда редактировать site.config.m4 не нужно.

2-ая ошибка .
/usr/src/sendmail/obj.Linux.2.4.21-99-default.i686/libsm/libsm.a -lresolv -lcrypt -lnsl -ldl
/usr/lib/gcc-lib/i586-suse-linux/3.3.1/../../../../i586-suse-linux/bin/ld: cannot find -lsasl
collect2: ld returned 1 exit status
make: *** [sendmail] Error 1
Как же так, говорите вы, ведь в site.config.m4 SASL прописан! Так то оно так, да в SUSE9.0 cyrus-sasl версии 2.1.15 (co 2 версией может работать только sendmail версий 8.13.x), и поэтому в site.config.m4 нужно указать, что работать будем со второй версией:
APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL=2')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
Кстати, в самом пакете об этом ни слова, информация отсюда - http://www.sendmail.org/~ca/email/auth.html
Еще одна причина возникновения этой ошибки - это
APPENDDEF(`confLIBDIRS',`-L/usr/local/lib/sasl2/')
На самом деле теперь нужно указывать путь без sasl:
APPENDDEF(`confLIBDIRS',`-L/usr/local/lib/')
либо просто опускать эту строку, если у вас стандартное ( с точки зрения sendmail ;) расположение системных файлов.

3-я ошибка.
Ну вот вроде все скомпилировалось, проверяем sendmail:
./sendmail -bt -d0.4 </dev/null
И видим, что NEWDB не поддерживается, а значит с hash-файлами работать будет невозможно:
Version 8.13.3
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NETINET NETUNIX PIPELINING SASLv2 SCANF XDEBUG
/etc/mail/sendmail.cf: line 173: readcf: map access: class hash not available
/etc/mail/sendmail.cf: line 194: readcf: map ADDR_LIST: class hash not available

А ведь NEWDB должен ставится по умолчанию - в ../devtools/README говорится:
confMAPDEF     [varies]          The map definitions, e.g., -DNDBM -DNEWDB.
-DNEWDB is always added if libdb.* can be found.
А в SUSE9.0 присутствует /usr/lib/libdb1.so и libdb1.a (BerkeleyDB), а вот libdb.a нет.
Создаем ссылку на этот файл:
ln -s /usr/lib/libdb1.a libdb.a
Снова компилируем.

Примечание.
Добавление в site.config.m4 APPENDDEF(`confMAPDEF',`-DNEWDB') также не спасает
При компиляции имеем:
/usr/src/sendmail/obj.Linux.2.4.21-99-default.i686/libsm/libsm.a -lresolv -lcrypt -lnsl -ldl
map.o(.text+0x1731): In function `db_map_open':
: undefined reference to `dbopen'
udb.o(.text+0x1130): In function `_udbx_init':
: undefined reference to `dbopen'
collect2: ld returned 1 exit status
make: *** [sendmail] Error 1
После вышеописанного создания libdb.a компиляция проходит успешно, зато в логах компиляции ключ -DNEWDB дублируется, и это понятно: один раз он берется по умолчанию, а второй раз из site.config.m4, так что эта строка лишняя.

4-ая ошибка.

In file included from conf.c:20:
../../include/sm/bdb.h:17:17: db.h: No such file or directory
In file included from map.c:32:
../../include/sm/bdb.h:17:17: db.h: No such file or directory
In file included from udb.c:25:
../../include/sm/bdb.h:17:17: db.h: No such file or directory
make: *** [depend] Error 1
Файл bdb.h в SUSE9.0 находится в /usr/include/db1/. Поэтому либо добавляем в site.config.m4
APPENDDEF(`confINCDIRS',`-I/usr/include/db1/')
либо делаем ссылку на этот файл из /usr/include.
Перекомпилируем.

В конечном итоге имеем вот такой рабочий site.config.m4 :

APPENDDEF(`conf_sendmail_ENVDEF',`-DMILTER -DSASL=2')
APPENDDEF(`confMAPDEF',`-DMAP_REGEX')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl2')
APPENDDEF(`confINCDIRS',`-I/usr/include/db1/')
PREPENDDEF(`confLIBSEARCH',`resolv')
Так как этот файл новый, то каждый раз компилируем с ключом -c: sh Build -c

Так же с этим ключом компилируем и все остальные необходимые программы: makemap, mail.local, mailstat, etc...

2. Проблемы с smtp-авторизацией.
Ну вот, вроде бы sendmail собран и запущен, с сервера почта уходит, пробую отправить почту с рабочего хоста.
Настраиваю почтовый клиент на smtp-авторизацию, пытаюсь отправить письмо - пароль не принимается, и постоянно всплывает окно авторизации.
В /var/log/maillog:
Feb 28 09:11:33 myhost sendmail[14546]: j1SHBGf8014546: step.domain.ru [2.2.1.1]: possible SMTP attack: command=AUTH, count=4
Feb 28 09:32:41 myhost sendmail[14546]: j1SHBGf8014546: step.domain.ru [2.2.1.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
В /var/log/messages:
Feb 22 12:45:41 myhost sendmail[1485]: unknown password verifier
Feb 22 12:45:41 myhost sendmail[1485]: Password verification failed
В /usr/lib/sasl/Sendmail.conf:
pwcheck_method:shadow

Моя ошибка в том, что я не учитываю, что теперь мною используется SASL второй версии, а он значительно отличается от первой версии.
В upgrading.html "Upgrading from Cyrus SASLv1 to Cyrus SASLv2" говорится:
If you used passwd, shadow, pam, kerberos_v4 or sia as your pwcheck_method in libsasl v1, you'll need to convert to using saslauthd. Arrange to start saslauthd -a method on boot. Change pwcheck_method in any configuration files to saslauthd.
Исправляю Sendmail.conf:
pwcheck_method: saslauthd
Мой текущий конфиг:
pwcheck_method: saslauthd
mech_list: plain login
log_level: 10
saslauthd_path: /var/state/saslauthd/mux
Запускаю /etc/init.d/saslauthd -a shadow.
ps aux|grep saslauthd:
root 14871 0.0 0.4 4136 1072 ? S 11:09 0:00 /usr/sbin/saslauthd -a shadow
root 14872 0.0 0.4 4136 1072 ? S 11:09 0:00 /usr/sbin/saslauthd -a shadow
root 14873 0.0 0.4 4136 1072 ? S 11:09 0:00 /usr/sbin/saslauthd -a shadow
root 14874 0.0 0.4 4136 1072 ? S 11:09 0:00 /usr/sbin/saslauthd -a shadow
root 14875 0.0 0.4 4136 1072 ? S 11:09 0:00 /usr/sbin/saslauthd -a shadow
Можно отредактировать /etc/sysconfig/saslauthd:
#SASLAUTHD_AUTHMECH=pam
SASLAUTHD_AUTHMECH=shadow
и запустить saslauthd без ключа a.
Нужно обязательно перезапустить sendmail: поправьте меня, если я ошибаюсь, но без перезапуска почтовика Sendmail.conf не перечитывается.

Отправляю письмо с рабочей станции - все o'k: пароль запрошен и принят, письмо ушло.
Да, в процессе отладки имели место и такие сообщения об ошибках:
Если в Sendmail.conf:
pwcheck_method:passwd
то в /var/log/messages имеем:
Feb 28 11:02:49 myhost sendmail[14834]: Password verification failed
Feb 28 11:02:59 myhost sendmail[14834]: unable to open Berkeley db /etc/sasldb2: No such file or directory

Или, если остановить saslauthd, то в /var/log/messages:
Feb 28 10:56:23 myhost sendmail[14763]: cannot connect to saslauthd server: No such file or directory
Feb 28 10:56:23 myhost sendmail[14763]: Password verification failed

3. Проблемы с pop3-авторизацией.
При попытке подключения к pop3-серверу, установленному из rpm, на почтовом клиенте (Netscape Messenger) процесс подключения к серверу зависает, появляется сообщение: "An error occured while sending your user name to the mail server", а в логах имеем:
Feb 24 11:27:09 myhost ipop3d[6144]: pop3 service init from 1.2.3.150
Feb 24 11:27:09 myhost ipop3d[6144]: AUTHENTICATE LOGIN failure host=step.mydom.ru [1.2.3.150]
Feb 24 11:27:09 myhost ipop3d[6144]: Command stream end of file while reading line user=??? host=step.mydom.ru [1.2.3.150]
При использовании TheBat клиент пишет:"FETCH:Server reports error. The response is:-ERR Unknown AUTHORIZATION stat"
В логах:
Mar 3 19:12:49 myhost ipop3d[27546]: pop3 service init from 1.2.3.150
Mar 3 19:12:49 myhost ipop3d[27546]: Command stream end of file while reading line user=??? host=step.mydom.ru [1.2.3.150]
Пробую подключится к 110 порту по telnet:
telnet myhost.mydom.ru 110
+OK POP3 myhost.mydom.ru v2003.83 server ready
+OK Supported authentication mechanism:
.
Как видите, ни PLAIN, ни LOGIN не поддерживаются.
И на любые команды (USER,PASS,LIST...) один и тот же ответ:
-ERR Unknown AUTHORIZATION state command

Самое время заглянуть в документацию (вообще-то, это нужно было сделать перез запуском pop3-демона:)
/usr/share/doc/imap/RELNOTES:
"...SSLTYPE=nopwd (в /usr/src/imap/Makefile указано, что эта опция означает "nopwd SSL support using OpenSSL, and plaintext authentication permitted only in SSL/TLS sessions") is now the default, in accordance with current IESG security requirements. In order to build the IMAP toolkit without SSL/TLS you must now use SSLTYPE=none. At initial build time, you will be told if the SSLTYPE setting is in compliance with IESG security requirements, and if it is not you will be asked to confirm to continue the build...."
/usr/share/doc/imap/FAQ.txt, п.3.17:
"...When plaintext passwords are disabled, the IMAP server will advertise the LOGINDISABLED capability and the POP3 server will not advertise the USER capability. ..."

Теперь по умолчанию pop3-сервер собирается с поддержкой SSL, и по умолчанию передача пароля в открытом виде разрешена только для ssl-сессии. PLAIN & LOGIN механизмы авторизации для pop3-сервера, запускаемого на стандартном 110 порту, теперь запрещены, и pop3-сервер вообще не предоставляет команды USER. Итак, В SUSE представлен pop3-сервер, предоставляющий такие механизмы авторизации как PLAIN & LOGIN только в SSL-режиме.

Читаем дальше:
/usr/share/doc/packages/imap/README.SUSE:
"...
For TLS/SSL encrypted connections (you most likely want these as plain password authentication is only allowed for those) you have to install a certificate imapd.pem and/or ipop3d in /etc/ssl/certs. If you don't have a certificate you can generate a self-signed certificate with the following commands:
cd /etc/ssl/certs
openssl req -new -x509 -nodes -out imapd.pem -keyout imapd.pem
openssl req -new -x509 -nodes -out ipop3d.pem -keyout ipop3d.pem
As the Common Name you must either enter the DNS name or IP address of your mail server. Note that a certificate is only valid for a limited time.
..."
Исполняем вышеуказанные команды. Следует иметь в виду, что самоподписанный сертификат используется только для тестирования соединения.
../imap/FAQ.txt/ 7.32 What does the PC error message: TLS/SSL failure: myserver: Self-signed certificate or untrusted authority mean?

"... An SSL or TLS session encryption failed because your server's certificate is "self-signed"; that is, it is not signed by any Certificate Authority (CA) and thus can not be validated. A CA-signed certificate costs money, and some smaller sites either don't want to pay for it or haven't gotten one yet. The bad part about this is that this means there is no guarantee that the server is really the system you think that it is.
Use the /novalidate-cert option in the mailbox name to disable validation of the certificate..."
Для нормальной работы в защищенном режиме следует обзавестись настоящим сертификатом. Подробности на сервере OpenSSL.

Редактируем /etc/xinetd/imap:
service pop3s
{
disable = no
log_type = FILE /var/log/pop3S-log
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/ipop3d
flags = IPv4
}

Перезапускаем xinetd.
Так, но при такой конфигурации невозможно использовать файлы /etc/hosts.allow & /etc/hosts.deny. Это файлы внутренного файрвола демона tcpd.
Для того, чтобы использовать эти файлы, нужно запустить pop3-демон через демон tcpd.
Снова редактируем /etc/xinetd/imap:
#
# imap - pop3 mail daemon
#
service pop3s
{
disable = no
flags = NAMEINARGS
- этот флаг теперь обязателен: он нужен для того, чтобы подсунуть tcpd в качестве аргумента имя программы. Без этого ключа демон tcpd не запустит pop-демон и кроме того забьет сообщениями /var/log/messages.
log_type = FILE /var/log/pop3S-log
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/tcpd
server_args = /usr/sbin/ipop3d
}

Формат /etc/hosts.deny: сначала запрещаем все соединения.
ALL : ALL

Формат /etc/hosts.allow: разрешаем соединения для определенных сервисов с определенных хостов:
ipop3d: 1.2.3.150 : ALLOW

/etc/init.d/xinetd restart
netstat -na|egrep 995:
tcp      0     0 0.0.0.0:995      0.0.0.0:*      LISTEN      1075/xinetd
Теперь воспользоваться telnet'ом для проверки работы pop3s-сервера нельзя, нужно использовать:
openssl s_client -host myhost.mydom.ru -port 995
Если все нормально, то в конце блока информации вы увидите:
Verify returncode: 18 (self signed certificate)

Вопрос, оставшийся для меня открытым:
в /usr/src/imap/docs/SSLBuild есть предупреждение:
"...NOTE: do *NOT* use TCP wrappers (tcpd) for the imaps and pop3s services! I don't know why, but it doesn't work with TCP wrappers..."
У меня же каким-то образом pop3s-сервис через tcpd-демон работает!

Настраиваем почтовый клиент: для The Bat нужно в Transport->Receive Mail->Connection выбрать "Secure to dedicated port (TLS)", при этом номер порта должен автоматически измениться на 995. Transport->Receive Mail->Authentication->Regular.
При первом заборе почты вы получите предупреждение:"Unknown CA Certificate is not trusted because it is not in the trusted Root CA address book. This connection may not be secure. You can add the certificate to be trusted root store by clicking "Add to trusted" button".
При этом в окне сообщений видим:
"FETCH:TLS handshake failue. Invalid server certificate. The CA Root certificate is not trusted."
Нажимаем кнопку "Add". Снова забираем почту, теперь все O'K, TheBat отчитывается:
"FETCH: initializeTLS handshake."
"FETCH: Certificate S/N: O, algorithm:RSA(1024bits),issued from ..."
"FETCH:This sertificate is self-issued."
"FETCH:TLS handshake complete."

Следует отметить, что сначала на сервере было установлено неправильное время - чужая зона.
Поэтому TheBat! отказывался работать с pop3s-сервером, сообщая:
!04.03.2005, 19:18:33: FETCH - TLS handshake failure. Invalid server certificate (This certificate is not yet valid).
После исправления времени все нормализовалось.
Еще один вопрос, оставшийся для меня открытым: это же сообщение появляется каждый раз после перегенерации самоподписанного ключа. TheBat! отказывается работать с pop3s-сервером, либо пока не будет исполнена команда
openssl s_client -host myhost.mydom.ru -port 995
с обязательными командами USER, PASS
либо пока не будет перезагружен сервер.

4. Компилируем imap без SSL.

Думаю, у многих локальных пользователей будут проблемы с подключением к 995 порту: не все почтовые клиенты умеют с ним общаться. Поэтому мне нужно пересобрать imap теперь уже без поддержки ssl.
Скачиваем исходники: UW-ftp://ftp.cac.washington.edu/mail/imap.tar.Z
Разворачиваем архив, внимательно читаем файл Build:
"UNIX BUILD NOTES
....
The default build is to build with SSL and disabling plaintext passwords unless SSL/TLS encryption is in effect (SSLTYPE=nopwd).
....
To build without SSL, add "SSLTYPE=none" to the make command line.
Note that doing so will produce an IMAP server which is NON-COMPLIANT with current IESG security requirements
...
Before doing a make on UNIX, you should read imap-2004/Makefile and see if your system type is known.
The various system types are three-letter codes.
If your system type is known, then use this as the make option: make slx
..."

В Makefile, действительно, перечислены несколько 3-буквенных кодов для Linux.
Несмотря на то, что у меня SUSE, код lsu мне не подошел (при установке SUSE мною проявлено слишком много самостоятельности :), а вот это сработало:
make slx SSLTYPE=none

Итак, в /usr/src/imap/popd/ скомпилирован новый ipop3d-демон. Копируем новый ipop3d в /usr/sbin.

Редактируем /etc/xinetd/imap(pop3-сервис запускаем через TCP WRAPPER tcpd):
#
# imap - pop3 mail daemon
#
service pop3
{
disable = no
flags = NAMEINARGS
log_type = FILE /var/log/pop3-log
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/tcpd
server_args = /usr/sbin/ipop3d
}
/etc/init.d/xinetd restart

Telnet myhost.mydom.ru 110
+OK POP3 myhost.mydom.ru v2004.89 server ready
AUTH
+OK Supported aut mech :
LOGIN

5. Компилируем imap over SSL и с поддержкой plaintext-авторизации в незащищенном режиме

Предположим,что часть пользователей будет работать с pop3 over SSL, а другая часть - с простым pop3-сервером через 110 порт.
Снова пересобираем imapd. Читаем файл SSLBuild:
"... To build with SSL but allow plaintext passwords in insecure sessions,add SSLTYPE=unix to the make command line..."
Кроме того нужно подправить /usr/src/imap/Makefile, чтобы при компиляции использовались директории /usr/include/ssl и /etc/ssl/certs, определенные в SUSE9.0, а не директории по умолчанию. Для этого ищем переменную EXTRASPECIALS и редактируем ее следующим образом:
EXTRASPECIALS="SSLINCLUDE=/usr/include/openssl SSLCERTS=/etc/ssl/certs SSLKEYS=/etc/ssl/private"
(SPECIALS= позволяет отредактировать путь к инклудам, но напрочь отказывается работать с SSLCERTS и SSLKEYS)
Запускаем make slx SSLTYPE=unix

Итак, в /usr/src/imap/popd/ скомпилирован новый ipop3d-демон, копируем новый ipop3d в /usr/sbin.

Снова идем в /etc/ssl/certs и запускаем команду:
openssl req -new -x509 -nodes -out ipop3d.pem -keyout ipop3d.pem

Снова редактируем /etc/xinetd/imap:
#
# imap - pop3 mail daemon
#
service pop3
{
disable = no
flags = NAMEINARGS
log_type = FILE /var/log/pop3-log
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/tcpd
server_args = /usr/sbin/ipop3d
}
#
# imap - pop3 mail daemon over tls/ssl
#
service pop3s
{
flags = NAMEINARGS
disable = no
log_type = FILE /var/log/pop3S-log
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/tcpd
server_args = /usr/sbin/ipop3d
}
/etc/init.d/xinetd restart 6. Ошибки при компиляции imap.
news.c: In function `news_open': news.c:347: warning: passing arg 3 of `scandir' from incompatible pointer type
http://www.washington.edu/imap/IMAP-FAQs/index.html#3.20

mtest.o(.text+0x1b2a): In function `mm_login': /usr/src/imapns/mtest/mtest.c:585: the `gets' function is dangerous and should not be used.
http://www.washington.edu/imap/IMAP-FAQs/index.html#3.22

../c-client/c-client.a(osdep.o)(.text+0x7af3): In function `ssl_onceonlyinit': /usr/src/imapns/c-client/osdep.c:267: the use of `tmpnam' is dangerous, better use `mkstemp'
http://www.washington.edu/imap/IMAP-FAQs/index.html#3.23
FAQ рекомендует не обращать внимания на эти сообщения.

6A. Если при обращении к pop3-серверу происходит задержка в 30s
В FAQ по этому поводу говорится:
"...Этому есть две причины.

1. У вас установлена система (напр., Linux), которая по умолчанию пытается подключится к 113 порту клиента (IDENT-сервер). А так как на вашей системе установлен firewall или NAT, блокирующий соединения по этому порту, то отсюда и возникает задержка подключения к pop3-порту...
...Эта проблема чаще всего возникает на системах, использующих xinetd вместо inetd.
Найдите файлы /etc/xinetd.conf, /etc/xinetd.d/imapd, /etc/inetd.d/ipop2d, /etc/xinetd.d/ipop3d.
Найдите в них строку:
log_on_success += USERID
и удалите/закомментируйте ее. Вы ничего не потеряете и не навредите своей системе...
По поводу USERID в man xinetd.conf говорится:
log_on_succeess USERID:
logs the user id of the remote user using the RFC 1413 identification protocol. This option is available only for multi-threaded strem services.

2. DNS тратит много времени на обратный резолвинг ip-адреса клента.Это проблема DNS. В идеале DNS должен вернуть имя клиента, но если это невозможно, он должен быстро вернуть сообшение об ошибке.

7. Файл syslog.conf для логирования сообщений почтовой системы.

Меня не устраивает тот факт, что часть почтовых сообщений пишется в messages (пользователей много, и эти сообщения порядком засоряют messages, в который, с моей точки зрения, должны записываться более важные сообщения), поэтому редактирую syslog.conf след. образом (это часть файла):
#
# all email-messages in one file
# mail.*          -/var/log/maillog

#
# all auth and authpriv in one file
#
auth.*          -/var/log/auth
authpriv.*          -/var/log/secure

#
# save the rest in one file
#
*.*;news.none;mail.none;authpriv.none;auth.none          -/var/log/messages

8. Прикручиваем Drweb. Сообщение "sendmail[508]: NOQUEUE: SYSERR(drweb): can not chdir(/var/spool/clientmqueue/)": Permission denied в /var/log/maillog.
Не выставлены правильные права и владельцы на файл /usr/sbin/sendmail/
Внимательно читаем файл из sendmail-дистрибутива /usr/src/sendmail-XXX/sendmail/SECURITY, создаем пользователя и группу smmsp, выставляем правильные права на /usr/sbin/sendmail.

9.Прикручиваем Drweb. Сообщение "sendmail[509]: Authentication-Warning: somedomain.ru: drweb set sender to DrWEB-DAEMON@somedomain.ru using -f.
Пользователь не указан в числе тех, кому доверено посылать локальную почту.
Информация из /usr/src/drweb/doc/readme.rus:
"... внесите пользователя drweb (или того, от которого работает drweb-smf) в список trusted-users в файле submit.cf

------------------- cut ---------------------
#####################
# Trusted users #
#####################
Tdrweb
------------------- cut ---------------------

(sendmail нужно будет перезапустить)

или добавьте в submit.mc

------------------- cut ---------------------
define(`confTRUSTED_USERS', `drweb')"
------------------- cut ---------------------
..."
После редактирования submit.mc submit.cf следует пересобрать:
m4 /usr/src/sendmail/cf/m4/cf.m4 submit.mc >submit.cf
Sendmail перезапустить.

10. Проблема при компиляции OpenSSL
Компилируем OpenSSL:
./config no-zlib no-threads
make
make test замирает навечно на словах:
"The following command should have some OK's and some failures
There are definitly a few expired certificates
../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs ../certs/*.pem"
По умолчанию OpenSSL будет складывать файлы в /usr/local/ssl.
/usr/src/OpenSSH/INSTALL:
"...This will build and install OpenSSL in the default location, which is (for historical reasons) /usr/local/ssl..."
Если этого каталога не существует, то вы столкнетесь с подвисанием навечно make test.
У меня это вылечилось указанием --prefix=/usr/local

11.Проблемы с OpenSSH
11.1 Ошибка при компиляции OpenSSH In function `dlfcn_load':: undefined reference to `dlopen'
Компилируем OpenSSH:
./configure --sysconfdir=/etc/ssh --with-tcp-wrappers --with-md5-passwords
make
make install
И получаем ошибку:
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x145): In function `dlfcn_load':: undefined reference to `dlopen'
Можно запустить ./configure с ключом LD_FLAGS="-ldl":
LD_FLAGS="-ldl" ./configure --sysconfdir=/etc/ssh --with-tcp-wrappers --with-md5-passwords
Информация взята из файла INSTALL:"...
If you need to pass special options to the compiler or linker, you can specify these as environment variables before running ./configure.
For example:
CFLAGS="-O -m486" LDFLAGS="-s" LIBS="-lrubbish" LD="/usr/foo/ld" ./configure
..."
Проверено, работает.
Или отредактировать файл Makefile, создающийся после исполнения ./configure ..., добавив EXTRA_LDFLAGS=-ldl или в имеющуюся уже строку LDFLAGS добавив -ldl .
(не проверялось).

11.2 Предупреждение при первом подключении к sshd: The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.

The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
RSA fingerprint is ...
Are you sure you want to continue connecting (yes/no)? yes
Здесь очень важно (см. 10.3.4. The SSH suite, 10.3.4.1. Introduction) ответить именно "yes" или "no", а не "y" или "n".
Иначе Вы будете без конца получать сообщение: "Please type 'yes' or 'no': ".

11.3 Ошибка при продключении к sshd: sshd re-exec requires execution with an absolute path

Если при подключении с клиентского хоста к sshd ( /usr/local/bin/ssh -vvv 127.0.0.1 ), запущенному через xinetd, вы получаете сообщение:

OpenSSH_4.1p1, OpenSSL 0.9.8 05 Jul 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/termit/.ssh/identity type -1
debug1: identity file /home/termit/.ssh/id_rsa type -1
debug1: identity file /home/termit/.ssh/id_dsa type -1
debug1: ssh_exchange_identification: sshd re-exec requires execution with an absolute path
ssh_exchange_identification: Connection closed by remote host
то скорее всего в файле запуска ssh-сервиса отсутствует флаг -i.
Man гласит:
"... -i Specifies that sshd is being run from inetd(8). sshd is normally
not run from inetd because it needs to generate the server key
before it can respond to the client, and this may take tens of
seconds. Clients would have to wait too long if the key was re-
generated every time. However, with small key sizes (e.g., 512)
using sshd from inetd may be feasible.
..."
Ваш /etc/xinetd.d/ssh должен будет выглядеть приблизительно так:
service ssh
{
disable = no
log_type = FILE /var/log/ssh-log
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/local/sbin/sshd
server_args = -i
}
Обращаю ваше внмание на то, что, если ssh собирался с опцией --with-tcp-wrappers, то даже не будучи запущенным через tcpd-сервер, он все равно просматривает файлы /etc/hosts.allow & hosts.deny.
То есть запуск через tcpd уже лишний:
{
disable = no
flags = NAMEINARGS
log_type = FILE /var/log/ssh-log
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/tcpd
server_args = /usr/local/sbin/sshd -i
}
Хотя и так sshd будет работать.

Ну вот, вроде бы и все...

Еще один вопрос, оставшийся без ответа: как сказать pop-демону, чтобы он отключил определение доменного имени ip-адреса.
Мне, например, совершенно не нужно, чтобы демон тратил свое драгоценное время :) на запросы dns-серверу и писал в логи помимо ip еще и доменные имена.
В доке imaprc.txt есть такая опция
set allow-reverse-dns 0
Но как ее использовать, мне так и не удалось понять.

Обратная связь
Страница создана 18 февраля 2005г.
Последнее обновление: 23 ноября 2005г.
Самое последнее обновление: 27 марта 2007г.
Вопросы, замечания, комментарии, пожалуйста, сюда: sciurus@mail.ru
Этот почтовый ящик я проверяю не чаще раза в неделю, поэтому не обессудьте за задержку с ответом.
Просьба в качестве темы сообщения указать слово "Sendmail", отвечу обязательно.
[1]