kolab 3.0 alpha error during setup-kolab

[Dirk Werner]

On 08/16/2012 11:01 AM, Dirk Werner wrote:
> On 08/15/2012 09:20 PM, Dirk Werner wrote:
>> On 08/15/2012 09:13 PM, Jeroen van Meeuwen wrote:
>>> On Wednesday, August 15, 2012 07:22:40 PM Dirk Werner wrote:
>>>> On 08/15/2012 06:49 PM, Jeroen van Meeuwen wrote:
>>>>> On Wednesday, August 15, 2012 06:03:44 PM Dirk Werner wrote:
>>>>>> There is no directory /etc/dirsrv/slapd-remote existing.
>>>>> Hi Dirk,
>>>>>
>>>>> could you run setup-kolab with -d 9 please, capturing the output?
>>>>>
>>>>> # setup-kolab -d 9 2>&1 | tee setup-kolab.log
>>>> Hi Jeroen,
>>>> this did go much further than the first try, it did hang at one point,
>>>> so I had to cancel the process. Here's the content of the file
>>>> setup-kolab.log:
>>>>
>>>> (...snip...)
>>>> Setup is now going to set up the 389 Directory Server. This may take a
>>>> little
>>>> while (during which period there is no output and no progress indication).
>>>>
>>>> 2012-08-15 19:08:17,138 pykolab.setup INFO Setting up 389 Directory Server
>>>> 2012-08-15 19:08:30,389 pykolab.setup DEBUG [2220]: Setup DS stdout:
>>>> 2012-08-15 19:08:30,391 pykolab.setup DEBUG [2220]: Creating directory
>>>> server . . .
>>>> Your new DS instance 'remote' was successfully created.
>>>> Creating the configuration directory server . . .
>>>> Error: failed to open an LDAP connection to host 'remote.airwerk.net'
>>>> port '389' as user 'cn=Directory Manager'.  Error: unknown.
>>> Here is a clue... though this is only stdout.
>>>
>>> Regrettably, the stdout output doesn't show the cause of the configuration 
>>> server failing to be bootstrapped.
>>>
>>> The rest of the output indicates to me that the processes completed 
>>> successfully, actually.
>>>
>>> Kind regards,
>>>
>>> Jeroen van Meeuwen
>>>
>> OK, I'll try to work with this installation tomorrow, many thanks for
>> your attention!
>> Dirk
> During setup-kolab, I had entered passwords for the specific parts of
> kolab, but I did not notify any information about certificate generation
> and I suspect they have not been created. The bootstrapping seems to
> have been done partially. I can logon to kolab-webadmin, I have created
> two users and logged into roundcubemail to try sharing their calendars.
> This failed cause mails don't go through. Shall I reinstall, can I
> provide more logging output? pykolab.log seems to be clean.
>
> _______________________________________________
> Kolab-users mailing list
> Kolab-users at kolab.org
> https://www.intevation.de/mailman/listinfo/kolab-users
There is an Ioerror in maillog - IOERROR: opening
/var/lib/imap/user_deny.db: No such file or directory

These are the last lines of maillog, looks not bad in my eyes:

Aug 16 11:00:03 remote imaps[7112]: login: localhost.localdomain
[127.0.0.1] werner.dirk at airwerk.net PLAIN+TLS User logged in
SESSIONID=<remote-7112-1345107603-1>
Aug 16 11:00:03 remote imaps[7112]: open: user werner^dirk at airwerk.net
opened Freebusy
Aug 16 11:00:03 remote imaps[7112]: open: user werner^dirk at airwerk.net
opened Calendar/Personal Calendar
Aug 16 11:00:03 remote imaps[7112]: open: user werner^dirk at airwerk.net
opened Calendar
Aug 16 11:00:03 remote imaps[7112]: USAGE werner^dirk at airwerk.net user:
0.011998 sys: 0.007999
Aug 16 11:00:03 remote imaps[7182]: accepted connection
Aug 16 11:00:03 remote imaps[7182]: SSL_accept() incomplete -> wait
Aug 16 11:00:03 remote imaps[7182]: SSL_accept() succeeded -> done
Aug 16 11:00:03 remote imaps[7182]: starttls: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits new) no authentication
Aug 16 11:00:03 remote imaps[7182]: ptload(): fetched cache record
(cyrus-admin)(mark 1345102998, current 1345107603, limit 1345096803)
Aug 16 11:00:03 remote imaps[7182]: ptload returning data
Aug 16 11:00:03 remote imaps[7182]: canonified cyrus-admin -> cyrus-admin
Aug 16 11:00:03 remote imaps[7182]: ptload(): fetched cache record
(werner.dirk at airwerk.net)(mark 1345102998, current 1345107603, limit
1345096803)
Aug 16 11:00:03 remote imaps[7182]: ptload returning data
Aug 16 11:00:03 remote imaps[7182]: canonified werner.dirk at airwerk.net
-> werner.dirk at airwerk.net
Aug 16 11:00:03 remote imaps[7182]: ptload(): fetched cache record
(cyrus-admin)(mark 1345102998, current 1345107603, limit 1345096803)
Aug 16 11:00:03 remote imaps[7182]: ptload returning data
Aug 16 11:00:03 remote imaps[7182]: using ptloaded value of: cyrus-admin
Aug 16 11:00:03 remote imaps[7182]: login: localhost.localdomain
[127.0.0.1] werner.dirk at airwerk.net PLAIN+TLS User logged in
SESSIONID=<remote-7182-1345107603-1>
Aug 16 11:00:03 remote imaps[7182]: open: user werner^dirk at airwerk.net
opened Freebusy
Aug 16 11:00:03 remote imaps[7182]: USAGE werner^dirk at airwerk.net user:
0.017998 sys: 0.009999
Aug 16 11:01:07 remote master[1936]: process 7184 exited, status 0
Aug 16 11:01:22 remote master[1936]: process 7112 exited, status 0
Aug 16 11:02:02 remote master[1936]: process 7182 exited, status 0
Aug 16 11:02:02 remote master[7207]: about to exec
/usr/lib/cyrus-imapd/imapd
Aug 16 11:02:02 remote imaps[7207]: executed
Aug 16 11:02:02 remote imaps[7207]: IOERROR: opening
/var/lib/imap/user_deny.db: No such file or directory
Aug 16 11:06:47 remote master[7215]: about to exec
/usr/lib/cyrus-imapd/ctl_cyrusdb
Aug 16 11:06:47 remote ctl_cyrusdb[7215]: checkpointing cyrus databases
Aug 16 11:06:47 remote ctl_cyrusdb[7215]: archiving database file:
/var/lib/imap/mailboxes.db
Aug 16 11:06:47 remote ctl_cyrusdb[7215]: archiving database file:
/var/lib/imap/annotations.db
Aug 16 11:06:47 remote ctl_cyrusdb[7215]: done checkpointing cyrus databases
Aug 16 11:06:47 remote master[1936]: process 7215 exited, status 0
Aug 16 11:07:03 remote clamd[2026]: SelfCheck: Database status OK.