Problems with Kolab 16 fresh install on Centos 7



  • I'm having a few issues with a new install of Kolab 16 in an Centos 7 LXC container on my virtual host.

    When I ran the setup-kolab command, the first output was:
    "Redirecting to /bin/systemctl start guam.service
    Failed to start guam.service: Unit guam.service failed to load: No such file or directory."

    I kept going, but I will note that trying to start guam from the command line after the install generates the same output.

    Second problem is that Kolab seems to expect imaps on port 993, but this entry in SERVICES section of cyrus.conf begs to differ:
    imaps cmd="imapd -s" listen="127.0.0.1:9993" prefork=5

    I changed the listen parameter to imaps (like it is on my other kolab installs) and moved on.

    Finally, when I log into the web admin panel with the Directory Manager credentials, tabs where I should be able to add things like users, groups, roles, resources, etc. do not let me add anything. There are no users, and no form to add users. Same on the other tabs I mentioned. My best guess is that there is a database problem, a suspicion that was bolstered when I tried Roundcube and it told me it couldn't connect to the database. I'll look into that when I have more time.



  • I have same problem.
    The problem with connect to mysql.
    Than you switch to user or group page look at
    #tail -f /var/log/kolab-webadmin/errors
    02-Feb-2016 18:53:01 +0100: [ERROR] DB Error: SQLSTATE[HY000] [2002] Permission denied

    So, i'm on the way to solve it. Will write later.



  • Edited

    FIX for user/groups in admin menu

    /etc/kolab/kolab.conf

    [kolab_wap]
    skin = default
    OLD
    sql_uri = mysql://kolab:passwd@localhost/kolab
    NEW
    sql_uri = mysql://kolab:passwd@127.0.0.1/kolab
    ssl_verify_peer = false
    ssl_verify_host = false



  • Could some one tell me , why t f they use mysql with openldap?



  • @Constin
    As best as I can tell from my working 3.5 Kolab installation, the mysql config files look the same. I might be missing something, though.



  • @troycarpenter
    Ok , so error in mysql connector or /etc/hosts
    Play with 127.0.0.1 and localhost



  • So I wiped out that VM and created a new one to try again from scratch. This time guam was installed, but still won't start up. I now see what is happening with the cyrus-imap and guam: it looks like cyrus is running on 9993, and guam is supposed to be running on 993 and 143 to act as the proxy.

    Unfortunately, I still can't get guam to run. Right now I get this:
    "guam.service - Intelligent IMAP Reverse Proxy
    Loaded: loaded (/usr/lib/systemd/system/guam.service; enabled; vendor preset: disabled)
    Active: failed (Result: start-limit) since Tue 2016-02-02 22:35:57 UTC; 4s ago
    Process: 12544 ExecStart=/usr/sbin/guam foreground (code=exited, status=1/FAILURE)
    Main PID: 12544 (code=exited, status=1/FAILURE)

    Feb 02 22:35:56 kolab.carpenter.cx systemd[1]: Unit guam.service entered failed state.
    Feb 02 22:35:56 kolab.carpenter.cx systemd[1]: guam.service failed.
    Feb 02 22:35:57 kolab.carpenter.cx systemd[1]: guam.service holdoff time over, scheduling restart.
    Feb 02 22:35:57 kolab.carpenter.cx systemd[1]: start request repeated too quickly for guam.service
    Feb 02 22:35:57 kolab.carpenter.cx systemd[1]: Failed to start Intelligent IMAP Reverse Proxy.
    Feb 02 22:35:57 kolab.carpenter.cx systemd[1]: Unit guam.service entered failed state.
    Feb 02 22:35:57 kolab.carpenter.cx systemd[1]: guam.service failed."

    My two other problems still exist. Logging into kolab-webadmin still doesn't allow me to add users (or anything else).

    Pulling up the Roundcube interface gives me an error:
    "DATABASE ERROR: CONNECTION FAILED!

    Unable to connect to the database!
    Please contact your server-administrator."

    Oh, and there was one error message about clamav :
    "Failed to restart clamd@amavisd.service: Unit clamd@amavisd.service failed to load: No such file or directory."



  • Deleted. cyrss config - ok. Problem with guam.



  • Here next error with /webmail connect to database
    Why this log not in /var/log????
    [root@kolab logs]# cat /usr/share/roundcubemail/logs/errors

    [03-Feb-2016 09:43:22,738800 +0100]: <pd5joc8h> DB Error: SQLSTATE[HY000] [2002] Permission denied in /usr/share/roundcubemail/program/lib/Roundcube/rcube_db.php on line 173 (GET /webmail/)

    FIX:

    /usr/share/roundcubemail/config/config.inc.php

    OLD
       $config['db_dsnw'] = 'mysqli://roundcube:heremypassword@localhost/roundcube';
     NEW 
       $config['db_dsnw'] = 'mysqli://roundcube:heremypassword@127.0.0.1/roundcube';
    
    


  • FIX for user/groups in admin menu

    /etc/kolab/kolab.conf

    [kolab_wap]
    skin = default
    OLD
    sql_uri = mysql://kolab:passwd@localhost/kolab
    NEW
    sql_uri = mysql://kolab:passwd@127.0.0.1/kolab
    ssl_verify_peer = false
    ssl_verify_host = false
    

  • Global Moderator

    @Constin said:

    Could some one tell me , why t f they use mysql with openldap?

    We do not use MySQL nor OpenLDAP. It's MariaDB with 389 Directory Server.



  • Take a look at aseigo's blog entry on GUAM. The depiction of the architecture defined by the standard configuration can be reduced to two listeners listening on the ports 143 and 993, and a single IMAP server which GUAM connects to on port 9993.

    It is therefore wrong to change the port, on which the IMAP server listens on, from 9993 to 993 when in the same time not disabling GUAM (which in the end is probably not what you want) or not adjusting GUAM's configuration (which probably isn't your intention either since you probably want your clients to be able to access the server through the standard ports).

    From what I can tell when looking at this problem (which I am currently trying to debug myself), something went wrong with GUAM an prevents it from running correctly.


  • Global Moderator

    @troycarpenter said:

    Oh, and there was one error message about clamav :
    "Failed to restart clamd@amavisd.service: Unit clamd@amavisd.service failed to load: No such file or directory."

    It seems clamav is not being pulled in with amavisd-new any longer. This, I can fix (see Winterfell, the Kolab 16 inclusion request and its acceptance/inclusion).

    After installing the clamav-server-systemd package though, the result would be:

    [root@kolab ~]# rpm -ql clamav-server-systemd
    /usr/lib/systemd/system/clamd@.service
    [root@kolab ~]# systemctl enable clamd@amavisd.service
    The unit files have no [Install] section. They are not meant to be enabled
    using systemctl.
    Possible reasons for having this kind of units are:
    1) A unit may be statically enabled by being symlinked from another unit's
       .wants/ or .requires/ directory.
    2) A unit's purpose may be to act as a helper for some other unit which has
       a requirement dependency on it.
    3) A unit may be started when needed via activation (socket, path, timer,
       D-Bus, udev, scripted systemctl call, ...).
    

    This is a known problem (see bugzilla #3348), but also an upstream problem -- it should be reported to the Red Hat Bugzilla -- as I would prefer to avoid having to ship clamav ourselves.

    It is resolved by:

    [root@kolab ~]# cp /lib/systemd/system/clamd\@.service /etc/systemd/system/clamd@.service
    [root@kolab ~]# cat >> /etc/systemd/system/clamd\@.service << EOF
    > [Install]
    > WantedBy=multi-user.target
    > EOF
    [root@kolab ~]# systemctl enable clamd@amavisd.service
    Created symlink from /etc/systemd/system/multi-user.target.wants/clamd@amavisd.service to /etc/systemd/system/clamd@.service.
    [root@kolab ~]# 
    

  • Global Moderator

    @troycarpenter said:

    I'm having a few issues with a new install of Kolab 16 in an Centos 7 LXC container on my virtual host.

    When I ran the setup-kolab command, the first output was:
    "Redirecting to /bin/systemctl start guam.service
    Failed to start guam.service: Unit guam.service failed to load: No such file or directory."

    I kept going, but I will note that trying to start guam from the command line after the install generates the same output.

    This has been resolved in later versions of guam and pykolab (0.7.1 and 0.7.20 respectively).

    Second problem is that Kolab seems to expect imaps on port 993, but this entry in SERVICES section of cyrus.conf begs to differ:
    imaps cmd="imapd -s" listen="127.0.0.1:9993" prefork=5

    I changed the listen parameter to imaps (like it is on my other kolab installs) and moved on.

    It is guam that is intended to run on ports 143 and 993, and catch all IMAP connections from clients, in order to allow its logic to be applied.

    Finally, when I log into the web admin panel with the Directory Manager credentials, tabs where I should be able to add things like users, groups, roles, resources, etc. do not let me add anything. There are no users, and no form to add users. Same on the other tabs I mentioned. My best guess is that there is a database problem, a suspicion that was bolstered when I tried Roundcube and it told me it couldn't connect to the database. I'll look into that when I have more time.

    This is a problem we have not encountered, though. Are you certain localhost properly resolves?



  • @kanarip
    Do you have possibility to use Openldap instead of 389 DS?
    setup-kolas -with-openldap Setup configuration for OpenLDAP compatibility.
    I want to integrate kolab in exist Openldap server.


  • Global Moderator

    @Constin said:

    @kanarip
    Do you have possibility to use Openldap instead of 389 DS?
    setup-kolas -with-openldap Setup configuration for OpenLDAP compatibility.
    I want to integrate kolab in exist Openldap server.

    It's technically possible, but there's restrictions to what capabilities OpenLDAP can provide Kolab with, and we have certainly not automated the setup procedure for integration in to existing LDAP servers. As such, --with-openldap only sets /etc/kolab/kolab.conf configuration options (in the [ldap] section) that are better compatible for OpenLDAP. You will still have to provide the correct bind credentials, ensure the necessary ACLs and privileges (lookthrough, etc.) are associated with the entries, as well as put the appropriate schemas in place.

    The fastest way to set up Kolab with an OpenLDAP server is to set it up with 389 DS first, then strip off 389 DS and change the options to point to the correct LDAP server with the correct settings.

    The default kolab.conf file has more information on the exact workings of different settings and should be included as documentation with the packages you have installed. It is otherwise available in GIT.



  • webmail login

    Invalid request! No data was saved.

    [03-Feb-2016 13:23:35 Europe/Berlin] PHP Warning: stream_socket_client(): unable to connect to localhost:143 (Connection refused) in /usr/share/roundcubemail/program/lib/Roundcube/rcube_imap_generic.php on line 943
    [03-Feb-2016 12:23:35,859900 +0100]: <lj2114de> IMAP Error: Login failed for **@.com from 11.11.11.11. Could not connect to localhost:143: Connection refused in /usr/share/roundcubemail/program/lib/Roundcube/rcube_imap.php on line 193 (POST /webmail/?_task=login&_action=login)

    ahh ok , this is next step.
    Solution coming



  • @kanarip
    Thx
    Nice to hear it. i don't afraid to work with configs)



  • @kanarip
    I can't find the clamav-system-systemd package, and it shows up in the dependencies now for kolab-mta. However, there is a clamav-server-systemd package. Is that the same, and if so, should the kolab-mta dependency get updated? It's preventing a number of updates from installing.

    @Constin
    I was able to get Roundcube and kolab-webadmin to work once I made the database reference changes. Good catch, but I think the install needs to be fixed so that localhost works as originally designed.



  • @troycarpenter said:

    @Constin
    I was able to get Roundcube and kolab-webadmin to work once I made the database reference changes. Good catch, but I think the install needs to be fixed so that localhost works as originally designed.

    I think that's ok with in configs 127.0.0.1 , but i use this install only for test. I don't want to use it in production jet. Too many bugs during clear auto-installation from scratch is no good.

    Yes , we need to solve this problem with localhost. But i have good /etc/hosts

    [root@kolab ~]# cat /etc/hosts
    127.0.0.1 localhost LXC_NAME
    69.XXX.XXX.196 kolab.---.com kolab
    [root@kolab ~]# ping localhost
    PING localhost (127.0.0.1) 56(84) bytes of data.
    64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.020 ms
    

    and mysql conf too

    [root@kolab ~]# mysql -h 127.0.0.1 -u root -p
    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    Your MariaDB connection id is 54
    Server version: 5.5.44-MariaDB MariaDB Server
    
    Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    MariaDB [(none)]> select user,host from mysql.user;
    +-----------+----------------+
    | user      | host           |
    +-----------+----------------+
    | root      | 127.0.0.1      |
    | root      | ::1            |
    |           | kolab.hst4.com |
    | root      | kolab.hst4.com |
    |           | localhost      |
    | kolab     | localhost      |
    | root      | localhost      |
    | roundcube | localhost      |
    +-----------+----------------+
    8 rows in set (0.00 sec)
    
    MariaDB [(none)]> exit
    Bye
    [root@kolab ~]# mysql -h localhost -u root -p
    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    Your MariaDB connection id is 55
    Server version: 5.5.44-MariaDB MariaDB Server
    
    Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    MariaDB [(none)]> exit
    Bye
    
    [root@kolab ~]# mysql -h localhost -u kolab -p
    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    Your MariaDB connection id is 56
    Server version: 5.5.44-MariaDB MariaDB Server
    
    Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    MariaDB [(none)]>
    

  • Global Moderator

    @Constin You are clearly running in to problems that have to do more with the setup of your LXC chroot on steroids than they have to do with any number of bugs in Kolab.

    Let's not forget this release you are consuming is subject to continuous integration using Docker containers (higher quality steroids), running setup-kolab and suites of functional tests dozens of times a day, followed by full KVM and VirtualBox-based scrutiny by human beings.

    Let's not expect Kolab to fix every single aspect of an environment it runs in, when otherwise it runs in to trouble and/or fails.


Log in to reply