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

[Gunnar Wrobel]

Johannes Graumann <johannes_graumann at web.de> writes:

> 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?

They are not needed on the newer server version.

Cheers,

Gunnar

>
> Thanks for your time, Joh
>
> _______________________________________________
> Kolab-users mailing list
> Kolab-users at kolab.org
> https://kolab.org/mailman/listinfo/kolab-users

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~