[Freeipa-users] FreeIPA 3.3.3 backup and restore
Hi All, I was reading this page but seems very confusing: https://www.freeipa.org/page/V3/Backup_and_Restore#Data_Backup_.26_Restore_Process_.28online.29 ipa-backup and ipa-restore command doesn't exists. I know full system backup works, but is there have a way to do core Kerberos DB backup? or the most important DB would be LDAP only? Other than full system backup, is there have any other way to do backup and restore for FreeIPA? -- 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] How to restore data to a fresh IPA reinstall from a CA-less replica
On 05/25/2015 05:46 PM, Sina Owolabi wrote: Hi! Please how do I restore data to a freshly reinstalled IPA server from an existing CA-less replica that has had replication agreements removed? By restore, you mean actually migrate? We have a pending RFE for this: https://fedorahosted.org/freeipa/ticket/3656 Migration of users/groups can be done via migrate-ds command. Migration of SUDO/HBAC/automount/... can be done by LDIF export and import (with some changes realms, etc.). But we have no automated way how to migrate Kerberos keys or certificates as the underlying keys are different. Both servers are running rhel 6.6 with ipa-server versions 3.0.0 ( For some reason the IPA servers do not upgrade beyond this version). If you want a higher version than FreeIPA 3.0.0, please use RHEL-7.x. RHEL-7.1 has FreeIPA 4.1, which is much more cooler than 3.0.0 :-) This is what we recommend for new deployments anyway. I have been searching for information from RHEL knowledgebase and from the FreeIPA site but I do not find information that exactly matches my situation. I am grateful for any assistance in this. Thanks! HTH, Martin -- 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] Restore deleted RBAC Rules?
On 05/25/2015 04:27 PM, Striker Leggette wrote: Is it possible to restore deleted RBAC rules that were deleted from Permissions and Privileges? Hello Striker, Only if you did a data backup. I do not know about other way... More information and ideas about Backup and Restore in FreeIPA: http://www.freeipa.org/page/Backup_and_Restore Martin -- 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] Any thoughts on sssd_sudo memory usage ?
Thanks, I'll try some workarounds and wait for new package in centos repositories On Tue, May 26, 2015 at 7:53 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (26/05/15 06:44), Vaclav Adamec wrote: With higher debug level I see that sssd sudo trying to resolve local account (for nagios monitoring) There was/is a bug which does not respect filter_user in sudo provider https://fedorahosted.org/sssd/ticket/2625. (It's already fixed in fedora = 22) It would be a workaround for you. On Tue, May 26, 2015 at 6:39 AM, Vaclav Adamec vaclav.ada...@suchy-zleb.cz wrote: ps -eo pid,cmd,size,rss | grep sssd_sudo 1533 /usr/libexec/sssd/sssd_sudo 4245972 4247700 and huge amount of this (trying again and again): (Tue May 26 06:35:47 2015) [sssd[sudo]] [sudosrv_check_user_dp_callback] (0x0040): Could not look up the user [2]: No such file or directory (Tue May 26 06:35:47 2015) [sssd[sudo]] [sudosrv_get_user] (0x0080): No results for getpwnam call but other servers in same datacenter looks ok in the same time, but later this error was visible also on others, it's just question of time. I assume you have sssd-1.11 because such bug was fixed in sssd-1.12 https://git.fedorahosted.org/cgit/sssd.git/commit/?id=09579ae252c181c7884defc0612c36108f6cf509 You can test with my pre-release of sssd-1.12.5 https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/ (It already contains fix for #2625) LS -- -- May the fox be with you ... /\ (~( ) ) /\_/\ (_=---_(@ @) ( \ / /|/\|\ V -- 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] Single mail deployment i an FreeIPA-WindowsAD scenario.
On 05/26/2015 12:21 AM, Carlos Raúl Laguna wrote: Any ideas how to overcome this? Winsync may be a better approach for us instead of cross-trust.Regards 2015-05-25 13:06 GMT-04:00 Carlos Raúl Laguna carlosla1...@gmail.com mailto:carlosla1...@gmail.com: How i can use a single backend for a email deployment in such scenario ? Since i am using forest trust, therefore users are not present in one place. Regards Hello Carlos, I think you will need to deploy the use case better, what do you mean by email deployment. If you want LDAP BIND-like authentication for a mail server, it should work with trusts also, if you direct the LDAP base to cn=compat. Some related reading: https://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf https://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts HOWTOs on mails: http://www.freeipa.org/page/HowTos#Mail_Services HTH, Martin -- 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] Haunted servers?
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so busy, they
have already rotated out.
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 22} 55371e9e0016 553eec6400040016
unable to decode {replica 23} 5545d61f00020017 555432430017
unable to decode {replica 24} 554d53d30018 554d54a400020018
unable to decode {replica 25} 554d78bf0019 555af30200040019
unable to decode {replica 9} 55402c3900030009 55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still trying to find the leaking
server(s). here is what I mean by that. As you see, I continue to find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other data - it is
blank?
Hello Janelle,
Thanks for update. So you worry that there might still be the rogue IPA
replica that would be injecting the wrong replica data?
In any case, I bet Ludwig and Thierry will follow up with your thread, there is
just delay caused by the various public holidays and PTOs this week and we need
to rest before digging into the fun with RUVs - as you already know yourself :-)
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 22} 55371e9e0016 553eec6400040016
unable to decode {replica 24} 554d53d300010018 554d54a400020018
unable to decode {replica 25} 554d78bf00020019 555af30200040019
unable to decode {replica 9}
Now, if I delete these from a server using the ldapmodify method - they go away
briefly, but then if I restart the server, they come back.
Let me try to explain -- given a number of servers, say 8, if I user ldapmodify
to delete from 1 of those, they seem to go away from maybe 4 of them -- but if
I wait a few minutes, it is almost as though replication is re-adding these
bad replicas from the servers that I have NOT deleted them from.
So my question is simple - is there something in the logs I can look for that
would indicate the SOURCE of these bogus entries? Is the replica 9 with NO
extra data any indication of something I could look for?
I am not willing to give up easily (as you might have already guessed) and I am
determined to find the cause of these. I know we need more logs, but with all
the traffic, the logs rollover within a few hours, and if the problem is
happening at 3am for example, I am not able to track it down because the logs
have rolled.
Back to my investigations.
~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] How to restore data to a fresh IPA reinstall from a CA-less replica
Hi Martin I actually mean restore. It's a complicated situation... There once was a primary and it's CA replica. The primary got hosed and was cloned a few years ago from the replica. Then the replica got hosed a few times too, saved by the primary, only now it wouldn't install a CA during replica setup. Now the cloned primary got hosed (it sees itself as a clone and being a the only CA, has nowhere to go to renew certs). We opted to reinstall a fresh primary and now we are looking for how to copy existing data from the standing CA-less replica (everything is the same, realms, DNS hosts, HBAC, sudo rules, etc ) to the freshly installed CA primary. This would be amazing if we could or we'll have to setup the entire network and rules from scratch. I would really appreciate some example commands we could run to import data into the new primary. We've already run db2bak and db2ldif on the replica to export from a helpful script we found in a thread. I hope you can help us! On Tue, May 26, 2015, 7:42 AM Martin Kosek mko...@redhat.com wrote: On 05/25/2015 05:46 PM, Sina Owolabi wrote: Hi! Please how do I restore data to a freshly reinstalled IPA server from an existing CA-less replica that has had replication agreements removed? By restore, you mean actually migrate? We have a pending RFE for this: https://fedorahosted.org/freeipa/ticket/3656 Migration of users/groups can be done via migrate-ds command. Migration of SUDO/HBAC/automount/... can be done by LDIF export and import (with some changes realms, etc.). But we have no automated way how to migrate Kerberos keys or certificates as the underlying keys are different. Both servers are running rhel 6.6 with ipa-server versions 3.0.0 ( For some reason the IPA servers do not upgrade beyond this version). If you want a higher version than FreeIPA 3.0.0, please use RHEL-7.x. RHEL-7.1 has FreeIPA 4.1, which is much more cooler than 3.0.0 :-) This is what we recommend for new deployments anyway. I have been searching for information from RHEL knowledgebase and from the FreeIPA site but I do not find information that exactly matches my situation. I am grateful for any assistance in this. Thanks! HTH, Martin -- 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] ERROR: Operations error: Allocation of a new value for range cn=posix ids, cn=distributed numeric assignment plugin, cn=plugins, cn=config failed! Unable to proceed.
On 05/26/2015 01:12 PM, Viktor Voltaire wrote: I run a setup of two freeipa servers 4.1 on centos 7. I have recently migrated from my my old master to a new one, decommissioning the two old servers and setting up another new replica. When i try to add a new user i get the following error: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. Any thoughts? Regards, Hello Viktor, please read RANGES section of `man ipa-replica-manage` Guessing what could have happened: - new servers were created but none got DNA range because no new user nor group was created there - when servers were decommissioned, their ranges were not returned back to different master (this might be bug). Could be fixed by creating new DNA ranges on the new masters using ipa-replica-manage tool. -- Petr Vobornik -- 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] ERROR: Operations error: Allocation of a new value for range cn=posix ids, cn=distributed numeric assignment plugin, cn=plugins, cn=config failed! Unable to proceed.
I run a setup of two freeipa servers 4.1 on centos 7. I have recently migrated from my my old master to a new one, decommissioning the two old servers and setting up another new replica. When i try to add a new user i get the following error: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. Any thoughts? Regards, -- Viktor Voltaire Mobile: +46 725 057 447 tel:%2B46%20725%20057%20447 Mail: viktor.volta...@aphelion.se mailto:viktor.volta...@aphelion.se Aphelion AB | Kungsgatan 2, SE-111 43 Stockholm, Sweden | Phone: +46 8 588 977 00 tel:%2B46%208%20588%20977%2000 Aphelion eFX Trading Inc | 31 Penn Plaza, New York, NY 10001, USA | Phone: +1 646 821 4585 tel:%2B1%20646%20821%204585 * Email confidentiality notice * This email and any files transmitted with it may contain confidential information and is intended only for the person or entity which it is addressed to. If you have received this email in error, please notify the sender immediately by e-mail and delete the e-mail without taking notice of its content. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of the Aphelion Group. Therefore this e-mail does not represent a binding agreement nor an offer to deal. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Neither the Aphelion Group nor the sender can accept any liability for any kind of damage as the result of viruses, transmission errors or omissions in the contents of this message. If verification should be required please request a hard-copy version. Aphelion AB, Kungsgatan 2, 111 43 Stockholm, Sweden, www.aphelion.se http://www.aphelion.se -- 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] ERROR: Operations error: Allocation of a new value for range cn=posix ids, cn=distributed numeric assignment plugin, cn=plugins, cn=config failed! Unable to proceed.
Hi Petr, I created new DNA ranges on my primary master, this resolved the issue. I think the issue was not adding any new user on the new master before decommissioning the old ones. Regards, Viktor Petr Vobornik skrev den 2015-05-26 13:22: On 05/26/2015 01:12 PM, Viktor Voltaire wrote: I run a setup of two freeipa servers 4.1 on centos 7. I have recently migrated from my my old master to a new one, decommissioning the two old servers and setting up another new replica. When i try to add a new user i get the following error: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. Any thoughts? Regards, Hello Viktor, please read RANGES section of `man ipa-replica-manage` Guessing what could have happened: - new servers were created but none got DNA range because no new user nor group was created there - when servers were decommissioned, their ranges were not returned back to different master (this might be bug). Could be fixed by creating new DNA ranges on the new masters using ipa-replica-manage tool. -- 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] SSH GSSAPI + FreeIPA with Windows 2008 Trust
Hi Alexander, thank you for your fast reply. I've already executed: # ipa host-mod --ok-as-delegate=TRUE but still cant log in using GSSAPI to ipa clients. Please find answers below: 1. Yes, logging to Linux IPA Client (Centos 6.6) without entering password is not working from AD-joined Windows station with PuTTY. Logging to IPA Master server without entering password (using gssapi) works ok. 2. - 3. Logging in to ipa clients from AD-joined Windows station with Putty (0.64) always requires password and then Kerberos ticket is available in the shell. After I changed loglevel in /etc/sshd/sshd_config on ipa client to LogLevel Debug i found in /var/log/secure: debug1: userauth-request for user leszek service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for leszek ... debug1: Postponed gssapi-with-mic for leszek from X.X.X.X debug1: Got no client credentials Failed gssapi-with-mic for user leszek After entering password and logging to system I found this in /var/log/secure: ... debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism /var/log/sssd/sssd_domain.log ... [ipa_subdom_get_forest] (0x0400: 4th component is not 'trust', nothing to do. ... Any ideas? /lm 2015-05-25 13:25 GMT+02:00 Alexander Bokovoy aboko...@redhat.com: On Mon, 25 May 2015, crony wrote: Hi All, we have setup FreeIPA 4.1 (Centos 7) Trust with Windows 2008R2. All (HBAC, SUDO) works pretty well except SSH SSO using GSSAPI from Windows AD clients (ex. putty) to Linux client machines (Centos 6). Password authentication works, just gssapi fails. Do you have have anything in the SSH server logs when using high enough debug level? SSH GSSAPI (single sign-on) should just work fine. On contrary, delegation or forwarding of credentials (i.e. Kerberos TGT from AD side being available after login to SSH server) should not work unless ok-as-delegate flag is set on the host principal -- see 'ipa host-mod --ok-as-delegate=TRUE'. So what exactly is not working: 1. Logging in without entering a password from AD-joined Windows station with PuTTY? 2. Logging in without the password works but no Kerberos ticket available in the shell? 3. Logging in always requires password and then Kerberos ticket is not available in the shell? 4. Something else? Actually, there is one scenario where SSH GSSAPI authentication works - when connecting to FreeIPA master or replica (trust were established here), but not to FreeIPA host clients. Important sections of configuration files (servers/clients): /etc/ssh/sshd_config: GSSAPIAuthentication yes KerberosAuthentication yes Remove 'KerberosAuthentication yes', you don't want it to be used, only GSSAPI. /etc/krb5.conf: auth_to_local = RULE:[1:$1 at $0](^.* at WINDOWS.DOMAIN$)s/ at WINDOWS.DOMAIN/ at windows.domain/ auth_to_local = DEFAULT You don't need to specify auth_to_local rules in krb5.conf in RHEL 7.1 because we now have this filled in by SSSD. As you are claiming FreeIPA 4.1 is in use, it means CentOS 7.1, thus SSSD automatically contributing auth_to_local plugin. BTW. after I log in by password to linux client machine I can use gssapi within the same host by ssh-ing in a loop to the localhost, so locally GSSAPI works here. This is expected and is by design. Is there something I missed? Any help would be greatly appreciated. Answer my questions above, I suspect all you need is to mark the host principal as available for delegation. -- / Alexander Bokovoy -- Pozdrawiam Leszek Miś www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -- 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] FreeIPA On SuSE (SLES 11, 12, and up)
Traiano Welcome wrote: Hi All Has anyone successfully configured IPA v4.xx on SLES (specifically 11.x)? As a client or a server? I'm pretty sure that sssd is built for SLES 12, I don't see it on 11 and that would be the major hurdle for a client. You can probably connect it using nss_ldap in any case. 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] Haunted servers?
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so busy,
they
have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009 55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still trying to find the
leaking
server(s). here is what I mean by that. As you see, I continue to
find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other
data - it is
blank?
Hello Janelle,
Thanks for update. So you worry that there might still be the rogue
IPA replica that would be injecting the wrong replica data?
In any case, I bet Ludwig and Thierry will follow up with your thread,
there is just delay caused by the various public holidays and PTOs
this week and we need to rest before digging into the fun with RUVs -
as you already know yourself :-)
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 22} 55371e9e0016 553eec6400040016
unable to decode {replica 24} 554d53d300010018 554d54a400020018
unable to decode {replica 25} 554d78bf00020019 555af30200040019
unable to decode {replica 9}
Now, if I delete these from a server using the ldapmodify method -
they go away
briefly, but then if I restart the server, they come back.
Let me try to explain -- given a number of servers, say 8, if I user
ldapmodify
to delete from 1 of those, they seem to go away from maybe 4 of them
-- but if
I wait a few minutes, it is almost as though replication is
re-adding these
bad replicas from the servers that I have NOT deleted them from.
On each replica (master/replica) there are one RUV in the database and
one RUV in the changelog.
When cleanallruv succeeds it clears both of them. All replica should be
reachable when you issue cleanallruv, so that
it can clean the RUVs on all the replicas in almost single operation.
If some replica are not reachable, they keep
information of about the cleaned RID and then can later propagate those
old RID to the rest of the replica.
Ludwig managed to reproduce the issue with a quite complex test case (3
replicas and multiple cleanallruv).
We have not yet identified the reason how a cleaned replicaId can get
resurrected.
In parallel we just reproduced it without a clear test case but in a 2
replica topology.
So my question is simple - is there something in the logs I can look
for that
would indicate the SOURCE of these bogus entries? Is the replica 9
with NO
extra data any indication of something I could look for?
I guess that if I have the answer to your question we would have
understood the bug ..
I am not willing to give up easily (as you might have already
guessed) and I am
determined to find the cause of these. I know we need more logs, but
with all
the traffic, the logs rollover within a few hours, and if the problem is
happening at 3am for example, I am not able to track it down because
the logs
have rolled.
Back to my investigations.
~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
[Freeipa-users] Installation on CentOS 6.6 with DNS
Hi, I've been trying to setup IPA on CentOS 6.6 with the --setup-dns option on, using the CentOS provided packages: rpm My problem is that everything is installed except when I use this flag. So, when I run: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U The installation finishes successfully. If I add DNS switches to the installation, it fails almost at the end: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U --setup-dns --no-forwarders Output (clipped): --- ... Configuring the web interface (httpd): Estimated time 1 minute [1/13]: setting mod_nss port to 443 [2/13]: setting mod_nss password file [3/13]: enabling mod_nss renegotiate [4/13]: adding URL rewriting rules [5/13]: configuring httpd [6/13]: setting up ssl [7/13]: setting up browser autoconfig [8/13]: publish CA cert [9/13]: creating a keytab for httpd [10/13]: clean up any existing httpd ccache [11/13]: configuring SELinux for httpd [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Restarting the directory server Restarting the KDC Can't contact LDAP server [root@ipa ~]# --- The screen output is at http://pastebin.com/HKiUwKq4The end of the error log is at http://pastebin.com/jDUhBCL7 (it's a 29 MB file so I only pasted the end of it). If anyone has come across anything like this, I would appreciate your help. Thanks. Ricardo. -- 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] FreeIPA On SuSE (SLES 11, 12, and up)
Hi All Has anyone successfully configured IPA v4.xx on SLES (specifically 11.x)? Thanks in advance, Traiano -- 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] OSX login very slow
John Obaterspok wrote: Hello, I'm using OSX 10.10.3 (Yosemite) and I've followed the Freeipa/OSX guide at linsec.ca http://linsec.ca. I can do the following with very fast response time: - id ipauser on osx host - klist/kdestroy/kinit a ticket - ssh via SSO to ipaserver with this ticket - ping osxhost osxhost.local from ipaserver - lookup users in OSX directory app - IPA server has green light in OSX network account server The thing that fails for me is login from OSX login window. Well, it doesn't fail but it took 12 minutes for an IPA user to login. Any ideas what to look for? My guess is DNS issues. Wireshark may help you sort out what is going on. 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] Haunted servers?
On 5/26/15 7:04 AM, thierry bordaz wrote:
On 05/26/2015 08:47 AM, Martin Kosek wrote:
On 05/26/2015 12:20 AM, Janelle wrote:
On 5/24/15 3:12 AM, Janelle wrote:
And just like that, my haunted servers have all returned.
I am going to just put a gun to my head and be done with it. :-(
Why do things run perfectly and then suddenly ???
Logs show little to nothing, mostly because the servers are so
busy, they
have already rotated out.
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 23} 5545d61f00020017
555432430017
unable to decode {replica 24} 554d53d30018
554d54a400020018
unable to decode {replica 25} 554d78bf0019
555af30200040019
unable to decode {replica 9} 55402c3900030009
55402c3900030009
Don't know what to do anymore. At my wit's end..
~J
So things are getting more interesting. Still trying to find the
leaking
server(s). here is what I mean by that. As you see, I continue to
find these
-- BUT, notice a new symptom -- replica 9 does NOT show any other
data - it is
blank?
Hello Janelle,
Thanks for update. So you worry that there might still be the rogue
IPA replica that would be injecting the wrong replica data?
In any case, I bet Ludwig and Thierry will follow up with your
thread, there is just delay caused by the various public holidays and
PTOs this week and we need to rest before digging into the fun with
RUVs - as you already know yourself :-)
unable to decode {replica 16} 5535647200030010
5535647200030010
unable to decode {replica 22} 55371e9e0016
553eec6400040016
unable to decode {replica 24} 554d53d300010018
554d54a400020018
unable to decode {replica 25} 554d78bf00020019
555af30200040019
unable to decode {replica 9}
Now, if I delete these from a server using the ldapmodify method -
they go away
briefly, but then if I restart the server, they come back.
Let me try to explain -- given a number of servers, say 8, if I user
ldapmodify
to delete from 1 of those, they seem to go away from maybe 4 of them
-- but if
I wait a few minutes, it is almost as though replication is
re-adding these
bad replicas from the servers that I have NOT deleted them from.
On each replica (master/replica) there are one RUV in the database and
one RUV in the changelog.
When cleanallruv succeeds it clears both of them. All replica should
be reachable when you issue cleanallruv, so that
it can clean the RUVs on all the replicas in almost single
operation. If some replica are not reachable, they keep
information of about the cleaned RID and then can later propagate
those old RID to the rest of the replica.
Ludwig managed to reproduce the issue with a quite complex test case
(3 replicas and multiple cleanallruv).
We have not yet identified the reason how a cleaned replicaId can get
resurrected.
In parallel we just reproduced it without a clear test case but in a 2
replica topology.
So my question is simple - is there something in the logs I can look
for that
would indicate the SOURCE of these bogus entries? Is the replica 9
with NO
extra data any indication of something I could look for?
I guess that if I have the answer to your question we would have
understood the bug ..
A little more information to go on:
I changed my password on a master (actually, the original master) and
was able to login to each replica within a few seconds with the new
password. This tells me replication is working across all the servers.
I also created a new account and it showed up on all the servers, again
within 15-20 seconds. This tells me replication is working just fine.
I don't understand why the cleanallruv does not process across all the
servers the same way. Baffling indeed.
Perhaps the most important question -- does these bogus entries actually
cause a problem? I mean they don't seem to be. What if I just ignored them?
~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] Restore deleted RBAC Rules?
Martin Kosek wrote: On 05/25/2015 04:27 PM, Striker Leggette wrote: Is it possible to restore deleted RBAC rules that were deleted from Permissions and Privileges? Hello Striker, Only if you did a data backup. I do not know about other way... More information and ideas about Backup and Restore in FreeIPA: http://www.freeipa.org/page/Backup_and_Restore Martin It depends on what was deleted. If he deleted common rules shipped by IPA then re-running ipa-ldap-updater should re-add them. The --test option will show you what it would do without updating the entries, assuming you have a version that has --test. Regardless, the next package update will re-run the updater and add them back anyway. 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] Installation on CentOS 6.6 with DNS
Have you add your ipa.domain.com ip address on /etc/hosts file? The error seems like your installation can't resolve the ip address. On Wednesday, May 27, 2015, Ricardo Oliveira n3...@hotmail.com wrote: Hi, I've been trying to setup IPA on CentOS 6.6 with the --setup-dns option on, using the CentOS provided packages: rpm My problem is that everything is installed except when I use this flag. So, when I run: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U The installation finishes successfully. If I add DNS switches to the installation, it fails almost at the end: ipa-server-install -a sillyPassword123 --hostname=ipa.mydomain.com -r MYDOMAIN.COM -p sillyPassword123 -n mydomain.com -U --setup-dns --no-forwarders Output (clipped): --- ... Configuring the web interface (httpd): Estimated time 1 minute [1/13]: setting mod_nss port to 443 [2/13]: setting mod_nss password file [3/13]: enabling mod_nss renegotiate [4/13]: adding URL rewriting rules [5/13]: configuring httpd [6/13]: setting up ssl [7/13]: setting up browser autoconfig [8/13]: publish CA cert [9/13]: creating a keytab for httpd [10/13]: clean up any existing httpd ccache [11/13]: configuring SELinux for httpd [12/13]: restarting httpd [13/13]: configuring httpd to start on boot Done configuring the web interface (httpd). Applying LDAP updates Restarting the directory server Restarting the KDC Can't contact LDAP server [root@ipa ~]# --- The screen output is at http://pastebin.com/HKiUwKq4 The end of the error log is at http://pastebin.com/jDUhBCL7 (it's a 29 MB file so I only pasted the end of it). If anyone has come across anything like this, I would appreciate your help. Thanks. Ricardo. -- Sent from iDewangga Device -- 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] Single mail deployment i an FreeIPA-WindowsAD scenario.
Hello Martin, The email deployment it is a groupware in this scenario Kolab, kolab use 389 ad as main backend and it require some kolab ldap specific attribute to work properly, this is not a problem in fact is quite easy to use freeipa as kolab backend, so far so good but the romance only get this far. Since we also use Windows Ad with forest-trust not all user are present in the FreeIPA directory and there it is where my problem lays. Since not all user are in the same box it become difficult to implement one mail system for all users. Regards -- 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
