Questions related to lib389 issue #1 cn=config

[Ankit Yadav]

Hello Everyone,

I am currently working on one of the issue of lib389 issue #1 cn=config. Below are some
steps that I did to help myself and a question related to these steps.

lib389 issue #1 Description: 
Once we have enough plugin and index code, we should be able to use dsconf to compare the
state of two instances. This will let us check for differing plugin, index, configuration
values between two servers.
Additionally, we would be able to mask "known different" values, such as fs
paths, hostnames, etc.
This will help in migrations and upgrades of DS.

I have an instance of 389-ds installed with this configuration:

computer name = local.com
system user = dirsrv
system group = dirsrv
network port = 389
directory server identifier = local
suffix dc=local
cn = Directory Manager

To see configuration of server I tried this command : $ ldapsearch -H ldap:// -x -s base
-b "" -LLL "+"

I got this output: 

dn:
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config
createTimestamp: 20170313052148Z
modifyTimestamp: 20170313052148Z
nsUniqueId: f4bebe00-07ac11e7-80000000-00000000
namingContexts: dc=local
nsBackendSuffix: userRoot:dc=local
subschemaSubentry: cn=schema
supportedExtension: 2.16.840.1.113730.3.5.7
supportedExtension: 2.16.840.1.113730.3.5.8
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 2.16.840.1.113730.3.5.3
supportedExtension: 2.16.840.1.113730.3.5.12
supportedExtension: 2.16.840.1.113730.3.5.5
supportedExtension: 2.16.840.1.113730.3.5.6
supportedExtension: 2.16.840.1.113730.3.5.9
supportedExtension: 2.16.840.1.113730.3.5.4
supportedExtension: 2.16.840.1.113730.3.6.5
supportedExtension: 2.16.840.1.113730.3.6.6
supportedExtension: 2.16.840.1.113730.3.6.7
supportedExtension: 2.16.840.1.113730.3.6.8
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 2.16.840.1.113730.3.4.3
supportedControl: 2.16.840.1.113730.3.4.4
supportedControl: 2.16.840.1.113730.3.4.5
supportedControl: 1.2.840.113556.1.4.473
supportedControl: 2.16.840.1.113730.3.4.9
supportedControl: 2.16.840.1.113730.3.4.16
supportedControl: 2.16.840.1.113730.3.4.15
supportedControl: 2.16.840.1.113730.3.4.17
supportedControl: 2.16.840.1.113730.3.4.19
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8
supportedControl: 1.3.6.1.4.1.4203.666.5.16
supportedControl: 2.16.840.1.113730.3.4.14
supportedControl: 2.16.840.1.113730.3.4.20
supportedControl: 1.3.6.1.4.1.1466.29539.12
supportedControl: 2.16.840.1.113730.3.4.12
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.13
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: SCRAM-SHA-1
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: ANONYMOUS
supportedLDAPVersion: 2
supportedLDAPVersion: 3
vendorName: 389 Project
vendorVersion: 389-Directory/1.3.5.15 B2016.308.2026

Are the above attributes and those configuration attributes which we are trying to compare
in this issue are same?

[William Brown]

