[Kolab-devel] Kolab 3.0 on Debian Wheezy: More Issues

Johannes Graumann johannes_graumann at web.de
Thu Sep 27 13:25:10 CEST 2012


Hi,

Jeroen van Meeuwen wrote:
> On Wednesday, September 26, 2012 04:26:31 PM Johannes Graumann wrote:
>> Hello,
>> 
>> Please find attached the output of my most recent attempt to run
>> PROMPT> setup-kolab --yes -d 9|tee setup-kolab.log
>> 
>> Here are my comments:
>> 1) The '--yes' argument to "setup-kolab" (see "--help") seems broken -
>> the program keeps asking for passwords and verification of domain names,
>> etc. Can you reproduce this? Should I report this as a bug against
>> pykolab/setup- kolab?
>> 
> 
> --yes should only work for yes/no questions (or
> pykolab.utils.ask_confirmation()). I reckon it doesn't work for the domain
> / root_dn questions, which should be relatively easy to fix.
For the kind of testing I'm doing it would really be helpfull to have an 
additional switch to just blow through the script accepting all the default 
strings

>> 2) Line 1-4, 6-9, 445-456
>> 
>> > Could not change the ownership of log file /var/log/kolab/pykolab.log
>> 
>> I have run
>> PROMPT> mkdir /var/log/kolab/ && touch /var/log/kolab/pykolab.log &&
>> chmod - R 777/var/log/kolab/
>> to try and remedy this - to no avail. How crucial is it and what user
>> actually is trying to execute the 'chown'?
>> 
> 
> We have an existing bug:
> 
>   https://bugzilla.kolabsys.com/show_bug.cgi?id=1037
> 
> The directory is supposed to be owned by the kolab user that Kolab daemons
> set their uid/gid to when started by root.
> 
> setup-kolab though starts as root, and does not set its ruid/rgid to
> kolab:kolab, and so attempts to correct the ownership of the log file
> /var/log/kolab/pykolab.log to the kolab:kolab user/group.
So why the error? Because at this stage kolab/kolab don't exist yet?

>> 3) Line 82ff
>> 
>> > Warning: Hostname kolab.<MYDOMAIN>.org is valid, but none of the IP
>> > addresses resolve back to kolab.<MYDOMAIN>.org
>> > address 127.0.0.1 resolves to host localhost
>> 
>> '/etc/hosts' actually reads '127.0.0.1 localhost
>> kolab.graumannschaft.org' - this is not good enough?
>> 
> 
> Therefore '127.0.0.1' does not resolve back to 'kolab.graumannshaft.org',
> but instead resolves back to 'localhost'.
> 
> pykolab attempts to get the system's hostname / fqdn / domain name using
> its 'socket' module;
> 
>   $ python -c 'import socket; print socket.getfqdn()'
>   albert.kolabsys.com
>   $ python -c 'import socket; print socket.gethostname()'
>   albert.kolabsys.com
> 
> This will (normally) poll for the IP address and DNS name on the first
> non- loopback interface.
> 
> It should suffice to add 'kolab.graumannshaft.org' with that external IP
> address to /etc/hosts, if you have no DNS infrastructure in which you
> could set an actual record (noted you would need to remove the FQDN from
> the 127.0.0.1 line as well).
> 
> Alternatively, switch the position of 'localhost' and
> 'kolab.graumannshaft.org' in /etc/hosts.
Thanks for your explanation. Easily taken care of.

>> 4) Line 422
>> 
>> > 2012-09-26 13:02:41,479 pykolab.setup WARNING Could not find the Kolab
>> > schema file
>> 
>> This seems serious and may cause the ultimate error below (7)). Note that
>> in the development wheezy repository kolab is not directly dependent on
>> kolab- schema, which has to be manually pulled in (I filed a bug for
>> that) - may that be related?
>> 
> 
> It is serious, and indeed causes 7).
> 
>> 5) Line 423
>> 
>> > 2012-09-26 13:02:41,479 pykolab.setup ERROR Could not start and
>> > configure to start on boot, the directory server service.
>> 
>> Also potentially bad. What is it actually trying to/supposed to do? What
>> file to edit?
>> 
> 
> At this part of the routine the necessary "service dirsrv restart" and
> "chkconfig dirsrv on" equivalent should be executed. Near line ~286 of
> pykolab/setup/setup_ldap.py is where this happens.
https://issues.kolab.org/show_bug.cgi?id=1052 with a proposed patch ...

>> 6) Line 457
>> 
>> > 2012-09-26 13:02:57,324 pykolab.auth WARNING Python LDAP library does
>> > not support persistent search
>> 
>> Is this significant?
>> 
> 
> It is somewhat significant - what version of python-ldap is installed?
The installed version is 2.4.10-1.

>> 7) Line 635ff
>> 
> 
> Related to 4) as you suspected.

Thanks for listening.

Sincerely, Joh




More information about the devel mailing list