[389-users] Re: x-forwarded-for
My code on the load balancer inserts the XFF message before any client data gets passed. So forging can be handled by ignoring any subsequent XFF messages, only the first one is the one from the load balancer. However, this doesn’t allow for cascading load balancers. HTML’s X-Forwarded-For header handles this by having each load balancer just append to the string. I’m not sure how important this capability is. > On May 18, 2016, at 7:48 PM, William Brown wrote: > > On Wed, 2016-05-18 at 23:04 +0200, Jochen Schneider wrote: >> Hi Rich, hi Robert, >> >> On 18/05/16 15:48, Rich Megginson wrote: >>> >>> On 05/18/2016 07:35 AM, Robert Viduya wrote: >>>> >>>> I have no issues with that. >>> Can you open a 389 ticket? https://fedorahosted.org/389/newticket >>> >>>> >>>> I’m a little concerned about the ldap message id, however. >>> Me too. Developers, LDAP SMEs, please feel free to chime in. >> this is quite an interesting approach and it will probably work in the >> vast majority of cases. > > I think it sounds a bit fragile, and really relies on the log aggregation > techniques of the implementor. I'm not sure I like > this approach. > > As well, how is this locked down to prevent a fradulent client sending a fake > control first, then their real operation? It would > certainly cause confusion in the logs > >> But instead of adding a separate LDAP _operation_ to the stream (where >> we cannot easily ensure uniqueness of the message id) we could implement >> the "LDAP Session Tracking Control" from >> http://tools.ietf.org/html/draft-wahl-ldap-session and only insert that >> _control_ into the first LDAP operation. >> There is already a 389 ticket for the server side functionality >> (https://fedorahosted.org/389/ticket/47873). >> On the F5 there is ASN1::element which makes construction of the control >> and adding it to the LDAP operation quite feasible. > > The issue with this is that this control can be forged. We would need to > essentially add another layer of "auth" which states > that we allow the control from only certain source ips, ie the load balancer > that is allowed to add this control. And even IP > layer checks can be forged unless you turn on things like reverse path > checking and such on the host. > > > Both solutions really have shortcomings and complexity, but I think I would > prefer to implement the draft version of session-03 > over the "loosely coupled" approach that Robert developed. We could at least > lock it down to a check on the plugin only allowed > some set of IP's to use the control, and put a check in dsktune for rpf. Then > the load balancer can inject the control to the > operation as needed. > > > Saying this, there is no faster way to ruin your network than to allow a load > balancer to tamper with your traffic. I've seen > horrible, horrible things happen because of bigip, netscalers, ace, and > others, tampered with the internals of DNS, LDAP, HTTP > ... At the point you allow a load balancer to actively look at your traffic > you are opening yourself to many subtle, hard to > isolate issues. > > I really can't recommend that you use one arm mode for LDAP, and highly > recomend that you use routed mode, with TLS/SSL > termination on the LDAP servers themself. > > But that's a discussion for another thread I think . > >> >> Regards, >> J. >> -- >> 389-users mailing list >> 389-users@lists.fedoraproject.org >> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org > > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Brisbane > > -- > 389-users mailing list > 389-users@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389-users mailing list 389-users@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
[389-users] Re: x-forwarded-for
I have no issues with that. I’m a little concerned about the ldap message id, however. > On May 18, 2016, at 9:02 AM, Rich Megginson wrote: > > On 05/17/2016 02:04 PM, Robert Viduya wrote: >> We run a cluster of directory servers (4 masters, 2 hubs, 14 slaves) behind >> a set of F5 Bigip load balancers. Our Bigip admins recently decided to >> switch the boxes to "one-armed" mode and that services would have to use >> X-Forwarded-For headers or equivalent to get the actual client IP address. >> Obviously, LDAP has no equivalent. >> >> So, I've hacked something together and I'm posting it looking for feedback. >> If the stuff is actually usable for other folks, that's good too. >> >> On the load balancer side, the code is specifically for the F5 Bigips. But >> if other load balancers have similar abilities to trigger on events and can >> insert binary data into the datastream, it should be adaptable. >> >> Essentially what I've done is defined a new LDAP Extended Operation with a >> payload that's a string containing the source IP address of the incoming >> connection. The load balancer sends this LDAP operation as soon as it opens >> a connection to the LDAP server, before any other traffic gets sent. On the >> directory server side, I've written an Extended Operation plugin that then >> logs the string. All we need is logging, so that's good enough for us. >> There's room for improvement there though, like making the address available >> for IP based ACls (which we don't use). >> >> In order to insert an LDAP operation into the stream, the code on the load >> balancer needs to choose an LDAP message-id that hopefully the real client >> isn't going to use. Going on the assumption that the client will start at 0 >> and increment up, I had the code insert a message-id of 0x7000. I >> initially thought I'd have to have the code on the load balancer look for >> the response message and throw it away so the client doesn't see it, but >> I've found that the clients just seem to ignore it with no ill effects, so I >> haven't bothered filtering the response out. The less the code on the load >> balancer does, the better. >> >> There's a possibility that the client could send it's own xff extended >> operation, but since the load balancer always sends first, we can just >> ignore any subsequent log entries. >> >> On the directory server plugin side, I needed to be able to log this to the >> access log, not to the error log. The slapi_log_access function isn't >> declared in the plugin header file, so I had to declare it manually. >> >> Here's what our log entries look like now, for both 636 (SSL) and 389 >> (cleartext before starttls): >> >> [17/May/2016:15:34:22 -0400] conn=230843 fd=156 slot=156 SSL connection from >> 130.207.167.12 to 130.207.183.16 >> [17/May/2016:15:34:22 -0400] conn=230843 op=0 EXT >> oid="1.3.6.1.4.1.636.2.11.11.1" name="forwarded-for extended op" >> [17/May/2016:15:34:22 -0400] conn=230843 op=0 forwarded for 130.207.167.12 >> [17/May/2016:15:34:22 -0400] conn=230843 op=0 RESULT err=0 tag=120 >> nentries=0 etime=0 >> >> [17/May/2016:15:34:22 -0400] conn=230844 fd=156 slot=156 connection from >> 130.207.167.12 to 130.207.183.16 >> [17/May/2016:15:34:22 -0400] conn=230844 op=0 EXT >> oid="1.3.6.1.4.1.636.2.11.11.1" name="forwarded-for extended op" >> [17/May/2016:15:34:22 -0400] conn=230844 op=0 forwarded for 130.207.167.12 >> [17/May/2016:15:34:22 -0400] conn=230844 op=0 RESULT err=0 tag=120 >> nentries=0 etime=0 >> >> We haven't switched our Bigips yet, so the "connection from" line still >> shows the actual client IP address. >> >> F5 Bigip code fragments are called "irules" and are written in TCL. The tar >> file below contains two different irule files, one for cleartext streams and >> one for SSL streams. By SSL streams, I mean where SSL connections from the >> client are terminated at the load balancer and then re-SSLed to the ldap >> server. Sorry, I'm not writing the other kind. > > This is really nice, and a big help for tracing connections through load > balancers and other similar devices. > Are you interested in contributing this to 389? > >> >> >> >> >> >> >> >> -- >> 389-users mailing list >> 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> >> http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org >> <http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org> > > -- > 389-users mailing list > 389-users@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org -- 389-users mailing list 389-users@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
[389-users] x-forwarded-for
We run a cluster of directory servers (4 masters, 2 hubs, 14 slaves) behind a set of F5 Bigip load balancers. Our Bigip admins recently decided to switch the boxes to "one-armed" mode and that services would have to use X-Forwarded-For headers or equivalent to get the actual client IP address. Obviously, LDAP has no equivalent.So, I've hacked something together and I'm posting it looking for feedback. If the stuff is actually usable for other folks, that's good too.On the load balancer side, the code is specifically for the F5 Bigips. But if other load balancers have similar abilities to trigger on events and can insert binary data into the datastream, it should be adaptable.Essentially what I've done is defined a new LDAP Extended Operation with a payload that's a string containing the source IP address of the incoming connection. The load balancer sends this LDAP operation as soon as it opens a connection to the LDAP server, before any other traffic gets sent. On the directory server side, I've written an Extended Operation plugin that then logs the string. All we need is logging, so that's good enough for us. There's room for improvement there though, like making the address available for IP based ACls (which we don't use).In order to insert an LDAP operation into the stream, the code on the load balancer needs to choose an LDAP message-id that hopefully the real client isn't going to use. Going on the assumption that the client will start at 0 and increment up, I had the code insert a message-id of 0x7000. I initially thought I'd have to have the code on the load balancer look for the response message and throw it away so the client doesn't see it, but I've found that the clients just seem to ignore it with no ill effects, so I haven't bothered filtering the response out. The less the code on the load balancer does, the better.There's a possibility that the client could send it's own xff extended operation, but since the load balancer always sends first, we can just ignore any subsequent log entries.On the directory server plugin side, I needed to be able to log this to the access log, not to the error log. The slapi_log_access function isn't declared in the plugin header file, so I had to declare it manually.Here's what our log entries look like now, for both 636 (SSL) and 389 (cleartext before starttls):[17/May/2016:15:34:22 -0400] conn=230843 fd=156 slot=156 SSL connection from 130.207.167.12 to 130.207.183.16[17/May/2016:15:34:22 -0400] conn=230843 op=0 EXT oid="1.3.6.1.4.1.636.2.11.11.1" name="forwarded-for extended op"[17/May/2016:15:34:22 -0400] conn=230843 op=0 forwarded for 130.207.167.12[17/May/2016:15:34:22 -0400] conn=230843 op=0 RESULT err=0 tag=120 nentries=0 etime=0[17/May/2016:15:34:22 -0400] conn=230844 fd=156 slot=156 connection from 130.207.167.12 to 130.207.183.16[17/May/2016:15:34:22 -0400] conn=230844 op=0 EXT oid="1.3.6.1.4.1.636.2.11.11.1" name="forwarded-for extended op"[17/May/2016:15:34:22 -0400] conn=230844 op=0 forwarded for 130.207.167.12[17/May/2016:15:34:22 -0400] conn=230844 op=0 RESULT err=0 tag=120 nentries=0 etime=0We haven't switched our Bigips yet, so the "connection from" line still shows the actual client IP address.F5 Bigip code fragments are called "irules" and are written in TCL. The tar file below contains two different irule files, one for cleartext streams and one for SSL streams. By SSL streams, I mean where SSL connections from the client are terminated at the load balancer and then re-SSLed to the ldap server. Sorry, I'm not writing the other kind. ldapxff.tar Description: Unix tar archive -- 389-users mailing list 389-users@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
Re: [389-users] Review 389-ds install/upgrade procedures and requisites on http://directory.fedoraproject.org/docs/389ds/download.html
Ok, I'll look into upgrading. It sounds like I need to stop paying attention to the 389 website and just stick to Redhat's site for release information. On Mar 9, 2015, at 8:01 PM, Rich Megginson wrote: > On 03/09/2015 05:54 PM, Rich Megginson wrote: >> On 03/09/2015 04:44 PM, Robert Viduya wrote: >>> >>>> On Mar 9, 2015, at 5:30 PM, Noriko Hosoi wrote: >>>> >>>> Hello, >>>> >>>> On 03/09/2015 02:18 PM, Robert Viduya wrote: >>>>> I'm in the same boat. We, as an enterprise, have standardized on RHEL6 >>>>> as our OS, with RHEL7 only on the horizon. Switching to either Fedora or >>>>> CentOS isn't an option. But the only "official" 389 release for RHEL6 is >>>>> years old. >>>>> >>>>> I reported a bug about a year ago, 47739, that's been fixed since >>>>> 1.2.11.26. But only 1.2.11.15 is available for RHEL6. So, yes, there's >>>>> at least one fix that we need that isn't available to us. But really, >>>>> there's tons of bug fixes and features that have come out since then. >>>>> The longer we're held back, the harder it will be to get our user base to >>>>> adapt to all the new features once we do upgrade. >>>> The fix for the ticket 47739 is included in 389-ds-base-1.2.11.15-32 and >>>> newer and released on October 13, 2014 for RHEL-6.6. >>>> >>>> Sorry about missing the announcement. Could it be possible to upgrade >>>> your RHEL6 bits to the latest 389-ds-base-1.2.11.15-50.el6? >>>> >>> >>> Ok, so the EL6 dash releases have fixes for stuff that isn’t in the base >>> 1.2.11.15 release. Is that detailed somewhere? Yes, I can upgrade to -50, >>> but I and my managers would want to know what’s changed. >> >> As a RHEL customer, you have access to the portal, so you can go to >> https://access.redhat.com/downloads/content/rhel---6/x86_64/168/389-ds-base/1.2.11.15-50.el6_6/x86_64/fd431d51/package >> and look at the changelog for the 389-ds-base package. This has >> descriptions of the changes along with bugzilla bug number and sometimes 389 >> trac ticket numbers. >> >> There's probably some way to get a list of all errata for the 389-ds-base >> package in RHEL6, but I can't seem to find it. > > Found it. Unfortunately, it is not broken down by package. But if you go to > this page and search for 389-ds-base you can find them. The erratas have the > full documentation, bug/enhancement descriptions, and package versions. > https://rhn.redhat.com/errata/rhel-server-6-errata.html > > For example, here is the latest errata released on March 5, 2015: > https://rhn.redhat.com/errata/RHSA-2015-0628.html > >> >>> >>> >>> >>> -- >>> 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 mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Review 389-ds install/upgrade procedures and requisites on http://directory.fedoraproject.org/docs/389ds/download.html
> On Mar 9, 2015, at 5:30 PM, Noriko Hosoi wrote: > > Hello, > > On 03/09/2015 02:18 PM, Robert Viduya wrote: >> I'm in the same boat. We, as an enterprise, have standardized on RHEL6 as >> our OS, with RHEL7 only on the horizon. Switching to either Fedora or >> CentOS isn't an option. But the only "official" 389 release for RHEL6 is >> years old. >> >> I reported a bug about a year ago, 47739, that's been fixed since 1.2.11.26. >> But only 1.2.11.15 is available for RHEL6. So, yes, there's at least one >> fix that we need that isn't available to us. But really, there's tons of >> bug fixes and features that have come out since then. The longer we're held >> back, the harder it will be to get our user base to adapt to all the new >> features once we do upgrade. > The fix for the ticket 47739 is included in 389-ds-base-1.2.11.15-32 and > newer and released on October 13, 2014 for RHEL-6.6. > > Sorry about missing the announcement. Could it be possible to upgrade your > RHEL6 bits to the latest 389-ds-base-1.2.11.15-50.el6? > Ok, so the EL6 dash releases have fixes for stuff that isn’t in the base 1.2.11.15 release. Is that detailed somewhere? Yes, I can upgrade to -50, but I and my managers would want to know what’s changed. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Review 389-ds install/upgrade procedures and requisites on http://directory.fedoraproject.org/docs/389ds/download.html
I'm in the same boat. We, as an enterprise, have standardized on RHEL6 as our OS, with RHEL7 only on the horizon. Switching to either Fedora or CentOS isn't an option. But the only "official" 389 release for RHEL6 is years old. I reported a bug about a year ago, 47739, that's been fixed since 1.2.11.26. But only 1.2.11.15 is available for RHEL6. So, yes, there's at least one fix that we need that isn't available to us. But really, there's tons of bug fixes and features that have come out since then. The longer we're held back, the harder it will be to get our user base to adapt to all the new features once we do upgrade. Is compiling from source our only option? Because, I can do that. I'd just rather not have to. On Mar 9, 2015, at 10:26 AM, Rich Megginson wrote: > On 03/09/2015 12:39 AM, Juan Carlos Camargo wrote: >> I'd like to see an updated install/upgrade procedure for 389-ds. The info on >> the web page is outdated, links for coprs are not working either , maybe >> they are not valid anymore. > > They are not, and have been removed. It was just too difficult to maintain > the copr repos. The recommended versions are now the ones provided by your > base operating system. > See also http://www.port389.org/docs/389ds/releases/end-1-2-11.html > >> As a user of Centos6x I'm somehow lost when I see versions of the product >> coming out whereas my servers are stuck with the older ones. > > Right. We are trying to keep EL6 versions stable - they are mostly in > maintenance mode. Is there some feature you require that is not available in > 1.2.11 but is in some later version? If not, then do you really need to > upgrade? > >> Should I make the move to Fedora? > > It depends. Have you considered upgrading to CentOS 7.x instead? The only > problem is that the admin server and console bits are not yet available, but > should be shortly. > >> >> >> Tfn: 957-211157 / 650932877 >> >> >> >> -- >> 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
Re: [389-users] sasl/gssapi issue
> > Not sure, but if there is, it should be on (ignore authzid) by default. > Please file a ticket. > Shucks, I was hoping for a quick answer, some setting I had overlooked. We're running a version that's about a year old, "389-Directory/1.2.11.15 B2013.100.2247". I think I'll stand up a test server running whatever version is currently in Stable and see if the issue might have already been fixed. I feel more comfortable opening a ticket on that release rather than on what we're running. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] sasl/gssapi issue
This isn't a client issue, this is a server issue. The server is allowing me to bind to one user using another user's credentials. It's the server's responsibility to verify proper credentials on bind requests. On Mar 6, 2014, at 6:17 PM, Paul Robert Marino wrote: > This is an issue with the LDAP search command which is part of the openldap > project not 389 server. > That said I think it ignores the -X if you only have one cached credential > and are using it in combination with the -Y GSSAPI option further more if you > want it to prompt you for a password you need to add a -W > > > -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] sasl/gssapi issue
We're trying to get GSSAPI authentication working with 389 and following the doc page on the website, I think I've gotten it working a little too well. We're using the stock ldapsearch command that comes with RHN, I believe it's from openldap. Here's a command log $ kinit us...@prism.gatech.edu Password for us...@prism.gatech.edu: $ klist Ticket cache: FILE:/tmp/krb5cc_651342_Bepfv28166 Default principal: us...@prism.gatech.edu Valid starting ExpiresService principal 03/06/14 16:55:07 03/07/14 16:55:07 krbtgt/prism.gatech@prism.gatech.edu $ ldapsearch -Y GSSAPI -H ldap://servera.iem.gatech.edu -LLL -b '' -s base 'objectclass=*' > /dev/null SASL/GSSAPI authentication started SASL username: us...@prism.gatech.edu SASL SSF: 56 SASL data security layer installed. $ ldapsearch -X us...@prism.gatech.edu -Y GSSAPI -H ldap://servera.iem.gatech.edu -LLL -b '' -s base 'objectclass=*' > /dev/null SASL/GSSAPI authentication started SASL username: us...@prism.gatech.edu SASL SSF: 56 SASL data security layer installed. and here's the relevant access log entries: [06/Mar/2014:16:55:18 -0500] conn=1387 fd=64 slot=64 connection from 192.168.232.4 to 192.168.232.4 [06/Mar/2014:16:55:18 -0500] conn=1387 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [06/Mar/2014:16:55:18 -0500] conn=1387 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [06/Mar/2014:16:55:18 -0500] conn=1387 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [06/Mar/2014:16:55:18 -0500] conn=1387 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [06/Mar/2014:16:55:18 -0500] conn=1387 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [06/Mar/2014:16:55:18 -0500] conn=1387 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=usera,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [06/Mar/2014:16:55:18 -0500] conn=1387 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs=ALL [06/Mar/2014:16:55:18 -0500] conn=1387 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [06/Mar/2014:16:55:18 -0500] conn=1387 op=4 UNBIND [06/Mar/2014:16:55:18 -0500] conn=1387 op=4 fd=64 closed - U1 [06/Mar/2014:16:55:25 -0500] conn=1388 fd=64 slot=64 connection from 192.168.232.4 to 192.168.232.4 [06/Mar/2014:16:55:25 -0500] conn=1388 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [06/Mar/2014:16:55:25 -0500] conn=1388 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [06/Mar/2014:16:55:25 -0500] conn=1388 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [06/Mar/2014:16:55:25 -0500] conn=1388 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [06/Mar/2014:16:55:25 -0500] conn=1388 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [06/Mar/2014:16:55:25 -0500] conn=1388 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=userb,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [06/Mar/2014:16:55:25 -0500] conn=1388 op=3 SRCH base="" scope=0 filter="(objectClass=*)" attrs=ALL [06/Mar/2014:16:55:25 -0500] conn=1388 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [06/Mar/2014:16:55:25 -0500] conn=1388 op=4 UNBIND [06/Mar/2014:16:55:25 -0500] conn=1388 op=4 fd=64 closed - U1 The issue is that if we do the ldapsearch without specifying an authzid (the "-X" option to ldapsearch), the bind correctly binds to DN that maps to the Kerberos principal name. However, if we specify an authzid that's different than what we kinitted to, the directory server binds to the DN that maps to that authzid even though we don't have the credentials for that user. It uses usera's credentials to bind to userb's DN. My question is, is there a configuration setting somewhere that would make the directory server ignore any passed in authzid when using GSSAPI and just use what's in the credential cache?-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] 389-ds-base-devel and rhel6
I'm trying to set up 389 on an RHEL6 server, all our previous installs have been on RHEL5 or earlier. We have a locally developed plugin and we need the include files from package 389-ds-base-devel. I've got both epel and epel-389-ds-base configured as repos. However, yum is balking at installing that particular dev package with the following: Error: Package: 389-ds-base-devel-1.2.10.26-1.el6_3.x86_64 (epel-389-ds-base) Requires: svrcore-devel Error: Package: 389-ds-base-devel-1.2.10.26-1.el6_3.x86_64 (epel-389-ds-base) Requires: 389-ds-base-libs = 1.2.10.26-1.el6_3 Available: 389-ds-base-libs-1.2.8.2-1.el6.i686 (rhel-x86_64-server-6) 389-ds-base-libs = 1.2.8.2-1.el6 Available: 389-ds-base-libs-1.2.8.2-1.el6_1.3.i686 (rhel-x86_64-server-6) 389-ds-base-libs = 1.2.8.2-1.el6_1.3 Available: 389-ds-base-libs-1.2.9.14-1.el6.i686 (rhel-x86_64-server-6) 389-ds-base-libs = 1.2.9.14-1.el6 Available: 389-ds-base-libs-1.2.9.14-1.el6_2.2.i686 (rhel-x86_64-server-6) 389-ds-base-libs = 1.2.9.14-1.el6_2.2 Available: 389-ds-base-libs-1.2.10.2-15.el6.i686 (rhel-x86_64-server-6) 389-ds-base-libs = 1.2.10.2-15.el6 Available: 389-ds-base-libs-1.2.10.2-18.el6_3.i686 (rhel-x86_64-server-6) 389-ds-base-libs = 1.2.10.2-18.el6_3 Available: 389-ds-base-libs-1.2.10.2-20.el6_3.i686 (rhel-x86_64-server-6) 389-ds-base-libs = 1.2.10.2-20.el6_3 Available: 389-ds-base-libs-1.2.10.12-1.el6.x86_64 (epel-389-ds-base) 389-ds-base-libs = 1.2.10.12-1.el6 Available: 389-ds-base-libs-1.2.10.14-1.el6.x86_64 (epel-389-ds-base) 389-ds-base-libs = 1.2.10.14-1.el6 Available: 389-ds-base-libs-1.2.10.26-1.el6_3.x86_64 (epel-389-ds-base) 389-ds-base-libs = 1.2.10.26-1.el6_3 Available: 389-ds-base-libs-1.2.11.15-11.el6.i686 (rhel-x86_64-server-6) 389-ds-base-libs = 1.2.11.15-11.el6 Available: 389-ds-base-libs-1.2.11.15-12.el6_4.i686 (rhel-x86_64-server-6) 389-ds-base-libs = 1.2.11.15-12.el6_4 I've tried enabling and disabling either repo with no success. Am I missing something simple? -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] replication from 1.2.8.3 to 1.2.10.4
On Jul 13, 2012, at 10:05 AM, Rich Megginson wrote:
> The only thing 1.2.10.12 needs is testers to give it positive karma ("Works
> For Me") in
> https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-6265/389-ds-base-1.2.10.12-1.el5
> or whatever your platform is.
>
> If you don't have a FAS account or don't want to do this, do I have your
> permission to provide your name and email to the update as a user for which
> the update is working?
Eh, not quite. It's working for us on only one of over 20 ldap servers and
that one server is just a hub (i.e., it's not getting customer traffic). Also,
that one server has been running for less than a day.
I'll roll it out to more of our servers over the next few days and see how it
holds up.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] replication from 1.2.8.3 to 1.2.10.4
>> I've enabled the core dump stuff, but now I can't seem to get it to crash. >> But I'm still getting the changelog messages in the error logs whenever I >> restart. In addition, the hub server keeps running out of disk space. I >> tracked it down to the access log filling up with MOD messages from >> replication. It looks like changes are coming down from our 1.2.8 servers >> and being applied over and over again. As an example, one of our entries >> was modified three times today, and on all our other machines I see the >> following in the access log file: >> >> # egrep 78b8cc871a3cda9f352580e797b270bc access >> [12/Jul/2012:11:00:59 -0400] conn=383671 op=3145 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:11:01:24 -0400] conn=383671 op=3153 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:11:01:38 -0400] conn=383671 op=3157 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> >> But on the problematic hub server, I see: >> >> # egrep 78b8cc871a3cda9f352580e797b270bc access >> [12/Jul/2012:15:17:29 -0400] conn=2 op=58 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:17:29 -0400] conn=2 op=60 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:17:29 -0400] conn=2 op=61 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:42 -0400] conn=6 op=169 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:42 -0400] conn=6 op=171 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:42 -0400] conn=6 op=172 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:45 -0400] conn=3 op=170 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:45 -0400] conn=3 op=172 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:45 -0400] conn=3 op=173 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:51 -0400] conn=2 op=2234 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:51 -0400] conn=2 op=2236 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:51 -0400] conn=2 op=2237 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:55 -0400] conn=6 op=2233 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:55 -0400] conn=6 op=2235 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:55 -0400] conn=6 op=2236 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> [12/Jul/2012:15:24:57 -0400] conn=3 op=2234 MOD >> dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" >> ... >> >> I truncated the output for brevity, but there's over 250 MODs to that one >> object. It's as if the server isn't able to do the replication bookkeeping >> and is accepting changes over and over again. Eventually the disk fills up. > Do you see error messages from the supplier suggesting that it is attempting > to send the operation but failing and retrying? No, there's nothing in the error logs on the supplier side. > Do all of these operations have the same CSN? The csn will be logged with > the RESULT line for the operation. Also, what is the err=? for the MOD > operations? err=0? Some other code? Here's some sample out, again, limited for brevity. Most of the RESULT lines don't have a CSN, just the first few. All the err= codes are 0. I've grepped out just the DN sample from my previous mail, again for brevity. There's a lot more DNs being reported: [12/Jul/2012:15:17:29 -0400] conn=2 op=58 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=
Re: [389-users] replication from 1.2.8.3 to 1.2.10.4
On Jul 12, 2012, at 11:36 AM, Rich Megginson wrote: > On 07/12/2012 08:50 AM, Robert Viduya wrote: >> On Jul 11, 2012, at 7:17 PM, Rich Megginson wrote: >> >>> On 07/11/2012 11:12 AM, Robert Viduya wrote: >>>> > So is it possible that the hub was This question seems incomplete? > > ok - please follow the directions at > http://port389.org/wiki/FAQ#Debugging_Crashes to enable core files and get a > stack trace > > Also, 1.2.10.12 is available in the testing repos. Please give this a try. > There were a couple of fixes made since 1.2.10.4 that may be applicable: > > Ticket 336 [abrt] 389-ds-base-1.2.10.4-2.fc16: index_range_read_ext: Process > /usr/sbin/ns-slapd was killed by signal 11 (SIGSEGV) > Ticket #347 - IPA dirsvr seg-fault during system longevity test > Ticket #348 - crash in ldap_initialize with multiple threads > Ticket #361: Bad DNs in ACIs can segfault ns-slapd > Trac Ticket #359 - Database RUV could mismatch the one in changelog under the > stress > Ticket #382 - DS Shuts down intermittently > Ticket #390 - [abrt] 389-ds-base-1.2.10.6-1.fc16: slapi_attr_value_cmp: > Process /usr/sbin/ns-slapd was killed by signal 11 (SIGSEGV I've enabled the core dump stuff, but now I can't seem to get it to crash. But I'm still getting the changelog messages in the error logs whenever I restart. In addition, the hub server keeps running out of disk space. I tracked it down to the access log filling up with MOD messages from replication. It looks like changes are coming down from our 1.2.8 servers and being applied over and over again. As an example, one of our entries was modified three times today, and on all our other machines I see the following in the access log file: # egrep 78b8cc871a3cda9f352580e797b270bc access [12/Jul/2012:11:00:59 -0400] conn=383671 op=3145 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:11:01:24 -0400] conn=383671 op=3153 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:11:01:38 -0400] conn=383671 op=3157 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" But on the problematic hub server, I see: # egrep 78b8cc871a3cda9f352580e797b270bc access [12/Jul/2012:15:17:29 -0400] conn=2 op=58 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:17:29 -0400] conn=2 op=60 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:17:29 -0400] conn=2 op=61 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:42 -0400] conn=6 op=169 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:42 -0400] conn=6 op=171 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:42 -0400] conn=6 op=172 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:45 -0400] conn=3 op=170 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:45 -0400] conn=3 op=172 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:45 -0400] conn=3 op=173 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:51 -0400] conn=2 op=2234 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:51 -0400] conn=2 op=2236 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:51 -0400] conn=2 op=2237 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:55 -0400] conn=6 op=2233 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:55 -0400] conn=6 op=2235 MOD dn="gtdirguid=78b8cc871a3cda9f352580e797b270bc,ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu" [12/Jul/2012:15:24:55 -0400] conn=6 op=2236 MOD dn="gtdirguid=78b8cc871a3
Re: [389-users] replication from 1.2.8.3 to 1.2.10.4
On Jul 11, 2012, at 7:17 PM, Rich Megginson wrote:
> On 07/11/2012 11:12 AM, Robert Viduya wrote:
>> Is replication from a 1.2.8.3 server to a 1.2.10.4 server known to work or
>> not work? We're having changelog issues.
>>
>> Background:
>>
>> We have an ldap service consisting of 3 masters, 2 hubs and 16 slaves. All
>> were running 1.2.8.3 since last summer with no issues. This summer, we
>> decided to bring them all up to the latest stable release, 1.2.10.4. We
>> can't afford a lot of downtime for the service as a whole, but with the
>> redundancy level we have, we can take down a machine or two at a time
>> without user impact.
>>
>> We started with one slave, did a clean install of 1.2.10.4 on it, set up
>> replication agreements from our 1.2.8.3 hubs to it and watched it for a week
>> or so. Everything looked fine, so we started rolling through the rest of
>> the slave servers, got them all running 1.2.10.4 and so far haven't seen any
>> problems.
>>
>> A couple of days ago, I did one of our two hubs. The first time I bring up
>> the daemon after doing the initial import of our ldap data everything seems
>> fine. However, we start seeing errors the first time we restart:
>>
>> [11/Jul/2012:10:43:58 -0400] - slapd shutting down - signaling operation
>> threads
>> [11/Jul/2012:10:43:58 -0400] - slapd shutting down - waiting for 2 threads
>> to terminate
>> [11/Jul/2012:10:44:01 -0400] - slapd shutting down - closing down internal
>> subsystems and plugins
>> [11/Jul/2012:10:44:02 -0400] - Waiting for 4 database threads to stop
>> [11/Jul/2012:10:44:04 -0400] - All database threads now stopped
>> [11/Jul/2012:10:44:04 -0400] - slapd stopped.
>> [11/Jul/2012:10:45:00 -0400] - 389-Directory/1.2.10.4 B2012.101.2023
>> starting up
>> [11/Jul/2012:10:45:07 -0400] NSMMReplicationPlugin - ruv_compare_ruv: the
>> max CSN [4ffdca7e0033] from RUV [changelog max RUV] is larger than
>> the max CSN [4ffb605d0033] from RUV [database RUV] for element
>> [{replica 51} 4ffb602b00030033 4ffdca7e0033]
>> [11/Jul/2012:10:45:07 -0400] NSMMReplicationPlugin -
>> replica_check_for_data_reload: Warning: data for replica
>> ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu does not
>> match the data in the changelog. Recreating the changelog file. This could
>> affect replication with replica's consumers in which case the consumers
>> should be reinitialized.
>> [11/Jul/2012:10:45:07 -0400] NSMMReplicationPlugin - ruv_compare_ruv: the
>> max CSN [4ffdca700034] from RUV [changelog max RUV] is larger than
>> the max CSN [4ffb709800010034] from RUV [database RUV] for element
>> [{replica 52} 4ffb6ea20034 4ffdca700034]
>> [11/Jul/2012:10:45:07 -0400] NSMMReplicationPlugin -
>> replica_check_for_data_reload: Warning: data for replica
>> ou=people,dc=gted,dc=gatech,dc=edu does not match the data in the changelog.
>> Recreating the changelog file. This could affect replication with replica's
>> consumers in which case the consumers should be reinitialized.
>> [11/Jul/2012:10:45:08 -0400] - slapd started. Listening on All Interfaces
>> port 389 for LDAP requests
>> [11/Jul/2012:10:45:08 -0400] - Listening on All Interfaces port 636 for
>> LDAPS requests
>
> The problem is that hubs have changelogs but dedicated consumers do not.
>
> Were either of the replicas with ID 51 or 52 removed/deleted at some point in
> the past?
No, 51 and 52 belong to an active, functional master.
>
>>
>> The _second_ restart is even worse, we get more error messages (see below)
>> and then the daemon dies
>
> Dies? Exits? Crashes? Core files? Do you see any ns-slapd segfault
> messages in /var/log/messages? When you restart the directory server after
> it dies, do you see "Disorderly Shutdown" messages in the directory server
> errors log?
Found these in the kernel log file:
Jul 11 10:46:26 bellar kernel: ns-slapd[4041]: segfault at 0011 rip
2b5fe0801857 rsp 76e65970 error 4
Jul 11 10:47:23 bellar kernel: ns-slapd[4714]: segfault at 0011 rip
2b980c6ce857 rsp 681f5970 error 4
And yes, we get "Disorderly Shutdown" messages in the errors log.
>
>
>> after it says it's listening on it's ports:
>>
>> [11/Jul/2012:10:45:32 -0400] - slapd shutting down - signaling operation
>> threads
>> [11/Jul/2012:10:45:32 -0400] - slapd shutting down - waiting for 29 threads
>> to terminate
>> [11
[389-users] replication from 1.2.8.3 to 1.2.10.4
Is replication from a 1.2.8.3 server to a 1.2.10.4 server known to work or not
work? We're having changelog issues.
Background:
We have an ldap service consisting of 3 masters, 2 hubs and 16 slaves. All
were running 1.2.8.3 since last summer with no issues. This summer, we decided
to bring them all up to the latest stable release, 1.2.10.4. We can't afford a
lot of downtime for the service as a whole, but with the redundancy level we
have, we can take down a machine or two at a time without user impact.
We started with one slave, did a clean install of 1.2.10.4 on it, set up
replication agreements from our 1.2.8.3 hubs to it and watched it for a week or
so. Everything looked fine, so we started rolling through the rest of the
slave servers, got them all running 1.2.10.4 and so far haven't seen any
problems.
A couple of days ago, I did one of our two hubs. The first time I bring up the
daemon after doing the initial import of our ldap data everything seems fine.
However, we start seeing errors the first time we restart:
[11/Jul/2012:10:43:58 -0400] - slapd shutting down - signaling operation threads
[11/Jul/2012:10:43:58 -0400] - slapd shutting down - waiting for 2 threads to
terminate
[11/Jul/2012:10:44:01 -0400] - slapd shutting down - closing down internal
subsystems and plugins
[11/Jul/2012:10:44:02 -0400] - Waiting for 4 database threads to stop
[11/Jul/2012:10:44:04 -0400] - All database threads now stopped
[11/Jul/2012:10:44:04 -0400] - slapd stopped.
[11/Jul/2012:10:45:00 -0400] - 389-Directory/1.2.10.4 B2012.101.2023 starting up
[11/Jul/2012:10:45:07 -0400] NSMMReplicationPlugin - ruv_compare_ruv: the max
CSN [4ffdca7e0033] from RUV [changelog max RUV] is larger than the max
CSN [4ffb605d0033] from RUV [database RUV] for element [{replica 51}
4ffb602b00030033 4ffdca7e0033]
[11/Jul/2012:10:45:07 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: data for replica
ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu does not
match the data in the changelog. Recreating the changelog file. This could
affect replication with replica's consumers in which case the consumers should
be reinitialized.
[11/Jul/2012:10:45:07 -0400] NSMMReplicationPlugin - ruv_compare_ruv: the max
CSN [4ffdca700034] from RUV [changelog max RUV] is larger than the max
CSN [4ffb709800010034] from RUV [database RUV] for element [{replica 52}
4ffb6ea20034 4ffdca700034]
[11/Jul/2012:10:45:07 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: data for replica
ou=people,dc=gted,dc=gatech,dc=edu does not match the data in the changelog.
Recreating the changelog file. This could affect replication with replica's
consumers in which case the consumers should be reinitialized.
[11/Jul/2012:10:45:08 -0400] - slapd started. Listening on All Interfaces port
389 for LDAP requests
[11/Jul/2012:10:45:08 -0400] - Listening on All Interfaces port 636 for LDAPS
requests
The _second_ restart is even worse, we get more error messages (see below) and
then the daemon dies after it says it's listening on it's ports:
[11/Jul/2012:10:45:32 -0400] - slapd shutting down - signaling operation threads
[11/Jul/2012:10:45:32 -0400] - slapd shutting down - waiting for 29 threads to
terminate
[11/Jul/2012:10:45:34 -0400] - slapd shutting down - closing down internal
subsystems and plugins
[11/Jul/2012:10:45:35 -0400] - Waiting for 4 database threads to stop
[11/Jul/2012:10:45:36 -0400] - All database threads now stopped
[11/Jul/2012:10:45:36 -0400] - slapd stopped.
[11/Jul/2012:10:46:11 -0400] - 389-Directory/1.2.10.4 B2012.101.2023 starting up
[11/Jul/2012:10:46:11 -0400] NSMMReplicationPlugin - ruv_compare_ruv: RUV
[changelog max RUV] does not contain element [{replica 68
ldap://gtedm3.iam.gatech.edu:389} 4be339e60044 4ffdc9a10044]
which is present in RUV [database RUV]
[11/Jul/2012:10:46:11 -0400] NSMMReplicationPlugin - ruv_compare_ruv: RUV
[changelog max RUV] does not contain element [{replica 71
ldap://gtedm4.iam.gatech.edu:389} 4be6031e0047 4ffdc9a80047]
which is present in RUV [database RUV]
[11/Jul/2012:10:46:11 -0400] NSMMReplicationPlugin - ruv_compare_ruv: the max
CSN [4ffb62a200010033] from RUV [changelog max RUV] is larger than the max
CSN [4ffb605d0033] from RUV [database RUV] for element [{replica 51}
4ffb605d0033 4ffb62a200010033]
[11/Jul/2012:10:46:11 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: data for replica
ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu does not
match the data in the changelog. Recreating the changelog file. This could
affect replication with replica's consumers in which case the consumers should
be reinitialized.
[11/Jul/2012:10:46:11 -0400] NSMMReplicationPlugin - ruv_compare_ruv: RUV
[changelog max RUV] does not contain element [{replica 69
ldap://gtedm
Re: [389-users] RH5 upgrade Problem Directoryserver
I'm having issues with this as well, but I'm trying to do a clean install, not an upgrade. I pulled down 389-dsgw-1.1.7-2.el5.x86_64.rpm as suggested, but it's failing to install with dependency errors as well: # yum localinstall 389-dsgw-1.1.7-2.el5.x86_64.rpm Loaded plugins: downloadonly, rhnplugin, security Setting up Local Package Process Examining /home/robert/389-dsgw-1.1.7-2.el5.x86_64.rpm: 389-dsgw-1.1.7-2.el5.x86_64 Nothing to do # rpm -i 389-dsgw-1.1.7-2.el5.x86_64.rpm error: Failed dependencies: /etc/dirsrv/admin-serv/httpd.conf is needed by 389-dsgw-1.1.7-2.el5.x86_64 libadminutil.so.0()(64bit) is needed by 389-dsgw-1.1.7-2.el5.x86_64 libadmsslutil.so.0()(64bit) is needed by 389-dsgw-1.1.7-2.el5.x86_64 Not sure where to go from here. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] issues with 1.2.7.5
On Dec 21, 2010, at 8:17 PM, Marc Sauton wrote: > Check the access log file for the bind attempts, and > nsslapd-allow-anonymous-access in your dse.ldif > Try to click OK and provide pw if prompted again. > May be related to these reports: > https://bugzilla.redhat.com/show_bug.cgi?id=627906 > https://bugzilla.redhat.com/show_bug.cgi?id=661116 > If it the case, you may want to add a comment. The access log shows a number of bind requests, one to dn="" and the rest to dn="cn=directory manager". All of them were successful (err=0). Nsslapd-allow-anonymous-access is "on". On Dec 22, 2010, at 2:16 PM, Aaron Hagopian wrote: > I think you're supposed to login to the 389-console with the admin user not > your directory manager. I get the same error with the admin user. I've been managing a Fedora directory cluster for years now and have always used Directory Manager. Is this something new? -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] replication between 1.2.2 and 1.2.6.1
A quick grep through the code shows that repl90consumer (a field of Private_Repl_Protocol struct) is never initialized to zero. Neither is field repl71consumer, but field repl50consumer is initialized to zero in Repl_5_Inc_Protocol_new. On Oct 15, 2010, at 11:19 AM, Robert Viduya wrote: > > On Oct 14, 2010, at 5:25 PM, Nathan Kinder wrote: > >> The 1.2.6.1 instance should detect that the 1.2.2 version does not support >> the newer startReplication extop. This detection is done by searching the >> rootDSE of the receiving side to see if it advertises >> 2.16.840.1.113730.3.5.12 as a supportedExtension. The code is designed to >> send the old style startReplication extop if it detects that the newer style >> is not supported. >> >> I would like to see the rootDSE entry from the 1.2.2 system. > > dn: > objectClass: top > namingContexts: dc=gted,dc=gatech,dc=edu > namingContexts: o=netscaperoot > supportedExtension: 2.16.840.1.113730.3.5.7 > supportedExtension: 2.16.840.1.113730.3.5.8 > supportedExtension: 2.16.840.1.113730.3.5.10 > supportedExtension: 2.16.840.1.113730.3.5.3 > supportedExtension: 2.16.840.1.113730.3.5.5 > supportedExtension: 2.16.840.1.113730.3.5.6 > supportedExtension: 2.16.840.1.113730.3.5.9 > supportedExtension: 2.16.840.1.113730.3.5.4 > supportedExtension: 1.3.6.1.4.1.1466.20037 > supportedExtension: 1.3.6.1.4.1.4203.1.11.1 > supportedControl: 2.16.840.1.113730.3.4.2 > supportedControl: 2.16.840.1.113730.3.4.3 > supportedControl: 2.16.840.1.113730.3.4.4 > supportedControl: 2.16.840.1.113730.3.4.5 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.16 > supportedControl: 2.16.840.1.113730.3.4.15 > supportedControl: 2.16.840.1.113730.3.4.17 > supportedControl: 2.16.840.1.113730.3.4.19 > supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 > supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.3.6.1.4.1.4203.666.5.16 > supportedControl: 2.16.840.1.113730.3.4.14 > supportedControl: 2.16.840.1.113730.3.4.20 > supportedControl: 1.3.6.1.4.1.1466.29539.12 > supportedControl: 2.16.840.1.113730.3.4.12 > supportedControl: 2.16.840.1.113730.3.4.18 > supportedControl: 2.16.840.1.113730.3.4.13 > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: LOGIN > supportedSASLMechanisms: DIGEST-MD5 > supportedSASLMechanisms: PLAIN > supportedSASLMechanisms: ANONYMOUS > supportedSASLMechanisms: CRAM-MD5 > supportedSASLMechanisms: GSSAPI > supportedLDAPVersion: 2 > supportedLDAPVersion: 3 > vendorName: 389 Project > vendorVersion: 389-Directory/1.2.2 B2009.237.2054 > dataversion: 020101015151757020101015151757020101015151757020101015151757 > netscapemdsuffix: cn=ldap://dc=stefan,dc=iam,dc=gatech,dc=edu:389 > > -- > 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] replication between 1.2.2 and 1.2.6.1
On Oct 14, 2010, at 5:25 PM, Nathan Kinder wrote: > The 1.2.6.1 instance should detect that the 1.2.2 version does not support > the newer startReplication extop. This detection is done by searching the > rootDSE of the receiving side to see if it advertises > 2.16.840.1.113730.3.5.12 as a supportedExtension. The code is designed to > send the old style startReplication extop if it detects that the newer style > is not supported. > > I would like to see the rootDSE entry from the 1.2.2 system. dn: objectClass: top namingContexts: dc=gted,dc=gatech,dc=edu namingContexts: o=netscaperoot supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: LOGIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: GSSAPI supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.2.2 B2009.237.2054 dataversion: 020101015151757020101015151757020101015151757020101015151757 netscapemdsuffix: cn=ldap://dc=stefan,dc=iam,dc=gatech,dc=edu:389 -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