On Mon, 2017-03-13 at 06:06 +0000, Ankit Yadav wrote:
>  Hello Everyone,
>  
>  I am currently working on one of the issue of lib389 issue #1 cn=config. Below are some
> steps that I did to help myself and a question related to these steps.
>  
>  lib389 issue #1 Description: 
>  Once we have enough plugin and index code, we should be able to use dsconf to compare the
> state of two instances. This will let us check for differing plugin, index, configuration
> values between two servers.
>  Additionally, we would be able to mask "known different" values, such as fs
> paths, hostnames, etc.
>  This will help in migrations and upgrades of DS.
>  
>  I have an instance of 389-ds installed with this configuration:
>  
>  computer name = local.com
>  system user = dirsrv
>  system group = dirsrv
>  network port = 389
>  directory server identifier = local
>  suffix dc=local
>  cn = Directory Manager
>  
>  To see configuration of server I tried this command : $ ldapsearch -H ldap:// -x -s base
> -b "" -LLL "+"
>  
>  I got this output: 
>  
>  dn:
>  creatorsName: cn=server,cn=plugins,cn=config
>  modifiersName: cn=server,cn=plugins,cn=config
>  createTimestamp: 20170313052148Z
>  modifyTimestamp: 20170313052148Z
>  nsUniqueId: f4bebe00-07ac11e7-80000000-00000000
>  namingContexts: dc=local
>  nsBackendSuffix: userRoot:dc=local
>  subschemaSubentry: cn=schema
>  supportedExtension: 2.16.840.1.113730.3.5.7
>  supportedExtension: 2.16.840.1.113730.3.5.8
>  supportedExtension: 1.3.6.1.4.1.4203.1.11.3
>  supportedExtension: 2.16.840.1.113730.3.5.3
>  supportedExtension: 2.16.840.1.113730.3.5.12
>  supportedExtension: 2.16.840.1.113730.3.5.5
>  supportedExtension: 2.16.840.1.113730.3.5.6
>  supportedExtension: 2.16.840.1.113730.3.5.9
>  supportedExtension: 2.16.840.1.113730.3.5.4
>  supportedExtension: 2.16.840.1.113730.3.6.5
>  supportedExtension: 2.16.840.1.113730.3.6.6
>  supportedExtension: 2.16.840.1.113730.3.6.7
>  supportedExtension: 2.16.840.1.113730.3.6.8
>  supportedExtension: 1.3.6.1.4.1.4203.1.11.1
>  supportedControl: 2.16.840.1.113730.3.4.2
>  supportedControl: 2.16.840.1.113730.3.4.3
>  supportedControl: 2.16.840.1.113730.3.4.4
>  supportedControl: 2.16.840.1.113730.3.4.5
>  supportedControl: 1.2.840.113556.1.4.473
>  supportedControl: 2.16.840.1.113730.3.4.9
>  supportedControl: 2.16.840.1.113730.3.4.16
>  supportedControl: 2.16.840.1.113730.3.4.15
>  supportedControl: 2.16.840.1.113730.3.4.17
>  supportedControl: 2.16.840.1.113730.3.4.19
>  supportedControl: 1.3.6.1.1.13.1
>  supportedControl: 1.3.6.1.1.13.2
>  supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1
>  supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2
>  supportedControl: 1.2.840.113556.1.4.319
>  supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8
>  supportedControl: 1.3.6.1.4.1.4203.666.5.16
>  supportedControl: 2.16.840.1.113730.3.4.14
>  supportedControl: 2.16.840.1.113730.3.4.20
>  supportedControl: 1.3.6.1.4.1.1466.29539.12
>  supportedControl: 2.16.840.1.113730.3.4.12
>  supportedControl: 2.16.840.1.113730.3.4.18
>  supportedControl: 2.16.840.1.113730.3.4.13
>  supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
>  supportedSASLMechanisms: EXTERNAL
>  supportedSASLMechanisms: SCRAM-SHA-1
>  supportedSASLMechanisms: GSS-SPNEGO
>  supportedSASLMechanisms: GSSAPI
>  supportedSASLMechanisms: DIGEST-MD5
>  supportedSASLMechanisms: CRAM-MD5
>  supportedSASLMechanisms: PLAIN
>  supportedSASLMechanisms: LOGIN
>  supportedSASLMechanisms: ANONYMOUS
>  supportedLDAPVersion: 2
>  supportedLDAPVersion: 3
>  vendorName: 389 Project
>  vendorVersion: 389-Directory/1.3.5.15 B2016.308.2026
>  
>  Are the above attributes and those configuration attributes which we are trying to
> compare in this issue are same? 
This output you are seeing is the rootDSE: It describes the features and
supported components of the server.

You will eventually be looking at cn=config, but for now your first
check to make the comparison work should be looking at objects from
lib389/idm/group.py for example. Make two groups in dc=example,dc=com,
then compare them.

You'll need a reproducable environment, so first, look at creating a
py.test case in lib389/tests/, and getting that to work, to build and
tear down an instance. We have plenty of examples in that folder of how
to do this. 

From there you can create the groups, then work on the comparison. 

I hope that helps you, 


>  
>  Sincerely,
>  
>  William Brown
>  Software Engineer
>  Red Hat, Australia/Brisbane
>

[Ankit Yadav]

I tried to run test cases got this output:

5 failed, 28 passed, 42 error in 101.93 seconds

obviously the output was quite long above line is just the summary.

detailed output is here
https://drive.google.com/open?id=1fbNXTH_tTjHwdl6ZWE_-4QsnOzI8J97oGxr0KZm...

Is this normal or there is something wrong with my setup.

One more question there was an error I was getting when I first tried to run tests. the
error was  /lib389/__init__.py  line number 526.
Is this really a issue or it was just my machine.

[Ankit Yadav]

I solved the error in /lib389/__init__.py  line number 526 was 

this code ==>  self.inst = self.serverid at line 526 was above this code ==> 
self.serverid = args.get(SER_SERVERID_PROP, None). Now here we someone has tried to assign
self.serverid to self.inst before self.serverid has been assigned from agrs.

I moved the assignment ==> self.inst = self.serverid below where the serverid was
assigned from args. This is how I solved the first error.
Now I am getting some other errors don't know how to resolve them below.

Now I am unable to setup and teardown because there is one error 

self = <ConfigParser.SafeConfigParser instance at 0x7f90c4b09248>, section =
'slapd'
option = 'error_log', 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 'error_log' in section: 'slapd'

