Re: [Freeipa-users] compat settings
On Thu, 21 May 2015, Rudolf Gabler wrote:
Hi to whom it may concern,
we used for many years a 2 location policy to separate email users from
unix users in order to not using the same passwords. So we had 2 trees
in our LDAP with the same user but different passwords.
In freeipa (where we want to migrate now) I can use the accounts and
compat (for email) trees for this purpose and so I added a
dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: userPassword=*
to the compat settings to have a separate place for the password (!not
userPassword=%{userPassword}, because then the accounts password are
mirrored). This works, but I’m not allowed to change the password i.e.
with: ldappasswd -x -D cn=Directory Manager -W -S
uid=myuser,cn=users,cn=compat,dc=example,dc=com
I get a result of:
No such object (32)
Additional info: Failed to update password
where as for the accounts tree the ldappasswd is working fine.
What additional setting may be required?
slapi-nis does not support modifying entries in the compat tree. The
tree is virtual, it is re-populated from the original data every time
389-ds server is restarted.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ruv problem
On 05/21/2015 09:50 AM, Alexander Frolushkin wrote:
Thank you. Do I need to run this on each of my 17 IPA servers in unix
domain?
no, the cleanallruv task should be propagated to all server a repl
agreement exists
WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764
*From:*freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Ludwig Krispenz
*Sent:* Thursday, May 21, 2015 1:37 PM
*To:* freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] ruv problem
could you try this:
https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html
it was successfully applied before
On 05/21/2015 06:58 AM, Alexander Frolushkin wrote:
Hello again.
Is it now clear how to deal with problem ipa-replica-manage
list-ruv showing
unable to decode: {replica 16} 548a81260010
548a81260010
?
I have this on all of my 17 servers, including a new replica
created recently, and
ipa-replica-manage clean-ruv 16 says
unable to decode: {replica 16} 548a81260010
548a81260010 Replica ID 16 not found
WBR,
Alexander Frolushkin
Информация в этом сообщении предназначена исключительно для
конкретных лиц, которым она адресована. В сообщении может
содержаться конфиденциальная информация, которая не может быть
раскрыта или использована кем-либо, кроме адресатов. Если вы не
адресат этого сообщения, то использование, переадресация,
копирование или распространение содержания сообщения или его части
незаконно и запрещено. Если Вы получили это сообщение ошибочно,
пожалуйста, незамедлительно сообщите отправителю об этом и удалите
со всем содержимым само сообщение и любые возможные его копии и
приложения.
The information contained in this communication is intended solely
for the use of the individual or entity to whom it is addressed
and others authorized to receive it. It may contain confidential
or legally privileged information. The contents may not be
disclosed or used by anyone other than the addressee. If you are
not the intended recipient(s), any use, disclosure, copying,
distribution or any action taken or omitted to be taken in
reliance on it is prohibited and may be unlawful. If you have
received this communication in error please notify us immediately
by responding to this email and then delete the e-mail and all
attachments and any copies thereof.
(c)20mf50
Информация в этом сообщении предназначена исключительно для конкретных
лиц, которым она адресована. В сообщении может содержаться
конфиденциальная информация, которая не может быть раскрыта или
использована кем-либо, кроме адресатов. Если вы не адресат этого
сообщения, то использование, переадресация, копирование или
распространение содержания сообщения или его части незаконно и
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста,
незамедлительно сообщите отправителю об этом и удалите со всем
содержимым само сообщение и любые возможные его копии и приложения.
The information contained in this communication is intended solely for
the use of the individual or entity to whom it is addressed and others
authorized to receive it. It may contain confidential or legally
privileged information. The contents may not be disclosed or used by
anyone other than the addressee. If you are not the intended
recipient(s), any use, disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it is prohibited and may
be unlawful. If you have received this communication in error please
notify us immediately by responding to this email and then delete the
e-mail and all attachments and any copies thereof.
(c)20mf50
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ruv problem
could you try this:
https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html
it was successfully applied before
On 05/21/2015 06:58 AM, Alexander Frolushkin wrote:
Hello again.
Is it now clear how to deal with problem ipa-replica-manage list-ruv
showing
unable to decode: {replica 16} 548a81260010 548a81260010
?
I have this on all of my 17 servers, including a new replica created
recently, and
ipa-replica-manage clean-ruv 16 says
unable to decode: {replica 16} 548a81260010
548a81260010 Replica ID 16 not found
WBR,
Alexander Frolushkin
?? ? ? ? ? ??? ??
???, ??? ??? ??. ? ? ? ???
??, ??? ?? ? ???
???-, ? ?. ?? ?? ??? ?
?, ?? ?, ?, ??? ???
??? ?? ? ??? ??? ? ? ?
?. ?? ??? ? , ??,
??? ??? ?? ? ??? ??
?? ? ? ? ? ??? ? ? ??.
The information contained in this communication is intended solely for
the use of the individual or entity to whom it is addressed and others
authorized to receive it. It may contain confidential or legally
privileged information. The contents may not be disclosed or used by
anyone other than the addressee. If you are not the intended
recipient(s), any use, disclosure, copying, distribution or any action
taken or omitted to be taken in reliance on it is prohibited and may
be unlawful. If you have received this communication in error please
notify us immediately by responding to this email and then delete the
e-mail and all attachments and any copies thereof.
(c)20mf50
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] compat settings
Hi to whom it may concern,
we used for many years a 2 location policy to separate email users from unix
users in order to not using the same passwords. So we had 2 trees in our LDAP
with the same user but different passwords.
In freeipa (where we want to migrate now) I can use the accounts and compat
(for email) trees for this purpose and so I added a
dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: userPassword=*
to the compat settings to have a separate place for the password (!not
userPassword=%{userPassword}, because then the accounts password are mirrored).
This works, but I’m not allowed to change the password i.e. with:
ldappasswd -x -D cn=Directory Manager -W -S
uid=myuser,cn=users,cn=compat,dc=example,dc=com
I get a result of:
No such object (32)
Additional info: Failed to update password
where as for the accounts tree the ldappasswd is working fine.
What additional setting may be required?
Regards,
Rudi Gabler
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] confused by ldapsearch results
On 05/21/2015 07:50 AM, Martin Kosek wrote: On 05/20/2015 04:01 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote: This worked for me: $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=cm (|(uid=admin)(name=admin)) dn SASL/GSSAPI authentication started SASL username: ad...@example.com SASL SSF: 56 SASL data security layer installed. dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com Note that cn is Common Name which is set to the user's full name, in this case likely George Boyce. So that will never match gboyce. Rob Rob, Thanks for your example, it had me test my ldap bind which narrows the problem and gives me a workaround. I used cn=gboyce to pull my group record, so I expected my test to return two records for my account and my group. And it does when I authenticate as admin as in your test. So the problem is isolated to when I use a dedicated search account. I missed this note on setting up system accounts: Note: IPA 4.0 is going to change the default stance on data from nearly everything is readable to nothing is readable, by default. You will eventually need to add some Access Control Instructions (ACI's) to grant read access to the parts of the LDAP tree you will need. Looks like I need to do just that. :-) Still the behavior of returning nothing by adding an extra false term, IIRC, this is done on purpose, there was an CVE and as a fix, if you are querying with an attribute you do not have permission to query with, you get no answers. correct. It was https://bugzilla.redhat.com/show_bug.cgi?id=979508 and behaviour matches the spec in 13.3.3.3: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Permissions For the other problem, there is not enough information to judge. If two entries are in different subtrees also different acis could apply, we need the full set of acis, the full search and eventuallay access control logging (nsslapd-errorlog-level: 128) or returning one entry when each of the terms each returns a unique entry, seems wrong. It does return two entries when both are in the same subtree. This one sounds strange, CCing Ludwig for reference. ### ### everything ok when using admin... two records, one from users, one from groups ### # ldapsearch -Y GSSAPI -b dc=... (|(uid=admin)(cn=gboyce)) dn SASL/GSSAPI authentication started SASL username: admin@... SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base dc=... with scope subtree # filter: (|(uid=admin)(cn=gboyce)) # requesting: dn # # admin, users, accounts, ... dn: uid=admin,cn=users,cn=accounts,dc=... # gboyce, groups, accounts, ... dn: cn=gboyce,cn=groups,cn=accounts,dc=... # search result search: 4 result: 0 Success # numResponses: 3 # numEntries: 2 ## ### ### system account (without ACLs) returns simple queries, but not correct results for compound queries in different subtrees ### ### ### different subtrees fails... ### # ldapsearch -x -D uid=LDAPsearch,cn=sysaccounts,cn=etc,dc=... -w ... -b dc=... (|(uid=admin)(cn=gboyce)) dn # extended LDIF # # LDAPv3 # base dc=... with scope subtree # filter: (|(uid=admin)(cn=gboyce)) # requesting: dn # # admin, users, accounts, ... dn: uid=admin,cn=users,cn=accounts,dc=... # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ### ### same subtree works... ### # l (|(cn=admins)(cn=gboyce)) dn # extended LDIF # # LDAPv3 # base dc=... with scope subtree # filter: (|(cn=admins)(cn=gboyce)) # requesting: dn # # admins, groups, accounts, ... dn: cn=admins,cn=groups,cn=accounts,dc=... # gboyce, groups, accounts, ... dn: cn=gboyce,cn=groups,cn=accounts,dc=... # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 ### ### valid filter from above with extra false term... ### # l (|(cn=admins)(cn=gboyce)(name=foobar)) dn # extended LDIF # # LDAPv3 # base dc=... with scope subtree # filter: (|(cn=admins)(cn=gboyce)(name=foobar)) # requesting: dn # # search result search: 2 result: 0 Success # numResponses: 1 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 5/20/15 7:53 AM, Mark Reynolds wrote:
On 05/20/2015 10:17 AM, thierry bordaz wrote:
On 05/20/2015 03:46 PM, Janelle wrote:
On 5/20/15 6:01 AM, thierry bordaz wrote:
On 05/20/2015 02:57 AM, Janelle wrote:
On 5/19/15 12:04 AM, thierry bordaz wrote:
On 05/19/2015 03:42 AM, Janelle wrote:
On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I really wish the
product was more stable, it is so much potential and yet.
Servers running for 6 days no issues. No new accounts or
changes (maybe a few users changing passwords) and again, 5 out
of 16 servers are no longer in sync.
I can test it easily by adding an account and then waiting a
few minutes, then run ipa user-show --all username on all
the servers, and only a few of them have the account. I have
now waited 15 minutes, still no luck.
Oh well.. I guess I will go look at alternatives. I had such
high hopes for this tool. Thanks so much everyone for all your
help in trying to get things stable, but for whatever reason,
there is a random loss of sync among the servers and obviously
this is not acceptable.
regards
~J
All the replicas are happy again. I found these again:
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 23} 5553e3a30017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
What I also found to be interesting is that I have not deleted any
masters at all, so this was quite perplexing where the orphaned
entries came from. However I did find 3 of the replicas did not
show complete RUV lists... While most of the replicas had a list
of all 16 servers, a couple of them listed only 4 or 5. (using
ipa-replica-manage list-ruv)
I don't know about the orphaned entries. Did you get entries below
deleted parents ?
AFAIK all replicas are master and so have an entry {replica rid}
in the RUV. We should expect all servers having the same number of
RUVelements (16, 4 or 5). The servers with 4 or 5 may be isolated
so that they did not received updates from those with 16 RUVelements.
would you copy/paste an example of RUV with 16 and with 4-5 ?
Now, the steps to clear this were:
Removed the unable to decode with the direct ldapmodify's. This
worked across all replicas, which was nice and did not have to be
repeated in each one. In other words, entered on a single server,
and it was removed on all.
Hello,
Did you do direct ldapmodify onto the RUV entry
(nsuniqueid=---,SUFFIX) , clean RUV ?
Thierry,
Janelle just manually added a cleanallruv task (that I had recommended
the other week).
Mark
dc1-ipa1 and dc1-ipa2 are missing some RUVelement. If you do an
update on dc3-ipa1, is it replicated to dc1-ipa[12] ?
Also there are duplicated RID (9, 25) for dc1-ipa2.example.com:389.
You may see some messages like 'attrlist_replace' in some error logs.
25 seems to be the new RID.
thanks
thierry
re-initialized --from=good server on the ones with the short list.
Waited 5 minutes to let everything settle, then started running
tests of adds/deletes which seemed to be just fine.
Here are 2 of the DCs
-
Node dc1-ipa1
-
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa4.example.com 389 4
-
Node dc1-ipa2
-
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
-
Node dc1-ipa3
-
dc3-ipa1.example.com 389 14
dc3-ipa2.example.com 389 13
dc3-ipa3.example.com 389 12
dc3-ipa4.example.com 389 11
dc2-ipa1.example.com 389 7
dc2-ipa2.example.com 389 6
dc2-ipa3.example.com 389 5
dc2-ipa4.example.com 389 3
dc4-ipa1.example.com 389 18
dc4-ipa2.example.com 389 19
dc4-ipa3.example.com 389 20
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa2.example.com 389 9
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 24} 554d53d30018 554d54a400020018
dc5-ipa1.example.com 389 26
dc5-ipa2.example.com 389 15
dc5-ipa3.example.com 389 17
-
Node dc1-ipa4
-
dc3-ipa1.example.com 389 14
dc3-ipa2.example.com 389 13
dc3-ipa3.example.com 389 12
dc3-ipa4.example.com 389 11
dc2-ipa1.example.com 389 7
dc2-ipa2.example.com 389 6
dc2-ipa3.example.com 389 5
dc2-ipa4.example.com 389 3
dc4-ipa1.example.com 389 18
dc4-ipa2.example.com 389 19
dc4-ipa3.example.com 389 20
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa2.example.com 389 9
dc1-ipa3.example.com 389 8
Re: [Freeipa-users] confused by ldapsearch results
Knowing that the first issue is 'working as designed', I can now focus on exactly how to fix it. In my case, the issue is that a vendor's code is appending name=... to its search filter to find a user group. Thanks, I can troubleshoot the second issue, it isn't a roadblock to my task. On 05/21/2015 07:50 AM, Martin Kosek wrote: On 05/20/2015 04:01 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote: Still the behavior of returning nothing by adding an extra false term, IIRC, this is done on purpose, there was an CVE and as a fix, if you are querying with an attribute you do not have permission to query with, you get no answers. correct. It was https://bugzilla.redhat.com/show_bug.cgi?id=979508 and behaviour matches the spec in 13.3.3.3: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Permissions For the other problem, there is not enough information to judge. If two entries are in different subtrees also different acis could apply, we need the full set of acis, the full search and eventuallay access control logging (nsslapd-errorlog-level: 128) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 5/21/15 5:20 AM, thierry bordaz wrote: Hello Janelle, Those 3 RIDs were already present in Node dc2-ipa1, correct ? They reappeared on others nodes as well ? May be ds2-ipa1 established a replication session with its peers and send those RIDs. Could you track in all the access logs, when the op csn=5552f71800030017 was applied. Note that the two hexa values of replica 23 changed (5545d61f00020017 5552f71800030017 vs 5553e3a30017 555432430017). Have you recreated a replica 23 ?. Do you have replication logging enabled ? thanks thierry Just to help me -- what is the best way to enable the logging level you need? I thought I did it correctly adding to ldif.dse, but I don't think it took. I am used to OpenLDAP, so perhaps there is a different way to do it with 389-ds. Can you suggest settings of logging you want me to use? ~Janelle -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 05/21/2015 06:25 AM, Janelle wrote: On 5/21/15 5:20 AM, thierry bordaz wrote: Hello Janelle, Those 3 RIDs were already present in Node dc2-ipa1, correct ? They reappeared on others nodes as well ? May be ds2-ipa1 established a replication session with its peers and send those RIDs. Could you track in all the access logs, when the op csn=5552f71800030017 was applied. Note that the two hexa values of replica 23 changed (5545d61f00020017 5552f71800030017 vs 5553e3a30017 555432430017). Have you recreated a replica 23 ?. Do you have replication logging enabled ? thanks thierry Just to help me -- what is the best way to enable the logging level you need? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting The Replication log level. I thought I did it correctly adding to ldif.dse, but I don't think it took. You cannot edit dse.ldif while the server is running. Anyway, ldapmodify is the best way to set this value. I am used to OpenLDAP, so perhaps there is a different way to do it with 389-ds. Can you suggest settings of logging you want me to use? The Replication log level. ~Janelle -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 05/21/2015 03:04 PM, Janelle wrote: On 5/21/15 5:49 AM, Rich Megginson wrote: On 05/21/2015 06:25 AM, Janelle wrote: On 5/21/15 5:20 AM, thierry bordaz wrote: Hello Janelle, Those 3 RIDs were already present in Node dc2-ipa1, correct ? They reappeared on others nodes as well ? May be ds2-ipa1 established a replication session with its peers and send those RIDs. Could you track in all the access logs, when the op csn=5552f71800030017 was applied. Note that the two hexa values of replica 23 changed (5545d61f00020017 5552f71800030017 vs 5553e3a30017 555432430017). Have you recreated a replica 23 ?. Do you have replication logging enabled ? thanks thierry Just to help me -- what is the best way to enable the logging level you need? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting The Replication log level. I thought I did it correctly adding to ldif.dse, but I don't think it took. You cannot edit dse.ldif while the server is running. Anyway, ldapmodify is the best way to set this value. I am used to OpenLDAP, so perhaps there is a different way to do it with 389-ds. Can you suggest settings of logging you want me to use? The Replication log level. ~Janelle How do I kill one of the ldapmodify cleans I had started but seems to be stuck: abort should be done by ldapmodify similar to starting it: ldapmo |ldapmodify dn: cn=abort 222, cn=abort cleanallruv, cn=tasks, cn=config objectclass: extensibleObject cn: abort 222 replica-base-dn: dc=example,dc=com replica-id: 222 replica-certify-all: no -- if set to no the task does not wait for all the replica servers to have been sent the abort task, or be online, before completing. If set to yes, the task will run forever until all the configured replicas have been aborted. Note - the orginal default was yes, but this was changed to no on 4/21/15. It is best to set this attribute anyway, and not rely on what the default is.| if it doesn't work we have to ask Mark :-) CLEANALLRUV tasks RID 24 None No abort CLEANALLRUV tasks running It has been 45 minutes and still nothing, so I want to kill it and try again. ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 5/21/15 5:49 AM, Rich Megginson wrote: On 05/21/2015 06:25 AM, Janelle wrote: On 5/21/15 5:20 AM, thierry bordaz wrote: Hello Janelle, Those 3 RIDs were already present in Node dc2-ipa1, correct ? They reappeared on others nodes as well ? May be ds2-ipa1 established a replication session with its peers and send those RIDs. Could you track in all the access logs, when the op csn=5552f71800030017 was applied. Note that the two hexa values of replica 23 changed (5545d61f00020017 5552f71800030017 vs 5553e3a30017 555432430017). Have you recreated a replica 23 ?. Do you have replication logging enabled ? thanks thierry Just to help me -- what is the best way to enable the logging level you need? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting The Replication log level. I thought I did it correctly adding to ldif.dse, but I don't think it took. You cannot edit dse.ldif while the server is running. Anyway, ldapmodify is the best way to set this value. I am used to OpenLDAP, so perhaps there is a different way to do it with 389-ds. Can you suggest settings of logging you want me to use? The Replication log level. ~Janelle How do I kill one of the ldapmodify cleans I had started but seems to be stuck: CLEANALLRUV tasks RID 24 None No abort CLEANALLRUV tasks running It has been 45 minutes and still nothing, so I want to kill it and try again. ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 05/21/2015 01:36 PM, Janelle wrote:
And just like that - for no reason, they all reappeared:
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 23} 5545d61f00020017 5552f71800030017
unable to decode {replica 24} 554d53d30018 554d54a400020018
:-(
~J
so it is the same set of rids again. Just to be sure, do servers with
rid 16, 23 and 24 still exist ? I think last time you cleaned them by
ldapmodify, so they should no longer exist.
you said you would enable logging, did you find something in the logs ?
or can we have a look at them ?
Ludwig
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 5/21/15 5:20 AM, thierry bordaz wrote:
On 05/21/2015 01:36 PM, Janelle wrote:
On 5/20/15 7:53 AM, Mark Reynolds wrote:
On 05/20/2015 10:17 AM, thierry bordaz wrote:
On 05/20/2015 03:46 PM, Janelle wrote:
On 5/20/15 6:01 AM, thierry bordaz wrote:
On 05/20/2015 02:57 AM, Janelle wrote:
On 5/19/15 12:04 AM, thierry bordaz wrote:
On 05/19/2015 03:42 AM, Janelle wrote:
On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I really wish the
product was more stable, it is so much potential and yet.
Servers running for 6 days no issues. No new accounts or
changes (maybe a few users changing passwords) and again, 5
out of 16 servers are no longer in sync.
I can test it easily by adding an account and then waiting a
few minutes, then run ipa user-show --all username on all
the servers, and only a few of them have the account. I have
now waited 15 minutes, still no luck.
Oh well.. I guess I will go look at alternatives. I had such
high hopes for this tool. Thanks so much everyone for all
your help in trying to get things stable, but for whatever
reason, there is a random loss of sync among the servers and
obviously this is not acceptable.
regards
~J
All the replicas are happy again. I found these again:
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 23} 5553e3a30017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
What I also found to be interesting is that I have not deleted
any masters at all, so this was quite perplexing where the
orphaned entries came from. However I did find 3 of the replicas
did not show complete RUV lists... While most of the replicas
had a list of all 16 servers, a couple of them listed only 4 or
5. (using ipa-replica-manage list-ruv)
I don't know about the orphaned entries. Did you get entries
below deleted parents ?
AFAIK all replicas are master and so have an entry {replica
rid} in the RUV. We should expect all servers having the same
number of RUVelements (16, 4 or 5). The servers with 4 or 5 may
be isolated so that they did not received updates from those with
16 RUVelements.
would you copy/paste an example of RUV with 16 and with 4-5 ?
Now, the steps to clear this were:
Removed the unable to decode with the direct ldapmodify's. This
worked across all replicas, which was nice and did not have to be
repeated in each one. In other words, entered on a single server,
and it was removed on all.
Hello,
Did you do direct ldapmodify onto the RUV entry
(nsuniqueid=---,SUFFIX) , clean RUV ?
Thierry,
Janelle just manually added a cleanallruv task (that I had
recommended the other week).
Mark
dc1-ipa1 and dc1-ipa2 are missing some RUVelement. If you do an
update on dc3-ipa1, is it replicated to dc1-ipa[12] ?
Also there are duplicated RID (9, 25) for dc1-ipa2.example.com:389.
You may see some messages like 'attrlist_replace' in some error logs.
25 seems to be the new RID.
thanks
thierry
re-initialized --from=good server on the ones with the short list.
Waited 5 minutes to let everything settle, then started running
tests of adds/deletes which seemed to be just fine.
Here are 2 of the DCs
-
Node dc1-ipa1
-
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa4.example.com 389 4
-
Node dc1-ipa2
-
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
-
Node dc1-ipa3
-
dc3-ipa1.example.com 389 14
dc3-ipa2.example.com 389 13
dc3-ipa3.example.com 389 12
dc3-ipa4.example.com 389 11
dc2-ipa1.example.com 389 7
dc2-ipa2.example.com 389 6
dc2-ipa3.example.com 389 5
dc2-ipa4.example.com 389 3
dc4-ipa1.example.com 389 18
dc4-ipa2.example.com 389 19
dc4-ipa3.example.com 389 20
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa2.example.com 389 9
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 24} 554d53d30018
554d54a400020018
dc5-ipa1.example.com 389 26
dc5-ipa2.example.com 389 15
dc5-ipa3.example.com 389 17
-
Node dc1-ipa4
-
dc3-ipa1.example.com 389 14
dc3-ipa2.example.com 389 13
dc3-ipa3.example.com 389 12
dc3-ipa4.example.com 389 11
dc2-ipa1.example.com 389 7
dc2-ipa2.example.com 389 6
dc2-ipa3.example.com 389 5
dc2-ipa4.example.com 389 3
dc4-ipa1.example.com 389 18
dc4-ipa2.example.com 389 19
dc4-ipa3.example.com 389 20
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
Re: [Freeipa-users] replication again :-(
On 5/21/15 5:16 AM, Ludwig Krispenz wrote:
On 05/21/2015 01:36 PM, Janelle wrote:
And just like that - for no reason, they all reappeared:
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 23} 5545d61f00020017 5552f71800030017
unable to decode {replica 24} 554d53d30018 554d54a400020018
:-(
~J
so it is the same set of rids again. Just to be sure, do servers with
rid 16, 23 and 24 still exist ? I think last time you cleaned them by
ldapmodify, so they should no longer exist.
you said you would enable logging, did you find something in the logs
? or can we have a look at them ?
Ludwig
They do NOT exist. Have not found anything in the logs. I also now have
2 masters who no longer start. Not sure if this is related, but starting
them after a minute or so, dirsrv dies...
For the last 48 hours things were working perfectly. Some minor adds and
a few deletes, but replication was working flawlessly. Then I woke up to
this. :-(
Still a lot to go through before I can post anything. More to come.
~Janelle
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 05/21/2015 01:36 PM, Janelle wrote:
On 5/20/15 7:53 AM, Mark Reynolds wrote:
On 05/20/2015 10:17 AM, thierry bordaz wrote:
On 05/20/2015 03:46 PM, Janelle wrote:
On 5/20/15 6:01 AM, thierry bordaz wrote:
On 05/20/2015 02:57 AM, Janelle wrote:
On 5/19/15 12:04 AM, thierry bordaz wrote:
On 05/19/2015 03:42 AM, Janelle wrote:
On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I really wish the
product was more stable, it is so much potential and yet.
Servers running for 6 days no issues. No new accounts or
changes (maybe a few users changing passwords) and again, 5
out of 16 servers are no longer in sync.
I can test it easily by adding an account and then waiting a
few minutes, then run ipa user-show --all username on all
the servers, and only a few of them have the account. I have
now waited 15 minutes, still no luck.
Oh well.. I guess I will go look at alternatives. I had such
high hopes for this tool. Thanks so much everyone for all your
help in trying to get things stable, but for whatever reason,
there is a random loss of sync among the servers and obviously
this is not acceptable.
regards
~J
All the replicas are happy again. I found these again:
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 23} 5553e3a30017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
What I also found to be interesting is that I have not deleted
any masters at all, so this was quite perplexing where the
orphaned entries came from. However I did find 3 of the replicas
did not show complete RUV lists... While most of the replicas had
a list of all 16 servers, a couple of them listed only 4 or 5.
(using ipa-replica-manage list-ruv)
I don't know about the orphaned entries. Did you get entries below
deleted parents ?
AFAIK all replicas are master and so have an entry {replica rid}
in the RUV. We should expect all servers having the same number of
RUVelements (16, 4 or 5). The servers with 4 or 5 may be isolated
so that they did not received updates from those with 16 RUVelements.
would you copy/paste an example of RUV with 16 and with 4-5 ?
Now, the steps to clear this were:
Removed the unable to decode with the direct ldapmodify's. This
worked across all replicas, which was nice and did not have to be
repeated in each one. In other words, entered on a single server,
and it was removed on all.
Hello,
Did you do direct ldapmodify onto the RUV entry
(nsuniqueid=---,SUFFIX) , clean RUV ?
Thierry,
Janelle just manually added a cleanallruv task (that I had
recommended the other week).
Mark
dc1-ipa1 and dc1-ipa2 are missing some RUVelement. If you do an
update on dc3-ipa1, is it replicated to dc1-ipa[12] ?
Also there are duplicated RID (9, 25) for dc1-ipa2.example.com:389.
You may see some messages like 'attrlist_replace' in some error logs.
25 seems to be the new RID.
thanks
thierry
re-initialized --from=good server on the ones with the short list.
Waited 5 minutes to let everything settle, then started running
tests of adds/deletes which seemed to be just fine.
Here are 2 of the DCs
-
Node dc1-ipa1
-
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa4.example.com 389 4
-
Node dc1-ipa2
-
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
-
Node dc1-ipa3
-
dc3-ipa1.example.com 389 14
dc3-ipa2.example.com 389 13
dc3-ipa3.example.com 389 12
dc3-ipa4.example.com 389 11
dc2-ipa1.example.com 389 7
dc2-ipa2.example.com 389 6
dc2-ipa3.example.com 389 5
dc2-ipa4.example.com 389 3
dc4-ipa1.example.com 389 18
dc4-ipa2.example.com 389 19
dc4-ipa3.example.com 389 20
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa2.example.com 389 9
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 24} 554d53d30018
554d54a400020018
dc5-ipa1.example.com 389 26
dc5-ipa2.example.com 389 15
dc5-ipa3.example.com 389 17
-
Node dc1-ipa4
-
dc3-ipa1.example.com 389 14
dc3-ipa2.example.com 389 13
dc3-ipa3.example.com 389 12
dc3-ipa4.example.com 389 11
dc2-ipa1.example.com 389 7
dc2-ipa2.example.com 389 6
dc2-ipa3.example.com 389 5
dc2-ipa4.example.com 389 3
dc4-ipa1.example.com 389 18
dc4-ipa2.example.com 389 19
dc4-ipa3.example.com 389 20
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa2.example.com 389 9
Re: [Freeipa-users] Updates refused when trying to do dynamic DNS updates with TSIG
On 20.5.2015 17:38, Brian Koontz wrote: Running FreeIPA 4.1.4, Fedora 21. Trying to get dynamic DNS updates on clients to work following these instructions: http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG (Using GSS-TSIG isn't an option because I have no way of authenticating every time a client IP changes.) Generally, GSS-TSIG with Kerberos should not be affected by changes in client's IP address and is strongly recommended over TSIG. I've reread the instructions several times, but each time I get update failed: REFUSED. Logs aren't showing anything useful other than the query is being refused. Is this document missing an important step? Yes, thank you for catching this! I added 'ipa dnszone-mod --dynamic-update=1' command to the how-to: http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG#Server (I saw no need to create a DNS/ service as there should be no krb5 authentication involved here...) This is correct assumption, you should not need it. Thank you for your time! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Count of IPA Servers for SSSD
Hi All what a count of IPA servers does make sense for sssd configuration? We have 5 IPA servers and each Host can reach them. Can I put them all to sssd configuration (redundancy) or does it dont make sense (timeouts to big etc)? MfG Christoph Kaminski -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 05/21/2015 03:59 PM, Janelle wrote:
On 5/21/15 6:46 AM, Ludwig Krispenz wrote:
On 05/21/2015 03:28 PM, Janelle wrote:
I think I found the problem.
There was a lone replica running in another DC. It was installed as
a replica some time ago with all the others. Think of this -- the
original config had 5 servers, one of them was this server. Then the
other 4 servers were RE-BUILT from scratch, so all the replication
agreements were changed AND - this is the important part - the 5th
server was never added back in. BUT - the 5th server was left
running and never told it that it was not a member anymore. It still
thought it had a replication agreement with original server 1, but
server 1 knew otherwise.
Now, although the first 4 servers were rebuilt, the same domain,
realm, AND passwords were used.
I am guessing that somehow, this 5th server keeps trying to
interject its info into the ring of 4 servers, kind of forcing its
way in. Somehow, because the original credentials still work (but
certs are all different) is leaving the first 4 servers with a
can't decode issue.
There should be some security checks so this can't happen. It should
also be easy to replicate.
Now I have to go re-initialize all the servers from a good server,
so everyone is happy again. The problem server has been shutdown
completely. (and yes, there were actually 3 of them in my scenario -
I just used 1 to simplify my example - but that explains the 3 CSNs
that just kept appearing)
What concerns me most about this - were the servers outside of the
good ring somehow able to inject data into replication which might
have been causing bad data??? This is bad if it is true.
it depends a bit on what you mean by rebuilt from scratch.
A replication session needs to meet three conditions to be able to
send data:
- the supplier side needs to be able to authenticate and the
authenticated users has to be in the list of binddns of the replica
- the data generation of supplier and consumer side need to be the
same (they all have to have the same common origin)
- the supplier needs to have the changes (CSNs) to be able to
position in its changelog to send updates
now if you have 5 servers, forget about one of them and do not change
the credentials in the others and do not reinitialize the database by
an ldif import to generate a new database generation, the fifth
server will still be able to connect and eventually send updates -
how should the other servers know that this one is no longer a good
one
~Janelle
The only problem left now - is no matter what, this last entry will
NOT go away and now I have 2 stuck cleanruvs that will not abort
either.
unable to decode {replica 24} 554d53d30018 554d54a400020018
CLEANALLRUV tasks
RID 24 None
No abort CLEANALLRUV tasks running
=
ldapmodify -D cn=directory manager -W -a
dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
cn: abort 24
replica-id: 24
replica-certify-all: no
adding new entry cn=abort 24, cn=abort cleanallruv, cn=tasks,
cn=config
ldap_add: No such object (32)
in your dse.ldif do you see something like:
nsds5ReplicaCleanRUV: 300::no
in the replica object ?
This is where the task lives as long as it couldn't reach all servers
for which a replication agreement exists.
If abort task doesn't work, you could try to stop the server, remove
these lines from the dse.ldif, start the server again.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Count of IPA Servers for SSSD
Christoph Kaminski wrote: Hi All what a count of IPA servers does make sense for sssd configuration? We have 5 IPA servers and each Host can reach them. Can I put them all to sssd configuration (redundancy) or does it dont make sense (timeouts to big etc)? The recommended procedure is to use DNS SRV records. SSSD will automatically fail over using them. This has the advantage that if you add/remove some IPA masters you don't have to go and change every single sssd.conf. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 05/21/2015 09:15 AM, Ludwig Krispenz wrote: On 05/21/2015 03:04 PM, Janelle wrote: On 5/21/15 5:49 AM, Rich Megginson wrote: On 05/21/2015 06:25 AM, Janelle wrote: On 5/21/15 5:20 AM, thierry bordaz wrote: Hello Janelle, Those 3 RIDs were already present in Node dc2-ipa1, correct ? They reappeared on others nodes as well ? May be ds2-ipa1 established a replication session with its peers and send those RIDs. Could you track in all the access logs, when the op csn=5552f71800030017 was applied. Note that the two hexa values of replica 23 changed (5545d61f00020017 5552f71800030017 vs 5553e3a30017 555432430017). Have you recreated a replica 23 ?. Do you have replication logging enabled ? thanks thierry Just to help me -- what is the best way to enable the logging level you need? http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting The Replication log level. I thought I did it correctly adding to ldif.dse, but I don't think it took. You cannot edit dse.ldif while the server is running. Anyway, ldapmodify is the best way to set this value. I am used to OpenLDAP, so perhaps there is a different way to do it with 389-ds. Can you suggest settings of logging you want me to use? The Replication log level. ~Janelle How do I kill one of the ldapmodify cleans I had started but seems to be stuck: abort should be done by ldapmodify similar to starting it: ldapmo |ldapmodify dn: cn=abort 222, cn=abort cleanallruv, cn=tasks, cn=config objectclass: extensibleObject cn: abort 222 replica-base-dn: dc=example,dc=com replica-id: 222 replica-certify-all: no -- if set to no the task does not wait for all the replica servers to have been sent the abort task, or be online, before completing. If set to yes, the task will run forever until all the configured replicas have been aborted. Note - the orginal default was yes, but this was changed to no on 4/21/15. It is best to set this attribute anyway, and not rely on what the default is.| if it doesn't work we have to ask Mark :-) The abort task should work, assuming replica-certify-all is to no. If there is still a problem you can always monitor the errors log (/var/log/dirsrv/slapd-INSTANCE/errors), and grep for CleanAllRUV to sort the output. Mark | | CLEANALLRUV tasks RID 24 None No abort CLEANALLRUV tasks running It has been 45 minutes and still nothing, so I want to kill it and try again. ~J -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Proper configuration of service accounts
Rob, Try adding the inetUser objectclass to your system account. You're probably lacking memberOf. Thanks, that worked. My last issue is to add read/search permission on the name attribute as the vendor doesn't offer a way to not include it in a search filter to find user groups. I was in Code 500 many moons ago, Center Network Environment (CNE). Small world :-) The NICS contract covers CNE at Goddard and at the Agency level. I'm setting up a new NMS system for the NASCOM mission network. George Boyce, SAIC/NICS GCC Systems Support NASA GSFC Code 762 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 05/21/2015 03:28 PM, Janelle wrote: I think I found the problem. There was a lone replica running in another DC. It was installed as a replica some time ago with all the others. Think of this -- the original config had 5 servers, one of them was this server. Then the other 4 servers were RE-BUILT from scratch, so all the replication agreements were changed AND - this is the important part - the 5th server was never added back in. BUT - the 5th server was left running and never told it that it was not a member anymore. It still thought it had a replication agreement with original server 1, but server 1 knew otherwise. Now, although the first 4 servers were rebuilt, the same domain, realm, AND passwords were used. I am guessing that somehow, this 5th server keeps trying to interject its info into the ring of 4 servers, kind of forcing its way in. Somehow, because the original credentials still work (but certs are all different) is leaving the first 4 servers with a can't decode issue. There should be some security checks so this can't happen. It should also be easy to replicate. Now I have to go re-initialize all the servers from a good server, so everyone is happy again. The problem server has been shutdown completely. (and yes, there were actually 3 of them in my scenario - I just used 1 to simplify my example - but that explains the 3 CSNs that just kept appearing) What concerns me most about this - were the servers outside of the good ring somehow able to inject data into replication which might have been causing bad data??? This is bad if it is true. it depends a bit on what you mean by rebuilt from scratch. A replication session needs to meet three conditions to be able to send data: - the supplier side needs to be able to authenticate and the authenticated users has to be in the list of binddns of the replica - the data generation of supplier and consumer side need to be the same (they all have to have the same common origin) - the supplier needs to have the changes (CSNs) to be able to position in its changelog to send updates now if you have 5 servers, forget about one of them and do not change the credentials in the others and do not reinitialize the database by an ldif import to generate a new database generation, the fifth server will still be able to connect and eventually send updates - how should the other servers know that this one is no longer a good one ~Janelle -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)
Sanju A wrote: Dear Rob, Please find the result of getcert list. Request ID '20140430124456': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.tcs-mobility.com,O=EXAMPLE.COM expires: 2016-04-30 12:44:55 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes You need to run getcert list on the IPA master running the CA that can't be contacted, not the host you're trying to delete. rob Regards Sanju Abraham From: Rob Crittenden rcrit...@redhat.com To: Sanju A sanj...@tcs.com, freeipa-users@redhat.com Date: 20-05-2015 19:04 Subject: Re: [Freeipa-users] Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) Sanju A wrote: Hi, I am getting the following error while removing a host. --- Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) --- This usually means that the CA is not serving requestss. It may be up and running but that doesn't mean the webapp is working. This is often due to expired CA subsystem certificates. Run getcert list to check. rob =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 5/21/15 6:46 AM, Ludwig Krispenz wrote: On 05/21/2015 03:28 PM, Janelle wrote: I think I found the problem. There was a lone replica running in another DC. It was installed as a replica some time ago with all the others. Think of this -- the original config had 5 servers, one of them was this server. Then the other 4 servers were RE-BUILT from scratch, so all the replication agreements were changed AND - this is the important part - the 5th server was never added back in. BUT - the 5th server was left running and never told it that it was not a member anymore. It still thought it had a replication agreement with original server 1, but server 1 knew otherwise. Now, although the first 4 servers were rebuilt, the same domain, realm, AND passwords were used. I am guessing that somehow, this 5th server keeps trying to interject its info into the ring of 4 servers, kind of forcing its way in. Somehow, because the original credentials still work (but certs are all different) is leaving the first 4 servers with a can't decode issue. There should be some security checks so this can't happen. It should also be easy to replicate. Now I have to go re-initialize all the servers from a good server, so everyone is happy again. The problem server has been shutdown completely. (and yes, there were actually 3 of them in my scenario - I just used 1 to simplify my example - but that explains the 3 CSNs that just kept appearing) What concerns me most about this - were the servers outside of the good ring somehow able to inject data into replication which might have been causing bad data??? This is bad if it is true. it depends a bit on what you mean by rebuilt from scratch. A replication session needs to meet three conditions to be able to send data: - the supplier side needs to be able to authenticate and the authenticated users has to be in the list of binddns of the replica - the data generation of supplier and consumer side need to be the same (they all have to have the same common origin) - the supplier needs to have the changes (CSNs) to be able to position in its changelog to send updates now if you have 5 servers, forget about one of them and do not change the credentials in the others and do not reinitialize the database by an ldif import to generate a new database generation, the fifth server will still be able to connect and eventually send updates - how should the other servers know that this one is no longer a good one ~Janelle To clarify rebuilt from scratch: ipa-server-install --uninstall --unattended yum remove 389-ds-* certmonger-* freeipa-* reboot yum install freeipa-server ipa-server-install The reason for the uninstalls is to clear out all leftover folders and certs. Also run are: rm -f /var/lib/sss/db/* rm -rf /etc/ipa rm -rf /var/log/dirsrv/ But those are before the re-install. So the 5th server was left running, and yes, the admin username and PW are the same, so that may be how it is happening, regardless of certificates being different. ~Janelle -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 5/21/15 6:46 AM, Ludwig Krispenz wrote:
On 05/21/2015 03:28 PM, Janelle wrote:
I think I found the problem.
There was a lone replica running in another DC. It was installed as a
replica some time ago with all the others. Think of this -- the
original config had 5 servers, one of them was this server. Then the
other 4 servers were RE-BUILT from scratch, so all the replication
agreements were changed AND - this is the important part - the 5th
server was never added back in. BUT - the 5th server was left running
and never told it that it was not a member anymore. It still thought
it had a replication agreement with original server 1, but server 1
knew otherwise.
Now, although the first 4 servers were rebuilt, the same domain,
realm, AND passwords were used.
I am guessing that somehow, this 5th server keeps trying to interject
its info into the ring of 4 servers, kind of forcing its way in.
Somehow, because the original credentials still work (but certs are
all different) is leaving the first 4 servers with a can't decode
issue.
There should be some security checks so this can't happen. It should
also be easy to replicate.
Now I have to go re-initialize all the servers from a good server, so
everyone is happy again. The problem server has been shutdown
completely. (and yes, there were actually 3 of them in my scenario -
I just used 1 to simplify my example - but that explains the 3 CSNs
that just kept appearing)
What concerns me most about this - were the servers outside of the
good ring somehow able to inject data into replication which might
have been causing bad data??? This is bad if it is true.
it depends a bit on what you mean by rebuilt from scratch.
A replication session needs to meet three conditions to be able to
send data:
- the supplier side needs to be able to authenticate and the
authenticated users has to be in the list of binddns of the replica
- the data generation of supplier and consumer side need to be the
same (they all have to have the same common origin)
- the supplier needs to have the changes (CSNs) to be able to position
in its changelog to send updates
now if you have 5 servers, forget about one of them and do not change
the credentials in the others and do not reinitialize the database by
an ldif import to generate a new database generation, the fifth server
will still be able to connect and eventually send updates - how should
the other servers know that this one is no longer a good one
~Janelle
The only problem left now - is no matter what, this last entry will NOT
go away and now I have 2 stuck cleanruvs that will not abort either.
unable to decode {replica 24} 554d53d30018 554d54a400020018
CLEANALLRUV tasks
RID 24 None
No abort CLEANALLRUV tasks running
=
ldapmodify -D cn=directory manager -W -a
dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
cn: abort 24
replica-id: 24
replica-certify-all: no
adding new entry cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config
ldap_add: No such object (32)
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
I think I found the problem. There was a lone replica running in another DC. It was installed as a replica some time ago with all the others. Think of this -- the original config had 5 servers, one of them was this server. Then the other 4 servers were RE-BUILT from scratch, so all the replication agreements were changed AND - this is the important part - the 5th server was never added back in. BUT - the 5th server was left running and never told it that it was not a member anymore. It still thought it had a replication agreement with original server 1, but server 1 knew otherwise. Now, although the first 4 servers were rebuilt, the same domain, realm, AND passwords were used. I am guessing that somehow, this 5th server keeps trying to interject its info into the ring of 4 servers, kind of forcing its way in. Somehow, because the original credentials still work (but certs are all different) is leaving the first 4 servers with a can't decode issue. There should be some security checks so this can't happen. It should also be easy to replicate. Now I have to go re-initialize all the servers from a good server, so everyone is happy again. The problem server has been shutdown completely. (and yes, there were actually 3 of them in my scenario - I just used 1 to simplify my example - but that explains the 3 CSNs that just kept appearing) What concerns me most about this - were the servers outside of the good ring somehow able to inject data into replication which might have been causing bad data??? This is bad if it is true. ~Janelle -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] User Can't Authenticate
I've got a freeIPA client where a user account cannot authenticate. The log entry for IPA looks like: audit/audit.log.4:type=USER_AUTH msg=audit(1425316592.375:38090): user pid=16485 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct=aswanda exe=/usr/sbin/sshd hostname=172.31.0.162 addr=172.31.0.162 terminal=ssh res=failed' When I try to sudo to the user account, I get the following error: [root@myhost ~]# sudo su - testusersu: user testuser does not exist However, all that works for my account. Please help. Thanks in advance. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] User Can't Authenticate
On 05/21/2015 05:54 PM, John Williams wrote: I've got a freeIPA client where a user account cannot authenticate. The log entry for IPA looks like: audit/audit.log.4:type=USER_AUTH msg=audit(1425316592.375:38090): user pid=16485 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct=aswanda exe=/usr/sbin/sshd hostname=172.31.0.162 addr=172.31.0.162 terminal=ssh res=failed' When I try to sudo to the user account, I get the following error: [root@myhost ~]# sudo su - testuser su: user testuser does not exist However, all that works for my account. Please help. Thanks in advance. What do you use on the client? SSSD? What is the OS version? What SSSD logs show? -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] disable unwanted kerberos encryption types
We have requirements to only allow AES encryption. I'm trying to understand what is the default and where everything comes in to play, the user tickets are AES when obtained using kinit, but the system keytab shows des3 and arcfour in addition to AES. So my questions are What is enabled/supported by default? How can des3 and arcfour encryption types be disabled for Kerberos? ? I've seen references to krbDefaultEncSaltTypes but cannot seem to find that in the directory anywhere. Are there any implications to doing this? Running RHEL 6.6 clients against 7.1 servers supporting local and trusted AD users. Thanks -andy *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 5/21/15 8:12 AM, Ludwig Krispenz wrote:
On 05/21/2015 03:59 PM, Janelle wrote:
On 5/21/15 6:46 AM, Ludwig Krispenz wrote:
On 05/21/2015 03:28 PM, Janelle wrote:
I think I found the problem.
There was a lone replica running in another DC. It was installed as
a replica some time ago with all the others. Think of this -- the
original config had 5 servers, one of them was this server. Then
the other 4 servers were RE-BUILT from scratch, so all the
replication agreements were changed AND - this is the important
part - the 5th server was never added back in. BUT - the 5th server
was left running and never told it that it was not a member
anymore. It still thought it had a replication agreement with
original server 1, but server 1 knew otherwise.
Now, although the first 4 servers were rebuilt, the same domain,
realm, AND passwords were used.
I am guessing that somehow, this 5th server keeps trying to
interject its info into the ring of 4 servers, kind of forcing its
way in. Somehow, because the original credentials still work (but
certs are all different) is leaving the first 4 servers with a
can't decode issue.
There should be some security checks so this can't happen. It
should also be easy to replicate.
Now I have to go re-initialize all the servers from a good server,
so everyone is happy again. The problem server has been shutdown
completely. (and yes, there were actually 3 of them in my scenario
- I just used 1 to simplify my example - but that explains the 3
CSNs that just kept appearing)
What concerns me most about this - were the servers outside of the
good ring somehow able to inject data into replication which
might have been causing bad data??? This is bad if it is true.
it depends a bit on what you mean by rebuilt from scratch.
A replication session needs to meet three conditions to be able to
send data:
- the supplier side needs to be able to authenticate and the
authenticated users has to be in the list of binddns of the replica
- the data generation of supplier and consumer side need to be the
same (they all have to have the same common origin)
- the supplier needs to have the changes (CSNs) to be able to
position in its changelog to send updates
now if you have 5 servers, forget about one of them and do not
change the credentials in the others and do not reinitialize the
database by an ldif import to generate a new database generation,
the fifth server will still be able to connect and eventually send
updates - how should the other servers know that this one is no
longer a good one
~Janelle
The only problem left now - is no matter what, this last entry will
NOT go away and now I have 2 stuck cleanruvs that will not abort
either.
unable to decode {replica 24} 554d53d30018 554d54a400020018
CLEANALLRUV tasks
RID 24 None
No abort CLEANALLRUV tasks running
=
ldapmodify -D cn=directory manager -W -a
dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
cn: abort 24
replica-id: 24
replica-certify-all: no
adding new entry cn=abort 24, cn=abort cleanallruv, cn=tasks,
cn=config
ldap_add: No such object (32)
in your dse.ldif do you see something like:
nsds5ReplicaCleanRUV: 300::no
in the replica object ?
This is where the task lives as long as it couldn't reach all servers
for which a replication agreement exists.
If abort task doesn't work, you could try to stop the server, remove
these lines from the dse.ldif, start the server again
Sadly, nothing even close to that anywhere. And now, after trying to
remove another replica which had been showing as a duplicate, although
authentication is continuing to work, I am afraid to try and do anything
else to replication, for fear of bringing all of production down.
I did not notice this at first - but yesterday when I shared my RUVs --
there was something I missed:
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa2.example.com 389 9
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
ipa2 appears twice with RUV 9 and 25 - with no explanation.
Frustrated.
~Janelle
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replication again :-(
On 05/21/2015 09:59 AM, Janelle wrote:
On 5/21/15 6:46 AM, Ludwig Krispenz wrote:
On 05/21/2015 03:28 PM, Janelle wrote:
I think I found the problem.
There was a lone replica running in another DC. It was installed as
a replica some time ago with all the others. Think of this -- the
original config had 5 servers, one of them was this server. Then the
other 4 servers were RE-BUILT from scratch, so all the replication
agreements were changed AND - this is the important part - the 5th
server was never added back in. BUT - the 5th server was left
running and never told it that it was not a member anymore. It still
thought it had a replication agreement with original server 1, but
server 1 knew otherwise.
Now, although the first 4 servers were rebuilt, the same domain,
realm, AND passwords were used.
I am guessing that somehow, this 5th server keeps trying to
interject its info into the ring of 4 servers, kind of forcing its
way in. Somehow, because the original credentials still work (but
certs are all different) is leaving the first 4 servers with a
can't decode issue.
There should be some security checks so this can't happen. It should
also be easy to replicate.
Now I have to go re-initialize all the servers from a good server,
so everyone is happy again. The problem server has been shutdown
completely. (and yes, there were actually 3 of them in my scenario -
I just used 1 to simplify my example - but that explains the 3 CSNs
that just kept appearing)
What concerns me most about this - were the servers outside of the
good ring somehow able to inject data into replication which might
have been causing bad data??? This is bad if it is true.
it depends a bit on what you mean by rebuilt from scratch.
A replication session needs to meet three conditions to be able to
send data:
- the supplier side needs to be able to authenticate and the
authenticated users has to be in the list of binddns of the replica
- the data generation of supplier and consumer side need to be the
same (they all have to have the same common origin)
- the supplier needs to have the changes (CSNs) to be able to
position in its changelog to send updates
now if you have 5 servers, forget about one of them and do not change
the credentials in the others and do not reinitialize the database by
an ldif import to generate a new database generation, the fifth
server will still be able to connect and eventually send updates -
how should the other servers know that this one is no longer a good
one
~Janelle
The only problem left now - is no matter what, this last entry will
NOT go away and now I have 2 stuck cleanruvs that will not abort
either.
unable to decode {replica 24} 554d53d30018 554d54a400020018
CLEANALLRUV tasks
RID 24 None
No abort CLEANALLRUV tasks running
=
ldapmodify -D cn=directory manager -W -a
dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
cn: abort 24
replica-id: 24
replica-certify-all: no
adding new entry * cn=abort 24, cn=abort cleanallruv, cn=tasks,
cn=config *
ldap_add: No such object (32)
There should not be a white space at the beginning: * cn=abort 24,
cn=abort cleanallruv, cn=tasks, cn=config **
*
When I run the abort task I don't have that extra white space, and the
task is successfully added:
[root@localhost ~]# ldapmodify -D cn=dm -w password -a
dn: cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=example,dc=com
cn: abort 24
replica-id: 24
replica-certify-all: no
adding new entry *cn=abort 24, cn=abort cleanallruv, cn=tasks, cn=config*
The extra white space is the probable cause of the error 32 (no such
object) you were seeing. You can verify this by looking at the access
log (/var/log/dirsrv/slapd-INSTANCE/access)
Like I said before you could also check the errors log for the reason
why the cleanAllRUV task is not completing as well.
Regards,
Mark
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
