Fresh 3.0 install on CentOS6.4: Calendar issues

[Johannes Graumann]

Johannes Graumann wrote:

> Johannes Graumann wrote:
> 
>> Johannes Graumann wrote:
>> 
>>> Hello,
>>> 
>>> I have a fresh install of kolab 3 setup and created a test user. I have
>>> started to explore the roundcube components and am running into problems
>>> with the calendar.
>>> 
>>> While "Agenda" and "Month" views seem fine, "Week" and "Day" views are
>>> broken and I am unable to create any events (grayed out,
>>> unresponsive button).
>>> 
>>> On selection of the calendar component, /var/log/roundcubemail/sql
>>> reports whats appended below. The logs otherwise seem uninformative to
>>> this newbie.
>> 
>> A second look reveals these:
>> 
>> httpd/error_log:[Tue Nov 12 12:35:47 2013] [error] [client 10.10.10.13]
>> PHP
>> Warning:  Invalid argument supplied for foreach() in /usr/share/
>> roundcubemail/plugins/calendar/calendar.php on line 518, referer:
>> https://mail.<MYSERVER>/?_task=settings&_action=edit-prefs&
>> _section=calendar&_framed=1
>> 
>> httpd/error_log:[Wed Nov 13 01:15:58 2013] [error] [client 10.10.10.13]
>> PHP
>> Warning:  syntax error, unexpected '=' in /usr/share/kolab-freeb
>> usy/config/config.ini on line 5\n in /usr/share/kolab-
>> freebusy/lib/Kolab/FreeBusy/Config.php on line 50
>> httpd/error_log:[Wed Nov 13 01:15:58 2013] [error] [client 10.10.10.13]
>> PHP
>> Fatal error:  Failed to parse configuration from /usr/share/kola
>> b-freebusy/config/config.ini in /usr/share/kolab-
>> freebusy/lib/Kolab/FreeBusy/Config.php on line 71
>> 
>> Line 51 in /usr/share/kolab-freebusy/config/config.ini reads:
>> bind_dn = uid=kolab-service,ou=Special Users,dc=graumannschaft,dc=org
> 
> I investigated the freebusy situation a little further and came across
> this:
> # kolab-freebusyd --generateall
> (02:23:30) authenticationjob.cpp(35):   logging in as  cyrus-admin  using
> kolab-freebusyd(917) KTcpSocket::showSslErrors: "The host name did not
> match any of the valid hosts for this certificate"
> kolab-freebusyd(917) KTcpSocket::showSslErrors: "The certificate is self-
> signed, and untrusted"
> Initial SSL handshake failed. cipher.isNull() is false , cipher.usedBits()
> is 256 , the socket says: "Unknown error" and the list of SSL errors
> contains 2 items.
> kolab-freebusyd(917) KIMAP::LoginJob::handleResponse: Capabilities
> updated: ("IMAP4rev1", "LITERAL+", "ID", "ENABLE", "ACL", "RIGHTS=kxte",
> "QUOTA", "MAILBOX-REFERRALS", "NAMESPACE", "UIDPLUS", "NO_ATOMIC_RENAME",
> "UNSELECT", "CHILDREN", "MULTIAPPEND", "BINARY", "CATENATE", "CONDSTORE",
> "ESEARCH", "SORT", "SORT=MODSEQ", "SORT=DISPLAY", "THREAD=ORDEREDSUBJECT",
> "THREAD=REFERENCES", "ANNOTATEMORE", "LIST-EXTENDED", "WITHIN", "QRESYNC",
> "SCAN", "XLIST", "URLAUTH", "URLAUTH=BINARY", "X-NETSCAPE", "AUTH=PLAIN",
> "AUTH=LOGIN", "SASL-IR", "COMPRESS=DEFLATE", "IDLE")
> kolab-freebusyd(917) KIMAP::LoginJobPrivate::sasl_interact: sasl_interact
> kolab-freebusyd(917) KIMAP::LoginJobPrivate::sasl_interact: SASL_INTERACT
> id: 16385
> kolab-freebusyd(917) KIMAP::LoginJobPrivate::sasl_interact: SASL_CB_[USER|
> AUTHNAME]: ' "cyrus-admin" '
> kolab-freebusyd(917) KIMAP::LoginJobPrivate::sasl_interact: SASL_INTERACT
> id: 16386
> kolab-freebusyd(917) KIMAP::LoginJobPrivate::sasl_interact: SASL_CB_[USER|
> AUTHNAME]: ' "cyrus-admin" '
> kolab-freebusyd(917) KIMAP::LoginJobPrivate::sasl_interact: SASL_INTERACT
> id: 16388
> kolab-freebusyd(917) KIMAP::LoginJobPrivate::sasl_interact: SASL_CB_PASS:
> [hidden]
> (02:23:34) authenticationjob.cpp(60):   Failed to login: Login failed,
> server replied: A000002 NO authentication failure
> kolab-freebusyd(917) SequentialCompositeJob::slotResult: Error:  "Failed
> to login: Login failed, server replied: A000002 NO authentication failure
> "
> (02:23:34) fbcoordinator.cpp(84):       Error while generating for all
> users:  Failed to login: Login failed, server replied: A000002 NO
> authentication failure
> (02:23:34) fbcoordinator.cpp(117):      All done. Total time elapsed [s]:
> 3.303
> 
> kolab 3 is running in an lxc-container and http/s is distributed to it via
> nginx (in another container).

Could it be that this is linked to the fact that I disregarded the advise to 
fix the FQDN BEFORE installation and only did so after?

Joh