/usr/lib64/python2.7/ConfigParser.py:618: NoOptionError

This error is coming in 42 test cases.
test summary ==>  5 failed, 28 passed, 42 error in 101.93 seconds

[William Brown]

On Tue, 2017-03-14 at 13:32 +0000, Ankit Yadav wrote:
>  I solved the error in /lib389/__init__.py  line number 526 was 
>  
>  this code ==>  self.inst = self.serverid at line 526 was above this code ==> 
> self.serverid = args.get(SER_SERVERID_PROP, None). Now here we someone has tried to assign
> self.serverid to self.inst before self.serverid has been assigned from agrs.
>   
Can you send me the output of 

rpm -qa | grep lib389

and what the command line to run the tests is you are using?

I find that the best way is:

yum install "389*"
git clone .../lib389.git
cd lib389
sudo PYTHONPATH=`pwd` py.test -s lib389/<test name>

IE:

{william@ldapkdc 10:56} ~/development/389ds/lib389 I0> sudo
PYTHONPATH=`pwd` py.test -s lib389/tests/aci_test.py 
===============================================================================================
test session starts
===============================================================================================
platform linux2 -- Python 2.7.5 -- py-1.4.27 -- pytest-2.7.0
rootdir: /home/william/development/389ds/lib389, inifile: 
collected 2 items 

