Re: [Freeipa-users] IPA Startup issues
On 05/16/2011 04:56 PM, Rich Megginson wrote: On 05/16/2011 08:43 AM, Sigbjorn Lie wrote: On 05/16/2011 03:52 PM, Simo Sorce wrote: On Sat, 2011-05-14 at 16:46 +0200, Sigbjorn Lie wrote: I've noticed that if the machine running IPA is very busy at startup, the IPA services will not be online when the machine is started. I noticed this is as my test virtualization host has had it's power cord knocked out a few times. When I restart the host machine, all the virtual machines is started at the same time, causing (a lot) higher than normal latency for each virtual machine. This causes the IPA daemons to start, while during the startup one or several IPA daemons fails due to dependencies of other daemons which is not started yet, and all the IPA daemons is stopped as not all the IPA daemons started successfully. I've noticed that the default behavior of the ipactl command is to shut down all the IPA daemons, if any of the IPA daemons should fail during startup. This can be seen in the logs of the individual services, as some is started successfully, just to receive a shutdown signal shortly after. It seem to be the pki-ca which shut down my IPA services this morning. When rebooting the virtual machine running the IPA daemons during normal load of the host machine, all the IPA daemons start successfully. Logging on to the IPA server and manually starting the IPA daemons after the load of the host machine has decreased also works. I suggest changing the startup scripts to allow (a lot) longer startup times for the IPA daemons prior to failing them. At the moment we just run servicename start and wait until it is done. If the pki-cad service timeouts and returns an error I think we need to open a bug against the dogtag component as that is the cause. Can you open a bug in the freeipa trac with logs showing that service is responsible for the failure ? I haven't been able to figure out which service that failed IPA yet. A lot of log files scattered around. As you can see from the slapd errors file, the slapd daemon was available for almost 3 minutes before receiving the shutdown signal. I notice now that the PKI daemon failed 8 seconds after slapd had shut down, so I was wrong in blaming the PKI daemon. See below for a list of log files I've been trough. They all have on thing in common, the daemons starts when the host machine is started, at approx 06:34, then receives a shutdown signal around 06:37. Some time later when the host has calmed down, I'm logging in and manually starting IPA using ipactl start, and all the daemons start without any problem. And they keep running after my manual intervention. I wish I could be more specific, but I'm unsure where else to look. Suggestions? /var/log/krb5kdc.log /var/log/pki-ca/catalina.out /var/log/dirsrv/slapd-IX-TEST-COM/errors /var/log/dirsrv/slapd-PKI-IPA/errors /var/log/httpd/error_log /var/log/messages (named log) slapd errors: [14/May/2011:06:33:52 +0200] - 389-Directory/1.2.8.rc1 B2011.062.1416 starting up [14/May/2011:06:33:54 +0200] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. 1) Disorderly Shutdown means a) crash b) kill -9 or similar - neither of which should be happening - is this the replica install or the first master install? First master install. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for Linux desktop deployment
Sorry to answer my own post! After trying out all the permutations and combinations of automountkey-add/del command, I figured out the following entry and it works for all the PRE CREATED home folders across all the machines except NFS server, /etc/auto.home:* -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 hugayat.cohort.org:/ With this entry, it gets automounted if I have the home folder present already in my NFS partition (i.e /xtra/home/XXX). It is not working when I try to login to NFS server. Instead it is creating a home folder on the fly under /home of NFS server. Is this what I can achieve maximum ? or can I have folders automatically created while login for the first time ? Thanks again for making me reach up to this point! Regards,Nidal Lets try to isolate it a little further. If you log in to that machine as root, and then do su - nasir, does it let you create the directory or give you the same error? I'm guessing it is ssh that is complaining here. If the mount point is set up correctly, you should be able to crete and chown the /home/nasir directory, either via odd job, or just test it as root. What I am guessing is happening here is that ssh is not triggereing the odd job creation of the home directory. Either that, or this particular IPA client was run without the switch to create the home-dir. If Automount is commented out, does the /home/nasir directory get created on the local disk? On 05/16/2011 09:19 PM, nasir nasir wrote: Thanks again! No! it allows auto mount that pre created home folder ONLY to the NFS server. For e.g if I have /xtra/home/nasir alread created, then it automatically mounts while login to NFS server ( ssh -l nasir NFS_SERVER ). But when I try to login as the same user to some other machine ( ssh -l nasir ANY_IPA_MACHINE) it gives the following error, [root@openipa ~]# ssh -l nasir 192.168.1.222 -X nasir@192.168.1.222's password: Creating home directory for nasir. Last login: Tue May 17 04:06:43 2011 from openipa.cohort.org Could not chdir to home directory /home/nasir: No such file or directory -sh-4.1$ ls So it is not working right ? Hope it is clear to you now. Thanks and regards, Nidal If I manually create one home folder( e.g /xtra/home/abc ) under than, then I can mount it, but nothing can be written to it by the user as it gives permission denied error. Yes, but it should allow the root user to create and chown the directory, so the autocreation of home dirs should work. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for Linux desktop deployment
On 05/17/2011 02:03 AM, nasir nasir wrote: Further to my previous mail, let us try to isolate it even more by comparing the login attempts to the NFS server(hugayat.cohort.org) and another IPA client(rhel.cohort.org) This is the relevant /var/log/message in the two cases *1. ssh -l nasir hugayat.cohort.org* May 17 07:45:14 hugayat automount[15767]: get_query_dn: lookup(ldap): found search base under cn=automount,dc=cohort,dc=org 12 May 17 07:45:14 hugayat automount[15767]: get_query_dn: lookup(ldap): found query dn automountmapname=auto.home,cn=default,cn=automount,dc=cohort,dc=org 13 May 17 07:45:14 hugayat automount[15767]: connected to uri ldap://192.168.1.240 14 May 17 07:45:14 hugayat automount[15767]: lookup_one: lookup(ldap): searching for ((objectclass=automount)(|(automountKey=nasir)(automountKey=/)(automountKey=\2A))) under automountmapname=auto.ho me,cn=default,cn=automount,dc=cohort,dc=org 15 May 17 07:45:14 hugayat automount[15767]: lookup_one: lookup(ldap): getting first entry for automountKey=nasir 16 May 17 07:45:14 hugayat automount[15767]: lookup_one: lookup(ldap): examining first entry 17 May 17 07:45:14 hugayat automount[15767]: lookup_mount: lookup(ldap): nasir - -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 hugayat.cohort.org:/xtra/home/ 18 May 17 07:45:14 hugayat automount[15767]: parse_mount: parse(sun): expanded entry: -fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 hugayat.cohort.org:/xtra/home/nasir 19 May 17 07:45:14 hugayat automount[15767]: parse_mount: parse(sun): gathered options: fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192 20 May 17 07:45:14 hugayat automount[15767]: parse_mount: parse(sun): dequote(hugayat.cohort.org:/xtra/home/nasir) - hugayat.cohort.org:/xtra/home/nasir 21 May 17 07:45:14 hugayat automount[15767]: parse_mount: parse(sun): core of entry: options=fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192, loc=hugayat.cohort.org:/xtra/home/nasir 22 May 17 07:45:14 hugayat automount[15767]: sun_mount: parse(sun): mounting root /home, mountpoint nasir, what hugayat.cohort.org:/xtra/home/nasir, fstype nfs4, options rw,sec=krb5,soft,rsize=8192,wsize=8192 23 May 17 07:45:14 hugayat automount[15767]: mount_mount: mount(nfs): root=/home name=nasir what=hugayat.cohort.org:/xtra/home/nasir, fstype=nfs4, options=rw,sec=krb5,soft,rsize=8192,wsize=8192 24 May 17 07:45:14 hugayat automount[15767]: mount_mount: mount(nfs): nfs options=rw,sec=krb5,soft,rsize=8192,wsize=8192, nosymlink=0, ro=0 25 May 17 07:45:14 hugayat automount[15767]: mount_mount: mount(nfs): calling mkdir_path /home/nasir 26 May 17 07:45:14 hugayat automount[15767]: mount_mount: mount(nfs): *nasir is local, attempt bind mount* I'm guessing that there is some policy enforced by the NFS server here that lets you do something like this. ...and here's the source code http://autofs5.sourcearchive.com/documentation/5.0.4-2/mount__nfs_8c-source.html Here's the comment right above the line that generates that message. * If the port option is specified, then we don't want * a bind mount. Use the port option if you want to * avoid attempting a local bind mount, such as when * tunneling NFS via localhost. So no surprise that the behavior is different on the NFS server than the rest of the cluster. 27 May 17 07:45:14 hugayat automount[15767]: mount_mount: mount(bind): calling mkdir_path /home/nasir 28 May 17 07:45:14 hugayat automount[15767]: mount_mount: mount(bind): calling mount --bind -s -o defaults /xtra/home/nasir /home/nasir 29 May 17 07:45:14 hugayat automount[15767]: mount_mount: mount(bind): mounted /xtra/home/nasir type bind on /home/nasir *2. ssh -l rhel.cohort.org* 7 May 17 07:46:06 rhel automount[15387]: find_server: trying server uri ldap://192.168.1.240 8 May 17 07:46:06 rhel automount[15387]: do_bind: lookup(ldap): auth_required: 1, sasl_mech (null) 9 May 17 07:46:06 rhel automount[15387]: do_bind: lookup(ldap): ldap simple bind returned 0 10 May 17 07:46:06 rhel automount[15387]: get_query_dn: lookup(ldap): check search base list 11 May 17 07:46:06 rhel automount[15387]: get_query_dn: lookup(ldap): found search base under cn=automount,dc=cohort,dc=org 12 May 17 07:46:06 rhel automount[15387]: get_query_dn: lookup(ldap): found query dn automountmapname=auto.home,cn=default,cn=automount,dc=cohort,dc=org 13 May 17 07:46:06 rhel automount[15387]: connected to uri ldap://192.168.1.240 14 May 17 07:46:06 rhel automount[15387]: lookup_one: lookup(ldap): searching for ((objectclass=automount)(|(automountKey=nasir)(automountKey=/)(automountKey=\2A))) under automountmapname=auto.home, cn=default,cn=automount,dc=cohort,dc=org 15 May 17 07:46:06 rhel automount[15387]: lookup_one: lookup(ldap): getting first entry for automountKey=nasir 16 May 17 07:46:06 rhel automount[15387]: lookup_one: lookup(ldap): examining first entry 17 May 17
Re: [Freeipa-users] IPA Startup issues
On 05/17/2011 06:40 AM, Sigbjorn Lie wrote: On 05/16/2011 04:56 PM, Rich Megginson wrote: On 05/16/2011 08:43 AM, Sigbjorn Lie wrote: On 05/16/2011 03:52 PM, Simo Sorce wrote: On Sat, 2011-05-14 at 16:46 +0200, Sigbjorn Lie wrote: I've noticed that if the machine running IPA is very busy at startup, the IPA services will not be online when the machine is started. I noticed this is as my test virtualization host has had it's power cord knocked out a few times. When I restart the host machine, all the virtual machines is started at the same time, causing (a lot) higher than normal latency for each virtual machine. This causes the IPA daemons to start, while during the startup one or several IPA daemons fails due to dependencies of other daemons which is not started yet, and all the IPA daemons is stopped as not all the IPA daemons started successfully. I've noticed that the default behavior of the ipactl command is to shut down all the IPA daemons, if any of the IPA daemons should fail during startup. This can be seen in the logs of the individual services, as some is started successfully, just to receive a shutdown signal shortly after. It seem to be the pki-ca which shut down my IPA services this morning. When rebooting the virtual machine running the IPA daemons during normal load of the host machine, all the IPA daemons start successfully. Logging on to the IPA server and manually starting the IPA daemons after the load of the host machine has decreased also works. I suggest changing the startup scripts to allow (a lot) longer startup times for the IPA daemons prior to failing them. At the moment we just run servicename start and wait until it is done. If the pki-cad service timeouts and returns an error I think we need to open a bug against the dogtag component as that is the cause. Can you open a bug in the freeipa trac with logs showing that service is responsible for the failure ? I haven't been able to figure out which service that failed IPA yet. A lot of log files scattered around. As you can see from the slapd errors file, the slapd daemon was available for almost 3 minutes before receiving the shutdown signal. I notice now that the PKI daemon failed 8 seconds after slapd had shut down, so I was wrong in blaming the PKI daemon. See below for a list of log files I've been trough. They all have on thing in common, the daemons starts when the host machine is started, at approx 06:34, then receives a shutdown signal around 06:37. Some time later when the host has calmed down, I'm logging in and manually starting IPA using ipactl start, and all the daemons start without any problem. And they keep running after my manual intervention. I wish I could be more specific, but I'm unsure where else to look. Suggestions? /var/log/krb5kdc.log /var/log/pki-ca/catalina.out /var/log/dirsrv/slapd-IX-TEST-COM/errors /var/log/dirsrv/slapd-PKI-IPA/errors /var/log/httpd/error_log /var/log/messages (named log) slapd errors: [14/May/2011:06:33:52 +0200] - 389-Directory/1.2.8.rc1 B2011.062.1416 starting up [14/May/2011:06:33:54 +0200] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. 1) Disorderly Shutdown means a) crash b) kill -9 or similar - neither of which should be happening - is this the replica install or the first master install? First master install. What is in the slapd errors log before [14/May/2011:06:33:52 +0200] - 389-Directory/1.2.8.rc1 B2011.062.1416 starting up? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL client to IPA
So what should the command be? regards -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Friday, 13 May 2011 9:11 p.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] RHEL client to IPA On 05/13/2011 06:00 AM, Steven Jones wrote: [root@vuwunicoipamt01 etc]# ipa-getkeytab -k /tmp/vuwnicologint2.keytab -p host/vuwunicologint2.unix.vuw.ac.nz -s vuwunicoipamt01.unix.vuw.ac.nz -p admin The second -p overrides the first. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL client to IPA
Steven Jones wrote: So what should the command be? # kinit admin # ipa-getkeytab -k /tmp/vuwnicologint2.keytab -p host/vuwunicologint2.unix.vuw.ac.nz -s vuwunicoipamt01.unix.vuw.ac.nz rob regards -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Friday, 13 May 2011 9:11 p.m. To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] RHEL client to IPA On 05/13/2011 06:00 AM, Steven Jones wrote: [root@vuwunicoipamt01 etc]# ipa-getkeytab -k /tmp/vuwnicologint2.keytab -p host/vuwunicologint2.unix.vuw.ac.nz -s vuwunicoipamt01.unix.vuw.ac.nz -p admin The second -p overrides the first. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] How to reset the admin password
Steven Jones wrote: ? $ LDAPTLS_CACERT=/etc/ipa/ca.crt ldappasswd -ZZ -D 'cn=directory manager' -W -S uid=admin,cn=users,cn=accounts,dc=example,dc=com You'll first be prompted for the new admin password twice, then for the Directory Manager password. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL client to IPA
Im getting, SASL bind failed! 8 Steven Jones wrote: So what should the command be? # kinit admin # ipa-getkeytab -k /tmp/vuwnicologint2.keytab -p host/vuwunicologint2.unix.vuw.ac.nz -s vuwunicoipamt01.unix.vuw.ac.nz ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] RHEL client to IPA
Is ns-ldap / kdc running on vuwunicoipamt01.unix.vuw.ac.nz? service dirsrv status service krb5kdc status And are you running the command on vuwunicoipamt01.unix.vuw.ac.nz? On May 17, 2011, at 8:23 PM, Steven Jones steven.jo...@vuw.ac.nzmailto:steven.jo...@vuw.ac.nz wrote: Im getting, SASL bind failed! 8 Steven Jones wrote: So what should the command be? # kinit admin # ipa-getkeytab -k /tmp/vuwnicologint2.keytab -p host/vuwunicologint2.unix.vuw.ac.nz -s vuwunicoipamt01.unix.vuw.ac.nz ___ Freeipa-users mailing list Freeipa-users@redhat.commailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
