Re: [Freeipa-users] Replication status
On Mon, May 21, 2012 at 3:21 PM, Rich Megginson rmegg...@redhat.com wrote: On 05/21/2012 07:13 AM, Dan Scott wrote: https://fedorahosted.org/**freeipa/ticket/2770https://fedorahosted.org/freeipa/ticket/2770 I've modified the nagios perl script that I got from: http://directory.**fedoraproject.org/wiki/Howto:**ReplicationMonitoringhttp://directory.fedoraproject.org/wiki/Howto:ReplicationMonitoring to do anonymous binds and to allow an additional parameter with the port number. Should I send it to someone? I don't know who maintains that nagios script. you can always post it to the nagios exchange site ( http://exchange.nagios.org/) so others can benefit from it. -- natxo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
Hi, On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden rcrit...@redhat.com wrote: Rich Megginson wrote: On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html We already have some delegated permissions for replication but none granting only read access. Off the cuff, something like this might work: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX changetype: add objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read Replication Agreements ipapermissiontype: SYSTEM Note that you'll need to replace $SUFFIX with your base dn (dc=example,dc=com). This is untested so YMMV. If you find that it works and is useful please let us know, maybe we can add this for everyone to enjoy :-) Is it safe to allow anonymous access to read this attribute? I added the following ACI: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///anyone;;) And I can now get the replication status using an anonymous bind. I also modified the nagios perl script to make an anonymous bind and check the replication status - it's working OK. I don't know if the aci should be a standard feature, option to enable, or just to provide the ldif for anyone who wants it. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
On 05/18/2012 08:13 AM, Dan Scott wrote: Hi, On Wed, May 2, 2012 at 11:13 PM, Rob Crittendenrcrit...@redhat.com wrote: Rich Megginson wrote: On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html We already have some delegated permissions for replication but none granting only read access. Off the cuff, something like this might work: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX changetype: add objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read Replication Agreements ipapermissiontype: SYSTEM Note that you'll need to replace $SUFFIX with your base dn (dc=example,dc=com). This is untested so YMMV. If you find that it works and is useful please let us know, maybe we can add this for everyone to enjoy :-) Is it safe to allow anonymous access to read this attribute? I added the following ACI: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///anyone;;) It would be better to restrict the list of attributes to only those needed by the app e.g. (targetattr=foo || bar || baz || ...) And I can now get the replication status using an anonymous bind. I also modified the nagios perl script to make an anonymous bind and check the replication status - it's working OK. I don't know if the aci should be a standard feature, option to enable, or just to provide the ldif for anyone who wants it. Sure. If you think it should be a standard feature, just file a ticket. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
On Fri, May 18, 2012 at 10:29 AM, Rich Megginson rmegg...@redhat.com wrote: On 05/18/2012 08:13 AM, Dan Scott wrote: Hi, On Wed, May 2, 2012 at 11:13 PM, Rob Crittendenrcrit...@redhat.com wrote: Rich Megginson wrote: On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html We already have some delegated permissions for replication but none granting only read access. Off the cuff, something like this might work: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX changetype: add objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read Replication Agreements ipapermissiontype: SYSTEM Note that you'll need to replace $SUFFIX with your base dn (dc=example,dc=com). This is untested so YMMV. If you find that it works and is useful please let us know, maybe we can add this for everyone to enjoy :-) Is it safe to allow anonymous access to read this attribute? I added the following ACI: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///anyone;;) It would be better to restrict the list of attributes to only those needed by the app e.g. (targetattr=foo || bar || baz || ...) OK, thanks. I had a look through the available data and I think these would be best: nsDS5ReplicaHost||nsds5replicaLastUpdateStatus||nsds5replicaLastUpdateStart||nsds5replicaLastUpdateEnd||nsds5replicaLastInitStart||nsds5replicaLastInitEnd||nsds5replicaUpdateInProgress And I can now get the replication status using an anonymous bind. I also modified the nagios perl script to make an anonymous bind and check the replication status - it's working OK. I don't know if the aci should be a standard feature, option to enable, or just to provide the ldif for anyone who wants it. Sure. If you think it should be a standard feature, just file a ticket. OK, will do, once I've figured out a few more things. I want to enable this for the PKI-CA directory too. I changed the dn to dn: cn=o=ipaca,cn=mapping tree,cn=config and added this to my server on port 7389. Using targetattr=*, everything works fine, but when I restrict it to the list of attributes above, I don't get any results. Is there another attribute I need to add? Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
On Fri, May 18, 2012 at 12:21 PM, Rich Megginson rmegg...@redhat.com wrote: On 05/18/2012 10:06 AM, Dan Scott wrote: On Fri, May 18, 2012 at 10:29 AM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 08:13 AM, Dan Scott wrote: Hi, On Wed, May 2, 2012 at 11:13 PM, Rob Crittendenrcrit...@redhat.com wrote: Rich Megginson wrote: On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html We already have some delegated permissions for replication but none granting only read access. Off the cuff, something like this might work: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX changetype: add objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read Replication Agreements ipapermissiontype: SYSTEM Note that you'll need to replace $SUFFIX with your base dn (dc=example,dc=com). This is untested so YMMV. If you find that it works and is useful please let us know, maybe we can add this for everyone to enjoy :-) Is it safe to allow anonymous access to read this attribute? I added the following ACI: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///anyone;;) It would be better to restrict the list of attributes to only those needed by the app e.g. (targetattr=foo || bar || baz || ...) OK, thanks. I had a look through the available data and I think these would be best: nsDS5ReplicaHost||nsds5replicaLastUpdateStatus||nsds5replicaLastUpdateStart||nsds5replicaLastUpdateEnd||nsds5replicaLastInitStart||nsds5replicaLastInitEnd||nsds5replicaUpdateInProgress And I can now get the replication status using an anonymous bind. I also modified the nagios perl script to make an anonymous bind and check the replication status - it's working OK. I don't know if the aci should be a standard feature, option to enable, or just to provide the ldif for anyone who wants it. Sure. If you think it should be a standard feature, just file a ticket. OK, will do, once I've figured out a few more things. I want to enable this for the PKI-CA directory too. I changed the dn to dn: cn=o=ipaca,cn=mapping tree,cn=config and added this to my server on port 7389. Using targetattr=*, everything works fine, but when I restrict it to the list of attributes above, I don't get any results. Is there another attribute I need to add? Not sure why it would be any different for CA replication . . . Sorry, I wasn't clear. The difference isn't between CA and main, it's between restricting to (targetattr=nsDS5ReplicaHost||.) and (targetattr=*). If I add the targetattr=* to the CA dirsrv, it works fine. Neither work when I restrict to particular attributes. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
On 05/18/2012 10:31 AM, Dan Scott wrote: On Fri, May 18, 2012 at 12:21 PM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 10:06 AM, Dan Scott wrote: On Fri, May 18, 2012 at 10:29 AM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 08:13 AM, Dan Scott wrote: Hi, On Wed, May 2, 2012 at 11:13 PM, Rob Crittendenrcrit...@redhat.com wrote: Rich Megginson wrote: On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html We already have some delegated permissions for replication but none granting only read access. Off the cuff, something like this might work: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX changetype: add objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read Replication Agreements ipapermissiontype: SYSTEM Note that you'll need to replace $SUFFIX with your base dn (dc=example,dc=com). This is untested so YMMV. If you find that it works and is useful please let us know, maybe we can add this for everyone to enjoy :-) Is it safe to allow anonymous access to read this attribute? I added the following ACI: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///anyone;;) It would be better to restrict the list of attributes to only those needed by the app e.g. (targetattr=foo || bar || baz || ...) OK, thanks. I had a look through the available data and I think these would be best: nsDS5ReplicaHost||nsds5replicaLastUpdateStatus||nsds5replicaLastUpdateStart||nsds5replicaLastUpdateEnd||nsds5replicaLastInitStart||nsds5replicaLastInitEnd||nsds5replicaUpdateInProgress And I can now get the replication status using an anonymous bind. I also modified the nagios perl script to make an anonymous bind and check the replication status - it's working OK. I don't know if the aci should be a standard feature, option to enable, or just to provide the ldif for anyone who wants it. Sure. If you think it should be a standard feature, just file a ticket. OK, will do, once I've figured out a few more things. I want to enable this for the PKI-CA directory too. I changed the dn to dn: cn=o=ipaca,cn=mapping tree,cn=config and added this to my server on port 7389. Using targetattr=*, everything works fine, but when I restrict it to the list of attributes above, I don't get any results. Is there another attribute I need to add? Not sure why it would be any different for CA replication . . . Sorry, I wasn't clear. The difference isn't between CA and main, it's between restricting to (targetattr=nsDS5ReplicaHost||.) and (targetattr=*). If I add the targetattr=* to the CA dirsrv, it works fine. Neither work when I restrict to particular attributes. If you look at the access log it should tell you which attributes it is searching for. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
On 05/18/2012 11:46 AM, Dan Scott wrote: On Fri, May 18, 2012 at 12:38 PM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 10:31 AM, Dan Scott wrote: On Fri, May 18, 2012 at 12:21 PM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 10:06 AM, Dan Scott wrote: On Fri, May 18, 2012 at 10:29 AM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 08:13 AM, Dan Scott wrote: Hi, On Wed, May 2, 2012 at 11:13 PM, Rob Crittendenrcrit...@redhat.com wrote: Rich Megginson wrote: On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html We already have some delegated permissions for replication but none granting only read access. Off the cuff, something like this might work: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX changetype: add objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read Replication Agreements ipapermissiontype: SYSTEM Note that you'll need to replace $SUFFIX with your base dn (dc=example,dc=com). This is untested so YMMV. If you find that it works and is useful please let us know, maybe we can add this for everyone to enjoy :-) Is it safe to allow anonymous access to read this attribute? I added the following ACI: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///anyone;;) It would be better to restrict the list of attributes to only those needed by the app e.g. (targetattr=foo || bar || baz || ...) OK, thanks. I had a look through the available data and I think these would be best: nsDS5ReplicaHost||nsds5replicaLastUpdateStatus||nsds5replicaLastUpdateStart||nsds5replicaLastUpdateEnd||nsds5replicaLastInitStart||nsds5replicaLastInitEnd||nsds5replicaUpdateInProgress And I can now get the replication status using an anonymous bind. I also modified the nagios perl script to make an anonymous bind and check the replication status - it's working OK. I don't know if the aci should be a standard feature, option to enable, or just to provide the ldif for anyone who wants it. Sure. If you think it should be a standard feature, just file a ticket. OK, will do, once I've figured out a few more things. I want to enable this for the PKI-CA directory too. I changed the dn to dn: cn=o=ipaca,cn=mapping tree,cn=config and added this to my server on port 7389. Using targetattr=*, everything works fine, but when I restrict it to the list of attributes above, I don't get any results. Is there another attribute I need to add? Not sure why it would be any different for CA replication . . . Sorry, I wasn't clear. The difference isn't between CA and main, it's between restricting to (targetattr=nsDS5ReplicaHost||.) and (targetattr=*). If I add the targetattr=* to the CA dirsrv, it works fine. Neither work when I restrict to particular attributes. If you look at the access log it should tell you which attributes it is searching for. Nothing shows up in the log. Does it show failed access attempts by default? Yes. The access log is buffered, so it may take a while for the request to show up. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
On Fri, May 18, 2012 at 1:52 PM, Rich Megginson rmegg...@redhat.com wrote: On 05/18/2012 11:46 AM, Dan Scott wrote: On Fri, May 18, 2012 at 12:38 PM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 10:31 AM, Dan Scott wrote: On Fri, May 18, 2012 at 12:21 PM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 10:06 AM, Dan Scott wrote: On Fri, May 18, 2012 at 10:29 AM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 08:13 AM, Dan Scott wrote: Hi, On Wed, May 2, 2012 at 11:13 PM, Rob Crittendenrcrit...@redhat.com wrote: Rich Megginson wrote: On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html We already have some delegated permissions for replication but none granting only read access. Off the cuff, something like this might work: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX changetype: add objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read Replication Agreements ipapermissiontype: SYSTEM Note that you'll need to replace $SUFFIX with your base dn (dc=example,dc=com). This is untested so YMMV. If you find that it works and is useful please let us know, maybe we can add this for everyone to enjoy :-) Is it safe to allow anonymous access to read this attribute? I added the following ACI: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///anyone;;) It would be better to restrict the list of attributes to only those needed by the app e.g. (targetattr=foo || bar || baz || ...) OK, thanks. I had a look through the available data and I think these would be best: nsDS5ReplicaHost||nsds5replicaLastUpdateStatus||nsds5replicaLastUpdateStart||nsds5replicaLastUpdateEnd||nsds5replicaLastInitStart||nsds5replicaLastInitEnd||nsds5replicaUpdateInProgress And I can now get the replication status using an anonymous bind. I also modified the nagios perl script to make an anonymous bind and check the replication status - it's working OK. I don't know if the aci should be a standard feature, option to enable, or just to provide the ldif for anyone who wants it. Sure. If you think it should be a standard feature, just file a ticket. OK, will do, once I've figured out a few more things. I want to enable this for the PKI-CA directory too. I changed the dn to dn: cn=o=ipaca,cn=mapping tree,cn=config and added this to my server on port 7389. Using targetattr=*, everything works fine, but when I restrict it to the list of attributes above, I don't get any results. Is there another attribute I need to add? Not sure why it would be any different for CA replication . . . Sorry, I wasn't clear. The difference isn't between CA and main, it's between restricting to (targetattr=nsDS5ReplicaHost||.) and (targetattr=*). If I add the targetattr=* to the CA dirsrv, it works fine. Neither work when I restrict to particular attributes. If you look at the access log it should tell you which attributes it is searching for. Nothing shows up in the log. Does it show failed access attempts by default? Yes. The access log is buffered, so it may take a while for the request to show up. Ahh, OK thanks. The request is: [18/May/2012:13:59:02 -0400] conn=10516 fd=86 slot=86 connection from 192.168.1.202 to 192.168.1.201 [18/May/2012:13:59:02 -0400] conn=10516 op=0 BIND dn= method=128 version=3 [18/May/2012:13:59:02 -0400] conn=10516 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn= [18/May/2012:13:59:02 -0400] conn=10516 op=1 SRCH base=cn=config scope=2 filter=(objectClass=nsDS5ReplicationAgreement) attrs=ALL [18/May/2012:13:59:02 -0400] conn=10516 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [18/May/2012:13:59:02 -0400] conn=10516 op=-1 fd=86 closed - B1 If I search for 'ALL' attrs, but only have permission for some. Will I get no results? Or only those I have
Re: [Freeipa-users] Replication status
On 05/18/2012 12:05 PM, Dan Scott wrote: On Fri, May 18, 2012 at 1:52 PM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 11:46 AM, Dan Scott wrote: On Fri, May 18, 2012 at 12:38 PM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 10:31 AM, Dan Scott wrote: On Fri, May 18, 2012 at 12:21 PM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 10:06 AM, Dan Scott wrote: On Fri, May 18, 2012 at 10:29 AM, Rich Megginsonrmegg...@redhat.com wrote: On 05/18/2012 08:13 AM, Dan Scott wrote: Hi, On Wed, May 2, 2012 at 11:13 PM, Rob Crittendenrcrit...@redhat.com wrote: Rich Megginson wrote: On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html We already have some delegated permissions for replication but none granting only read access. Off the cuff, something like this might work: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX changetype: add objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read Replication Agreements ipapermissiontype: SYSTEM Note that you'll need to replace $SUFFIX with your base dn (dc=example,dc=com). This is untested so YMMV. If you find that it works and is useful please let us know, maybe we can add this for everyone to enjoy :-) Is it safe to allow anonymous access to read this attribute? I added the following ACI: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///anyone;;) It would be better to restrict the list of attributes to only those needed by the app e.g. (targetattr=foo || bar || baz || ...) OK, thanks. I had a look through the available data and I think these would be best: nsDS5ReplicaHost||nsds5replicaLastUpdateStatus||nsds5replicaLastUpdateStart||nsds5replicaLastUpdateEnd||nsds5replicaLastInitStart||nsds5replicaLastInitEnd||nsds5replicaUpdateInProgress And I can now get the replication status using an anonymous bind. I also modified the nagios perl script to make an anonymous bind and check the replication status - it's working OK. I don't know if the aci should be a standard feature, option to enable, or just to provide the ldif for anyone who wants it. Sure. If you think it should be a standard feature, just file a ticket. OK, will do, once I've figured out a few more things. I want to enable this for the PKI-CA directory too. I changed the dn to dn: cn=o=ipaca,cn=mapping tree,cn=config and added this to my server on port 7389. Using targetattr=*, everything works fine, but when I restrict it to the list of attributes above, I don't get any results. Is there another attribute I need to add? Not sure why it would be any different for CA replication . . . Sorry, I wasn't clear. The difference isn't between CA and main, it's between restricting to (targetattr=nsDS5ReplicaHost||.) and (targetattr=*). If I add the targetattr=* to the CA dirsrv, it works fine. Neither work when I restrict to particular attributes. If you look at the access log it should tell you which attributes it is searching for. Nothing shows up in the log. Does it show failed access attempts by default? Yes. The access log is buffered, so it may take a while for the request to show up. Ahh, OK thanks. The request is: [18/May/2012:13:59:02 -0400] conn=10516 fd=86 slot=86 connection from 192.168.1.202 to 192.168.1.201 [18/May/2012:13:59:02 -0400] conn=10516 op=0 BIND dn= method=128 version=3 [18/May/2012:13:59:02 -0400] conn=10516 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn= [18/May/2012:13:59:02 -0400] conn=10516 op=1 SRCH base=cn=config scope=2 filter=(objectClass=nsDS5ReplicationAgreement) attrs=ALL [18/May/2012:13:59:02 -0400] conn=10516 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [18/May/2012:13:59:02 -0400] conn=10516 op=-1 fd=86 closed - B1 If I search for 'ALL' attrs, but only have permission for some. Will I get no results? Or only those I have permission to read? Hmm - not sure
Re: [Freeipa-users] Replication status
I have been considering looking into using this: http://cnmonitor.sourceforge.net/ ~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117x-apple-data-detectors://0/0 T: +1 805.690.3478tel:+1%C2%A0805.690.3478 C: +1 805.717.0365tel:+1%20805.717.0365 jr.aqu...@citrixonline.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ On May 2, 2012, at 2:46 PM, Ian Levesque wrote: Hi, I'm curious how members of this list are monitoring their IPA servers' replication status. `ipa-replica-manage list` doesn't actually tell you if your replica is working. I just realized that our replica's IPA processes were hung (likely as a result of suspending resuming the VM it's running on). It would be great if our nagios could monitor the replica status - anyone here have any ideas? Cheers, Ian ___ Freeipa-users mailing list Freeipa-users@redhat.commailto: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
Re: [Freeipa-users] Replication status
Also See: http://directory.fedoraproject.org/wiki/Howto:CN%3DMonitor_LDAP_Monitoring ;) On May 3, 2012, at 9:26 AM, JR Aquino wrote: I have been considering looking into using this: http://cnmonitor.sourceforge.net/ ~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117x-apple-data-detectors://0/0 T: +1 805.690.3478tel:+1%C2%A0805.690.3478 C: +1 805.717.0365tel:+1%20805.717.0365 jr.aqu...@citrixonline.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ On May 2, 2012, at 2:46 PM, Ian Levesque wrote: Hi, I'm curious how members of this list are monitoring their IPA servers' replication status. `ipa-replica-manage list` doesn't actually tell you if your replica is working. I just realized that our replica's IPA processes were hung (likely as a result of suspending resuming the VM it's running on). It would be great if our nagios could monitor the replica status - anyone here have any ideas? Cheers, Ian ___ Freeipa-users mailing list Freeipa-users@redhat.commailto: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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
Hi, I'm definitely interested in this too. You can use ipa-replica-manage -v list $HOSTNAME to get detailed status information. I also found this: http://directory.fedoraproject.org/wiki/Howto:ReplicationMonitoring But I believe that it needs to have the Directory Manager password hardcoded. Let me know if you figure out a nice solution. Thanks, Dan On Wed, May 2, 2012 at 5:46 PM, Ian Levesque i...@crystal.harvard.edu wrote: Hi, I'm curious how members of this list are monitoring their IPA servers' replication status. `ipa-replica-manage list` doesn't actually tell you if your replica is working. I just realized that our replica's IPA processes were hung (likely as a result of suspending resuming the VM it's running on). It would be great if our nagios could monitor the replica status - anyone here have any ideas? Cheers, Ian ___ Freeipa-users mailing list 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
Re: [Freeipa-users] Replication status
On 05/02/2012 05:46 PM, Ian Levesque wrote: Hi, I'm curious how members of this list are monitoring their IPA servers' replication status. `ipa-replica-manage list` doesn't actually tell you if your replica is working. I just realized that our replica's IPA processes were hung (likely as a result of suspending resuming the VM it's running on). It would be great if our nagios could monitor the replica status - anyone here have any ideas? Cheers, Ian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users http://port389.org/wiki/Howto:ReplicationMonitoring -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
On 05/02/2012 04:11 PM, Ian Levesque wrote: On May 2, 2012, at 5:56 PM, Dmitri Pal wrote: I'm curious how members of this list are monitoring their IPA servers' replication status. `ipa-replica-manage list` doesn't actually tell you if your replica is working. I just realized that our replica's IPA processes were hung (likely as a result of suspending resuming the VM it's running on). It would be great if our nagios could monitor the replica status - anyone here have any ideas? http://port389.org/wiki/Howto:ReplicationMonitoring Thanks for the reply, but storing the directory manager password in plain text defies any sort of paranoia that should be fundamental to an IPA admin. I find it hard to believe it's even recommended at all! Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Thanks, Ian ___ Freeipa-users mailing list 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
Re: [Freeipa-users] Replication status
On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication status
Rich Megginson wrote: On 05/02/2012 07:36 PM, Ian Levesque wrote: On May 2, 2012, at 6:48 PM, Rich Megginson wrote: Is there any way to expose the nsDS5ReplicationAgreement objectClass to a less privileged account; i.e., an account solely designed to check replication status? You also need to expose the RUV tombstone entry at the base of each suffix. Good to know, thanks. I haven't messed with ACIs on 389ds/IPA before; any pointers? Cheers, Ian http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control.html We already have some delegated permissions for replication but none granting only read access. Off the cuff, something like this might work: dn: cn=$SUFFIX,cn=mapping tree,cn=config changetype: modify add: aci aci: (targetattr=*)(targetfilter=(|(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)))(version 3.0; aci permission:Read Replication Agreements; allow (read, search, compare) groupdn = ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX;) dn: cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX changetype: add objectClass: top objectClass: groupofnames objectClass: ipapermission cn: Read Replication Agreements ipapermissiontype: SYSTEM Note that you'll need to replace $SUFFIX with your base dn (dc=example,dc=com). This is untested so YMMV. If you find that it works and is useful please let us know, maybe we can add this for everyone to enjoy :-) rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
