Re: Questions related to lib389 issue #1 cn=config

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2017-03-17 at 23:32 +0530, Ankit Yadav wrote:
> I think I finally found the issue, the problem is with my version of
> 389-ds-base,  my version of 389-ds-base is
> 389-ds-base-1.3.5.15-1.fc25.x86_64. Because of this the defaults.inf file
> of my version has some keys missing in section "slapd"
> and hence I am getting the error :
> 
> 
> ===================== error start ===================
> E           NoOptionError: No option 'pid_file' in section: 'slapd'
> 
> /usr/lib64/python2.7/ConfigParser.py:618: NoOptionError
> =======================error end ==================

So if you want, raise a bug in pagure for 389-ds-base about the missing
values on 1.3.5.

What you could try is my copr repo that I try to keep up to date for
1.3.6. (git master) 

https://copr.fedoraproject.org/coprs/firstyear/ds/


> 
> *Contents of my defaults.inf files are:*
> 
> ; --- BEGIN COPYRIGHT BLOCK ---
> ; Copyright (C) 2016 Red Hat, Inc.
> ; All rights reserved.
> ;
> ; License: GPL (version 3 or any later version).
> ; See LICENSE for details.
> ; --- END COPYRIGHT BLOCK ---
> 
> ; Author: firstyear at redhat.com
> 
> ; This is a set of default paths that tools consuming DS should search
> ; for paths. This is the foundation of the version 2 ds setup inf
> ;
> ; All format strings should be in python syntax IE {key}
> 
> [slapd]
> ; These values should NOT be altered in an installation.
> ; This is because the server itself depends on these locations and values
> ; being known, and are set at compilation time.
> product = 389 Directory Server
> version = 1.3.5.15
> asan_enabled = 0
> prefix = /usr
> bin_dir = /usr/bin
> sbin_dir = /usr/sbin
> lib_dir = /usr/lib64
> data_dir = /usr/share
> tmp_dir = /tmp
> sysconf_dir = /etc
> initconfig_dir = /etc/sysconfig
> config_dir = /etc/dirsrv/slapd-{instance_name}
> local_state_dir = /var
> run_dir = /var/run/dirsrv
> plugin_dir = /usr/lib64/dirsrv/plugins
> 
> ; These values can be altered in an installation of ds
> user = dirsrv
> group = dirsrv
> root_dn = cn=Directory Manager
> 
> schema_dir = /etc/dirsrv/slapd-{instance_name}/schema
> cert_dir = /etc/dirsrv/slapd-{instance_name}
> 
> lock_dir = /var/lock/dirsrv/slapd-{instance_name}
> log_dir = /var/log/dirsrv/slapd-{instance_name}
> inst_dir = /var/lib/dirsrv/slapd-{instance_name}
> db_dir = /var/lib/dirsrv/slapd-{instance_name}/db
> backup_dir = /var/lib/dirsrv/slapd-{instance_name}/bak
> ldif_dir = /var/lib/dirsrv/slapd-{instance_name}/ldif
> 
> 
> After reading this file the error is obvious.
> 
> I tried to find the latest version (1.3.6) of 389--ds-base but was unable
> to find. Then I asked about this on IRC, got to know from one member that
> latest version is not available for fedora 25.
> If my conclusions are right then what to do in that case?
> 
> 
> Regards,
> Ankit yadav
> 
> On 16 March 2017 at 23:20, Ankit Yadav <ankitwrk@xxxxxxxxx> wrote:
> 
> > After reinstalling the 389-ds-base I realized that the same error I* am
> > getting even if I don't setup the 389-ds-base using setup-ds-admin.pl
> > <http://setup-ds-admin.pl>*
> > So conclusion from above statement is When I install 389-ds-base then I do
> > setup using this ==> "setup-ds-admin.pl" then I am getting the error
> > mentioned in previous mail. And when I just install 389-ds-base and don't
> > do the setup then also I am getting the error mentioned in previous mail
> > error.
> >
> > Getting same error before and after Setting up the 389-ds-base using "
> > setup-ds-admin.pl" means there is something wrong with my setup of
> > 389-ds-base.
> >
> > *Steps I follow to setup 389-ds-base  :*
> >
> > 1. Installed 389-ds-base using *sudo dnf install "389*"*
> > 2. setup 389-ds-base using *sudo* *setup-ds-admin.pl
> > <http://setup-ds-admin.pl>*
> >
> > Are these the only steps required to setup the 389-ds-base?
> > If the above steps are not sufficient then let me know how to setup it on
> > fedora 25.
> >
> > Regards,
> > Ankit Yadav.
> >
> > On 16 March 2017 at 12:46, Ankit Yadav <ankitwrk@xxxxxxxxx> wrote:
> >
> >> I am again getting same error
> >> Steps I followed:
> >>
> >> step 1 : cleaned every instance using remove-ds-admin.pl
> >>
> >> step 2: Removed 389-ds-base.
> >>
> >> step  3: Installed 389-ds-base using ==> sudo dnf install "389*"
> >>
> >> step 4: Setup 389-ds-base using "sudo setup-ds-admin.pl"
> >>
> >> step 5: Tried this command in updated lib389 repo ==>
> >>
> >> sudo PYTHONPATH=`pwd` py.test -s lib389/tests/cli/conf_backend.py
> >>
> >> step 6: Got some INFO logs and and 2 errors
> >>
> >> Errors:
> >> This error two times:
> >>
> >> *==================== error start =======================*
> >> *self = <ConfigParser.SafeConfigParser instance at 0x7efc0bcfe7e8>,
> >> section = 'slapd'*
> >> *option = 'pid_file', raw = False, vars = None*
> >>
> >> *    def get(self, section, option, raw=False, vars=None):*
> >> *        """Get an option value for a given section.*
> >>
> >> *            If `vars' is provided, it must be a dictionary. The option
> >> is looked up*
> >> *            in `vars' (if provided), `section', and in `defaults' in
> >> that order.*
> >>
> >> *            All % interpolations are expanded in the return values,
> >> unless the*
> >> *            optional argument `raw' is true. Values for interpolation
> >> keys are*
> >> *            looked up in the same manner as the option.*
> >>
> >> *            The section DEFAULT is special.*
> >> *            """*
> >> *        sectiondict = {}*
> >> *        try:*
> >> *            sectiondict = self._sections[section]*
> >> *        except KeyError:*
> >> *            if section != DEFAULTSECT:*
> >> *                raise NoSectionError(section)*
> >> *        # Update with the entry specific variables*
> >> *        vardict = {}*
> >> *        if vars:*
> >> *            for key, value in vars.items():*
> >> *                vardict[self.optionxform(key)] = value*
> >> *        d = _Chainmap(vardict, sectiondict, self._defaults)*
> >> *        option = self.optionxform(option)*
> >> *        try:*
> >> *            value = d[option]*
> >> *        except KeyError:*
> >> *>           raise NoOptionError(option, section)*
> >> *E           NoOptionError: No option 'pid_file' in section: 'slapd'*
> >>
> >> */usr/lib64/python2.7/ConfigParser.py:618: NoOptionError*
> >> *==================== error ends ====================*
> >>
> >> After removing all the instances this is what I am getting every time.
> >> What could be the possible reason for this error?
> >>
> >> Regards,
> >> Ankit Yadav.
> >>
> >>
> >>
> >>
> >> On 16 March 2017 at 12:18, Ankit Yadav <ankitwrk@xxxxxxxxx> wrote:
> >>
> >>>
> >>> Sorry I was travelling so was unable to try that.
> >>>
> >>> I have tried this command several times. Then I got a error like this:
> >>>
> >>> >         except KeyError:
> >>> > >           raise NoOptionError(option, section)
> >>> > E           NoOptionError: No option 'pid_file' in section: 'slapd'
> >>>
> >>> This shows my 389-ds-base is not installed properly so,
> >>> I have purged all the ds instances.
> >>> Now I am reinstalling the 389-ds-base and then try once again.
> >>>
> >>> I will update you about this once I am done.
> >>>
> >>> Regards,
> >>> Ankit Yadav.
> >>>
> >>>
> >>>
> >>>
> >>> On 15 March 2017 at 13:48, William Brown <wibrown@xxxxxxxxxx> wrote:
> >>>
> >>>> On Wed, 2017-03-15 at 12:50 +0530, Ankit Yadav wrote:
> >>>> > I have uninstalled that package.
> >>>> > There were some issues with my installation but now I am getting some
> >>>> > different errors.
> >>>> >
> >>>>
> >>>> That means you already have the instance of that name: The error is
> >>>> still a bit rough.
> >>>>
> >>>> Try:
> >>>>
> >>>> sudo /sbin/remove-ds.pl -i slapd-standalone
> >>>>
> >>>> Then run the test again.
> >>>>
> >>>> --
> >>>> Sincerely,
> >>>>
> >>>> William Brown
> >>>> Software Engineer
> >>>> Red Hat, Australia/Brisbane
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> >>>> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> >>>>
> >>>>
> >>>
> >>
> >
> _______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Directory Announce]     [Fedora Users]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Review]     [Fedora Art]     [Fedora Music]     [Fedora Packaging]     [CentOS]     [Fedora SELinux]     [Big List of Linux Books]     [KDE Users]     [Fedora Art]     [Fedora Docs]

  Powered by Linux