389-users June 2017

389-users@lists.fedoraproject.org

19 participants
25 discussions

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS. When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well. I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also. Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration. Thanks, Chris USA.NET You Run Your Business. We'll Run Your Email. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.

3 2

MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser 06 Aug '20

06 Aug '20

Hi, I'm new to 389-ds and last week downloaded and installed the software. I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query the server using TLS/SSL, and all appears working. I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client can see the unix users and groups using the "getent password" or "getent group" commands. Now, here's where I'm getting tripped up.......... I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations. I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-groups…) which is close enough to CentOS that the initial commands worked. I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system. I created a test group (that I didn't enable a posix GID) and tried to add a single user via: Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add. When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error: "Cannot save to directory server. netscape.ldap.LDAPException: error resiult(65): Object class violation" And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors: "Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed [17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)" So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before I even try to filter login access via groups on my client system. I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I should set the "value" to be. I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute on individual users, only groups. This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions. Any suggestions would be appreciated.

6 19

ldapsearch doesn't return the userpassword field
by Janet Houser 14 May '18

14 May '18

Hi, I've been looking through the archives for information, but I haven't stumbled on a solution to my problem. I'm running ds-389 (389-ds-base-1.3.4.0) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly. I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has of the password when an ldapsearch is issued. However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't quite get it right. Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password. Thanks,

5 12

DSGW and Multi-Line-Strings
by Kreuzenstein, Luke (DOA) 23 Jul '17

23 Jul '17

My organization has made extensive use of the Directory Server (Web) Gateway (DSGW) for 20 years. I've yet to come across any suitable alternative (suggestions welcome if you're familiar with its functionality). We are at least a decade behind with updates, having been tied to the Oracle fork of directory and mail server products until recently. I am now experimenting with potential conversion to 389-DS or RHDS including the updated DSGW, and I may have encountered a bug. Is the DSGW still used and supported? The specific problem appears to be the edit command (/usr/lib64/dirsrv/dsgw-cgi-bin/edit) failing to handle "syntax=mls" as encountered in a template file (/usr/share/dirsrv/dsgw/config/display-orgperson.html). The problem occurs if the attribute involved exists in the entry being edited, whether its value contains multiple lines or not. The symptom: The multi-line data is displayed cleanly using the search or csearch commands, but upon clicking the Edit button to enter edit mode, the web form is truncated. Bottom half blank, from one cell above whatever cell contains "syntax=mls". In the distributed template file the trigger line is:  The test environment: # uname -a Linux /host.domain/3.10.0-514.16.1.el7.x86_64 #1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux # yum list | grep 389 Installed Packages 389-admin.x86_64 1.1.46-1.el7 @epel 389-admin-console.noarch 1.1.12-1.el7 @epel 389-admin-console-doc.noarch 1.1.12-1.el7 @epel 389-adminutil.x86_64 1.1.21-2.el7 @epel 389-console.noarch 1.1.18-1.el7 @epel 389-ds.noarch 1.2.2-6.el7 @epel 389-ds-base.x86_64 1.3.5.10-20.el7_3 @updates 389-ds-base-libs.x86_64 1.3.5.10-20.el7_3 @updates 389-ds-console.noarch 1.2.16-1.el7 @epel 389-ds-console-doc.noarch 1.2.16-1.el7 @epel 389-dsgw.x86_64 1.1.11-5.el7 @epel 389-adminutil-devel.x86_64 1.1.21-2.el7 epel 389-ds-base-devel.x86_64 1.3.5.10-20.el7_3 updates 389-ds-base-snmp.x86_64 1.3.5.10-20.el7_3 updates pcp-pmda-ds389.x86_64 3.11.3-4.el7 base pcp-pmda-ds389log.x86_64 3.11.3-4.el7 base

2 3

Re: multimaster replication with # 389-DS version +OS ?, (William Brown)
by ghiureai 28 Jun '17

28 Jun '17

