On 09/09/2013 11:40 AM, 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:
    Hi,
    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 clients are a mix of RHEL and CentOS 5.8 servers, what version am I looking for any kind of caching?

By default, on EL5, sudo has to connect/bind/search/close for every single sudo lookup. I believe there are versions of sssd/sudo that do some sort of caching. I'm not sure if those are available for EL5.


    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.

Thanks will give it a go tomorrow.

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


    _______________________________________________
    Freeipa-users mailing list
    Freeipa-users@redhat.com  <mailto:Freeipa-users@redhat.com>
    https://www.redhat.com/mailman/listinfo/freeipa-users



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to