lib389/tests/aci_test.py OK group dirsrv exists
OK user dirsrv exists
{'allow': [{'values': ['read', 'search',
'write']}], 'target': [],
'targetattr': [{'values': ['uniqueMember', 'member'],
'equal': True}],
'targattrfilters': [], 'deny': [], 'acl': [{'values':
['Allow test
aci']}], 'deny_raw_bindrules': [], 'targetattrfilters': [],
'allow_raw_bindrules': [{'values':
['userdn="ldap:///dc=example,dc=com??sub?(ou=engineering)" and
userdn="ldap:///dc=example,dc=com??sub?(manager=uid=wbrown,ou=managers,dc=example,dc=com)
|| ldap:///dc=example,dc=com??sub?(manager=uid=tbrown,ou=managers,dc=example,dc=com)"
']}], 'targetfilter': [{'values': ['(ou=groups)'],
'equal': True}], 'targetscope': [], 'version 3.0;': [],
'rawaci': '(targetfilter ="(ou=groups)")(targetattr
="uniqueMember || member")(version 3.0; acl "Allow test aci";allow
(read, search, write)(userdn="ldap:///dc=example,dc=com??sub?(ou=engineering)"
and
userdn="ldap:///dc=example,dc=com??sub?(manager=uid=wbrown,ou=managers,dc=example,dc=com)
|| ldap:///dc=example,dc=com??sub?(manager=uid=tbrown,ou=managers,dc=example,dc=com)"
);)'}
..Instance slapd-standalone removed.


============================================================================================
2 passed in 7.90 seconds


I don't expect you to be able to run the full test suite, just target
the ones you are working on. In this case the cli tests in:

lib389/tests/cli/

IE

sudo PYTHONPATH=`pwd` py.test -s lib389/tests/cli/conf_backend.py



>  I moved the assignment ==> self.inst = self.serverid below where
> the serverid was assigned from args. This is how I solved the first error.
>  Now I am getting some other errors don't know how to resolve them below.
>  
>  Now I am unable to setup and teardown because there is one error 
>  
>  self = <ConfigParser.SafeConfigParser instance at 0x7f90c4b09248>, section =
> 'slapd'
>  option = 'error_log', 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 'error_log' in section: 'slapd'
>  
>  /usr/lib64/python2.7/ConfigParser.py:618: NoOptionError
>  
>  This error is coming in 42 test cases.
>  test summary ==>  5 failed, 28 passed, 42 error in 101.93 seconds
>   
>  _______________________________________________
>  389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org 
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

[Ankit Yadav]

output of rpm -qa | grep lib389 ==> python-lib389-1.0.2-3.fc25.noarch 

I followed your steps mentioned above but got the same error while running  ==> sudo
PYTHONPATH=`pwd` py.test -s lib389/tests/cli/conf_backend.py.
Then I cloned the latest lib389-master and build the rpm, installed both rpm python2 as
well as python3, still got the same error while running ==> sudo PYTHONPATH=`pwd`
py.test -s lib389/tests/cli/conf_backend.py

To describe the error I have copy pasted the terminal output 

***********************************************************Terminal text starts here
***************************************************************

➜  lib389 git:(ankit) sudo PYTHONPATH=`pwd` py.test -s lib389/tests/cli/conf_backend.py
[sudo] password for ankit: 
==================================================================================== test
session starts
=====================================================================================
platform linux2 -- Python 2.7.13, pytest-2.9.2, py-1.4.32, pluggy-0.3.1
rootdir: /home/ankit/projects/lib389, inifile: 
collected 1 items 

lib389/tests/cli/conf_backend.py DEBUG:lib389:Instance allocated
INFO:lib389:Allocate <class 'lib389.DirSrv'> with localhost:54321
INFO:lib389:Allocate <class 'lib389.DirSrv'> with localhost:54321
INFO:lib389:dir (sys) : /etc/sysconfig
INFO:lib389:dir (priv): /root/.dirsrv
INFO:lib389:List from /root/.dirsrv
INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv',
'SERVER_ID': 'standalone', 'hostname':
'localhost.localdomain', 'ldap-port': 54321, 'ldap-secureport':
None, 'ldapi_autobind': None, 'DS_ROOT': '',
'deployed-dir': '/usr', 'INST_DIR':
'/var/lib/dirsrv/slapd-standalone', 'SERVER_DIR': '/usr/lib64',
'server-id': 'standalone', 'ldapi_enabled': None,
'ldapi_socket': None, 'SERVERBIN_DIR': '/usr/sbin',
'root-dn': 'cn=Directory Manager', 'user-id': 'dirsrv',
'CONFIG_DIR': '/etc/dirsrv/slapd-standalone', 'PRODUCT_NAME':
'slapd', 'suffix': None}

INFO:lib389:dir (sys) : /etc/sysconfig
INFO:lib389:dir (priv): /root/.dirsrv
INFO:lib389:List from /root/.dirsrv
INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv',
'SERVER_ID': 'local', 'hostname': 'local.com',
'ldap-port': 389, 'ldap-secureport': None, 'ldapi_autobind':
'off', 'DS_ROOT': '', 'deployed-dir': '/usr',
'INST_DIR': '/usr/lib64/dirsrv/slapd-local', 'SERVER_DIR':
'/usr/lib64/dirsrv', 'server-id': 'local',
'ldapi_enabled': 'off', 'ldapi_socket':
'/var/run/slapd-local.socket', 'SERVERBIN_DIR': '/usr/sbin',
'root-dn': 'cn=Directory Manager', 'user-id': 'dirsrv',
'CONFIG_DIR': '/etc/dirsrv/slapd-local', 'PRODUCT_NAME':
'slapd', 'suffix': 'dc=local'}

INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv',
'SERVER_ID': 'standalone2', 'hostname': 'localhost',
'ldap-port': 54322, 'ldap-secureport': None, 'ldapi_autobind':
'off', 'DS_ROOT': '', 'deployed-dir': '/usr',
'INST_DIR': '/usr/lib64/dirsrv/slapd-standalone2', 'SERVER_DIR':
'/usr/lib64/dirsrv', 'server-id': 'standalone2',
'ldapi_enabled': 'off', 'ldapi_socket':
'/var/run/slapd-standalone2.socket', 'SERVERBIN_DIR': '/usr/sbin',
'root-dn': 'cn=Directory Manager', 'user-id': 'dirsrv',
'CONFIG_DIR': '/etc/dirsrv/slapd-standalone2', 'PRODUCT_NAME':
'slapd', 'suffix': 'dc=example,dc=com'}

INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv',
'SERVER_ID': 'standalone_1', 'hostname':
'localhost.localdomain', 'ldap-port': 38901, 'ldap-secureport':
None, 'ldapi_autobind': None, 'DS_ROOT': '',
'deployed-dir': '/usr', 'INST_DIR':
'/var/lib/dirsrv/slapd-standalone_1', 'SERVER_DIR': '/usr/lib64',
'server-id': 'standalone_1', 'ldapi_enabled': None,
'ldapi_socket': None, 'SERVERBIN_DIR': '/usr/sbin',
'root-dn': 'cn=Directory Manager', 'user-id': 'dirsrv',
'CONFIG_DIR': '/etc/dirsrv/slapd-standalone_1', 'PRODUCT_NAME':
'slapd', 'suffix': None}

INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv',
'SERVER_ID': 'standalone', 'hostname':
'localhost.localdomain', 'ldap-port': 54321, 'ldap-secureport':
None, 'ldapi_autobind': None, 'DS_ROOT': '',
'deployed-dir': '/usr', 'INST_DIR':
'/var/lib/dirsrv/slapd-standalone', 'SERVER_DIR': '/usr/lib64',
'server-id': 'standalone', 'ldapi_enabled': None,
'ldapi_socket': None, 'SERVERBIN_DIR': '/usr/sbin',
'root-dn': 'cn=Directory Manager', 'user-id': 'dirsrv',
'CONFIG_DIR': '/etc/dirsrv/slapd-standalone', 'PRODUCT_NAME':
'slapd', 'suffix': None}

INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv',
'SERVER_ID': 'master', 'hostname': 'localhost',
'ldap-port': 40389, 'ldap-secureport': None, 'ldapi_autobind':
'off', 'DS_ROOT': '', 'deployed-dir': '/usr',
'INST_DIR': '/usr/lib64/dirsrv/slapd-master', 'SERVER_DIR':
'/usr/lib64/dirsrv', 'server-id': 'master',
'ldapi_enabled': 'off', 'ldapi_socket':
'/var/run/slapd-master.socket', 'SERVERBIN_DIR': '/usr/sbin',
'root-dn': 'cn=Directory Manager', 'user-id': 'dirsrv',
'CONFIG_DIR': '/etc/dirsrv/slapd-master', 'PRODUCT_NAME':
'slapd', 'suffix': 'dc=example,dc=com'}

INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv',
'SERVER_ID': 'localhost', 'DS_ROOT': '',
'deployed-dir': '/usr', 'INST_DIR':
'/usr/lib64/dirsrv/slapd-localhost', 'SERVER_DIR':
'/usr/lib64/dirsrv', 'server-id': 'localhost',
'SERVERBIN_DIR': '/usr/sbin', 'CONFIG_DIR':
'/etc/dirsrv/slapd-localhost', 'PRODUCT_NAME': 'slapd'}

INFO:lib389:dir (sys) : /etc/sysconfig
INFO:lib389:dir (priv): /root/.dirsrv
INFO:lib389:List from /root/.dirsrv
INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv',
'SERVER_ID': 'standalone', 'hostname':
'localhost.localdomain', 'ldap-port': 54321, 'ldap-secureport':
None, 'ldapi_autobind': None, 'DS_ROOT': '',
'deployed-dir': '/usr', 'INST_DIR':
'/var/lib/dirsrv/slapd-standalone', 'SERVER_DIR': '/usr/lib64',
'server-id': 'standalone', 'ldapi_enabled': None,
'ldapi_socket': None, 'SERVERBIN_DIR': '/usr/sbin',
'root-dn': 'cn=Directory Manager', 'user-id': 'dirsrv',
'CONFIG_DIR': '/etc/dirsrv/slapd-standalone', 'PRODUCT_NAME':
'slapd', 'suffix': None}

DEBUG:lib389:running: /usr/sbin/remove-ds.pl -i slapd-standalone 
Instance slapd-standalone removed.
INFO:LogCapture.SetupDs:Running setup with verbose
INFO:LogCapture.SetupDs:READY: preparing installation for standalone
INFO:LogCapture.SetupDs:PASSED: using config settings 999999999
INFO:LogCapture.SetupDs:PASSED: user / group checking
INFO:LogCapture.SetupDs:PASSED: Hostname strict checking
INFO:LogCapture.SetupDs:PASSED: prefix checking
INFO:lib389:dir (sys) : /etc/sysconfig
INFO:lib389:dir (priv): /root/.dirsrv
INFO:LogCapture.SetupDs:PASSED: instance checking
INFO:LogCapture.SetupDs:PASSED: root user checking
INFO:LogCapture.SetupDs:PASSED: network avaliability checking
INFO:LogCapture.SetupDs:READY: beginning installation for standalone
INFO:LogCapture.SetupDs:ACTION: creating /var/lib/dirsrv/slapd-standalone/bak
INFO:LogCapture.SetupDs:ACTION: creating /etc/dirsrv/slapd-standalone
INFO:LogCapture.SetupDs:ACTION: creating /etc/dirsrv/slapd-standalone
INFO:LogCapture.SetupDs:ACTION: creating /var/lib/dirsrv/slapd-standalone/db
INFO:LogCapture.SetupDs:ACTION: creating /var/lib/dirsrv/slapd-standalone/ldif
INFO:LogCapture.SetupDs:ACTION: creating /var/lock/dirsrv/slapd-standalone
INFO:LogCapture.SetupDs:ACTION: creating /var/log/dirsrv/slapd-standalone
INFO:LogCapture.SetupDs:ACTION: creating /var/run/dirsrv
INFO:LogCapture.SetupDs:ACTION: Creating certificate database is
/etc/dirsrv/slapd-standalone
INFO:LogCapture.SetupDs:ACTION: Creating dse.ldif
INFO:lib389:Allocate <class 'lib389.DirSrv'> with localhost:54321
INFO:lib389:Allocate <class 'lib389.DirSrv'> with localhost:54321
INFO:lib389:dir (sys) : /etc/sysconfig
INFO:lib389:dir (priv): /root/.dirsrv
INFO:lib389:List from /root/.dirsrv
INFO:lib389:list instance {'RUN_DIR': '/var/run/dirsrv',
'SERVER_ID': 'standalone', 'hostname':
'localhost.localdomain', 'ldap-port': 54321, 'ldap-secureport':
None, 'ldapi_autobind': None, 'DS_ROOT': '',
'deployed-dir': '/usr', 'INST_DIR':
'/var/lib/dirsrv/slapd-standalone', 'SERVER_DIR': '/usr/lib64',
'server-id': 'standalone', 'ldapi_enabled': None,
'ldapi_socket': None, 'SERVERBIN_DIR': '/usr/sbin',
'root-dn': 'cn=Directory Manager', 'user-id': 'dirsrv',
'CONFIG_DIR': '/etc/dirsrv/slapd-standalone', 'PRODUCT_NAME':
'slapd', 'suffix': None}