On 06/27/2017 09:03 PM, 389-users-request(a)lists.fedoraproject.org wrote: > Send 389-users mailing list submissions to > 389-users(a)lists.fedoraproject.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > 389-users-request(a)lists.fedoraproject.org > > You can reach the person managing the list at > 389-users-owner(a)lists.fedoraproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 389-users digest..." > > Today's Topics: > > 1. Re: multimaster replication with # 389-DS version +OS ? > (William Brown) > > > ---------------------------------------------------------------------- > > Date: Wed, 28 Jun 2017 08:34:49 +1000 > From: William Brown <wibrown(a)redhat.com> > Subject: [389-users] Re: multimaster replication with # 389-DS version > +OS ? > To: "General discussion list for the 389 Directory server project." > <389-users(a)lists.fedoraproject.org> > Message-ID: <1498602889.32323.224.camel(a)redhat.com> > Content-Type: multipart/signed; micalg="pgp-sha1"; > protocol="application/pgp-signature"; > boundary="=-U4zaOUjBaBCmTIPu7Mut" > > > --=-U4zaOUjBaBCmTIPu7Mut > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Tue, 2017-06-27 at 09:47 -0700, ghiureai wrote: >>>> =3D20 >>> Yes, this is a valid and supported configuration for migration of >> the >>> data. We don't advise it "long term" but a few days should work just >> =20 >> Thank you William for reply, one more replication cfg question , >> right=20 >> now I have : DS server 1 multimaster replication with DS server 2 ,=20 >> when cfgt the DS server3 ( the one with # OS,# 389-DS >> version) ,when=20 >> initializing for multimaster replication should I use DS server 1 or >> 2? >> =20 >> Isabella > Hi, > > I don't think it matters too much which you use - but I think it's good > to have a migration plan sorted before you start. I have some tips on > this in the following blog post: > > https://fy.blackhats.net.au/blog/html/2016/06/03/zero_outage_migration_of_d= > irectory_server_infrastructure.html?highlight=3Dzero > > It sounds like you have a multimaster pair at the moment, so is your > plan to create a new multimaster pair after this migration?=20 William, Yes , indeed I plan to have a multimaster pair DS's replication after with a new OS and upgraded version, the clean job of old replication may require a reboot of old master for sure to cleanup some caches( this is what I saw from past replication cfg) I would really like to access your blog, but I get : server not found or access forbidden " You don't have permission to access /blog/html/2016/06/03/ on this server." !! Any help to see this site ? Thank you Isabella > You don't have permission to access /blog/html/2016/06/03/ > on this server. > > --=20 > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane > > > --=-U4zaOUjBaBCmTIPu7Mut > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: This is a digitally signed message part > Content-Transfer-Encoding: 7bit > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIbBAABAgAGBQJZUt2JAAoJEISUiynM+PAgluIP+O9DGL4zmDJSV/aXZtY5V/g2 > Th8cyHRV755uv7nlVwpRByEA7RkehgHOnSudKnXRpPdl9sBXvy6OGs0hLWPIL8Zh > IVNU0DLUZIHvR0/URbmsxY+k209zuPzwEj2HwSHL2nTG9ejipu66ywPNeX5PZcbD > HsfzdH8qM189tQ6eFbuR5aAoCMrs8DYtsVnaDNnjsPu7tGxftViLrvOx/XyYjJzR > 2SuNMY94k3M3StLZo8AZ7ALPOTULb1e9yM/n9M/iHkvdedLczoEECOOuiIId1p6n > 1kqfyLWM7iO8fr9s4IngYugNGAROaZm08BL+34F04Qmcm99fVsSimBq8Hd/3/xU8 > n9bx+PQ8w6e6RR6Z1gs1o+nKk2FqbkgYPQiPI1htbBBmXzkjcMwjnwbtkV3jqhaQ > XRyP2Xq4gaDkMRL66iTkDeFUMNLlQm3vBNhBT/+rDarSRJ8MtTtdBZE9BT5gUkEP > d2pou98nz+T298e38DP0BmM2HCB4r4H7Dush3AqM5PRG88j/g44Wj0z2SOwHoFAI > ZeztbBpabaSZNj6GB6BGTv+3xJELWlOEicOoUpjnwrtvVjLV8PMpkQjeXK3fSs3T > Z5htb7zBy4lGio++9R4hga1GvVD/JcAcY6/LuVqdDgZF4zJRdX/hSKK+KQWdwEb6 > WdTax5Gg33LAcZc7Y4U= > =THTz > -----END PGP SIGNATURE----- > > --=-U4zaOUjBaBCmTIPu7Mut-- > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > > > ------------------------------ > > End of 389-users Digest, Vol 145, Issue 31 > ******************************************

2 1

Re: setup-ds-admin.pl -u Script
by Paul Whitney 28 Jun '17

28 Jun '17

