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?
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
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_-4QsnOzI8J97oGxr0KZmFmk...
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.
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
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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
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 ***************************************************************
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?
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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
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@gmail.com 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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
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.
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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
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@gmail.com 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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
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@gmail.com 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 islooked up*
in `vars' (if provided), `section', and in `defaults' in thatorder.*
All % interpolations are expanded in the return values,unless the*
optional argument `raw' is true. Values for interpolationkeys 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@gmail.com 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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
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@gmail.com 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 :*
- Installed 389-ds-base using *sudo dnf install "389*"*
- setup 389-ds-base using *sudo* *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@gmail.com 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 optionis looked up*
in `vars' (if provided), `section', and in `defaults' inthat order.*
All % interpolations are expanded in the return values,unless the*
optional argument `raw' is true. Values for interpolationkeys 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@gmail.com 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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
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@gmail.com 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 :*
- Installed 389-ds-base using *sudo dnf install "389*"*
- setup 389-ds-base using *sudo* *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@gmail.com 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 optionis looked up*
in `vars' (if provided), `section', and in `defaults' inthat order.*
All % interpolations are expanded in the return values,unless the*
optional argument `raw' is true. Values for interpolationkeys 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@gmail.com 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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
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@redhat.com 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@gmail.com 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
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 :*
- Installed 389-ds-base using *sudo dnf install "389*"*
- setup 389-ds-base using *sudo* *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@gmail.com 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. Theoption
is looked up*
in `vars' (if provided), `section', and in `defaults' inthat order.*
All % interpolations are expanded in the return values,unless the*
optional argument `raw' is true. Values for interpolationkeys 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@gmail.com 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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.
fedoraproject.org
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
-- Sincerely,
William Brown Software Engineer Red Hat, Australia/Brisbane
389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
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.
389-devel@lists.fedoraproject.org
-
Ankit Yadav -
William Brown