DEBUG:lib389:nss cmd: ['/usr/bin/certutil', '-N', '-d',
'/etc/dirsrv/slapd-standalone', '-f',
'/etc/dirsrv/slapd-standalone/pwdfile.txt']
DEBUG:lib389:nss output: 
E

===========================================================================================
ERRORS
===========================================================================================
_____________________________________________________________________________ ERROR at
setup of test_backend_cli
_____________________________________________________________________________

request = <SubRequest 'topology' for <Function
'test_backend_cli'>>

    @pytest.fixture
    def topology(request):
    
        lc = LogCapture()
        instance = DirSrv(verbose=DEBUGGING)
        instance.log.debug("Instance allocated")
        args = {SER_PORT: INSTANCE_PORT,
                SER_SERVERID_PROP: INSTANCE_SERVERID}
        instance.allocate(args)
        if instance.exists():
            instance.delete()
    
        # This will need to change to instance.create in the future
        # when it's linked up!
        sds = SetupDs(verbose=DEBUGGING, dryrun=False, log=lc.log)
    
        # Get the dicts from Type2Base, as though they were from _validate_ds_2_config
        # IE get the defaults back just from Slapd2Base.collect
        # Override instance name, root password, port and secure port.
    
        general_options = General2Base(lc.log)
        general_options.verify()
        general = general_options.collect()
    
        # Need an args -> options2 ...
        slapd_options = Slapd2Base(lc.log)
        slapd_options.set('instance_name', INSTANCE_SERVERID)
        slapd_options.set('port', INSTANCE_PORT)
        slapd_options.set('root_password', PW_DM)
        slapd_options.verify()
        slapd = slapd_options.collect()
    
>        sds.create_from_args(general, slapd, {}, None) 
lib389/tests/cli/__init__.py:63: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
lib389/instance/setup.py:297: in create_from_args
    self._install_ds(general, slapd, backends)
lib389/instance/setup.py:424: in _install_ds
    ds_instance.start(timeout=60)
lib389/__init__.py:1169: in start
    if self.status() is True:
lib389/__init__.py:1270: in status
    pid = pid_from_file(self.ds_paths.pid_file)
lib389/paths.py:153: in __getattr__
    return self._config.get(SECTION, name).format(instance_name=self._serverid)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ 

self = <ConfigParser.SafeConfigParser instance at 0x7ff7d92e37e8>, 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
================================================================================== 1 error
in 0.69 seconds
===================================================================================

************************************************************Terminal text ends here
***************************************************************

[William Brown]

On Wed, 2017-03-15 at 03:37 +0000, Ankit Yadav wrote:
>  output of rpm -qa | grep lib389 ==>
> python-lib389-1.0.2-3.fc25.noarch  
You should erase this package, it's probably the source of some of your
issues.


>      pid = pid_from_file(self.ds_paths.pid_file)
>  lib389/paths.py:153: in __getattr__ 
...

>          except KeyError:
>  >           raise NoOptionError(option, section)
>  E           NoOptionError: No option 'pid_file' in section: 'slapd'

This means you are missing defaults.inf. Have you actually installed
389-ds-base on your system? 

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

[Ankit Yadav]

I have uninstalled that package.
There were some issues with my installation but now I am getting some
different errors.

================================================= error starts
=========================================
lib389/instance/setup.py:287: in create_from_args
    self._prepare_ds(general, slapd, backends)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <lib389.instance.setup.SetupDs object at 0x7f7bd157bf50>, general =
{'config_version': 2, 'defaults': '999999999',
'full_machine_name':
'localhost.localdomain', 'selinux': True, ...}
slapd = {'backup_dir': '/var/lib/dirsrv/slapd-standalone/bak',
'bin_dir':
'/usr/bin', 'cert_dir': '/etc/dirsrv/slapd-standalone',
'config_dir':
'/etc/dirsrv/slapd-standalone', ...}
backends = {}

    def _prepare_ds(self, general, slapd, backends):

        assert(general['defaults'] is not None)
        if self.verbose:
            self.log.info("PASSED: using config settings %s" %
general['defaults'])
        # Validate our arguments.
        assert(slapd['user'] is not None)
        # check the user exists
        assert(pwd.getpwnam(slapd['user']))
        slapd['user_uid'] = pwd.getpwnam(slapd['user']).pw_uid
        assert(slapd['group'] is not None)
        assert(grp.getgrnam(slapd['group']))
        slapd['group_gid'] = grp.getgrnam(slapd['group']).gr_gid
        # check this group exists
        # Check that we are running as this user / group, or that we are