Thank you Mark, that got me through it. Not sure exactly what gets updated behind the scene, but I did notice on some servers from the console their Build Number was updated to 2017.145.2037, but most of them still have the Build Number 2017.062.34. Does this mean the update failed to apply correctly? Is it something else? Paul M. Whitney E-mail: paul.whitney(a)mac.com Sent from my browser. On Jun 28, 2017, at 12:48 PM, Mark Reynolds <mareynol(a)redhat.com> wrote: On 06/28/2017 12:40 PM, Paul Whitney wrote: Just updated 389-ds-base to version 1.3.5.10-21. When I run the SUBJ script, I get an error indicating that could not update the Admin Server with Error: Administrative limit exceeded. Any ideas how I can get around this? Try setting the nsslapd-lookthoughlimit to -1 under "cn=config,cn=ldbm database,cn=plugins,cn=config" Thank you, Paul M. Whitney E-mail: paul.whitney(a)mac.com Sent from my browser. _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

2 1

setup-ds-admin.pl -u Script
by Paul Whitney 28 Jun '17

28 Jun '17

Just updated 389-ds-base to version 1.3.5.10-21. When I run the SUBJ script, I get an error indicating that could not update the Admin Server with Error: Administrative limit exceeded. Any ideas how I can get around this? Thank you, Paul M. Whitney E-mail: paul.whitney(a)mac.com Sent from my browser.

2 1

Re: multimaster replication with # 389-DS version +OS ?
by ghiureai 27 Jun '17

27 Jun '17

On 06/26/2017 03:02 PM, 389-users-request(a)lists.fedoraproject.org wrote: > Send 389-users mailing list submissions to > 389-users(a)lists.fedoraproject.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > 389-users-request(a)lists.fedoraproject.org > > You can reach the person managing the list at > 389-users-owner(a)lists.fedoraproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 389-users digest..." > > Today's Topics: > > 1. Re: What is the changelog:ent and changelog:dn (dbmon.sh output) refers in 389 (ldap) > (Matveev Alexey) > 2. multimaster replication with # 389-DS version +OS ? (ghiureai) > 3. pam_ldap not respecting passwordExpirationTime (Mitch Patenaude) > 4. Re: multimaster replication with # 389-DS version +OS ? > (William Brown) > > > ---------------------------------------------------------------------- > > Date: Mon, 26 Jun 2017 08:53:58 +0000 > From: Matveev Alexey <a.matveev(a)lan-project.ru> > Subject: [389-users] Re: What is the changelog:ent and changelog:dn > (dbmon.sh output) refers in 389 (ldap) > To: General discussion list for the 389 Directory server project. > <389-users(a)lists.fedoraproject.org> > Message-ID: > <59F2C869673F474192A4E21EF5C9CD2BDDB87E(a)LP-EX2K10-1.lan-project.ru> > Content-Type: multipart/alternative; boundary="_000_59F2C869673F474 > 192A4E21EF5C9CD2BDDB87ELPEX2K101lanproje_" > > --_000_59F2C869673F474192A4E21EF5C9CD2BDDB87ELPEX2K101lanproje_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Mark, thank you for reply. > Is low values of this attributes affect server performance? What ldap attri= > butes is corresponding to these db's? > > From: Mark Reynolds [mailto:mareynol@redhat.com] > Sent: Friday, June 23, 2017 8:15 PM > To: General discussion list for the 389 Directory server project. <389-user= > s(a)lists.fedoraproject.org>; Matveev Alexey <a.matveev(a)lan-project.ru> > Subject: [389-users] Re: What is the changelog:ent and changelog:dn (dbmon.= > sh output) refers in 389 (ldap) > > > On 06/23/2017 12:21 PM, Matveev Alexey wrote: > > Hello! > > I have FreeIPA 4.5.2 and tune it performance for adding more than 100k user= > s. > > I have a question about script dbmon.sh (or for 389 DS db in general) > > The output of the dbmon.sh says: > .... > dbcachefree 2374205440 free% 88.446 roevicts 0 hit% 99 pagein 36901 pageout= > 62843 > .... > dbname count free free% size > > changelog:ent 505 7367 0.4 4138.2 > > changelog:dn 141699 55 0.0 74.0 > > userroot:ent 147205 1220895664 56.9 6294.5 > > userroot:dn 133806 500270863 97.7 87.7 > > ipaca:ent 98 9719014 92.7 7823.9 > > ipaca:dn 98 10476664 99.9 92.8 > > I'm new to 389 and need some explanation. I know that the dbcachefree is ns= > slapd-dbcachesize, userroot:ent is nsslapd-cachememsize, userroot:dn is nss= > lapd-dncachememsize. > What is changelog:ent and changelog:dn > "changelog" is your retro change log backend. ":ent" refers to the entry c= > ache, and ":dn" refers to the dn cache. > > Thanks in advance! > > Alex > > > > > > _______________________________________________ > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org<mailto:389-user= > s(a)lists.fedoraproject.org> > > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org<mai= > lto:389-users-leave@lists.fedoraproject.org> > > > --_000_59F2C869673F474192A4E21EF5C9CD2BDDB87ELPEX2K101lanproje_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= > //www.w3.org/TR/REC-html40"> > <head> > <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> > <style></style> > </head> > <body bgcolor=3D"white" lang=3D"RU" link=3D"#0563C1" vlink=3D"#954F72"> > <div class=3D"WordSection1"> > Mark, t= > hank you for reply.<o:p></o:p> > Is low = > values of this attributes affect server performance? What ldap attributes i= > s corresponding to these db's?<o:p></o:p> > <o:p>&n= > bsp;</o:p> > <div> > <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = > 0cm 0cm"> > age:RU">From: e:RU"> Mark Reynolds [mailto:mareynol@redhat.com] > > Sent: Friday, June 23, 2017 8:15 PM > To: General discussion list for the 389 Directory server project. &l= > t;389-users(a)lists.fedoraproject.org>gt;; Matveev Alexey <a.matveev@lan-p= > roject.ru> > Subject: [389-users] Re: What is the changelog:ent and changelog:dn = > (dbmon.sh output) refers in 389 (ldap)<o:p></o:p> > </div> > </div> > <o:p> </o:p> > ize:12.0pt;mso-fareast-language:RU"><o:p> </o:p> > <div> > On 06/23/2017 12:21 PM, Matveev Alexey wrote:<o:p></= > o:p> > </div> > <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> > Hello!<o:p></o:p> > I have FreeIPA 4.5.2 and tune it performance for ad= > ding more than 100k users.<o:p></o:p> > I have a question about script dbmon.sh (or for 389= > DS db  in general)<o:p></o:p> > The output of the dbmon.sh says: > .... > dbcachefree 2374205440 free% 88.446 roevicts 0 hit% 99 pagein 36901 pageout= > 62843 > .... > dbname            &n= > bsp; count          free = >            free%&nbs= > p;   size<o:p></o:p> > changelog:ent      505&nbs= > p;           7367 &n= > bsp;          0.4  4138.2= > <o:p></o:p> > </blockquote> > <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> > changelog:dn     141699 &n= > bsp;        55     &= > nbsp;       0.0    74.0</= > span><o:p></o:p> > userroot:ent     147205 &n= > bsp;   1220895664    56.9  6294.5<o:p>= > </o:p> > userroot:dn      133806&nb= > sp;    500270863      97.7 &nb= > sp;  87.7<o:p></o:p> >     ipaca:ent   &nbsp= > ;     98        &nbs= > p;   9719014        &nbsp= > ; 92.7  7823.9<o:p></o:p> >     ipaca:dn    = >       98       &nbsp= > ;   10476664        99.9&= > nbsp;   92.8<o:p></o:p> > I'm new to 389 and need some explanation. I know th= > at the dbcachefree is nsslapd-dbcachesize, userroot:ent is nsslapd-cachemem= > size, userroot:dn is nsslapd-dncachememsize. > What is changelog:ent and changelog:dn<o:p></o:p> > </blockquote> > mes New Roman",serif;mso-fareast-language:RU">"changelog" is= > your retro change log backend.  ":ent" refers to the entry = > cache, and ":dn" refers to the dn cache. > > <o:p></o:p> > <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> > Thanks in advance!<o:p><= > /o:p> >  <o:p></o:p> > Alex<o:p></o:p> >  <o:p></o:p> > mes New Roman",serif;mso-fareast-language:RU"> > > > <o:p></o:p> > <pre>_______________________________________________<o:p></o:p></pre> > <pre>389-users mailing list -- <a href=3D"mailto:389-users@lists.fedoraproj= > ect.org">389-users(a)lists.fedoraproject.org</a><o:p></o:p></pre> > <pre>To unsubscribe send an email to <a href=3D"mailto:389-users-leave@list= > s.fedoraproject.org">389-users-leave(a)lists.fedoraproject.org</a><o:p></o:p>= > </pre> > </blockquote> > mes New Roman",serif;mso-fareast-language:RU"><o:p> </o:p>= > > </div> > </body> > </html> > > --_000_59F2C869673F474192A4E21EF5C9CD2BDDB87ELPEX2K101lanproje_-- > > ------------------------------ > > Date: Mon, 26 Jun 2017 09:30:58 -0700 > From: ghiureai <isabella.ghiurea(a)nrc-cnrc.gc.ca> > Subject: [389-users] multimaster replication with # 389-DS version +OS > ? > To: 389-users(a)lists.fedoraproject.org > Message-ID: <595136C2.5060807(a)nrc-cnrc.gc.ca> > Content-Type: text/plain; charset="ISO-8859-1"; format=flowed > > Hi List, > I have an existing multimaster replication 389-DS , 2 hosts running : > OS :el6.x86_64 #1 SMP > with > 389-ds-base-1.3.4.4-000.x86_64 > > I need to bring the 3 host and cfg multimaster rep/ or any other rep > if will work, > the new host will run: > OS: fc24.x86_64 #1 > with > 389-ds-base-libs-1.3.5.15-1.fc24.x86_64 > > wold this be able to run for couple of hours/one day , I want to use > multi master replication for migration/upgrade purpose only > > Thank you > Isabella > > ------------------------------ > > Date: Mon, 26 Jun 2017 17:16:07 +0000 > From: Mitch Patenaude <mpatenaude(a)shutterfly.com> > Subject: [389-users] pam_ldap not respecting passwordExpirationTime > To: "389-users(a)lists.fedoraproject.org" > <389-users(a)lists.fedoraproject.org> > Message-ID: <51E832D0-949B-4D9B-9AF0-24E45D2D3D8F(a)shutterfly.com> > Content-Type: multipart/alternative; > boundary="_000_51E832D0949B4D9B9AF024E45D2D3D8Fshutterflycom_" > > --_000_51E832D0949B4D9B9AF024E45D2D3D8Fshutterflycom_ > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 > > SSdtIHRyeWluZyB0byBtaWdyYXRlIG15IG9yZ2FuaXphdGlvbiBvZiBGRFMsIGJ1dCBwb2xpY3kg > cmVxdWlyZXMgYSA5MCBkYXkgcGFzc3dvcmQgZXhwaXJhdGlvbiwgYW5kIHBhbV9sZGFwIG1vZHVs > ZXMgYXJlbid0IGZvcmNpbmcgcGFzc3dvcmQgY2hhbmdlcyBldmVuIGFmdGVyIHRoZSBwYXNzd29y > ZCBleHBpcmVkLg0KDQpJIHNhdyBpbiBhIHRocmVhZCBiYWNrIGZyb20gMjAxMSB0aGF0IHNvbWVi > b2R5IHdhcyBoYXZpbmcgYW4gaXNzdWUgd2hlcmUgc2V0dGluZyBwYXNzd29yZEV4cGlyYXRpb25U > aW1lIHRvIDE5NzAwMTAxMDAwMDAwWiB3b3VsZCBmb3JjZSBhIGNoYW5nZSwgYnV0IDE5NzAwMTAx > MDAwMDAxWiB3b3VsZG4ndC4gIFdlbGwuLi4gZXZlbiBzZXR0aW5nIHRvIDE5NzAwMTAxMDAwMDAw > WiBkb2Vzbid0IHdvcmsgZm9yIG1lLg0KDQppbnRkbnMxLTAxLWx2On4gbXBhdGVuYXVkZSQgbHVz > ZXIgbWl0Y2h0ZXN0Mg0KZG46IHVpZD1taXRjaHRlc3QyLG91PVBlb3BsZSxkYz1wcm9kLGRjPXNo > dXR0ZXJmbHksZGM9Y29tDQpwYXNzd29yZEV4cGlyYXRpb25UaW1lOiAxOTcwMDEwMTAwMDAwMFoN > CmxvZ2luU2hlbGw6IC9iaW4vYmFzaA0KdWlkOiBtaXRjaHRlc3QyDQpjbjogTWl0Y2ggVGVzdDIN > CmdpdmVuTmFtZTogTWl0Y2gNCnNuOiBUZXN0Mg0KbWFpbDogbWl0Y2h0ZXN0MkBzaHV0dGVyZmx5 > LmNvbQ0Kb2JqZWN0Q2xhc3M6IHBlcnNvbg0Kb2JqZWN0Q2xhc3M6IG9yZ2FuaXphdGlvbmFsUGVy > c29uDQpvYmplY3RDbGFzczogaW5ldE9yZ1BlcnNvbg0Kb2JqZWN0Q2xhc3M6IHBvc2l4QWNjb3Vu > dA0Kb2JqZWN0Q2xhc3M6IHRvcA0Kb2JqZWN0Q2xhc3M6IHNoYWRvd0FjY291bnQNCm9iamVjdENs > YXNzOiBsZGFwUHVibGljS2V5DQp1aWROdW1iZXI6IDUxMzQNCmdpZE51bWJlcjogNTEzNA0KaG9t > ZURpcmVjdG9yeTogL2hvbWUvbWl0Y2h0ZXN0Mg0KZ2Vjb3M6IE1pdGNoIFRlc3QyDQoNCkJ1dCBp > dCBsZXRzIHRoYXQgYWNjb3VudCBsb2cgaW4gd2l0aG91dCBwcm9tcHRpbmcgZm9yIGEgcGFzc3dv > cmQgY2hhbmdlLg0KDQpBbnkgaWRlYXM/DQoNCg== > > --_000_51E832D0949B4D9B9AF024E45D2D3D8Fshutterflycom_ > Content-Type: text/html; charset="utf-8" > Content-ID: <99E0F0ABCBF85C43B71932102A26ACC0(a)shutterfly.com> > Content-Transfer-Encoding: base64 > > PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 > bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo > dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo > dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp > dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l > dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu > dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg > KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N > CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 > IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ > cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls > eTpNZW5sbzsNCglwYW5vc2UtMToyIDExIDYgOSAzIDggNCAyIDIgNDt9DQovKiBTdHlsZSBEZWZp > bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt > YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K > CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl > cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1k > ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 > ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNv > cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw > ZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv > bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u > bHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCglj > b2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 > Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u > MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 > fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0K > PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0Mx > IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 > Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkknbSB0cnlpbmcgdG8g > bWlncmF0ZSBteSBvcmdhbml6YXRpb24gb2YgRkRTLCBidXQgcG9saWN5IHJlcXVpcmVzIGEgOTAg > ZGF5IHBhc3N3b3JkIGV4cGlyYXRpb24sIGFuZCBwYW1fbGRhcCBtb2R1bGVzIGFyZW4ndCBmb3Jj > aW5nIHBhc3N3b3JkIGNoYW5nZXMgZXZlbiBhZnRlciB0aGUgcGFzc3dvcmQgZXhwaXJlZC48bzpw > PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u > dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z > b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgc2F3IGluIGEgdGhyZWFk > IGJhY2sgZnJvbSAyMDExIHRoYXQgc29tZWJvZHkgd2FzIGhhdmluZyBhbiBpc3N1ZSB3aGVyZSBz > ZXR0aW5nIHBhc3N3b3JkRXhwaXJhdGlvblRpbWUgdG8gMTk3MDAxMDEwMDAwMDBaIHdvdWxkIGZv > cmNlIGEgY2hhbmdlLCBidXQgMTk3MDAxMDEwMDAwMDFaIHdvdWxkbid0LiZuYnNwOyBXZWxsLi4u > IGV2ZW4gc2V0dGluZyB0byAxOTcwMDEwMTAwMDAwMFoNCiBkb2Vzbid0IHdvcmsgZm9yIG1lLjxv > OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm > b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i > TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv > dDtNZW5sbyZxdW90OyxzYW5zLXNlcmlmIj5pbnRkbnMxLTAxLWx2On4gbXBhdGVuYXVkZSQgbHVz > ZXIgbWl0Y2h0ZXN0MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi > PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1 > b3Q7LHNhbnMtc2VyaWYiPmRuOiB1aWQ9bWl0Y2h0ZXN0MixvdT1QZW9wbGUsZGM9cHJvZCxkYz1z > aHV0dGVyZmx5LGRjPWNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt > YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxv > JnF1b3Q7LHNhbnMtc2VyaWYiPnBhc3N3b3JkRXhwaXJhdGlvblRpbWU6IDE5NzAwMTAxMDAwMDAw > WjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl > PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNhbnMtc2Vy > aWYiPmxvZ2luU2hlbGw6IC9iaW4vYmFzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz > PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx > dW90O01lbmxvJnF1b3Q7LHNhbnMtc2VyaWYiPnVpZDogbWl0Y2h0ZXN0MjxvOnA+PC9vOnA+PC9z > cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu > MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNhbnMtc2VyaWYiPmNuOiBNaXRjaCBU > ZXN0MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 > eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNhbnMt > c2VyaWYiPmdpdmVuTmFtZTogTWl0Y2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i > TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv > dDtNZW5sbyZxdW90OyxzYW5zLXNlcmlmIj5zbjogVGVzdDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ > DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 > LWZhbWlseTomcXVvdDtNZW5sbyZxdW90OyxzYW5zLXNlcmlmIj5tYWlsOiBtaXRjaHRlc3QyQHNo > dXR0ZXJmbHkuY29tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ > PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVv > dDssc2Fucy1zZXJpZiI+b2JqZWN0Q2xhc3M6IHBlcnNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N > CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt > ZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNhbnMtc2VyaWYiPm9iamVjdENsYXNzOiBvcmdhbml6 > YXRpb25hbFBlcnNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi > PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1 > b3Q7LHNhbnMtc2VyaWYiPm9iamVjdENsYXNzOiBpbmV0T3JnUGVyc29uPG86cD48L286cD48L3Nw > YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w > cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssc2Fucy1zZXJpZiI+b2JqZWN0Q2xhc3M6 > IHBvc2l4QWNjb3VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi > PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1 > b3Q7LHNhbnMtc2VyaWYiPm9iamVjdENsYXNzOiB0b3A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 > cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh > bWlseTomcXVvdDtNZW5sbyZxdW90OyxzYW5zLXNlcmlmIj5vYmplY3RDbGFzczogc2hhZG93QWNj > b3VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 > eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNhbnMt > c2VyaWYiPm9iamVjdENsYXNzOiBsZGFwUHVibGljS2V5PG86cD48L286cD48L3NwYW4+PC9wPg0K > PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m > YW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssc2Fucy1zZXJpZiI+dWlkTnVtYmVyOiA1MTM0PG86cD48 > L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt > c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVvdDssc2Fucy1zZXJpZiI+Z2lk > TnVtYmVyOiA1MTM0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ > PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8mcXVv > dDssc2Fucy1zZXJpZiI+aG9tZURpcmVjdG9yeTogL2hvbWUvbWl0Y2h0ZXN0MjxvOnA+PC9vOnA+ > PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7LHNhbnMtc2VyaWYiPmdlY29zOiBN > aXRjaCBUZXN0MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz > cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvJnF1b3Q7 > LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CdXQgaXQgbGV0cyB0aGF0IGFj > Y291bnQgbG9nIGluIHdpdGhvdXQgcHJvbXB0aW5nIGZvciBhIHBhc3N3b3JkIGNoYW5nZS4mbmJz > cDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 > eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj > bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QW55IGlkZWFz > PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl > PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N > CjwvYm9keT4NCjwvaHRtbD4NCg== > > --_000_51E832D0949B4D9B9AF024E45D2D3D8Fshutterflycom_-- > > ------------------------------ > > Date: Tue, 27 Jun 2017 08:02:36 +1000 > From: William Brown <wibrown(a)redhat.com> > Subject: [389-users] Re: multimaster replication with # 389-DS version > +OS ? > To: "General discussion list for the 389 Directory server project." > <389-users(a)lists.fedoraproject.org> > Message-ID: <1498514556.32323.176.camel(a)redhat.com> > Content-Type: multipart/signed; micalg="pgp-sha1"; > protocol="application/pgp-signature"; > boundary="=-tjDvxDyyEGn5w8iHe7Gt" > > > --=-tjDvxDyyEGn5w8iHe7Gt > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Mon, 2017-06-26 at 09:30 -0700, ghiureai wrote: >> Hi List, >> I have an existing multimaster replication 389-DS , 2 hosts running : >> OS :el6.x86_64 #1 SMP >> with >> 389-ds-base-1.3.4.4-000.x86_64 >> =20 >> I need to bring the 3 host and cfg multimaster rep/ or any other rep= > =20 >> if will work, >> the new host will run: >> OS: fc24.x86_64 #1 >> with >> 389-ds-base-libs-1.3.5.15-1.fc24.x86_64 >> =20 >> wold this be able to run for couple of hours/one day , I want to use=20 >> multi master replication for migration/upgrade purpose only >> =20 > Yes, this is a valid and supported configuration for migration of the > data. We don't advise it "long term" but a few days should work just Thank you William for reply, one more replication cfg question , right now I have : DS server 1 multimaster replication with DS server 2 , when cfgt the DS server3 ( the one with # OS,# 389-DS version) ,when initializing for multimaster replication should I use DS server 1 or 2? Isabella > fine. > > > > --=20 > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane > > > --=-tjDvxDyyEGn5w8iHe7Gt > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: This is a digitally signed message part > Content-Transfer-Encoding: 7bit > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAABAgAGBQJZUYR8AAoJEISUiynM+PAgkK8P/0pNC5YlH12hG1ECr1T7+te3 > r0wAthiCFul4XjxDhfVMqv3fJMHqe5znqYkmfUJZaMbX5y0voofAJAI8kdY4sto8 > 2ysbk7bXF884H796Z/PvdcXYEA4SnXlzS/t4IfVrCWoE/ZEmhfv5FX72pn5Gsn2v > nhP8e/qP3wgA4bWoxs2Tpd28vdhW+iIUKBTG8H2m6AN7w7xfYukGsD/gIU8/WHL3 > P8dNmL+aOfrA8c5bTfBi7yE8sGzTXEYuu7ZVESgc4AOUdIMwGwz/TIgE98fbpYRk > enh1CaDabyrnZKUCW/NGfoqEvA/mCdnyEznOzI7WfS7RK/bhQgROdfJALICDTNOV > wlciphiKwGPqSCK6GvJHT7cFcN9SnVsrIgjcCvb5oGoU68pkCzVKFf/t8xJq2yNb > 3tmXLHsMeX1Xy8PXn4SNo88hTFepJCmyFJF7ev09CszO700XL3C4yNiZCN7GEeJT > ggwsupmgznhPyIETXZmiwiTrybp+wPVttjmNEi5o/mitgDWQVeyp3H4FUyFS+AHF > 9N2ESrYDINjWNV+6EIelhEHzY/0u/Occp2OJaH5kAbyyGKTGiY/1EXra/PnV5UaN > sMFtgKbFfbigenitYzdaArWG5PXIsLwWVgvNuK+Sg73RVnfQhddQCZHNfjOpIYYj > nho225e/huFqYToAVjVY > =dQwm > -----END PGP SIGNATURE----- > > --=-tjDvxDyyEGn5w8iHe7Gt-- > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > > > ------------------------------ > > End of 389-users Digest, Vol 145, Issue 28 > ******************************************

