Discussion:
setup-kolab gives misleading message (on Debian 8 Winterfell packages)
Alf B. Rustad
2016-05-22 18:50:22 UTC
Permalink
I set out to try the latest and greatest Kolab packages this week-end.
The install is done on a 64-bit Debian 8 using the Winterfell packages.
I had to rerun the setup-kolab script after I entered something wrong
the first time, and got this message:

It seems 389 Directory Server has an existing instance configured. This
setup
script does not intend to destroy or overwrite your data. Please make
sure
/etc/dirsrv/ and /var/lib/dirsrv/ are clean so that this setup does not
have to
worry.

Following the advice, I removed the content of those two folders to be
able to run the setup-kolab script again, but then I got this error
message:

Could not copy file '/etc/dirsrv/config/certmap.conf' to
'/etc/dirsrv/slapd-cloud/certmap.conf'. Error: No such file or directory

so it seems the first message is misleading, encouraging users to
remove a file that is a needed part of the 389-ds-base installation. I
suggest rephrasing the message, even a very generic message is better,
e.g.,

It seems 389 Directory Server has an existing instance configured. This
setup
script does not intend to destroy or overwrite your data. Please make
sure
/etc/dirsrv/ and /var/lib/dirsrv/ are in the same state as when the
direcotry server was installed so that this setup does not have to
worry.

Even better would be to include an option to clear the directory server
when running setup-kolab.

Almost forgot, thanks for an awesome software suite!
Timotheus Pokorra
2016-05-23 05:41:13 UTC
Permalink
Hello Alf,
Post by Alf B. Rustad
It seems 389 Directory Server has an existing instance configured. This
setup
script does not intend to destroy or overwrite your data. Please make sure
/etc/dirsrv/ and /var/lib/dirsrv/ are clean so that this setup does not have
to
worry.
Following the advice, I removed the content of those two folders to be able
Could not copy file '/etc/dirsrv/config/certmap.conf' to
'/etc/dirsrv/slapd-cloud/certmap.conf'. Error: No such file or directory
so it seems the first message is misleading, encouraging users to remove a
file that is a needed part of the 389-ds-base installation. I suggest
rephrasing the message, even a very generic message is better, e.g.,
Clean probably does not mean "deleted", but in the state how it was
before you configured the Kolab instance for the directory server.

This error message comes from the 389 Directory Server, as far as I can see.
I cannot find the error message in
https://git.kolab.org/diffusion/P/browse/master/pykolab/setup/setup_ldap.py

I think I remember I was told that you cannot re-run setup-kolab for
the directory server.
I usually do a full reinstall with this script:
https://github.com/TBits/KolabScripts/blob/master/kolab/reinstallCentOS.sh
Post by Alf B. Rustad
Even better would be to include an option to clear the directory server when
running setup-kolab.
Please file a feature request at
https://git.kolab.org/maniphest/task/edit/form/12/
Post by Alf B. Rustad
Almost forgot, thanks for an awesome software suite!
I am glad you are enjoying Kolab and you are experimenting with Winterfell!

Please note that Winterfell is the latest but not the greatest :) It
exists for testing purposes and development purposes, and is usually
not used in production.
But it is good that many in the community will try to break it because
the stable versions are derived from it!

All the best,
Timotheus
Alf B. Rustad
2016-05-24 14:13:06 UTC
Permalink
Hi Timotheus, thanks for caring :-)

It turns out that resetting the 389 Directory server was quite easy,
simply using the bundled remove-ds tool, like this:

remove-ds -i slapd-$HOSTNAME -a

I will consider submitting it as a suggestion to setup-kolab, if I am
able to confirm a successful setup. I was then able to get through the
setup, but with some error messages related to Postfix. When Postfix was
installed from packages, I was prompted, and opted, for "No
configuration". Do you know if I should go for the default "Internet
Site" option instead?

Then I discovered this one, with web-server not starting:

https://lists.kolabsys.com/pipermail/bugzilla/2015-February/022601.html

