Kolab 16 on Debian Stretch does not work OOTB
Closed, ResolvedPublic


dpkg -l pykolab

ii pykolab 0.8.10-0~kolab2 all Kolab Groupware daemon and utilities

Hello devs,

fresh Kolab 16 Installation on Debian 9 Stretch does not work "Out of the Box".

I did a "standard" Debian Stretch installation + SSH service - nothing more.
Adjusted /etc/hosts.
Adjusted /etc/hostname.
Added Kolab Repo and key, apt-get update, apt-get upgrade, apt-get install kolab.

Debian asked me for postfix configuration > i answered with "no configuration".
After all packages were installed I ran setup-kolab and answered all questions > OK.

Logged into kolab-webadmin and added a kolab mail-user > OK.
Logged into webmal (Roundcube) and tried to send mail to myself > Error.

First error I found in /var/log/mail.log was that transport.db was missing.
OK > postmap /etc/postfix/transport > fixed.
Second error I found was something about "submission premature error".
I did not find any solution to this so I changed roundcubes smtp_port from 587 to 25.
Tried to send the mail again > another error.
Checked /var/log/mail.log > TLS error > TLS is enforced.
Checked /etc/postfix/ > no "smtpd_tls_cert_file" and no "smtpd_tls_key_file".
Added them pointing to Debian standard /etc/ssl/certs/ssl-cert-snakeoil.pem and /etc/ssl/private/ssl-cert-snakeoil.key.
Tried to send the mail again > SUCCESS.

Some things went wrong during setup-kolab.
After that I checked tls certs and keys for imapd, guam, etc.

Guam and Cyrus use /etc/ssl/private/cyrus-imapd.pem for key and cert - why not buildin snakeoil?
This cert was generated for "localhost.localdomain" - why not FQDN of host?
This cert ist only 365 day valid - why?

Please don't misunderstand me, but...

  1. having different certs for different services on same server makes no sense in manner of administration.
  2. why not use buildin solution > snakeoil.
  3. Sure - these ones should be replaced with "real" ones but not necessary even in production environments where you have a reverse proxy holding all certs for all servers and ease adminstration. changing selfsigned certificates every year is a no-go.

Checked /usr/lib/python2.7/dist-packages/pykolab/setup/ to find out why the cert and key where not enabled in postfix.

cat /usr/lib/python2.7/dist-packages/pykolab/setup/| grep tls

        "smtpd_tls_auth_only": "yes",
        "smtpd_tls_security_level": "may",
        "smtp_tls_security_level": "may",
if os.path.isfile('/etc/pki/tls/certs/make-dummy-cert') and not os.path.isfile('/etc/pki/tls/private/localhost.pem'):['/etc/pki/tls/certs/make-dummy-cert', '/etc/pki/tls/private/localhost.pem'])
if os.path.isfile('/etc/pki/tls/private/localhost.pem'):
    postfix_main_settings['smtpd_tls_cert_file'] = "/etc/pki/tls/private/localhost.pem"
    postfix_main_settings['smtpd_tls_key_file'] = "/etc/pki/tls/private/localhost.pem"

Again "different" cert and key and it fails because these paths are used on "rpm" based distros I think but not "apt" based like Debian/Ubuntu.

These little bugs really kill the out-of-the-box experience but can easily be fixed in the kolab templates and python setup scripts.

When I have more time I will look into the submission problem - also I don't like submission.
Is submission necessary/mandatory for something else?


Ticket Type

Event Timeline

johndoe created this task.Dec 27 2018, 12:07 PM

Another problem:
After reboot dirsrv instance does not start.

systemctl enable dirsrv@INSTANCE > fixed.

johndoe added a comment.EditedDec 29 2018, 1:52 PM

I think I have found the problem for submission.

submisson_sender_restrictions, submission_recipient_restrictions and submission_data_restrictions are missing "permit_mynetworks".

All correspondig smtpd_* rules have "permit_mynetworks" set.
Adding "permit_mynetworks" to all three submission restrictions makes submission work.

I'm not familiar with submission - never used it with postfix on my side - but I think that this is necessary for submission, too.

Looking at /etc/posfix/ submission is using smtpd anyway. So what's the deal with it? Supporting broken clients? Outlook does not need this.


vanmeeuwen closed this task as Resolved.Mar 21 2019, 11:10 PM
vanmeeuwen moved this task from Backlog to Reviewed on the Bug Reports board.
vanmeeuwen claimed this task.
vanmeeuwen added a subscriber: vanmeeuwen.

Your problems shouldn't have occurred if you choose "Internet configuration" for postfix.

If I'm not mistaken, the 389-ds issue is an issue in the packaging upstream (something about and dirsrv@.service and dirsrv@$(hostname -s).service), but I don't recall exactly.