[Freeipa-users] FreeIPA for Linux desktop deployment
nasir nasir
kollathodi at yahoo.com
Mon Jul 25 00:58:35 UTC 2011
Hi,
Further to the ongoing deployment of Linux clients and servers using FreeIPA, I was able to successfully get all the requirements like,
-- complete centralized authentication and administration -- NFS home share -- HBAC -- FreeIPA acting as Integrated DNS server
Everything was good during the testing period. But when we went to production since day before yesterday, we are facing a serious issue. The DNS in IPA is giving out some problems. All of a sudden it becomes unresponsive. We already noticed this twice in the past 48 hours. Since this is the name server for the entire network, everything depending on this for name resolution fails. When I log in to FreeIPA server machine and tries to see the status of named service(service named status) the command hangs. Then I need to forcefully kill the named service and start it again(or alternatively restart ipa service) to get everything back to normal. I checked all the relevant log files and could see the following at various point of time in the /var/log/messages(trimmed out most of the part to show only possible named/sssd/ipa errors)
Jul 22 05:57:55 openipa named[10135]: semaphore.c:70: fatal error:Jul 22 05:57:55 openipa named[10135]: RUNTIME_CHECK(((pthread_mutex_destroy((&sem->mutex)) == 0) ? 0 : 34) == 0) failedJul 22 05:57:55 openipa named[10135]: exiting (due to fatal error in library)Jul 22 05:57:55 openipa abrt[12698]: /var/named/core.10135 is not a regular file with link count 1: Permission denied
Jul 22 14:35:56 openipa [sssd[ldap_child[17070]]]: Failed to initialize credentials using keytab [(null)]: Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP connection.Jul 22 14:35:56 openipa [sssd[ldap_child[17072]]]: Failed to initialize credentials using keytab [(null)]: Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP connection.
Jul 22 17:54:33 openipa named[15678]: error (network unreachable) resolving 'snapfiles.com/AAAA/IN': 2001:503:231d::2:30#53
Jul 22 20:00:02 openipa python: IPA compliance checking failed: Error initializing principal host/openipa.hugayet.com at HUGAYET.COM in /etc/krb5.keytab: (-1765328353, 'Decrypt integrity check failed')
Jul 23 09:10:01 openipa abrt[21599]: saved core dump of pid 20934 (/usr/sbin/named) to /var/spool/abrt/ccpp-1311401401-20934.new/coredump (37900288 bytes)Jul 23 09:10:01 openipa abrtd: Directory 'ccpp-1311401401-20934' creation detectedJul 23 09:10:01 openipa abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1307530903-2297)Jul 23 09:10:01 openipa abrtd: Deleting crash ccpp-1311401401-20934 (dup of ccpp-1307530903-2297), sending dbus signalJul 23 09:10:03 openipa named[21631]: starting BIND 9.7.3-RedHat-9.7.3-2.el6 -u named -4
Jul 23 15:35:56 openipa [sssd[ldap_child[22297]]]: Failed to initialize credentials using keytab [(null)]: Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP connection.Jul 23 15:35:56 openipa [sssd[ldap_child[22298]]]: Failed to initialize credentials using keytab [(null)]: Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP connection.
Jul 23 09:10:03 openipa named[21631]: adjusted limit on open files from 1024 to 1048576
Jul 24 03:16:01 openipa [sssd[ldap_child[22964]]]: Failed to initialize credentials using keytab [(null)]: Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP connection.Jul 24 04:00:02 openipa python: IPA compliance checking failed: Error initializing principal host/openipa.hugayet.com at HUGAYET.COM in /etc/krb5.keytab: (-1765328353, 'Decrypt integrity check failed')Jul 24 06:17:25 openipa named[21631]: semaphore.c:70: fatal error:Jul 24 06:17:25 openipa named[21631]: RUNTIME_CHECK(((pthread_mutex_destroy((&sem->mutex)) == 0) ? 0 : 34) == 0) failedJul 24 06:17:25 openipa named[21631]: exiting (due to fatal error in library)Jul 24 06:17:25 openipa abrt[23220]: saved core dump of pid 21631 (/usr/sbin/named) to /var/spool/abrt/ccpp-1311477445-21631.new/coredump (143396864 bytes)
Also, I could see the following in my krb5kdc.log,
ul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](Error): preauth pkinit failed to initialize: No realms configured correctly for pkinit supportJul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): setting up network...Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): listening on fd 9: udp 0.0.0.0.88 (pktinfo)krb5kdc: setsockopt(10,IPV6_V6ONLY,1) workedkrb5kdc: No realms configured correctly for pkinit support - Cannot request packet info for udp socket address :: port 88Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): skipping unrecognized local address family 17Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): skipping unrecognized local address family 17krb5kdc: setsockopt(10,IPV6_V6ONLY,1) workedJul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): listening on fd 10: udp fe80::6ab5:99ff:fec8:160%eth0.88krb5kdc: setsockopt(11,IPV6_V6ONLY,1) workedJul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): listening on
fd 12: tcp 0.0.0.0.88Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): listening on fd 11: tcp ::.88Jul 24 06:20:46 openipa.hugayet.com krb5kdc[23721](info): set up 4 sockets
Also, please note the following points,
---- For the DHCP service, I have a cobbler server running the service which will use the FreeIPA server's DNS servicee.(with ddns-update-style interim; option in the dhcp configuration file) ---- After seeing some permission related issues for named, I have given /var/named sufficient permission to named daemon for the folder. ---- Disabled ipv6 for named as I don't use it anyway(OPTIONS="-4" in /etc/sysconfig/named)
Thanks indeed for for all the help so far and waiting for your valuable input on this!
Regards,Nidal
--- On Wed, 5/18/11, nasir nasir <kollathodi at yahoo.com> wrote:
From: nasir nasir <kollathodi at yahoo.com>
Subject: Re: [Freeipa-users] FreeIPA for Linux desktop deployment
To: "Adam Young" <ayoung at redhat.com>
Cc: freeipa-users at redhat.com
Date: Wednesday, May 18, 2011, 11:00 AM
Adam,
I will look more in to this aspect and update later.
Big thanks to everyone for making me reach up to this point. I appreciate it tremendously. Now in my test environement I have a working FreeIPA server, NFS server(which is and IPA client), 2 more IPA clients. All running RHEL 6.1 beta.
Following things work fine now, -- Centralized authentication and user/group management -- Shared home folder automatically gets mounted to the client machine when the user login for the first time(Only catch is it needs to be created manually on the NFS server first) -- User profiles are preserved in the home folder
Next
steps,
-- Try whether I can have this WITHOUT creating the home folder manually on the NFS server first -- Replication of FreeIPA by adding one more server -- Try out HBAC, Roles, Netgroups and other features of FreeIPA -- Implement quota for user home folder
I will update the list about progress of all these later.
Thanks indeed to everyone once again!
Regards,Nidal
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 07:46:06 rhel automount[15387]:
lookup_mount: lookup(ldap): nasir ->
-fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192
hugayat.cohort.org:/xtra/home/&
18 May 17 07:46:06 rhel automount[15387]:
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:46:06 rhel automount[15387]:
parse_mount: parse(sun): gathered options:
fstype=nfs4,rw,sec=krb5,soft,rsize=8192,wsize=8192
20 May 17 07:46:06 rhel automount[15387]:
parse_mount: parse(sun):
dequote("hugayat.cohort.org:/xtra/home/nasir") ->
hugayat.cohort.org:/xtra/home/nasir
21 May 17 07:46:06 rhel automount[15387]:
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:46:06 rhel automount[15387]:
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=8 192
23 May 17 07:46:06 rhel automount[15387]:
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:46:06 rhel automount[15387]:
mount_mount: mount(nfs): nfs
options="rw,sec=krb5,soft,rsize=8192,wsize=8192",
nosymlink=0, ro=0
25 May 17 07:46:06 rhel automount[15387]:
mount_mount: mount(nfs): calling mkdir_path
/home/nasir
26 May 17 07:46:06 rhel automount[15387]:
mount_mount: mount(nfs): calling mount -t nfs4 -s -o
rw,sec=krb5,soft,rsize=8192,wsize=8192
hugayat.cohort.org:/xtra/home/nasir /home/nasir
27 May 17 07:46:06 rhel automount[15387]:
>> mount.nfs4: mounting
hugayat.cohort.org:/xtra/home/nasir failed, reason
given by server:
28 May 17 07:46:06 rhel automount[15387]:
>> No such file or directory
Please compare the lines between 20-30 in
both the cases. All the parameters
are same but in the first case it says the user
"nasir is local". What does it mean ?
Thanks
and regards,
Nidal
Thanks again! To answer your queries,
-- I get the same error for su -
nasir
-- I don't think ssh is not creating
oddjobd ; see the error in the trailing mail
which I am getting in the konsole while trying
to login. It does try to create home folder
-- The client IPA machine was created
with --mkhomedir switch. Also, I can see pam_oddjob_mkhomedir.so
entry in the system-auth and
password-auth files of pam(But not in ssh
file, though I manually tried once to insert
in ssh file and then it was trying to create
the home folder twice while SSHing !!).
-- As I said in previous mail,
Pre-created directories get autmounted and
setup correctly when I try to login to NFS
server(cohort.org.hugyat) but NOT to other
machines.
-- When autofs is disabled,
directories get created successfully in the
local hard disk on all the machines
configured with --mkhomedir switch
Any clue ?
Thanks and 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 at openipa ~]#
ssh -l nasir
192.168.1.222 -X
nasir at 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.
-----Inline Attachment Follows-----
_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
-----Inline Attachment Follows-----
_______________________________________________
Freeipa-users mailing list
Freeipa-users at redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20110724/e1409ad1/attachment.htm>
More information about the Freeipa-users
mailing list