[389-users] Ansible role for setting up 389ds replication

[Michal Medvecky]

Hello,

I would love to share the Ansible role we successfully used for setting up 389 
replication (even with TLS) on our clusters. It’s tested with Ubuntu only.

https://github.com/pan-net-security/ansible-389dir-replication 


There’s also a role for setting 389dir itself; if interested, please e-mail me, 
let’s say it’s not ready to be public yet :)

Feedback, contributions, issues welcome.


Michal___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Multi-Master tutorial

[Michal Medvecky]

I like this one much more:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/deployment_guide/Designing_the_Replication_Process-Common_Replication_Scenarios#Multi_Master_Replication-Multi_Master_Replication_Configuration_A_Four_Suppliers
 



> On 30 Aug 2018, at 18:05, rai...@ultra-secure.de wrote:
> 
> Hi,
> 
> there is this tutorial:
> 
> http://directory.fedoraproject.org/docs/389ds/howto/howto-walkthroughmultimasterssl.html
> 
> 
> But it seems very old.
> 
> 
> Does it still apply?
> 
> 
> 
> Best Regards
> Rainer
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Master-slave replication procedure

[Michal Medvecky]

Hello,

> 19. 6. 2018 v 23:43, Thomas E Lackey :
> 
> By happy timing, we (Bozeman Pass) just added one of our in-house tools for 
> configuring replication to GitHub: https://github.com/bozemanpass/replform 
> .

I had a look at this but I don’t like the fact you need to statically define 
the configuration. I have variable number of masters and variable number of 
slaves and if I understand this correctly, adding a new backend server would 
need copypasting the replform config.

Have you considered creating LDAP providers for Terraform itself?

Michal___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/BJGMW7P4GB7A6U3EVK7N354USFD37763/

[389-users] Re: Master-slave replication procedure

[Michal Medvecky]

So I experimented with that and the most reliable option is to write an entry 
to one of masters and then wait until entries appear on all replicas.

Btw the other thing I changed is that I ran tests over VMs instead of 
containers (bcz. I was unable to run syslog in my container env) - for real 
services we use VMs only, but for running automated tests, I was always using 
containers.

Michal

> 20. 6. 2018 v 20:51, Mark Reynolds :
> 
> Michal,
> 
> You can check these attributes in the agmt:
> 
> nsds5replicalastinitend
> 
> nsds5replicalastinitstatus
> 
> These are probably more accurate for what you are trying to do.
> 
> Regards,
> 
> Mark
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/DHXZKMPQMOJTD35JNLQBNUF6PMXRI3R7/

[389-users] Re: Master-slave replication procedure

[Michal Medvecky]

Adding a 60s sleep between replication setup (step 5) and tests (step 6) 
helped. 

I am not sure waiting for nsds5BeginReplicaRefresh disappearance is enough…

Michal
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/OPJIWGBETMCNXFIRF3DXPB4TJAH65GDX/

[389-users] Master-slave replication procedure

[Michal Medvecky]

Hello,

I’m trying hard to figure out the right (ansible-automated) procedure for 
setting up master-slave replication, but I often get RUV errors on agreements 
pointing to already initialized replicas.

My scenario is with 4 master servers (with multimaster replication working 
correctly) and 4 (independent) slave servers.

List of steps:

0) setup master-master replication between master servers (works OK)

1) create replication user cn=myreplicationusername,cn=config on all slaves 

2) create LDAP entry:
dn: cn=replica,cn=“dc=test,dc=com”,cn=mapping tree,cn=config; 
  nsds5replicaroot: “dc=test,dc=com"
  nsds5replicaid: "{{ range(1,65530) | random }}"
  nsds5replicatype: “2"
  nsds5ReplicaBindDN: “cn=myreplicationusername,cn=config"
  nsds5flags: “0”

3) create ro agreement from every master to every slave
on every master server, create LDAP entry
for every slave:
dn: “cn=ro-to-{{ one of slaves }},cn=replica,cn=“dc=test,dc=com",cn=mapping 
tree,cn=config"
objectClass:
  - nsds5replicationagreement
  - top
