[389-users] Re: SIEM Audit Data
Have you looked at the audit logs ? Use the below ldif to enable them. dn: cn=config changetype: modify replace: nsslapd-auditlog-logging-enabled nsslapd-auditlog-logging-enabled: on This will write to 'audit' file in the same dir as 'access' and 'errors' log file. On 14 October 2016 at 02:20, Paul Robert Marino wrote: > user authentication errors are usually recorded on the client end. > > On Thu, Oct 13, 2016 at 4:47 PM, Jason Nielsen wrote: > > Im looking for ways to pull a number of audit events from 389. Such as: > > > > -User authentication success and failures. > > -Group additions, removals and changes. > > -User additions, removals and possibly changes. > > > > Details in each of these would include items such as: > > > > username > > groupname > > attribute changed > > timestamp of event > > action > > > > Sending these out via syslog formatted messages is the preferred route. > > > > I have not been able to find anything definitive in how to do this. Debug > > logs seem to lack much of this or contain far too much information making > > the prohibitive to use. They are also formatted in such a way making it > > extremely difficult to process in any practical way. For example, you > would > > probably need a full LDIF interpreter to reformat them on the fly. I > assume > > I either have not dug far enough or simply digging in the wrong > direction. > > > > Is anyone out there doing something similar and pulling the above data > into > > a SIEM? If so would you be willing to share your experience on the topic > or > > point me in the right direction? > > > > Thanks! > > > > ___ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > ___ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
[389-users] REST API
http://directory.fedoraproject.org/docs/389ds/design/ldap-rest-api.html I found this document related to REST API for 389 DS. Is this a proposed feature in an upcoming release ? Where can I find more details ? Thanks. --Prashant -- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
[389-users] Re: Weird issue with searching cn=config
Thanks all for the inputs. Its finally working now. Somehow the ldapmodify command was not adding the aci to the localhost. I guess in other servers this was added thru replication but not on this one. Finally below command is what fixed it. ldapmodify -h localhost -D "cn=directory manager" -W -f repl-status-aci.ldif I was not specifying "-h localhost" previously. Btw it works both with groupdn = "ldap:///anyone"; as well as userdn = "ldap:///anyone"; Appreciate all the help. Thanks. --Prashant On 18 January 2016 at 21:57, Ludwig Krispenz wrote: > > On 01/18/2016 05:19 PM, Rob Crittenden wrote: > >> Prashant Bapat wrote: >> >>> Not actually. When I read the replication status as "directory manager" >>> I can see the agreements. It really boils down to the aci issue now. >>> >> What confuses me is the ldif using replace. What were you replacing? Can >> you search for the actual installed ACI? >> >> I'd have used userdn = "ldap://anyone"; and not groupdn. I'm not sure if >> that is the problem or not. >> > great eyes :-) > should be userdn > > >> rob >> >> On 18 January 2016 at 21:45, Ludwig Krispenz >> <mailto:lkris...@redhat.com>> wrote: >>> >>> >>> On 01/18/2016 05:09 PM, Prashant Bapat wrote: >>> >>>> Indeed! When I specify -h localhost it returns empty result. >>>> >>> this indicates that you really don't have a replication agreement on >>> this server, the search without localhost goes to another server. >>> You can check by looking into the config file: >>> /etc/dirsrv/slapd-/dse.ldif >>> >>> >>> So here is the problem. I have the below aci to read the >>>> replication status anonymously. >>>> >>>> dn: cn=mapping tree,cn=config >>>> changetype: modify >>>> replace: aci >>>> aci: >>>> >>>> (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement) >>>>(objectclass=nsDSWindowsReplicationAgreement))")(version 3.0; aci >>>>"permission:Read Replication Agreements"; allow (read, search, >>>> compare) >>>>groupdn = "ldap:///anyone";;) >>>> >>>> I have the exact same aci which seems to work on my other servers. >>>> But on this one server its not working. I have double checked that >>>> the aci is present. Also, I'm able to read the replication status >>>> as "directory manager". >>>> >>>> Any help appreciated. >>>> >>>> Thanks. >>>> --Prashant >>>> >>>> >>>> >>>> On 18 January 2016 at 20:45, Ludwig Krispenz >>> <mailto:lkris...@redhat.com>> wrote: >>>> >>>> >>>> On 01/18/2016 01:12 PM, Prashant Bapat wrote: >>>> >>>>> It does. >>>>> >>>>> Running the ldapsearch command gives me the expected output. >>>>> Below is what I'm running. >>>>> >>>>> $ ldapsearch -x -b cn=config >>>>> '(objectclass=nsds5replicationagreement)' >>>>> nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no >>>>> dn: cn=meToipa2.example.com >>>>> <http://meToipa2.example.com >>>>> >,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>>>> tree,cn=config >>>>> nsds5replicaLastUpdateStatus: 0 Replica acquired >>>>> successfully: Incremental update succeeded >>>>> >>>>> dn: cn=meToipa3.example.com >>>>> <http://meToipa3.example.com >>>>> >,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>>>> tree,cn=config >>>>> nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica >>>>> >>>>> dn: cn=meToipa4.example.com >>>>> <http://meToipa4.example.com >>>>> >,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping >>>>> tree,cn=config >>>>> nsds5replicaLastUpdateStatus: 0 Replica acquired >>>>> successfully: Incremental update succeeded >>>&
[389-users] Re: Weird issue with searching cn=config
Not actually. When I read the replication status as "directory manager" I
can see the agreements. It really boils down to the aci issue now.
On 18 January 2016 at 21:45, Ludwig Krispenz wrote:
>
> On 01/18/2016 05:09 PM, Prashant Bapat wrote:
>
> Indeed! When I specify -h localhost it returns empty result.
>
> this indicates that you really don't have a replication agreement on this
> server, the search without localhost goes to another server.
> You can check by looking into the config file:
> /etc/dirsrv/slapd-/dse.ldif
>
>
>
> So here is the problem. I have the below aci to read the replication
> status anonymously.
>
> dn: cn=mapping tree,cn=config
> changetype: modify
> replace: aci
> aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)
> (objectclass=nsDSWindowsReplicationAgreement))")(version 3.0; aci
> "permission:Read Replication Agreements"; allow (read, search, compare)
> groupdn = "ldap:///anyone";;)
>
> I have the exact same aci which seems to work on my other servers. But on
> this one server its not working. I have double checked that the aci is
> present. Also, I'm able to read the replication status as "directory
> manager".
>
> Any help appreciated.
>
> Thanks.
> --Prashant
>
>
>
> On 18 January 2016 at 20:45, Ludwig Krispenz wrote:
>
>>
>> On 01/18/2016 01:12 PM, Prashant Bapat wrote:
>>
>> It does.
>>
>> Running the ldapsearch command gives me the expected output. Below is
>> what I'm running.
>>
>> $ ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)'
>> nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no
>> dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
>> tree,cn=config
>> nsds5replicaLastUpdateStatus: 0 Replica acquired successfully:
>> Incremental update succeeded
>>
>> dn: cn=meToipa3.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
>> tree,cn=config
>> nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica
>>
>> dn: cn=meToipa4.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
>> tree,cn=config
>> nsds5replicaLastUpdateStatus: 0 Replica acquired successfully:
>> Incremental update succeeded
>>
>> This also indicates that the aci is proper.
>>
>> are you sure ldapsearch runs against the same server ? If you don't
>> specify -H or -h -p it could take the target from the ldap.conf
>>
>>
>> Thanks.
>> --Prashant
>>
>> On 18 January 2016 at 14:01, William Brown wrote:
>>
>>> On Mon, 2016-01-18 at 12:53 +0530, Prashant Bapat wrote:
>>> > Hi,
>>> >
>>> > There close to a dozen 389-DS as part of our FreeIPA infra. On one of
>>> > these
>>> > servers, I'm encountering a strange problem.
>>> >
>>> > We monitor the state of replication among the 389 servers using a
>>> > python-ldap based script. This works on all servers except 1.
>>> >
>>> > What I'm doing is fairly basic. Something along lines of ;
>>> >
>>> > ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)'
>>> > nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no
>>> >
>>> > Corresponding python code is below;
>>> >
>>> > conn.search_s("cn=config" ,ldap.SCOPE_SUBTREE,
>>> > '(objectclass=nsds5replicationagreement)', ["nsDS5ReplicaHost",
>>> > "nsds5replicaLastUpdateStatus", "nsds5replicaLastUpdateStart",
>>> > "nsds5replicaLastUpdateEnd"])
>>> >
>>> > Now for the strange issue.
>>> >
>>> > The above commands return the status of replication on all servers
>>> > except 1
>>> > which returns an empty response. This happens only for the python and
>>> > the
>>> > example perl script here
>>> > <http://directory.fedoraproject.org/docs/389ds/howto/howto-replicatio
>>> > nmonitoring.html>.
>>> > The ldapsearch command works fine!!!
>>> >
>>> > Below is the log from a server where this runs fine.
>>> >
>>> > [18/Jan/2016:07:09:19 +] conn=420951 fd=564 slot=564 connection
>>> > from
>>> > ::1 to ::1
>>> > [18/Jan/2016:07:09:19 +] conn=420951 op=0 BIND dn="" method=128
>>> > version=3
>>> > [18/Jan/2016:07:09:19 +] conn=420951 op=0 RE
[389-users] Re: Weird issue with searching cn=config
Indeed! When I specify -h localhost it returns empty result.
So here is the problem. I have the below aci to read the replication status
anonymously.
dn: cn=mapping tree,cn=config
changetype: modify
replace: aci
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5replicationagreement)
(objectclass=nsDSWindowsReplicationAgreement))")(version 3.0; aci
"permission:Read Replication Agreements"; allow (read, search, compare)
groupdn = "ldap:///anyone";;)
I have the exact same aci which seems to work on my other servers. But on
this one server its not working. I have double checked that the aci is
present. Also, I'm able to read the replication status as "directory
manager".
Any help appreciated.
Thanks.
--Prashant
On 18 January 2016 at 20:45, Ludwig Krispenz wrote:
>
> On 01/18/2016 01:12 PM, Prashant Bapat wrote:
>
> It does.
>
> Running the ldapsearch command gives me the expected output. Below is what
> I'm running.
>
> $ ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)'
> nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no
> dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
> tree,cn=config
> nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental
> update succeeded
>
> dn: cn=meToipa3.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
> tree,cn=config
> nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica
>
> dn: cn=meToipa4.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
> tree,cn=config
> nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental
> update succeeded
>
> This also indicates that the aci is proper.
>
> are you sure ldapsearch runs against the same server ? If you don't
> specify -H or -h -p it could take the target from the ldap.conf
>
>
> Thanks.
> --Prashant
>
> On 18 January 2016 at 14:01, William Brown wrote:
>
>> On Mon, 2016-01-18 at 12:53 +0530, Prashant Bapat wrote:
>> > Hi,
>> >
>> > There close to a dozen 389-DS as part of our FreeIPA infra. On one of
>> > these
>> > servers, I'm encountering a strange problem.
>> >
>> > We monitor the state of replication among the 389 servers using a
>> > python-ldap based script. This works on all servers except 1.
>> >
>> > What I'm doing is fairly basic. Something along lines of ;
>> >
>> > ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)'
>> > nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no
>> >
>> > Corresponding python code is below;
>> >
>> > conn.search_s("cn=config" ,ldap.SCOPE_SUBTREE,
>> > '(objectclass=nsds5replicationagreement)', ["nsDS5ReplicaHost",
>> > "nsds5replicaLastUpdateStatus", "nsds5replicaLastUpdateStart",
>> > "nsds5replicaLastUpdateEnd"])
>> >
>> > Now for the strange issue.
>> >
>> > The above commands return the status of replication on all servers
>> > except 1
>> > which returns an empty response. This happens only for the python and
>> > the
>> > example perl script here
>> > <http://directory.fedoraproject.org/docs/389ds/howto/howto-replicatio
>> > nmonitoring.html>.
>> > The ldapsearch command works fine!!!
>> >
>> > Below is the log from a server where this runs fine.
>> >
>> > [18/Jan/2016:07:09:19 +] conn=420951 fd=564 slot=564 connection
>> > from
>> > ::1 to ::1
>> > [18/Jan/2016:07:09:19 +] conn=420951 op=0 BIND dn="" method=128
>> > version=3
>> > [18/Jan/2016:07:09:19 +] conn=420951 op=0 RESULT err=0 tag=97
>> > nentries=0 etime=0 dn=""
>> > [18/Jan/2016:07:09:19 +] conn=420951 op=1 SRCH base="cn=config"
>> > scope=2
>> > filter="(objectClass=nsds5replicationagreement)"
>> > attrs="nsDS5ReplicaHost
>> > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart
>> > nsds5replicaLastUpdateEnd"
>> > [18/Jan/2016:07:09:19 +] conn=420951 op=1 RESULT err=0 tag=101
>> > nentries=3 etime=0
>> > [18/Jan/2016:07:09:19 +] conn=420951 op=2 UNBIND
>> > [18/Jan/2016:07:09:19 +] conn=420951 op=2 fd=564 closed - U1
>> >
>> > Below is the log from the 1 server where this fails.
>> >
>> > [18/Jan/2016:07:05:20 +] conn=226 fd=80 slot=80 connection from
>> > ::1 to
>> > ::1
>> > [18/Jan/2016:07:05:20 +] conn=
[389-users] Re: Weird issue with searching cn=config
It does.
Running the ldapsearch command gives me the expected output. Below is what
I'm running.
$ ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)'
nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no
dn: cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental
update succeeded
dn: cn=meToipa3.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
nsds5replicaLastUpdateStatus: 1 Can't acquire busy replica
dn: cn=meToipa4.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
tree,cn=config
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental
update succeeded
This also indicates that the aci is proper.
Thanks.
--Prashant
On 18 January 2016 at 14:01, William Brown wrote:
> On Mon, 2016-01-18 at 12:53 +0530, Prashant Bapat wrote:
> > Hi,
> >
> > There close to a dozen 389-DS as part of our FreeIPA infra. On one of
> > these
> > servers, I'm encountering a strange problem.
> >
> > We monitor the state of replication among the 389 servers using a
> > python-ldap based script. This works on all servers except 1.
> >
> > What I'm doing is fairly basic. Something along lines of ;
> >
> > ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)'
> > nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no
> >
> > Corresponding python code is below;
> >
> > conn.search_s("cn=config" ,ldap.SCOPE_SUBTREE,
> > '(objectclass=nsds5replicationagreement)', ["nsDS5ReplicaHost",
> > "nsds5replicaLastUpdateStatus", "nsds5replicaLastUpdateStart",
> > "nsds5replicaLastUpdateEnd"])
> >
> > Now for the strange issue.
> >
> > The above commands return the status of replication on all servers
> > except 1
> > which returns an empty response. This happens only for the python and
> > the
> > example perl script here
> > <http://directory.fedoraproject.org/docs/389ds/howto/howto-replicatio
> > nmonitoring.html>.
> > The ldapsearch command works fine!!!
> >
> > Below is the log from a server where this runs fine.
> >
> > [18/Jan/2016:07:09:19 +] conn=420951 fd=564 slot=564 connection
> > from
> > ::1 to ::1
> > [18/Jan/2016:07:09:19 +] conn=420951 op=0 BIND dn="" method=128
> > version=3
> > [18/Jan/2016:07:09:19 +] conn=420951 op=0 RESULT err=0 tag=97
> > nentries=0 etime=0 dn=""
> > [18/Jan/2016:07:09:19 +] conn=420951 op=1 SRCH base="cn=config"
> > scope=2
> > filter="(objectClass=nsds5replicationagreement)"
> > attrs="nsDS5ReplicaHost
> > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart
> > nsds5replicaLastUpdateEnd"
> > [18/Jan/2016:07:09:19 +] conn=420951 op=1 RESULT err=0 tag=101
> > nentries=3 etime=0
> > [18/Jan/2016:07:09:19 +] conn=420951 op=2 UNBIND
> > [18/Jan/2016:07:09:19 +] conn=420951 op=2 fd=564 closed - U1
> >
> > Below is the log from the 1 server where this fails.
> >
> > [18/Jan/2016:07:05:20 +] conn=226 fd=80 slot=80 connection from
> > ::1 to
> > ::1
> > [18/Jan/2016:07:05:20 +] conn=226 op=0 BIND dn="" method=128
> > version=3
> > [18/Jan/2016:07:05:20 +] conn=226 op=0 RESULT err=0 tag=97
> > nentries=0
> > etime=0 dn=""
> > [18/Jan/2016:07:05:20 +] conn=226 op=1 SRCH base="cn=config"
> > scope=2
> > filter="(objectClass=nsds5replicationagreement)"
> > attrs="nsDS5ReplicaHost
> > nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart
> > nsds5replicaLastUpdateEnd"
> > [18/Jan/2016:07:05:20 +] conn=226 op=1 RESULT err=0 tag=101
> > nentries=0
> > etime=0
> > [18/Jan/2016:07:05:20 +] conn=226 op=2 UNBIND
> > [18/Jan/2016:07:05:20 +] conn=226 op=2 fd=80 closed - U1
> >
> > I have an ACI which allows anonymous access to the replication info.
> >
> > Version is : 389-ds-base-1.3.3.13-1.fc21.x86_64
> >
> > Any help would be appreciated.
> >
> > Thanks.
> > --Prashant
> > --
> > 389 users mailing list
> > 389-users@%(host_name)s
> > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproj
> > ect.org
>
>
> The obvious first check is, does the server actually have a valid
> replication agreement? You can check this by looking at
> /etc/dirsrv/slapd-INSTANCE_NAME/dse.ldif.
>
> Second, check the aci on the server.
>
> Hope this helps.
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Brisbane
>
>
> --
> 389 users mailing list
> 389-users@%(host_name)s
>
> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
>
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
[389-users] Weird issue with searching cn=config
Hi,
There close to a dozen 389-DS as part of our FreeIPA infra. On one of these
servers, I'm encountering a strange problem.
We monitor the state of replication among the 389 servers using a
python-ldap based script. This works on all servers except 1.
What I'm doing is fairly basic. Something along lines of ;
ldapsearch -x -b cn=config '(objectclass=nsds5replicationagreement)'
nsds5replicaLastUpdateStatus -LLL -o ldif-wrap=no
Corresponding python code is below;
conn.search_s("cn=config" ,ldap.SCOPE_SUBTREE,
'(objectclass=nsds5replicationagreement)', ["nsDS5ReplicaHost",
"nsds5replicaLastUpdateStatus", "nsds5replicaLastUpdateStart",
"nsds5replicaLastUpdateEnd"])
Now for the strange issue.
The above commands return the status of replication on all servers except 1
which returns an empty response. This happens only for the python and the
example perl script here
.
The ldapsearch command works fine!!!
Below is the log from a server where this runs fine.
[18/Jan/2016:07:09:19 +] conn=420951 fd=564 slot=564 connection from
::1 to ::1
[18/Jan/2016:07:09:19 +] conn=420951 op=0 BIND dn="" method=128
version=3
[18/Jan/2016:07:09:19 +] conn=420951 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn=""
[18/Jan/2016:07:09:19 +] conn=420951 op=1 SRCH base="cn=config" scope=2
filter="(objectClass=nsds5replicationagreement)" attrs="nsDS5ReplicaHost
nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart
nsds5replicaLastUpdateEnd"
[18/Jan/2016:07:09:19 +] conn=420951 op=1 RESULT err=0 tag=101
nentries=3 etime=0
[18/Jan/2016:07:09:19 +] conn=420951 op=2 UNBIND
[18/Jan/2016:07:09:19 +] conn=420951 op=2 fd=564 closed - U1
Below is the log from the 1 server where this fails.
[18/Jan/2016:07:05:20 +] conn=226 fd=80 slot=80 connection from ::1 to
::1
[18/Jan/2016:07:05:20 +] conn=226 op=0 BIND dn="" method=128 version=3
[18/Jan/2016:07:05:20 +] conn=226 op=0 RESULT err=0 tag=97 nentries=0
etime=0 dn=""
[18/Jan/2016:07:05:20 +] conn=226 op=1 SRCH base="cn=config" scope=2
filter="(objectClass=nsds5replicationagreement)" attrs="nsDS5ReplicaHost
nsds5replicaLastUpdateStatus nsds5replicaLastUpdateStart
nsds5replicaLastUpdateEnd"
[18/Jan/2016:07:05:20 +] conn=226 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[18/Jan/2016:07:05:20 +] conn=226 op=2 UNBIND
[18/Jan/2016:07:05:20 +] conn=226 op=2 fd=80 closed - U1
I have an ACI which allows anonymous access to the replication info.
Version is : 389-ds-base-1.3.3.13-1.fc21.x86_64
Any help would be appreciated.
Thanks.
--Prashant
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
Re: [389-users] Random dirsrv freezes and high CLOSE_WAITs
Thanks German!
Let me try that and see.
On 13 October 2015 at 01:11, German Parente wrote:
>
>
> - Original Message -
> > From: "Rich Megginson"
> > To: 389-users@lists.fedoraproject.org
> > Sent: Saturday, October 3, 2015 12:49:38 AM
> > Subject: Re: [389-users] Random dirsrv freezes and high CLOSE_WAITs
> >
> > On 10/02/2015 10:59 AM, Prashant Bapat wrote:
> >
> >
> >
> > Hi
> >
> > Attached is the gdb output from both the servers. This was taken using
> the
> > following command.
> >
> > gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply all
> bt
> > full' -ex 'quit' /usr/sbin/ns-slapd `pidof ns-slapd`
> >
> > Version of 389 DS is : 389-ds-base-1.3.3.8-1.fc21.x86_64
> >
> > Any help is appreciated. This has been happening in our setup every
> > 10-14days.
> >
> > This is definitely some sort of hang with 389/slapi-nis. Please open a
> > ticket, and attach these stacktraces to the ticket as attachments.
> > https://fedorahosted.org/389/newticket
> >
>
> Hi,
>
> It's possible to workaround this issue by setting nsslapd-ioblocktimeout
> to a small value as 3 milliseconds, for instance.
>
> Regards.
>
> German.
>
>
> >
> >
> >
> >
> >
> >
> > Thanks.
> > --Prashant
> >
> > On 3 September 2015 at 10:42, Prashant Bapat < prash...@apigee.com >
> wrote:
> >
> >
> >
> > No nothing much in the error log.
> >
> > Let me wait for the next occurrence and get gdb.
> >
> > On 3 September 2015 at 22:11, Rich Megginson < rmegg...@redhat.com >
> wrote:
> >
> >
> >
> > On 09/03/2015 09:02 AM, Prashant Bapat wrote:
> >
> >
> >
> > Rich,
> >
> > Version is 389-ds-base-1.3.3.8-1.fc21.x86_64
> >
> > Below is the "ldapsearch" command that works on the LDAP server.
> >
> >
> >
> >
> > ldapsearch -x -b "uid=testuser,cn=users,cn=accounts,dc=example,dc=com"
> >
> > In python this would be
> >
> > ldap.initialize( "ldap://localhost"; ) [1]
> > conn.simple_bind_s() [2]
> > response = conn.search_s(
> > "uid=testuser,cn=users,cn=accounts,dc=example,dc=com" ,ldap.SCOPE_BASE)
> [3]
> >
> > [1] is different than " ipa.example.com " - so one possibility is that
> DNS is
> > not working correctly due to DS - but it depends on where the script is
> hung
> > [2] is the same - anonymous bind
> > [3] assuming uid is "testuser", then the base is the same in your python
> > script - however, in your python script, you are asking for a specific
> > attribute list ["ipaSshPubKey", "ipaSshSigTimestamp", "loginshell"] - not
> > sure why that would make a difference
> >
> > So, inconclusive. Will need to see the stacktrace from gdb when the
> server is
> > hung.
> >
> > Also, do you have any errors in the errors log?
> >
> >
> >
> >
> >
> > Below is an excerpt of the python script.
> >
> >
> >
> >
> > #!/usr/bin/env python
> > import sys
> > import ldap
> > from ldap import LDAPError
> >
> > SUFFIX = "dc=example,dc=com"
> > LDAPSERVER = " ipa.example.com "
> >
> > if not len(sys.argv) == 2:
> > raise sys.exit("Wrong arguments. Only argument should be the username")
> >
> > uid = sys.argv[1]
> > search = "uid=%s,cn=users,cn=accounts,%s" % (uid, SUFFIX)
> >
> > try:
> > conn = ldap.initialize( "ldap://%s"; % (LDAPSERVER))
> > conn.simple_bind_s()
> > response = conn.search_s(search ,ldap.SCOPE_BASE, "(objectClass=*)",
> > ["ipaSshPubKey", "ipaSshSigTimestamp", "loginshell"])
> > except LDAPError, e:
> > print e
> > print "Error getting info from LDAP. Either wrong username or issues with
> > LDAP server "
> > raise sys.exit(-1)
> >
> >
> >
> > On 3 September 2015 at 19:17, Rich Megginson < rmegg...@redhat.com >
> wrote:
> >
> >
> >
> > On 09/02/2015 09:45 PM, Prashant Bapat wrote:
> >
> >
> >
> > Hi,
> >
> > We have been using 389-ds as part of FreeIPA. In one of our
> environments, we
> > have 2 389-ds installations with replication.
> >
> > What version? rpm -q 389-ds-base
> >
> >
> >
>
Re: [389-users] Random dirsrv freezes and high CLOSE_WAITs
No nothing much in the error log.
Let me wait for the next occurrence and get gdb.
On 3 September 2015 at 22:11, Rich Megginson wrote:
> On 09/03/2015 09:02 AM, Prashant Bapat wrote:
>
> Rich,
>
> Version is 389-ds-base-1.3.3.8-1.fc21.x86_64
>
> Below is the "ldapsearch" command that works on the LDAP server.
>
> ldapsearch -x -b "uid=testuser,cn=users,cn=accounts,dc=example,dc=com"
>
>
> In python this would be
>
> ldap.initialize("ldap://localhost";) [1]
> conn.simple_bind_s() [2]
> response = conn.search_s(
> "uid=testuser,cn=users,cn=accounts,dc=example,dc=com",ldap.SCOPE_BASE) [3]
>
> [1] is different than "ipa.example.com" - so one possibility is that DNS
> is not working correctly due to DS - but it depends on where the script is
> hung
> [2] is the same - anonymous bind
> [3] assuming uid is "testuser", then the base is the same in your python
> script - however, in your python script, you are asking for a specific
> attribute list ["ipaSshPubKey", "ipaSshSigTimestamp", "loginshell"] - not
> sure why that would make a difference
>
> So, inconclusive. Will need to see the stacktrace from gdb when the
> server is hung.
>
> Also, do you have any errors in the errors log?
>
>
> Below is an excerpt of the python script.
>
> #!/usr/bin/env python
> import sys
> import ldap
> from ldap import LDAPError
>
> SUFFIX = "dc=example,dc=com"
> LDAPSERVER = "ipa.example.com"
>
> if not len(sys.argv) == 2:
> raise sys.exit("Wrong arguments. Only argument should be the username")
>
> uid = sys.argv[1]
> search = "uid=%s,cn=users,cn=accounts,%s" % (uid, SUFFIX)
>
> try:
> conn = ldap.initialize("ldap://%s"; % (LDAPSERVER))
> conn.simple_bind_s()
> response = conn.search_s(search ,ldap.SCOPE_BASE, "(objectClass=*)",
> ["ipaSshPubKey", "ipaSshSigTimestamp", "loginshell"])
> except LDAPError, e:
> print e
> print "Error getting info from LDAP. Either wrong username or issues
> with LDAP server "
> raise sys.exit(-1)
>
>
>
>
> On 3 September 2015 at 19:17, Rich Megginson wrote:
>
>> On 09/02/2015 09:45 PM, Prashant Bapat wrote:
>>
>> Hi,
>>
>> We have been using 389-ds as part of FreeIPA. In one of our environments,
>> we have 2 389-ds installations with replication.
>>
>>
>> What version? rpm -q 389-ds-base
>>
>>
>> Randomly, the 389-ds on either of them completely freezes and there are
>> high number of CLOSE_WAITs on tcp/389 port.
>>
>>
>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>>
>>
>> Only way to recover from this situation is to either reboot or "kill -9"
>> the ns-slapd process. Graceful restarts get stuck indefinitely.
>>
>> One curious thing when this happens, a search using "ldapsearch" command
>> seems to work but a search using a python-ldap client does not. FreeIPA
>> does not work either.
>>
>>
>> Can you be more specific? What is the exact ldapsearch command line, and
>> can you post/pastebin an excerpt of your python-ldap script?
>>
>>
>> Any pointers on troubleshooting this would be appreciated.
>>
>> Thanks.
>> --Prashant
>>
>>
>> --
>> 389 users mailing
>> list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>
>
>
> --
> 389 users mailing
> list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Random dirsrv freezes and high CLOSE_WAITs
Rich,
Version is 389-ds-base-1.3.3.8-1.fc21.x86_64
Below is the "ldapsearch" command that works on the LDAP server.
ldapsearch -x -b "uid=testuser,cn=users,cn=accounts,dc=example,dc=com"
Below is an excerpt of the python script.
#!/usr/bin/env python
import sys
import ldap
from ldap import LDAPError
SUFFIX = "dc=example,dc=com"
LDAPSERVER = "ipa.example.com"
if not len(sys.argv) == 2:
raise sys.exit("Wrong arguments. Only argument should be the username")
uid = sys.argv[1]
search = "uid=%s,cn=users,cn=accounts,%s" % (uid, SUFFIX)
try:
conn = ldap.initialize("ldap://%s"; % (LDAPSERVER))
conn.simple_bind_s()
response = conn.search_s(search ,ldap.SCOPE_BASE, "(objectClass=*)",
["ipaSshPubKey", "ipaSshSigTimestamp", "loginshell"])
except LDAPError, e:
print e
print "Error getting info from LDAP. Either wrong username or issues
with LDAP server "
raise sys.exit(-1)
On 3 September 2015 at 19:17, Rich Megginson wrote:
> On 09/02/2015 09:45 PM, Prashant Bapat wrote:
>
> Hi,
>
> We have been using 389-ds as part of FreeIPA. In one of our environments,
> we have 2 389-ds installations with replication.
>
>
> What version? rpm -q 389-ds-base
>
>
> Randomly, the 389-ds on either of them completely freezes and there are
> high number of CLOSE_WAITs on tcp/389 port.
>
>
> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs
>
>
> Only way to recover from this situation is to either reboot or "kill -9"
> the ns-slapd process. Graceful restarts get stuck indefinitely.
>
> One curious thing when this happens, a search using "ldapsearch" command
> seems to work but a search using a python-ldap client does not. FreeIPA
> does not work either.
>
>
> Can you be more specific? What is the exact ldapsearch command line, and
> can you post/pastebin an excerpt of your python-ldap script?
>
>
> Any pointers on troubleshooting this would be appreciated.
>
> Thanks.
> --Prashant
>
>
> --
> 389 users mailing
> list389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Random dirsrv freezes and high CLOSE_WAITs
Hi, We have been using 389-ds as part of FreeIPA. In one of our environments, we have 2 389-ds installations with replication. Randomly, the 389-ds on either of them completely freezes and there are high number of CLOSE_WAITs on tcp/389 port. Only way to recover from this situation is to either reboot or "kill -9" the ns-slapd process. Graceful restarts get stuck indefinitely. One curious thing when this happens, a search using "ldapsearch" command seems to work but a search using a python-ldap client does not. FreeIPA does not work either. Any pointers on troubleshooting this would be appreciated. Thanks. --Prashant -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Not able to enable audit logs
There is no error. It goes thru fine. When I restart the LDAP server after adding it, there is nothing in the audit file. And no entry in the dse.ldif. On 15 June 2015 at 13:39, German Parente wrote: > Hi Prashant, > > it should work in the same way. Are you having an error doing your > ldapmodify ? > > > There's not a specific entry for nsslapd-auditlog-logging-enabled. > > nsslapd-auditlog-logging-enabled is an attribute of cn=config entry. > > You should be able to query it by this command: > > ldapsearch -xLLL -D "cn=directory manager" -W -b "cn=config" -s base > nsslapd-auditlog-logging-enabled > dn: cn=config > nsslapd-auditlog-logging-enabled: on > > Regards, > > German. > > > - Original Message - > > From: "Prashant Bapat" > > To: "389-users" <389-users@lists.fedoraproject.org> > > Sent: Monday, June 15, 2015 9:56:48 AM > > Subject: [389-users] Not able to enable audit logs > > > > Hi, > > > > I have a setup of master-master replicated 389 DS installations as part > of > > FreeIPA. > > > > This is the version of the 389-ds : 389-ds-base-1.3.3.8-1.fc21.x86_64 > > > > On 1st server, I was able to enable the audit logs using the following > LDIF. > > > > > > > > > > dn: cn=config > > changetype: modify > > replace: nsslapd-auditlog-logging-enabled > > nsslapd-auditlog-logging-enabled: on > > > > However, the same LDIF when I run on the second server (which is the > > replicated master) the audit logs never get enabled. I'm not able to find > > the nsslapd-auditlog-logging-enabled entry under the dse.ldif . I have > tried > > restarting etc but no luck. > > > > Is this normal ? > > > > Thanks. > > --Prashant > > > > -- > > 389 users mailing list > > 389-users@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- > 389 users mailing list > 389-users@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Not able to enable audit logs
Hi, I have a setup of master-master replicated 389 DS installations as part of FreeIPA. This is the version of the 389-ds : 389-ds-base-1.3.3.8-1.fc21.x86_64 On 1st server, I was able to enable the audit logs using the following LDIF. dn: cn=config changetype: modify replace: nsslapd-auditlog-logging-enabled nsslapd-auditlog-logging-enabled: on However, the same LDIF when I run on the second server (which is the replicated master) the audit logs never get enabled. I'm not able to find the* nsslapd-auditlog-logging-enabled* entry under the* dse.ldif*. I have tried restarting etc but no luck. Is this normal ? Thanks. --Prashant -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Valgrind on a slapi plugin
Hi, Is there a documentation on how to run Valgrind on a Slapi plugin for 389 ds. Thanks. --Prashant -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] 389 DS Plugin development
Hi All,
I'm trying to write a rather straightforward plugin. I need to search for
an entry and return a specific attribute. But when I'm using
the slapi_search_internal_set_pb and slapi_search_internal_pb functions,
I'm always getting all the attributes.
My code is on the lines of whats is described here
http://docs.oracle.com/cd/E19424-01/820-4810/aahhb/index.html
The set_pb looks like this in my code.
slapi_search_internal_set_pb(
pb,
dn,/* Base DN for search*/
LDAP_SCOPE_SUBTREE, /*
Scope */
"objectclass=*",
/* Filter*/
srch_attrs, /* Set
to get all user attrs.*/
0, /*
Return attrs. and values */
NULL, /* No
controls */
NULL, /* DN
rather than unique ID */
plugin_id,
SLAPI_OP_FLAG_NEVER_CHAIN /*
Never chain this operation. */
);
The attrs are set like this:
char* srch_attrs[] = {"ipaSshPubKey", NULL};
Any help would be appreciated.
Thanks.
--Prashant
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
