subject:"\[Freeipa\-users\] Replication status"

Re: [Freeipa-users] Replication status

2012-05-21 Thread Natxo Asenjo

On Mon, May 21, 2012 at 3:21 PM, Rich Megginson  wrote:

> On 05/21/2012 07:13 AM, Dan Scott wrote:
>
>>
>>

> https://fedorahosted.org/**freeipa/ticket/2770
>>
>> I've modified the nagios perl script that I got from:
>>
>> http://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

2012-05-21 Thread Rich Megginson


On 05/21/2012 07:13 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 10:29 AM, Rich Megginson  wrote:

On 05/18/2012 08:13 AM, Dan Scott wrote:

Hi,

On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
  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.

OK, done.

https://fedorahosted.org/freeipa/ticket/2770

I've modified the nagios perl script that I got from:

http://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.


Dan


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

Re: [Freeipa-users] Replication status

2012-05-21 Thread Dan Scott

On Fri, May 18, 2012 at 10:29 AM, Rich Megginson  wrote:
> On 05/18/2012 08:13 AM, Dan Scott wrote:
>>
>> Hi,
>>
>> On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
>>  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.

OK, done.

https://fedorahosted.org/freeipa/ticket/2770

I've modified the nagios perl script that I got from:

http://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?

Dan

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

Re: [Freeipa-users] Replication status

2012-05-18 Thread Rich Megginson


On 05/18/2012 12:05 PM, Dan Scott wrote:

On Fri, May 18, 2012 at 1:52 PM, Rich Megginson  wrote:

On 05/18/2012 11:46 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 12:38 PM, Rich Megginson
  wrote:

On 05/18/2012 10:31 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 12:21 PM, Rich Megginson
  wrote:

On 05/18/2012 10:06 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 10:29 AM, Rich Megginson
  wrote:

On 05/18/2012 08:13 AM, Dan Scott wrote:

Hi,

On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
  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
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Adminis

Re: [Freeipa-users] Replication status

2012-05-18 Thread Dan Scott

On Fri, May 18, 2012 at 1:52 PM, Rich Megginson  wrote:
> On 05/18/2012 11:46 AM, Dan Scott wrote:
>>
>> On Fri, May 18, 2012 at 12:38 PM, Rich Megginson
>>  wrote:
>>>
>>> On 05/18/2012 10:31 AM, Dan Scott wrote:

 On Fri, May 18, 2012 at 12:21 PM, Rich Megginson
  wrote:
>
> On 05/18/2012 10:06 AM, Dan Scott wrote:
>>
>> On Fri, May 18, 2012 at 10:29 AM, Rich Megginson
>>  wrote:
>>>
>>> On 05/18/2012 08:13 AM, Dan Scott wrote:

 Hi,

 On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
  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

Re: [Freeipa-users] Replication status

2012-05-18 Thread Rich Megginson


On 05/18/2012 11:46 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 12:38 PM, Rich Megginson  wrote:

On 05/18/2012 10:31 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 12:21 PM, Rich Megginson
  wrote:

On 05/18/2012 10:06 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 10:29 AM, Rich Megginson
  wrote:

On 05/18/2012 08:13 AM, Dan Scott wrote:

Hi,

On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
  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

2012-05-18 Thread Dan Scott

On Fri, May 18, 2012 at 12:38 PM, Rich Megginson  wrote:
> On 05/18/2012 10:31 AM, Dan Scott wrote:
>>
>> On Fri, May 18, 2012 at 12:21 PM, Rich Megginson
>>  wrote:
>>>
>>> On 05/18/2012 10:06 AM, Dan Scott wrote:

 On Fri, May 18, 2012 at 10:29 AM, Rich Megginson
  wrote:
>
> On 05/18/2012 08:13 AM, Dan Scott wrote:
>>
>> Hi,
>>
>> On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
>>  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?

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

Re: [Freeipa-users] Replication status

2012-05-18 Thread Rich Megginson


On 05/18/2012 10:31 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 12:21 PM, Rich Megginson  wrote:

On 05/18/2012 10:06 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 10:29 AM, Rich Megginson
  wrote:

On 05/18/2012 08:13 AM, Dan Scott wrote:

Hi,

On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
  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

2012-05-18 Thread Dan Scott

On Fri, May 18, 2012 at 12:21 PM, Rich Megginson  wrote:
> On 05/18/2012 10:06 AM, Dan Scott wrote:
>>
>> On Fri, May 18, 2012 at 10:29 AM, Rich Megginson
>>  wrote:
>>>
>>> On 05/18/2012 08:13 AM, Dan Scott wrote:

 Hi,

 On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
  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

2012-05-18 Thread Rich Megginson


On 05/18/2012 10:06 AM, Dan Scott wrote:

On Fri, May 18, 2012 at 10:29 AM, Rich Megginson  wrote:

On 05/18/2012 08:13 AM, Dan Scott wrote:

Hi,

On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
  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 . . .



Thanks,

Dan


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

Re: [Freeipa-users] Replication status

2012-05-18 Thread Dan Scott

On Fri, May 18, 2012 at 10:29 AM, Rich Megginson  wrote:
> On 05/18/2012 08:13 AM, Dan Scott wrote:
>>
>> Hi,
>>
>> On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden
>>  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

2012-05-18 Thread Rich Megginson


On 05/18/2012 08:13 AM, Dan Scott wrote:

Hi,

On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden  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

2012-05-18 Thread Dan Scott

Hi,

On Wed, May 2, 2012 at 11:13 PM, Rob Crittenden  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

2012-05-03 Thread JR Aquino

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 
> 93117
> T:  +1 805.690.3478
> C: +1 805.717.0365
> jr.aqu...@citrixonline.com
> http://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.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

2012-05-03 Thread JR Aquino

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 
93117
T:  +1 805.690.3478
C: +1 805.717.0365
jr.aqu...@citrixonline.com
http://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.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

2012-05-02 Thread Rob Crittenden


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

Re: [Freeipa-users] Replication status

2012-05-02 Thread Rich Megginson


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

2012-05-02 Thread Ian Levesque

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


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

Re: [Freeipa-users] Replication status

2012-05-02 Thread Rich Megginson


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

2012-05-02 Thread Ian Levesque

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?

Thanks,
Ian

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

Re: [Freeipa-users] Replication status

2012-05-02 Thread Dmitri Pal

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

2012-05-02 Thread Dan Scott

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

[Freeipa-users] Replication status

2012-05-02 Thread Ian Levesque

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

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

Re: [Freeipa-users] Replication status

[Freeipa-users] Replication status

23 matches

Site Navigation

Mail list logo

Footer information