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

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