attributes:
  nsds5replicahost: "{{ one of slaves }}"
  nsds5replicaport: “389"
  nsds5ReplicaBindDN: “cn=myreplicationusername,cn=config"
  nsds5replicabindmethod: “SIMPLE"
  nsds5ReplicaTransportInfo: “LDAP"
  nsds5replicaroot: “dc=test,dc=com"
  description: "Agreement between {{ me }} and {{ one of slaves }}"
  nsds5replicaupdateschedule: "0001-2359 0123456"
  nsds5replicatedattributelist: "(objectclass=*) $ EXCLUDE 
authorityRevocationList"
  nsds5replicacredentials: “unbreakable"

4) refresh replicas (Created in 2)) on all hosts except the first master 

on {{ first master server }} update all agreements with 
nsds5BeginReplicaRefresh: “start” 

5) wait until nsds5BeginReplicaRefresh attribute disappears

6) run tests. 

And this is the pain point and the reason I’m emailing the list - I add a dummy 
record to every master server and check it on all slaves.

But tests often fail on a random server.

# ./test.sh
Testing master-slave replication ...
---
Adding entry to ldap-master01.test.com
adding new entry "uid=slave-repl-test-1,dc=test,dc=com"

Checking entry on slave servers
Checking uid=slave-repl-test-1 on ldap-slave01 ... 1 results ✓
Checking uid=slave-repl-test-1 on ldap-slave02 ... 1 results ✓
Checking uid=slave-repl-test-1 on ldap-slave03 ... 1 results ✓
Checking uid=slave-repl-test-1 on ldap-slave04 ... 0 results ☠
Removing entry from ldap-master01
deleting entry "uid=slave-repl-test-1,dc=test,dc=com"

---
Adding entry to ldap-master02.test.com
adding new entry "uid=slave-repl-test-2,dc=test,dc=com"

Checking entry on slave servers
Checking uid=slave-repl-test-2 on ldap-slave01 ... 1 results ✓
Checking uid=slave-repl-test-2 on ldap-slave02 ... 1 results ✓
Checking uid=slave-repl-test-2 on ldap-slave03 ... 1 results ✓
Checking uid=slave-repl-test-2 on ldap-slave04 ... 0 results ☠
Removing entry from ldap-master02
deleting entry "uid=slave-repl-test-2,dc=test,dc=com"

---
Adding entry to ldap-master03.test.com
adding new entry "uid=slave-repl-test-3,dc=test,dc=com"

Checking entry on slave servers
Checking uid=slave-repl-test-3 on ldap-slave01 ... 1 results ✓
Checking uid=slave-repl-test-3 on ldap-slave02 ... 1 results ✓
Checking uid=slave-repl-test-3 on ldap-slave03 ... 1 results ✓
Checking uid=slave-repl-test-3 on ldap-slave04 ... 0 results ☠
Removing entry from ldap-master03
deleting entry "uid=slave-repl-test-3,dc=test,dc=com"

---
Adding entry to ldap-master04.test.com
adding new entry "uid=slave-repl-test-4,dc=test,dc=com"

Checking entry on slave servers
Checking uid=slave-repl-test-4 on ldap-slave01 ... 1 results ✓
Checking uid=slave-repl-test-4 on ldap-slave02 ... 1 results ✓
Checking uid=slave-repl-test-4 on ldap-slave03 ... 1 results ✓
Checking uid=slave-repl-test-4 on ldap-slave04 ... 0 results ☠
Removing entry from ldap-master04
deleting entry "uid=slave-repl-test-4,dc=test,dc=com”

List agreement update status on ldap-master01:

ldap-master01: 

dn: 
cn=ro-to-ldap-slave01.test.com,cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping 
tree,cn=config
cn: ro-to-ldap-slave01.test.com
nsds5replicaLastUpdateStatus: Error (1) Can't acquire busy replica

