On 09/16/2013 03:21 AM, Charlie Derwent wrote:
Update on the errors
kinit charlesd
kinit: Generic error (see e-text) while getting initial credentials
krb5kdc.log - LOOKING_UP_CLIENT: charl...@example.com <mailto:charl...@example.com> for krbtg/example....@example.com <mailto:example....@example.com>, Server Error
Starting the IPA service (dirsrv in particular) gives
Failed to read data from Directory Service: Failed to get list of services to probe status! Configured hostname 'ipa3.example.com <http://ipa3.example.com>' doesn't match any master server in LDAP: No master found because of error: {'matched': dc=example,dc=com', 'desc': 'No such object'}
Shutting down
The errors log has a load of different services schema-compat-plugin. dna-plugin, ipalockout_preop/postop all complaining in one way or another about being unable to retrieve entries or no entries being set up.

I think you'll have to use the workaround where you change replication to use simple bind in order to initialize the consumer, then switch back to sasl/gssapi.

Simo/Rob - which ticket was this?  Does freeipa.org have the workaround?

On Fri, Sep 13, 2013 at 2:49 PM, Rich Megginson <rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:

    On 09/12/2013 08:04 PM, Charlie Derwent wrote:

    On Mon, Sep 9, 2013 at 5:32 PM, Rich Megginson
    <rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:

        On 09/09/2013 10:20 AM, Charlie Derwent wrote:
        2 questions, some of our automation accounts are needlessly
        querying the IPA server every time they call a command via
        sudo. This is generating a lot of noise in our access logs.
        Is there any way to ensure certain system accounts don't
        call out to the IPA server for additional groups or sudo
        permission when completing tasks?

        What are your client platforms?  Does sssd or newer versions
        of sudo cache?

        The other question is slightly more embarrassing, one of our
        guys saw /var filling and noticed that
        /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ had a load of "log"
        files which looked like they weren't being tidied.

        They are automatically cleaned up.  If you have a lot of
        updates, it may take longer.

        One stupid decision later and I'm now here asking on his
        behalf if there is anyway of restoring the database from a
        replica or is a complete rebuild required?

        Just reinit the replica using ipa-replica-manage.

    I just tried to reinit the replica but I'm getting an error about
    failure to connect to LDAP server I'm guessing that's because
    it's impossible for me to kinit on the server now given the state
    of the DB.

    It depends.  What error?  Can you provide the exact error message
    and/or excerpts from /var/log/dirsrv/slapd-DOMAIN-COM/errors?

        Second question is obviously a little bit more urgent than
        the first but any advice is greatly appreciated.

        Freeipa-users mailing list
        Freeipa-users@redhat.com  <mailto:Freeipa-users@redhat.com>

Freeipa-users mailing list

Reply via email to