but a reboot of the server seems to get them started. I was able to
access the webadmin panel setting up my user. However, I cannot login on
roundcube due to guam not running:

# systemctl status guam
● guam.service - Intelligent IMAP Reverse Proxy
Loaded: loaded (/lib/systemd/system/guam.service; enabled)
Active: failed (Result: start-limit) since ti. 2016-05-24 16:08:28 CEST;
8min ago
Main PID: 1031 (code=exited, status=1/FAILURE)

mai 24 16:08:28 cloud systemd[1]: guam.service: main process exited,
code=exited, status=1/FAILURE
mai 24 16:08:28 cloud systemd[1]: Unit guam.service entered failed
state.
mai 24 16:08:28 cloud systemd[1]: guam.service start request repeated
too quickly, refusing to start.
mai 24 16:08:28 cloud systemd[1]: Failed to start Intelligent IMAP
Reverse Proxy.
mai 24 16:08:28 cloud systemd[1]: Unit guam.service entered failed
state.

At this point I have to admit that I am tempted to throw in the towel
and go for Kolab 16 on CentOS 7. However, it would really be cool to get
it up and running, so I will burn some more hours on it :-) Giving it a
new go with a fresh install as we speak.

Cheers,

Alf
Post by Timotheus Pokorra
Hello Alf,
Post by Alf B. Rustad
It seems 389 Directory Server has an existing instance configured. This
setup
script does not intend to destroy or overwrite your data. Please make sure
/etc/dirsrv/ and /var/lib/dirsrv/ are clean so that this setup does not have
to
worry.
Following the advice, I removed the content of those two folders to be able
Could not copy file '/etc/dirsrv/config/certmap.conf' to
'/etc/dirsrv/slapd-cloud/certmap.conf'. Error: No such file or directory
so it seems the first message is misleading, encouraging users to remove a
file that is a needed part of the 389-ds-base installation. I suggest
rephrasing the message, even a very generic message is better, e.g.,
Clean probably does not mean "deleted", but in the state how it was
before you configured the Kolab instance for the directory server.
This error message comes from the 389 Directory Server, as far as I can see.
I cannot find the error message in
https://git.kolab.org/diffusion/P/browse/master/pykolab/setup/setup_ldap.py
I think I remember I was told that you cannot re-run setup-kolab for
the directory server.
https://github.com/TBits/KolabScripts/blob/master/kolab/reinstallCentOS.sh
Post by Alf B. Rustad
Even better would be to include an option to clear the directory server when
running setup-kolab.
Please file a feature request at
https://git.kolab.org/maniphest/task/edit/form/12/
Post by Alf B. Rustad
Almost forgot, thanks for an awesome software suite!
I am glad you are enjoying Kolab and you are experimenting with Winterfell!
Please note that Winterfell is the latest but not the greatest :) It
exists for testing purposes and development purposes, and is usually
not used in production.
But it is good that many in the community will try to break it because
the stable versions are derived from it!
All the best,
Timotheus
_______________________________________________
users mailing list
https://lists.kolab.org/mailman/listinfo/users
Timotheus Pokorra
2016-05-25 14:28:21 UTC
Permalink
Hello Alf,
to confirm a successful setup. I was then able to get through the setup, but
with some error messages related to Postfix. When Postfix was installed from
packages, I was prompted, and opted, for "No configuration". Do you know if
I should go for the default "Internet Site" option instead?
I think that is what I used when I tested with Debian. But usually I
did install from script, and was not asked that question, if I
remember correctly. I have not worked with Kolab on Debian for a long
while.
At this point I have to admit that I am tempted to throw in the towel and go
for Kolab 16 on CentOS 7. However, it would really be cool to get it up and
running, so I will burn some more hours on it :-) Giving it a new go with a
fresh install as we speak.
The community of users who would like to run Kolab on Debian is quite big:
https://git.kolab.org/project/members/88/
If you can find solutions, many people would appreciate it.
Hopefully others will join you in actually fixing things for Kolab on Debian.
Perhaps start filing a bug in the Debian project on Phabricator, to
get people moving?

Timotheus

Loading...