Problems with Kolab 16 fresh install on Centos 7


  • Global Moderator

    @Constin /var/log/maillog may contain something relevant.

    In any case, the following command sequence must get you back to having Cyrus IMAP listening on 127.0.0.1:9993 again:

    # systemctl stop cyrus-imapd
    # pkill -u cyrus
    # systemctl start cyrus-imapd
    

    The following command verifies Cyrus IMAP indeed does listen on 127.0.0.1:9993:

    # netstat -tlnp | grep :9993
    

    Once it does, try using the imtest command like so:

    # imtest -t "" -u john.doe@example.org -a john.doe@example.org -w welcome123 localhost
    

    and:

    # imtest -s  -u john.doe@example.org -a john.doe@example.org -w welcome123 localhost
    


  • yep , did it before
    all ok
    now it works)

    Update:
    That was my fail

    Starts to work then i completely disabled SElinux in config and reboot system

    mail log

    root@kolab ~]# cat /var/log/maillog | grep imaps
    Feb  4 12:23:13 kolab master[3257]: unable to bind to imaps/ipv4 socket: Permission denied
    Feb  4 12:23:13 kolab master[3257]: unable to create imaps listener socket: Permission denied
    Feb  4 12:25:08 kolab master[2614]: unable to bind to imaps/ipv4 socket: Permission denied
    Feb  4 12:25:08 kolab master[2614]: unable to create imaps listener socket: Permission denied
    Feb  4 15:41:55 kolab master[2609]: unable to bind to imaps/ipv4 socket: Permission denied
    Feb  4 15:41:55 kolab master[2609]: unable to create imaps listener socket: Permission denied
    Feb  4 15:44:12 kolab imaps[2611]: inittls: Loading hard-coded DH parameters
    Feb  4 15:44:12 kolab imaps[2611]: starttls: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits new) no authentication
    Feb  4 15:44:14 kolab imaps[2611]: login: localhost [127.0.0.1] cyrus-admin plaintext+TLS User logged in SESSIONID=<kolab.hst4.com-2611-1454597052-1-11458757884025962225>
    Feb  4 15:44:14 kolab imaps[2609]: inittls: Loading hard-coded DH parameters
    Feb  4 15:44:14 kolab imaps[2609]: starttls: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits reused) no authentication
    Feb  4 15:44:14 kolab imaps[2609]: login: localhost [127.0.0.1] ddd.ddd@XXX.com PLAIN+TLS User logged in SESSIONID=<kolab.hst4.com-2609-1454597054-1-12706623852540068327>
    Feb  4 15:44:18 kolab imaps[2609]: USAGE ddd.ddd@XXX.com user: 0.025656 sys: 0.100470
    Feb  4 15:44:18 kolab imaps[2610]: inittls: Loading hard-coded DH parameters
    Feb  4 15:44:18 kolab imaps[2610]: starttls: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits reused) no authentication
    Feb  4 15:44:18 kolab imaps[2610]: login: localhost [127.0.0.1] cyrus-admin plaintext+TLS User logged in SESSIONID=<kolab.hst4.com-2610-1454597058-1-5123250891466155274>
    Feb  4 15:45:56 kolab imaps[2603]: inittls: Loading hard-coded DH parameters
    Feb  4 15:45:56 kolab imaps[2603]: starttls: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits new) no authentication
    Feb  4 15:45:57 kolab imaps[2603]: login: localhost [127.0.0.1] cyrus-admin plaintext+TLS User logged in SESSIONID=<kolab.hst4.com-2603-1454597156-1-4751062290499462905>
    [root@kolab ~]#
    
    


  • I did another fresh install yesterday, and posted more details about the process on the kolab users mailing list. After the install, following the latest Centos7 instructions, everything seemed to work for me. The only configuration modification I still needed is doing the localhost->127.0.0.1 change for all the database lookup lines as mentioned in a previous message in this thread. Should that still be the case, or did I miss something?

    All other systems including imap, guam, clamav, got installed and working. One irony in the light of @kanarip's latest blog repost is that I can't get my FQDN to hold after a reboot...something is modifying it at startup and dropping the domain part, but I believe it was correct at the time I ran setup-kolab.

    One problem in Roundcube is that it's spitting out an "Internal Error" message every time it tries to check for new email. I haven't found a log yet to indicate what's happening. The popup shows up right after the "Refreshing..." notification message disappears in the lower right corner. I don't see the issue when I manually refresh by hitting the refresh button.

    There are some other operational issues I'm having, but those issues exist in my Kolab:Development install as well and are fodder for another post instead of this one.



  • It may be related to this thread i am also having this issue, got nothing in the logs, even setting debug_level over 5 in roundcube din´t give any hints.


  • Global Moderator

    @troycarpenter said:

    I did another fresh install yesterday, and posted more details about the process on the kolab users mailing list. After the install, following the latest Centos7 instructions, everything seemed to work for me. The only configuration modification I still needed is doing the localhost->127.0.0.1 change for all the database lookup lines as mentioned in a previous message in this thread. Should that still be the case, or did I miss something?

    I don't understand the case you seem to be hitting with the database access, except for that either forward or reverse DNS lookups seem to be failing to resolve either 127.0.0.1 and/or ::1, or localhost.

    This would deserve some more troubleshooting but I can not reproduce the issue on a KVM guest.

    All other systems including imap, guam, clamav, got installed and working. One irony in the light of @kanarip's latest blog repost is that I can't get my FQDN to hold after a reboot...something is modifying it at startup and dropping the domain part, but I believe it was correct at the time I ran setup-kolab.

    Is this still an LXC container? Does it loop- or bind-mount, or otherwise populate /etc/hosts by any chance?

    One problem in Roundcube is that it's spitting out an "Internal Error" message every time it tries to check for new email. I haven't found a log yet to indicate what's happening. The popup shows up right after the "Refreshing..." notification message disappears in the lower right corner. I don't see the issue when I manually refresh by hitting the refresh button.

    This is now [T967](https://git.kolab.org/T967], please follow that ticket for progress.

    There are some other operational issues I'm having, but those issues exist in my Kolab:Development install as well and are fodder for another post instead of this one.

    Please note that Kolab:Development is now Kolab:Winterfell. I'm just saying that in order to continue to receive updates from the bleeding edge, please switch over.



  • @kanarip said:

    @troycarpenter said:

    I did another fresh install yesterday, and posted more details about the process on the kolab users mailing list. After the install, following the latest Centos7 instructions, everything seemed to work for me. The only configuration modification I still needed is doing the localhost->127.0.0.1 change for all the database lookup lines as mentioned in a previous message in this thread. Should that still be the case, or did I miss something?

    I don't understand the case you seem to be hitting with the database access, except for that either forward or reverse DNS lookups seem to be failing to resolve either 127.0.0.1 and/or ::1, or localhost.

    This would deserve some more troubleshooting but I can not reproduce the issue on a KVM guest.

    All other systems including imap, guam, clamav, got installed and working. One irony in the light of @kanarip's latest blog repost is that I can't get my FQDN to hold after a reboot...something is modifying it at startup and dropping the domain part, but I believe it was correct at the time I ran setup-kolab.

    Is this still an LXC container? Does it loop- or bind-mount, or otherwise populate /etc/hosts by any chance?

    I am trying this in an LXC container, but I'm comparing it to my Development system (which I need to switch to Winterfell per your note below) which is a KVM, not LXC. The /etc/hosts files look the same between the two systems, and I don't think the /etc/hosts file is mounted strangely. I do believe there is something dropping the hostname with a 127.0.0.1 entry into the hosts file, but I have a startup script removing that line since my working mail system doesn't include it and is working.

    dig and nslookup on localhost doesn't give anything, but that is expected since those tools bypass /etc/hosts. If I ping localhost, it works, and the T967 workaround using localhost for the database reference also works.

    I will continue to investigate this, but if it is the only problem, I'm not as concerned about it right now.

    One problem in Roundcube is that it's spitting out an "Internal Error" message every time it tries to check for new email. I haven't found a log yet to indicate what's happening. The popup shows up right after the "Refreshing..." notification message disappears in the lower right corner. I don't see the issue when I manually refresh by hitting the refresh button.

    This is now [T967](https://git.kolab.org/T967], please follow that ticket for progress.

    Applied the workaround and the messages stopped. I wonder if that's also what broke my development system using Seafile as well...

    There are some other operational issues I'm having, but those issues exist in my Kolab:Development install as well and are fodder for another post instead of this one.

    Please note that Kolab:Development is now Kolab:Winterfell. I'm just saying that in order to continue to receive updates from the bleeding edge, please switch over.

    Thanks for the note on Winterfell. I will switch my development system over to it.



  • I have the same trouble on a fresh installed fedora
    20:42 guam.service: Failed with result 'start-limit'. systemd
    20:42 guam.service: Unit entered failed state. systemd
    20:42 Failed to start Intelligent IMAP Reverse Proxy. systemd
    20:42 guam.service: Start request repeated too quickly. systemd
    20:42 guam.service: Service hold-off time over, scheduling restart. systemd
    20:42 guam.service: Failed with result 'exit-code'. systemd
    20:42 guam.service: Unit entered failed state. systemd
    20:42 guam.service: Main process exited, code=exited, status=203/EXEC systemd
    20:42 guam.service: Failed at step EXEC spawning /usr/sbin/guam: Permission denied systemd
    20:42 Starting Intelligent IMAP Reverse Proxy...

    Should i re install with centos ? if its fixed there or ?



  • I think this will be my final update on this. Today I did a fresh install into a KVM instead of LXC container. This time I had to follow the install directions on the website much closer because the KVM is like a bare-metal install and had SELinux enabled. However, this install did NOT have the hostname issues, and I didn't need to change the localhost references to 127.0.0.1. I think that problem is unique to LXC containers.

    I still had to apply the T967 fix to get rid of the 30 second error messages in Roundcube.

    For iRony, I also had to manually apply T1022, as outlined here: https://kolab.org/hub/topic/15/upgrading-kolab-3-4-to-16/13. I've been able to download content using DAV, but I've not been able to do a two-way sync. Don't know if that's my client or iRony. Basically I'm seeing this at the client when trying to send data:

    "CalDavSynchronizer.DataAccess.WebDavClientException: Response status code does not indicate success: '500' ('InternalServerError'). Message:
    <?xml version="1.0" encoding="utf-8"?>
    <d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
    <s:sabredav-version>2.1.6</s:sabredav-version>
    <s:exception>Exception</s:exception>
    <s:message>Storage error. Library not found.</s:message>
    </d:error>"



  • very important thanks i use this for my website medespoir.ch and it's very informative




Log in to reply