dn: 
cn=ro-to-ldap-slave02.test.com,cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping 
tree,cn=config
cn: ro-to-ldap-slave02.test.com
nsds5replicaLastUpdateStatus: Error (1) Can't acquire busy replica

dn: 
cn=ro-to-ldap-slave03.test.com,cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping 
tree,cn=config
cn: ro-to-ldap-slave03.test.com
nsds5replicaLastUpdateStatus: Error (1) Can't acquire busy replica

dn: 
cn=ro-to-ldap-slave04.test.com,cn=replica,cn=dc\3Dtest\2Cdc\3Dcom,cn=mapping 
tree,cn=config
cn: ro-to-ldap-slave04.test.com
nsds5replicaLastUpdateStatus: Error (19) Replication error acquiring replica: 
Replica has different database generation ID, remote replica may need to be 
initialized (RUV error)


The fourth agreement seems unin

[389-users] Re: SSL replication error

[Michal Medvecky]

So I finally made it work.

I tried with F28 and I got the error message "system error -8157 (Certificate 
extension not found.)”. After some investigations, I realized that one of certs 
in my certificate chain was incorrectly imported (under wrong nickname, thus 
not imported at all).

After fixing that, it worked.

Then, I tried the same setup with Ubuntu 18.04 (389-ds 1.3.7.10, ldap-utils 
2.4.45+dfsg-1ubuntu1) and it works.

It’s still broken with 16.04 though (389 1.3.4.9-1, ldap-utils 
2.4.42+dfsg-2ubuntu3.2)

Thanks for all your effort,

Michal