root.
        assert(os.geteuid() == 0 or getpass.getuser() == slapd['user'])

        if self.verbose:
            self.log.info("PASSED: user / group checking")

        assert(general['full_machine_name'] is not None)
        assert(general['strict_host_checking'] is not None)
        if general['strict_host_checking'] is True:
            # Check it resolves with dns
            assert(socket.gethostbyname(general['full_machine_name']))
            if self.verbose:
                self.log.info("PASSED: Hostname strict checking")

        assert(slapd['prefix'] is not None)
        if (slapd['prefix'] != ""):
            assert(os.path.exists(slapd['prefix']))
        if self.verbose:
            self.log.info("PASSED: prefix checking")

        # We need to know the prefix before we can do the instance checks
        assert(slapd['instance_name'] is not None)
        # Check if the instance exists or not.
        # Should I move this import? I think this prevents some recursion
        from lib389 import DirSrv
        ds = DirSrv(verbose=self.verbose)
        ds.containerised = self.containerised
        ds.prefix = slapd['prefix']
        insts = ds.list(serverid=slapd['instance_name'])
>        assert(len(insts) == 0) 
E       assert 1 == 0
E        +  where 1 = len([{'CONFIG_DIR': '/etc/dirsrv/slapd-standalone',
'DS_ROOT': '', 'INST_DIR':
'/var/lib/dirsrv/slapd-standalone',
'PRODUCT_NAME': 'slapd', ...}])

lib389/instance/setup.py:234: AssertionError
==================================================================================
1 error in 0.18 seconds
===================================================================================

I removed all the instances of directory servers.

On 15 March 2017 at 09:11, William Brown <wibrown(a)redhat.com&gt; wrote:

>  On Wed, 2017-03-15 at 03:37 +0000, Ankit Yadav wrote:
>  > output of rpm -qa | grep lib389 ==> python-lib389-1.0.2-3.fc25.noarch
>
>  You should erase this package, it's probably the source of some of your
>  issues.
>
>
>  >     pid = pid_from_file(self.ds_paths.pid_file)
>  > lib389/paths.py:153: in __getattr__
>
>  ...
>
>  >         except KeyError:
>  > >           raise NoOptionError(option, section)
>  > E           NoOptionError: No option 'pid_file' in section: 'slapd'
>
>
>  This means you are missing defaults.inf. Have you actually installed
>  389-ds-base on your system?
>
>  --
>  Sincerely,
>
>  William Brown
>  Software Engineer
>  Red Hat, Australia/Brisbane
>
>
>  _______________________________________________
>  389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>
>

[Ankit Yadav]

I have fixed the issues with my installation hence now I am getting the
above error.

Regards,
Ankit yadav.

On 15 March 2017 at 12:50, Ankit Yadav <ankitwrk(a)gmail.com&gt; wrote:

