upgrade to 2.2-rc2: uninitialized value $Kolab::config{"base_dn"}

[Johannes Graumann]

Gunnar Wrobel wrote:

> Johannes Graumann <johannes_graumann at web.de> writes:
> 
>> Tobias Oed wrote:
>>
>>> Johannes Graumann wrote:
>>>> Richard Bos wrote:
>>>> 
>>>>> Op Thursday 10 April 2008 10:30:45 schreef Johannes Graumann:
>>>>>> Hi,
>>>>>>
>>>>>> Any proposals on where to look to investigate this issue?
>>>>>>
>>>>>> Thanks, Joh
>>>>>>
>>>>>> Use of uninitialized value in concatenation (.) or string
>>>>>> at /kolab/lib/perl/vendor_perl/5.10.0/Kolab.pm line 170.
>>>>>> Password verification failed.
>>>>>> Use of uninitialized value $Kolab::config{"base_dn"} in concatenation
>>>>>> (.) or string at /kolab/lib/perl/vendor_perl/5.10.0/Kolab.pm line
>>>>>> 186. Use of uninitialized value $Kolab::config{"bind_dn"} in
>>>>>> concatenation (.) or string at
>>>>>> /kolab/lib/perl/vendor_perl/5.10.0/Kolab.pm line 200. fatal: Can't
>>>>>> read configuration, please make sure that kolabquotawarn runs with
>>>>>> sufficient privileges
>>>>> Have a look at the last line.  You should have a look at
>>>>> kolabquotawarn, which runs from cron, I believe every 10 minutes.
>>>> 
>>>> Thanks. This error seems to show up when in
>>>> /kolab/etc/kolab/kolabquotawarn this line of code is hit:
>>>> # my $quotawarnpct = $Kolab::config{'cyrus-quotawarn'};
>>>> 
>>>> This seems - to my amateurist understanding - to indicate,
>>>> that 'cyrus-quotawarn' isn't available. Indeed, if I issue 'grep -r
>>>> cyrus-quotawarn *' in /kolab/etc, I only get these returns:
>>>> kolab/kolab_bootstrap:        'cyrus-quotawarn' => 80,
>>>> kolab/kolabquotareport:my $quotawarnpct =
>>>> $Kolab::config{'cyrus-quotawarn'}; kolab/kolabquotawarn:my
>>>> $quotawarnpct = $Kolab::config{'cyrus-quotawarn'};
>>>> kolab/templates/imapd.conf.template:quotawarn:  @@@cyrus-quotawarn@@@
>>>> openldap/schema/kolab2.schema:  NAME 'cyrus-quotawarn'
>>>> openldap/schema/kolab2.schema:        cyrus-quotawarn $
>>>> 
>>>> and none of them I see as defining the parameter the script is trying
>>>> to access ... can anyone enlighten me as to what I'm overlooking or
>>>> where to define this parameter how?
>>>> 
>>>> Thanks, Joh
>>> 
>>> 
>>> 'cyrus-quotawarn' is set to it's default value at boostrap time with
>>> kolab/kolab_bootstrap: 'cyrus-quotawarn' => 80. This value gets stored
>>> in ldap. From there it goes into imapd.conf each time you run kolabconf.
>>> kolabquotawarn reads it from ldap each time it is run via the
>>> $Kolab::config('...') call.
>>> In your case this fails because the 'base_dn' apears to not be defined.
>>> This is where kolab starts its searches in ldap. It is defined at
>>> bootstrap time and stored in /kolab/etc/kolab/kolab.conf
>>> Paste the contents of this file here so we can debug.
>>> Tobias
>>
>> Thanks for your insight! I paste the <SANITIZED> content of kolab.conf
>> below. Does this look ok? The 'bind_pw_hash' and 'calendar_*' bits where
>> in my 2.1 conf, but not in the 2.2-rc2 template, so I'm not sure whether
>> to use them or no ...
>> A quick glance at the output of slapcat indeed shows 'cyrus-quotawarn:
>> 80' in the 'dn: k=kolab,dc=morannon,dc=homelinux,dc=org' entry.
>>
>> Thanks for your time.
>>
>> Joh
>>
>> fqdnhostname : morannon.homelinux.org
>> is_master : true
>> base_dn : dc=morannon,dc=homelinux,dc=org
>> bind_dn : cn=manager,cn=internal,dc=morannon,dc=homelinux,dc=org
>> bind_pw : <DON'T WANT TO TELL>
>> #bind_pw_hash : {SSHA}<NOT EITHER>
>> ldap_uri : ldap://127.0.0.1:389
>> ldap_master_uri : ldap://127.0.0.1:389
>> php_dn : cn=nobody,cn=internal,dc=morannon,dc=homelinux,dc=org
>> php_pw : <STILL NO>
>> slurpd_addr : 127.0.0.1
>> slurpd_port : 9999
>> # calendar_dn : cn=calendar,cn=internal,dc=morannon,dc=homelinux,dc=org
>> # calendar_pw : <TSTS, I REPEAT MYSELF>
> 
> Looks okay. Are the permissions on the file okay so that the quotawarn
> script can read the values?

As I answered to Alain above:
The messages seem now gone, since I
changed ownership of /kolab/etc/kolab/kolab.conf from kolab-n to kolab
(based on a comparisson with the backup of my former 2.1 setup). Does that
make sense?

Can you say something about the "bind_pw_hash"/ "calendar_*" entries? Are
they needed?

Thanks for your time, Joh