> On 5 Jun 2018, at 15:41, Mark Reynolds  wrote:
> 
> What version of openldap is on your system?  There is known issue fixed in 
> openldap-2.4.23-31 and up
> 
> Can you do a ldapsearch from one system to the the other?
> 
> ldapsearch -ZZ -xLLL -h HOST -p PORT -b "" -s base
> 
> Then check the DS access and errors logs.  There should be more info there 
> for the failure.
> 
> I just setup self-signed certs on a F28 and everything works for me (with 
> host name checking set to "on").
> 
> 
> -
> [root@ibm-ls22-04 slapd-localhost]# certutil -d . -L
> 
> Certificate Nickname Trust Attributes
>  
> SSL,S/MIME,JAR/XPI
> 
> CA certificate   CTu,Cu,Cu
> Server-Cert  u,u,Pu
> --
> 
> Can you run "certutil -L" on your cert db?  Do your trust attrs match mine?
> 
> Maybe your cert is missing the basic constraints extension (See my CA cert 
> for an example)?
> 
> 
> 
> Here is my info:
> 
> 
> Server Cert:
> 
> 
> # certutil -d /etc/dirsrv/slapd-HOST -L -n Server-Cert
> 
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 1001 (0x3e9)
> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> Issuer: "CN=CAcert"
> Validity:
> Not Before: Tue Jun 05 11:19:13 2018
> Not After : Mon Jun 05 11:19:13 2028
> Subject: "CN=ibm-ls22-04.rhts.eng.brq.redhat.com,OU=389 Directory 
> Server"
> Subject Public Key Info:
> Public Key Algorithm: PKCS #1 RSA Encryption
> RSA Public Key:
> Modulus:
> cb:16:8f:2d:72:66:b3:35:83:35:ce:df:48:b1:82:cd:
> a3:ee:95:5d:a5:21:62:ae:a9:55:52:bb:f3:03:5c:cf:
> f0:51:64:83:17:44:1a:58:70:e7:57:9b:5d:3e:6d:0a:
> f4:a2:96:28:10:82:03:9c:4a:5c:a1:cf:27:5f:97:62:
> d6:c3:57:5f:0d:ca:c1:62:41:43:47:59:5c:b0:31:c6:
> f7:fe:18:d9:2d:14:ac:08:c8:82:a3:97:66:bf:b5:6d:
> d9:99:9a:7a:19:4e:94:01:52:b5:02:2f:46:70:08:25:
> 81:7f:82:13:27:95:04:04:1f:2b:4d:21:f9:3e:1c:3d:
> 19:82:de:d3:8e:7b:80:5c:ff:12:42:19:fa:60:e6:c1:
> d4:62:8b:00:21:5a:91:e6:12:b7:82:67:3c:14:18:59:
> 43:4d:9d:cb:f8:d7:85:a3:26:f3:19:68:96:47:38:c3:
> c9:c2:7a:9d:0d:b6:86:a4:f7:bd:7e:f8:5e:a5:a3:b1:
> 82:f6:b0:f2:e0:18:83:90:95:20:52:5b:73:d6:6d:70:
> 8d:ad:55:79:43:ba:04:21:aa:e3:e8:9b:24:81:5d:f3:
> dd:8d:e0:2c:8f:c9:28:ec:ff:24:d4:ac:85:d1:2b:4e:
> 03:9d:f8:77:4f:09:88:25:65:27:98:55:a2:30:35:65
> Exponent: 65537 (0x10001)
> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> Signature:
> 4a:06:4d:21:b4:be:fe:5f:47:3d:6f:0d:e6:8d:10:52:
> 0c:74:61:33:e5:f2:4f:68:13:7f:e4:b4:0b:b2:39:52:
> 79:ca:6e:1c:ce:df:02:a1:01:3b:0d:cd:39:d2:aa:42:
> bc:17:2c:29:bf:08:25:dd:3e:8c:24:6b:80:bd:59:f9:
> 0b:91:2b:f7:41:81:4f:42:7f:1e:30:b5:4e:7b:47:67:
> 08:58:87:0d:93:76:9a:04:d0:ee:fd:f5:9f:b7:2c:9e:
> 1e:a5:6f:69:4d:d9:3c:a6:cd:5f:a6:7d:b9:9a:cc:43:
> ef:ab:1d:38:b1:9f:33:cd:2e:84:5a:96:38:9d:99:a6:
> 1a:29:ec:f2:16:2f:e7:a0:8f:56:6d:a5:62:b2:59:3a:
> b4:2c:d4:c8:b3:30:1d:23:f6:0a:e7:6d:9b:e1:d5:5c:
> c7:27:36:52:33:88:75:1a:be:0d:8e:70:fc:25:75:2f:
> 6a:70:d4:36:81:81:87:ec:ea:53:f0:22:8f:e0:6c:26:
> 40:54:ec:29:b9:c9:e3:73:3c:d9:cd:50:b5:45:51:fd:
> 1f:cb:71:e9:ae:01:65:31:f5:b1:b7:13:3d:63:b7:20:
> 1c:72:4c:2d:50:2a:be:f7:77:e2:fb:0f:09:59:4a:0c:
> ba:83:a6:72:d4:96:77:36:28:bf:56:18:2c:e9:75:6d
> Fingerprint (SHA-256):
> 
> D9:DB:31:8F:A7:57:03:8F:28:9D:53:C1:32:AE:28:B3:02:F5:CE:E7:72:62:A8:BF:DD:92:39:A9:FD:98:05:C0
> Fingerprint (SHA1):
> 85:C4:0B:3F:FC:A3:57:FB:90:D5:BE:B7:E5:8A:9A:B6:48:CB:63:4C
> 
> Mozilla-CA-Policy: false (attribute missing)
> Certificate Trust Flags:
> SSL

[389-users] Re: SSL replication error

[Michal Medvecky]

> I'm not sure what is wrong/mismatched as it's failing inside of the openldap 
> client library.  I wonder if the cert nickname having the "CN=" in it is a 
> problem?  It shouldn't be, but who knows.
> 
I tried changing it to “server-cert”, did not help.

> openldap just describes the flag as:
> 
>  LDAPSSL_AUTH_CNCHECK indicates that you accept the server's certificate 
> only if you trust the CA who issued the certificate and if the value of the 
> cn attribute is the DNS hostname of the server.  <>
> 
> Under cn=config what is nsslapd-localhost set to?  Is it the correct FQDN?