>  I have uninstalled that package.
>  There were some issues with my installation but now I am getting some
>  different errors.
>
>  ================================================= error starts
>  =========================================
>  lib389/instance/setup.py:287: in create_from_args
>      self._prepare_ds(general, slapd, backends)
>  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>  self = <lib389.instance.setup.SetupDs object at 0x7f7bd157bf50>, general =
>  {'config_version': 2, 'defaults': '999999999',
> 'full_machine_name':
>  'localhost.localdomain', 'selinux': True, ...}
>  slapd = {'backup_dir': '/var/lib/dirsrv/slapd-standalone/bak',
> 'bin_dir':
>  '/usr/bin', 'cert_dir': '/etc/dirsrv/slapd-standalone',
> 'config_dir':
>  '/etc/dirsrv/slapd-standalone', ...}
>  backends = {}
>
>      def _prepare_ds(self, general, slapd, backends):
>
>          assert(general['defaults'] is not None)
>          if self.verbose:
>              self.log.info("PASSED: using config settings %s" %
>  general['defaults'])
>          # Validate our arguments.
>          assert(slapd['user'] is not None)
>          # check the user exists
>          assert(pwd.getpwnam(slapd['user']))
>          slapd['user_uid'] = pwd.getpwnam(slapd['user']).pw_uid
>          assert(slapd['group'] is not None)
>          assert(grp.getgrnam(slapd['group']))
>          slapd['group_gid'] = grp.getgrnam(slapd['group']).gr_gid
>          # check this group exists
>          # Check that we are running as this user / group, or that we are
>  root.
>          assert(os.geteuid() == 0 or getpass.getuser() == slapd['user'])
>
>          if self.verbose:
>              self.log.info("PASSED: user / group checking")
>
>          assert(general['full_machine_name'] is not None)
>          assert(general['strict_host_checking'] is not None)
>          if general['strict_host_checking'] is True:
>              # Check it resolves with dns
>              assert(socket.gethostbyname(general['full_machine_name']))
>              if self.verbose:
>                  self.log.info("PASSED: Hostname strict checking")
>
>          assert(slapd['prefix'] is not None)
>          if (slapd['prefix'] != ""):
>              assert(os.path.exists(slapd['prefix']))
>          if self.verbose:
>              self.log.info("PASSED: prefix checking")
>
>          # We need to know the prefix before we can do the instance checks
>          assert(slapd['instance_name'] is not None)
>          # Check if the instance exists or not.
>          # Should I move this import? I think this prevents some recursion
>          from lib389 import DirSrv
>          ds = DirSrv(verbose=self.verbose)
>          ds.containerised = self.containerised
>          ds.prefix = slapd['prefix']
>          insts = ds.list(serverid=slapd['instance_name'])
>  >       assert(len(insts) == 0)
>  E       assert 1 == 0
>  E        +  where 1 = len([{'CONFIG_DIR':
> '/etc/dirsrv/slapd-standalone',
>  'DS_ROOT': '', 'INST_DIR':
> '/var/lib/dirsrv/slapd-standalone',
>  'PRODUCT_NAME': 'slapd', ...}])
>
>  lib389/instance/setup.py:234: AssertionError
>  ==================================================================================
>  1 error in 0.18 seconds ==============================
>  =====================================================
>
>  I removed all the instances of directory servers.
>
>  On 15 March 2017 at 09:11, William Brown <wibrown(a)redhat.com&gt; wrote:
>
> > On Wed, 2017-03-15 at 03:37 +0000, Ankit Yadav wrote:
> > > output of rpm -qa | grep lib389 ==> python-lib389-1.0.2-3.fc25.noarch
> >
> > You should erase this package, it's probably the source of some of your
> > issues.
> >
> >
> > >     pid = pid_from_file(self.ds_paths.pid_file)
> > > lib389/paths.py:153: in __getattr__
> >
> > ...
> >
> > >         except KeyError:
> > > >           raise NoOptionError(option, section)
> > > E           NoOptionError: No option 'pid_file' in section:
> 'slapd'
> >
> >
> > This means you are missing defaults.inf. Have you actually installed
> > 389-ds-base on your system?
> >
> > --
> > Sincerely,
> >
> > William Brown
> > Software Engineer
> > Red Hat, Australia/Brisbane
> >
> >
> > _______________________________________________
> > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> >
> >
>

[William Brown]

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

[Ankit Yadav]

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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>
>

[Ankit Yadav]

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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> >
> >
>

[Ankit Yadav]

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
> >> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> >>
> >>
> >
>

[Ankit Yadav]

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

*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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
> >>> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
> >>>
> >>>
> >>
> >
>

[William Brown]

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  >>>> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>  >>>>
>  >>>>
>  >>>
>  >>
>  >
>  _______________________________________________
>  389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org 
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

[Ankit Yadav]

Thanks! It worked, this setup took more time than I expected but on other
side I have learned new things about lib389 and 389-ds-base, specially the
tests.

I will raise a bug in pagure for 389-ds-base. Since I am done with the
setup part I will continue to work of writing basic comparison function and
its tests in lib389.

Regards,
Ankit Yadav

On 19 March 2017 at 11:56, William Brown <wibrown(a)redhat.com&gt; wrote:

>  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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt;
> 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(a)lists.fedoraproject.org
>  > >>>> To unsubscribe send an email to 389-devel-leave@lists.
>  fedoraproject.org
>  > >>>>
>  > >>>>
>  > >>>
>  > >>
>  > >
>  > _______________________________________________
>  > 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>
>  --
>  Sincerely,
>
>  William Brown
>  Software Engineer
>  Red Hat, Australia/Brisbane
>
>
>  _______________________________________________
>  389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org
>
>

[William Brown]

On Sun, 2017-03-19 at 13:07 +0530, Ankit Yadav wrote:
>  Thanks! It worked, this setup took more time than I expected but on
> other
>  side I have learned new things about lib389 and 389-ds-base, specially the
>  tests. 
Great work: And this learning process is a very valuable experience.
These issues could affect anyone, so it's important that as a project we
streamline and improve this.

>  
>  I will raise a bug in pagure for 389-ds-base. Since I am done with the
>  setup part I will continue to work of writing basic comparison function and
>  its tests in lib389. 
Fantastic, thank you so much. I look forwards to your initial tests.
Thank you for sticking with it, and solving the problem. 

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane