Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - bubnov-pi

Pages: [1]
1
Russian / У кого-нибудь ошибка с ocsmanager есть?
« on: December 19, 2014, 11:56:57 am »
Опишу суть проблемы.
После позавчерашнего обновления openchange (zentyal-openchange:amd64 (4.0.3, 4.0.6), openchange-rpcproxy:amd64 (2.3-zentyal4, 2.3-zentyal5), sogo-openchange:amd64 (2.2.9a-zentyal2, 2.2.9a-zentyal3), openchangeserver:amd64 (2.3-zentyal4, 2.3-zentyal5), openchange-notification:amd64 (2.3-zentyal4, 2.3-zentyal5), openchange-ocsmanager:amd64 (2.3-zentyal4, 2.3-zentyal5) и openchangeproxy:amd64 (2.3-zentyal4, 2.3-zentyal5), если верить /var/log/apt/history.log), у меня на [тестовом] сервере zentyal4 в /var/log/syslog стали сыпаться бесконечные сообщения типа:
Code: [Select]
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Initializing broker connection
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Initializing TCP socket
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Connecting to broker localhost:5672
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Failed to connect to broker: a socket error occurred
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Closing broker connection
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Cancel consumer
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Failed to close channel: a socket error occurred
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Closing broker channel 2
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Failed to close channel: a socket error occurred
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Closing broker channel 1
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Failed to close channel: a socket error occurred
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Closing broker socket connection
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Failed to close connection: a socket error occurred
Dec 18 00:10:14 zentyal4 openchange-notification-service[5494]: Destroying broker connection state
Визуально, ничего не отвалилось - всё вроде работает. Но лог пухнет как бешеный.
Сервер выполняет единственную роль - почтовый сервер.
Потыкавшись вслепую, обнаружил, что в /etc/ocsmanager/ocsmanager.ini прописано:
Code: [Select]
[server:main]
use = egg:Paste#http
host = 127.0.0.1
port = 5000
protocol_version = HTTP/1.1
Заменил значение "port" на 5672, перезапустил openchange-ocsmanager, ошибки из лога пропали.
Вот, хотел поинтересоваться - это оно только у меня "сломалось", или это обновление кривое было?
(в старых логах вижу строки, свидетельствующие о том, что оно работало на порту 5672, поэтому и исправлял на него)

2
Hi all. My problem is very close to http://forum.zentyal.org/index.php/topic,12388.msg50950.html#msg50950 but have some differences

I have virtual maildomain 'test.ru' on zentyal 3.0 server.
Authorization domain (kerberos realm) is 'test.lan'.
Workstations and users are members of "Windows domain" 'test.lan'.
On workstations configured Thunderbird as default mail client with Kerberos / GSSAPI authorization.
Because authorization credentials are 'user@TEST.LAN', and mailaddresses are 'user@test.ru', I became some authorisation errors:
First from dovecot, when user try to recieve mail:
Code: [Select]
Jun 28 16:01:40 zent dovecot: auth: Error: userdb(user@TEST.LAN,192.168.122.29): user not found from userdb ldap
Jun 28 16:01:40 zent dovecot: imap: Error: Authenticated user not found from userdb, auth lookup id=2933784577 (client-pid=24627 client-id=1)
Jun 28 16:01:40 zent dovecot: imap-login: Internal login failure (pid=24627 id=1) (auth failed, 1 attempts): user=<user@TEST.LAN>, method=GSSAPI, rip=192.168.122.29, lip=192.168.122.101, mpid=24631, TLS
This error can be fixed by modifying rule in 'dovecot-ldap.conf' file to:
Code: [Select]
user_filter = (&(objectClass=CourierMailAccount)(|(uid=%n)(mail=%u)))But the second error occurs at sending emails, from postfix:
Code: [Select]
Jun 28 16:10:51 zent postfix/smtpd[24798]: connect from linux-7r77.test.lan[192.168.122.29]
Jun 28 16:10:51 zent postfix/smtpd[24798]: NOQUEUE: reject: RCPT from linux-7r77.test.lan[192.168.122.29]: 553 5.7.1 <user@test.ru>: Sender address rejected: not owned by user user@TEST.LAN; from=<user@test.ru> to=<mailuser@test.lan> proto=ESMTP helo=<[192.168.122.29]>
Jun 28 16:10:54 zent postfix/smtpd[24798]: disconnect from linux-7r77.test.lan[192.168.122.29]
And I can't find some way to solve it other than comment 'smtpd_sender_restrictions' rule, as in thread, pointed in first line of this post, so any authenticated user can send message "from" any e-mail address, and it is not so fine  :-\

Is this behavior of Zentyal server normal or erroneous? Have somebody any suggestions for more accurate solving this situation?

P.S.: Described situation is on just-installed (from "zentyal-3.0-2-i386.iso" disc) for test system; Current core version: 3.0.21, with all actual updates. Active modules: Network, Firewall, Antivirus, DHCP, DNS, Backup, Events, Logs, Mail Filter, Monitoring, NTP, VPN, Users and Groups, Web Server, FTP, Mail, File Sharing, HTTP Proxy, Webmail, Printer Sharing. I explore Zentyal as alternative to our old solution with different authentication databases/user accounts on different physical servers (fileserver, mailserver and proxy/web/GW). The first task is to transfer e-mail and central authorization roles to new platform, and I can't name my internal domain same as external, because users have access to external web-platform, that name is exact as our maildomain.

3
Russian / Возможно, ошибка в подсистеме LDAP
« on: June 26, 2013, 02:12:39 pm »
Здравствуйте!

(данное сообщение - альтернативная ветка моего вопроса в английском разделе - http://forum.zentyal.org/index.php/topic,16582.0.html)
Хотел поинтересоваться соображениями и наблюдениями общественности - обнаружил странность в конфигурации LDAP на Zentyal 3:
В вэб-интерфейсе Zentyal я наблюдаю такие параметры ldap:
Base DN:    dc=test,dc=lan
Root DN:    cn=zentyal,dc=test,dc=lan
Password:    VMTczzH8KybgMsbWtXhk
Read-only root DN:    cn=zentyalro,dc=test,dc=lan
Read-only password:    O8p0XRzIaLpdWwKEVxE1
Users DN:    ou=Users,dc=test,dc=lan
Groups DN:    ou=Groups,dc=test,dc=lan
(всё привожу как есть - всё равно машина в тестовой среде, так что пароли показать не страшно)
В приведённой таблице смущает два момента:
1. С приведёнными учётными данными (Root DN и Read-only root DN) мне не удалось авторизоваться на ldap-сервере ни удалённо, с соседней машины, ни локально, ldapsearch
2. "Users DN:" начинается с "ou=Users", но по факту (подключившись созданным в вэбке пользователем) в каталоге ldap я наблюдаю не "Подразделение" (ou), а "Контейнер" (cn), называющийся Users, соответственно и поиск приходится вести не в ou=Users,dc=test,dc=lan, а в cn=Users,dc=test,dc=lan
При этом, в конфигурации, например, dovecot, используются именно приведённые в вэб-интерфейсе данные (как для авторизации, так и для поиска данных пользователей), и если там вручную изменить ou на cn, при авторизации клиентов выдаётся ошибка (на этапе чтения user_attrs), то есть где-то существует именно OU "Users".

Есть у кого-нибудь соображения, бага это, или так сделано по каким-то скрытым от моего понимания причинам?

Почему обратил внимание на данную нестыковку - если использовать авторизацию в почте через GSSAPI, тот самый dovecot пытается получить дополнительные параметры пользователя (настройки квотирования) подставляя в поле поиска "mail", указанное пользователем имя входа, то есть, для пользователя "mailuser" в моём случае будет подставлено "mailuser@TEST.LAN", что в общем случае не соответствует действительности - адрес почты пользователя может отличаться от имени входа в домен, да и вообще, realm авторизации Kerberos не имеет ни малейшего отношения к виртуальному почтовому домену, в котором у пользователя находится ящик. Проблема с dovecot решается элементарной правкой конфига, изменяя как параметры подключения к LDAP, так и правило сопоставления имени пользователя - либо с sAMAccountName, либо с userPrincipalName, но вот квоты тогда не работают - видимо, они хранятся "в другом каталоге" ldap (содержимое которого для меня остаётся загадкой).

P.S.: Проблема наблюдается на свежеустановленном из образа "zentyal-3.0-2-i386.iso" тестовом сервере; Текущая версия: 3.0.21, со всеми обновлениями. Активные модули: Network, Firewall, Antivirus, DHCP, DNS, Backup, Events, Logs, Mail Filter, Monitoring, NTP, VPN, Users and Groups, Web Server, FTP, Mail, File Sharing, HTTP Proxy, Webmail, Printer Sharing. Zentyal изучается как возможная замена текущего "зоопарка" с разными точками авторизации, на физически разных машинах (файлсервер, почтовик и proxy/web/шлюз).

4
Installation and Upgrades / Possible error in LDAP subsystem
« on: June 26, 2013, 01:33:50 pm »
Hello, everybody!

I'm not sure, but I find some strange thing:
In Zentyal web interface (LDAP settings), I see "Users DN:    ou=Users,dc=test,dc=lan", but in fact, with any ldap-querying tool I can't to see this OU, there is only "cn=Users,dc=test,dc=lan", and all user accounts are placed into this Container (not Organisation unit), moreover, it is impossible to query LDAP with listed in web-interface credentials (for "adressbook" purpose, for example).
Okay, may be this shouldn't be a big problem, but in dovecot "user_attrs" parameter reads attributes from DN with "ou=", and if it changed to "cn=", occurs error.

Can somebody tell me, how it is possible? Is it a bug, or feature?

The second thing is unclear authentication mechanism with LDAP, if GSSAPI is used, but it is for my second topic.

P.S.: Described situation is on just-installed (from "zentyal-3.0-2-i386.iso" disc) for test system; Current core version: 3.0.21, with all actual updates. Active modules: Network, Firewall, Antivirus, DHCP, DNS, Backup, Events, Logs, Mail Filter, Monitoring, NTP, VPN, Users and Groups, Web Server, FTP, Mail, File Sharing, HTTP Proxy, Webmail, Printer Sharing. I explore Zentyal as alternative to our old solution with different authentication databases/user accounts on different physical servers (fileserver, mailserver and proxy/web/GW).
If some my sentences are not clear, please, ask me for more accurate definition - my English is not perfect...

Pages: [1]