yes.

> What is in /etc/openldap/ldap.conf?

?

> There are no messages containing "conn_connect”?

not a single one.


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: SSL replication error

[Michal Medvecky]

>> 
> The server uses the openldap client libraries for replication connections.  
> Setting nsslapd-ssl-check-hostname sets these flags on the connection as 
> follows:
> 
> For server authentication it sets this flag:
> 
> LDAPSSL_AUTH_CNCHECK   --> This checks the hostname in the certificate 
> subject to that of the host
>  
> For SSL client auth it sets this flag:
> 
> LDAP_OPT_X_TLS_HARD

Okay so it does more than is documented, now I get it.

> So the issue here is either openldap is not finding the correct hostname, or 
> the hostname in the certificate subject is wrong.

As I stated previously, my domain name and cert is good. Even the reverse dns 
record is correct.

I tried replacing the certificate with an incorrect one (with invalid CN) and 
the error displayed in log is the very same. So yes, it looks like “something” 
does not match (but what?)

Connecting to ldap server itself works, even openssl s_client verifies the 
server cert ok (including the chain, what was a nice surprise to me).

Just to be clear: I’m using my own root CA, with an intermediate CA which 
issued cert for CN=ldap-master-b01.example.com and 
CN=ldap-master-b02.example.com . Both are 
imported into certstore with nickname “CN=ldap-master-b0[12]” (including the 
“CN=“). 

In cn=RSA,cn=encryption,cn=config, I use 
nsSSLPersonalitySSL='CN=ldap-master-b[01].example.com’.

I tried changing the errorlog-level as you suggested, but I got no better 
message than...

[09/May/2018:21:13:25 +0200] NSMMReplicationPlugin - 
agmt="cn=rw-to-ldap-master-b02.example.com" (ldap-master-b02:636): binddn = 
cn=MasterMasterReplicationManager,cn=config,  passwd = 
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVGRERBNEJDUXhZamN5WXpNeVppMDNPR00zTXpOaA0KTUMxaE1XTmtabUl5WmkwMVpUVmtOR1l5TlFBQ0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCRDBuaTFJaDRXMmZDcnlqWUtXQmlMRw==}yFb3FVwDwpWKupgUWiS4wg==
[09/May/2018:21:13:26 +0200] slapi_ldap_bind - Error: could not send bind 
request for id [cn=MasterMasterReplicationManager,cn=config] authentication 
mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 
(Invalid function argument.), network error 115 (Operation now in progress, 
host "ldap-master-b02.example.com:636”)

root@ldap-master-b01:~# host ldap-master-b02.example.com
ldap-master-b02.example.com has address 100.127.177.145
root@ldap-master-b01:~# host 100.127.177.145
145.177.127.100.in-addr.arpa domain name pointer ldap-master-b02.example.com.

root@ldap-master-b02:~# certutil -L -d /etc/dirsrv/nss/ -n 
"CN=ldap-master-b02.example.com"|grep Subje
Subject: "CN=ldap-master-b02.example.com"___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: SSL replication error

[Michal Medvecky]

> On 8 May 2018, at 17:45, Mark Reynolds  wrote:
> 
> 
> 
> On 05/07/2018 08:00 AM, Michal Medvecky wrote:
>> [07/May/2018:13:51:13 +0200] slapi_ldap_bind - Error: could not send bind 
>> request for id [cn=MasterMasterReplicationManager,cn=config] authentication 
>> mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 
>> (Invalid function argument.), network error 115 (Operation now in progress, 
>> host "ldap-master-b02.mydomain.com:636”)
> Is there anything else the errors log?  What about the access log on:
> ldap-master-b02.mydomain.com? 

No, absolutely no error log. I can send you tcpdump :)

> Personally I have not seen this exact
> error, but I don't see anything that says it's SSL specific.  If you
> change the agreement to use LDAP instead of SSL does it work?

Yes, I’m actually modifying my previously working plain replication Ansible 
playbook to SSL-enabled…

Michal
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] SSL replication error