2 1

pam_ldap not respecting passwordExpirationTime
by Mitch Patenaude 27 Jun '17

27 Jun '17

I'm trying to migrate my organization of FDS, but policy requires a 90 day password expiration, and pam_ldap modules aren't forcing password changes even after the password expired. I saw in a thread back from 2011 that somebody was having an issue where setting passwordExpirationTime to 19700101000000Z would force a change, but 19700101000001Z wouldn't. Well... even setting to 19700101000000Z doesn't work for me. intdns1-01-lv:~ mpatenaude$ luser mitchtest2 dn: uid=mitchtest2,ou=People,dc=prod,dc=shutterfly,dc=com passwordExpirationTime: 19700101000000Z loginShell: /bin/bash uid: mitchtest2 cn: Mitch Test2 givenName: Mitch sn: Test2 mail: mitchtest2(a)shutterfly.com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: ldapPublicKey uidNumber: 5134 gidNumber: 5134 homeDirectory: /home/mitchtest2 gecos: Mitch Test2 But it lets that account log in without prompting for a password change. Any ideas?

3 3

multimaster replication with # 389-DS version +OS ?
by ghiureai 26 Jun '17

26 Jun '17

Hi List, I have an existing multimaster replication 389-DS , 2 hosts running : OS :el6.x86_64 #1 SMP with 389-ds-base-1.3.4.4-000.x86_64 I need to bring the 3 host and cfg multimaster rep/ or any other rep if will work, the new host will run: OS: fc24.x86_64 #1 with 389-ds-base-libs-1.3.5.15-1.fc24.x86_64 wold this be able to run for couple of hours/one day , I want to use multi master replication for migration/upgrade purpose only Thank you Isabella

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users June 2017