[Michal Medvecky]

Hello,

can someone please help me understanding this error:

[07/May/2018:13:51:13 +0200] slapi_ldap_bind - Error: could not send bind 
request for id [cn=MasterMasterReplicationManager,cn=config] authentication 
mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 
(Invalid function argument.), network error 115 (Operation now in progress, 
host "ldap-master-b02.mydomain.com:636”)

There is no error on the other side, of course the host and port is reachable, 
and SSL is enabled with a trusted certificate on the other side (what I 
verified by querying that server using ldapsearch).

This is the full dump of the replica entry:

# rw-to-ldap-master-b02.dev.mydomain.com, replica, dc\3Dmydomain\2C
 dc\3Deu, mapping tree, config
dn: cn=rw-to-ldap-master-b02.dev.mydomain.com,cn=replica,cn=dc\3D
 mydomain\2Cdc\3Deu,cn=mapping tree,cn=config
nsDS5ReplicaUpdateSchedule: 0001-2359 0123456
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaPort: 636
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindDN: cn=MasterMasterReplicationManager,cn=config
objectClass: nsds5replicationagreement
objectClass: top
nsDS5ReplicaRoot: dc=mydomain,dc=eu
nsDS5ReplicaHost: ldap-master-b02.dev.mydomain.com
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE authorityRevocationLis
 t
description: Agreement between ldap-master-b01.dev.mydomain.com a
 nd ldap-master-b02.dev.mydomain.com
cn: rw-to-ldap-master-b02.dev.mydomain.com
nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
 RERBNEJDUXhZamN5WXpNeVppMDNPR00zTXpOaA0KTUMxaE1XTmtabUl5WmkwMVpUVmtOR1l5TlFBQ
 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQlFjWk9FZlZBL2xQeG
 tMQ2ZRcHZmbw==}OjATeE/K+0qb9fB4HpA1sA==
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 1970010100Z
nsds5replicaLastUpdateEnd: 1970010100Z
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: -1 Unable to acquire replicaLDAP error: Can't co
 ntact LDAP server
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 1970010100Z
nsds5replicaLastInitEnd: 1970010100Z

Thanks

Michal
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Configuring TLS/SSL Enabled 389 Directory Server

[Michal Medvecky]

> Now I am trying to modify the settings of my dse.ldif file.  I can modify the 
> file without issue.  If I restart the service all my file edits are lost.  
> Why are my edits lost when restarting the service?  Thanks for your advice!


Never edit that file directly. Always use ldapmodify.

Michal___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: New Install Missing Schema Files

[Michal Medvecky]

You have to run setup-ds after package installation

> On 10 Oct 2017, at 17:13, Trevor Fong  wrote:
> 
> Hi Everyone,
> 
> I just did a new install and it looks like no schema files were included with 
> it?
> I seem to remember that previously, included schema files would be in 
> /etc/dirsrv/schema and would get copied into any new instances that were set 
> up.
> However with this install /etc/dirsrv/schema/ only contained 99user.ldif
> Am I missing something?
> 
> Thanks a lot,
> Trev
> 
> Here’s what I did:
> 
> [root@eldapdch1 tfong]# uname -a
> Linux eldapdch1 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9 03:55:24 EDT 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> [root@eldapdch1 etc]# yum install 389-ds
> Loaded plugins: rhnplugin, search-disabled-repos
> This system is receiving updates from RHN Classic or Red Hat Satellite.
> Resolving Dependencies
> --> Running transaction check
> ---> Package 389-ds.noarch 0:1.2.2-6.el7 will be installed
> --> Processing Dependency: 389-dsgw for package: 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-ds-console-doc for package: 
> 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-ds-console for package: 
> 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-ds-base for package: 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-console for package: 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-admin-console-doc for package: 
> 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-admin-console for package: 
> 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-admin for package: 389-ds-1.2.2-6.el7.noarch
> --> Running transaction check
> ---> Package 389-admin.x86_64 0:1.1.46-1.el7 will be installed
> --> Processing Dependency: libadmsslutil.so.0()(64bit) for package: 
> 389-admin-1.1.46-1.el7.x86_64
> --> Processing Dependency: libadminutil.so.0()(64bit) for package: 
> 389-admin-1.1.46-1.el7.x86_64
> ---> Package 389-admin-console.noarch 0:1.1.12-1.el7 will be installed
> ---> Package 389-admin-console-doc.noarch 0:1.1.12-1.el7 will be installed
> ---> Package 389-console.noarch 0:1.1.18-1.el7 will be installed
> ---> Package 389-ds-base.x86_64 0:1.3.6.1-19.el7_4 will be installed
> --> Processing Dependency: 389-ds-base-libs = 1.3.6.1-19.el7_4 for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> --> Processing Dependency: libnunc-stans.so.0()(64bit) for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> --> Processing Dependency: libsds.so.0()(64bit) for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> --> Processing Dependency: libns-dshttpd-1.3.6.1.so()(64bit) for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> --> Processing Dependency: libslapd.so.0()(64bit) for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> ---> Package 389-ds-console.noarch 0:1.2.16-1.el7 will be installed
> ---> Package 389-ds-console-doc.noarch 0:1.2.16-1.el7 will be installed
> ---> Package 389-dsgw.x86_64 0:1.1.11-5.el7 will be installed
> --> Running transaction check
> ---> Package 389-adminutil.x86_64 0:1.1.21-2.el7 will be installed
> ---> Package 389-ds-base-libs.x86_64 0:1.3.6.1-19.el7_4 will be installed
> --> Finished Dependency Resolution
> 
> Dependencies Resolved
> 
> =
> Package  Arch 
>  VersionRepository
>Size
> =
> Installing:
> 389-ds   noarch   
>  1.2.2-6.el7epel  
>11 k
> Installing for dependencies:
> 389-adminx86_64   
>  1.1.46-1.el7   epel  
>   391 k
> 389-admin-consolenoarch   
>  1.1.12-1.el7   epel  
>   204 k
> 389-admin-console-docnoarch   
>  1.1.12-1.el7   epel  
>45 k
> 389-adminutilx86_64   
>  1.1.21-2.el7   epel  
>73 k
> 389-console  noarch   

[389-users] Ubuntu packages for 389

[Michal Medvecky]

Hello,

I know it’s a bit weird question for something called “Fedora … “, but is there 
any chance someone maintains Ubuntu/Debian packages for latest 389 versions?

I’m struggling hard with the historical version available in Ubuntu (1.3.4.9) 
and for some reasons I can’t use any other distro :(

Michal
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: ldapcompare on cn=config

[Michal Medvecky]

> We need to raise it as an issue then. 

For the record, https://pagure.io/389-ds-base/issue/49390 


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: ldapcompare on cn=config

[Michal Medvecky]

Hello,

thanks for the reply.


> I think it's a "lack of a feature" in the server. If you want, raise an
> issue about it, and we'll look at it when we can, :) 

It’s actually required by Ansible ldap_attr module….

> A work around is to do ldapsearch for the object and attr and compare
> externally. 

… but using state: exact for my particular usage is fine.

But expect other people using Ansible complaining about this lack of feature.

Michal
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] ldapcompare on cn=config

[Michal Medvecky]

Hello,

 I need to do ldapcompare in cn=encryption,cn=config and have no idea why I 
can’t:


root@ldap01:/home/ubuntu# ldapcompare -h localhost -D cn=root -wadmin 
cn=encryption,cn=config nsSSL2:off
Compare Result: Server is unwilling to perform (53)
Additional info: Operation on Directory Specific Entry not allowed

cn=root is the directory manager user.

What can I do to change this?

389-ds 1.3.5.15 - ubuntu

Thanks

Michal
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org