On 07/12/2013 03:22 PM, Dean Hunter wrote: > On Fri, 2013-07-12 at 18:55 +0000, Adamson, Andy wrote: >> >> On Jul 12, 2013, at 2:43 PM, Ondrej Valousek <ovalou...@vendavo.com >> <mailto:ovalou...@vendavo.com>> >> wrote: >> >>> Just back to the Kerberized NFS. Any solution to RH bugzilla #786463 >>> on the horizon yet? >>> Expiring tickets will render the whole concept unusable otherwise. >> >> >> Hi >> >> >> I'm looking into Kerberized NFS client issues and bugs. I'll be sure >> to add this to my todo list. Do you know if anyone has tried with >> the latest upstream kernel? >> > > I have a Kerberized NFS auto mount working very nicely on Fedora 18, > FreeIPA 3.1.5-1 and company. But I am having problems getting the > same configuration to work on Fedora 19, FreeIPA 3.2.1-1 and company. > I have been working to refine the problem definition to more than it > does not work.
F19 has GSS proxy. I encourage you to use it. I know it was tried and worked as several bugs have been addressed. Gunther CCed will be back from PTO next week and should be able to help. > >> -->Andy >> >>> >>> >>> Anyone? >>> O. >>> >>> >>> >>> >>> Odesláno ze Samsung Mobile >>> >>> >>> >>> -------- Pu*vodní zpráva -------- >>> Od: Ondrej Valousek <ovalou...@vendavo.com >>> <mailto:ovalou...@vendavo.com>> >>> Datum: >>> Komu: and...@wasielewski.co.uk >>> <mailto:and...@wasielewski.co.uk>,freeipa-users@redhat.com >>> <mailto:freeipa-users@redhat.com> >>> Pr(edme(t: RE: [Freeipa-users] Problem with Kerberised NFS mount >>> >>> >>> Hard to say. >>> In general, when dealing w/ nfs & kerberos, I would advise to: >>> ? Upgrade to the latest fedora >>> ? Make sure idmapper is configured and working fine >>> ? Limit krb enctypes to 3des-cbc-crc (not sure if your kernel can >>> handle aes keys). >>> Ondrej >>> >>> >>> >>> >>> Odesláno ze Samsung Mobile >>> >>> >>> >>> -------- Pu*vodní zpráva -------- >>> Od: Andrew Wasielewski <and...@wasielewski.co.uk >>> <mailto:and...@wasielewski.co.uk>> >>> Datum: >>> Komu: freeipa-users@redhat.com <mailto:freeipa-users@redhat.com> >>> Pr(edme(t: [Freeipa-users] Problem with Kerberised NFS mount >>> >>> >>> Hello everyone, >>> >>> >>> I am setting up FreeIPA for a small home network. However I have a >>> problem mounting NFS shares with Kerberos enables - see syslog >>> output below. >>> >>> >>> My NFS, KDC and FreeIPA servers are all on the same host. I am >>> running the NFS mount directly on the server, which has local >>> firewall disabled - I get the same outcome on a remote client, but >>> this surely eliminates any network issues. >>> >>> >>> These are my NFS exports, which are visible both locally and >>> remotely with "showmount -e":- >>> >>> >>> [root@server ~]# exportfs -av >>> exporting gss/krb5:/home >>> exporting gss/krb5i:/home >>> exporting gss/krb5p:/home >>> >>> >>> The command "mount -t nfs4 -o sec=krb5 server.wasielewski.co.uk >>> <http://server.wasielewski.co.uk>:/home /mnt/test_mnt" hangs >>> indefinitely. However without the Kerberos export options the NFS >>> share can be mounted both locally and remotely without problem. >>> >>> >>> I read in a post that the "serializing key with enctype 18 and size >>> 32" entry in syslog means I am trying to use an unsupported key with >>> AES256 encryption (I can find very little about enctype numbers >>> though); however I appear to have an AES256 service principal: >>> >>> >>> [root@server etc]# ktutil >>> ktutil: rkt /etc/krb5.keytab >>> ktutil: list -e >>> slot KVNO Principal >>> ---- ---- >>> --------------------------------------------------------------------- >>> 1 2 host/server.wasielewski.co...@wasielewski.co.uk >>> <mailto:host/server.wasielewski.co...@wasielewski.co.uk> >>> (aes256-cts-hmac-sha1-96) >>> 2 2 host/server.wasielewski.co...@wasielewski.co.uk >>> <mailto:host/server.wasielewski.co...@wasielewski.co.uk> >>> (aes128-cts-hmac-sha1-96) >>> 3 2 host/server.wasielewski.co...@wasielewski.co.uk >>> <mailto:host/server.wasielewski.co...@wasielewski.co.uk> >>> (des3-cbc-sha1) >>> 4 2 host/server.wasielewski.co...@wasielewski.co.uk >>> <mailto:host/server.wasielewski.co...@wasielewski.co.uk> (arcfour-hmac) >>> 5 5 nfs/server.wasielewski.co...@wasielewski.co.uk >>> <mailto:nfs/server.wasielewski.co...@wasielewski.co.uk> >>> (aes256-cts-hmac-sha1-96) >>> >>> >>> My versions are: >>> Fedora 17 (kernel 3.8.13-100.fc17.x86_64) >>> FreeIPA 2.2.2 >>> krb5 1.10.2 >>> nfs-utils 1.2.6 >>> I have read of this issue being fixed by downgrading nfs-utils to >>> 1.2.5; however that is not possible due to conflict with systemd. >>> Everything else appears to work OK e.g. domain login, automap etc. >>> When I try to mount the Kerberised NFS share, *nothing* appears in >>> /var/log/krb5kdc.log >>> >>> >>> Here is my syslog output when attempt the mount: >>> >>> >>> Jul 12 01:13:10 server rpc.gssd[31628]: dir_notify_handler: sig 37 >>> si 0x7fffe59b94f0 data 0x7fffe59b93c0 >>> Jul 12 01:13:10 server rpc.gssd[31628]: handling gssd upcall >>> (/var/lib/nfs/rpc_pipefs/nfs/clnt48) >>> Jul 12 01:13:10 server rpc.gssd[31628]: handle_gssd_upcall: >>> 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' >>> Jul 12 01:13:10 server rpc.gssd[31628]: handling krb5 upcall >>> (/var/lib/nfs/rpc_pipefs/nfs/clnt48) >>> Jul 12 01:13:10 server rpc.gssd[31628]: process_krb5_upcall: service >>> is '<null>' >>> Jul 12 01:13:10 server rpc.gssd[31628]: Full hostname for >>> 'server.wasielewski.co.uk <http://server.wasielewski.co.uk>' is >>> 'server.wasielewski.co.uk <http://server.wasielewski.co.uk>' >>> Jul 12 01:13:10 server rpc.gssd[31628]: Full hostname for >>> 'server.wasielewski.co.uk <http://server.wasielewski.co.uk>' is >>> 'server.wasielewski.co.uk <http://server.wasielewski.co.uk>' >>> Jul 12 01:13:10 server rpc.gssd[31628]: No key table entry found for >>> SERVER.WASIELEWSKI.CO.UK$@WASIELEWSKI.CO.UK >>> <mailto:SERVER.WASIELEWSKI.CO.UK$@WASIELEWSKI.CO.UK> while getting >>> keytab entry for 'SERVER.WASIELEWSKI.CO.UK$@WASIELEWSKI.CO.UK >>> <mailto:SERVER.WASIELEWSKI.CO.UK$@WASIELEWSKI.CO.UK>' >>> Jul 12 01:13:10 server rpc.gssd[31628]: No key table entry found for >>> root/server.wasielewski.co...@wasielewski.co.uk >>> <mailto:root/server.wasielewski.co...@wasielewski.co.uk> while >>> getting keytab entry for >>> 'root/server.wasielewski.co...@wasielewski.co.uk >>> <mailto:root/server.wasielewski.co...@wasielewski.co.uk>' >>> Jul 12 01:13:10 server rpc.gssd[31628]: Success getting keytab entry >>> for 'nfs/server.wasielewski.co...@wasielewski.co.uk >>> <mailto:nfs/server.wasielewski.co...@wasielewski.co.uk>' >>> Jul 12 01:13:10 server rpc.gssd[31628]: INFO: Credentials in CC >>> 'FILE:/tmp/krb5cc_machine_WASIELEWSKI.CO.UK' are good until 1373659035 >>> Jul 12 01:13:10 server rpc.gssd[31628]: INFO: Credentials in CC >>> 'FILE:/tmp/krb5cc_machine_WASIELEWSKI.CO.UK' are good until 1373659035 >>> Jul 12 01:13:10 server rpc.gssd[31628]: using >>> FILE:/tmp/krb5cc_machine_WASIELEWSKI.CO.UK as credentials cache for >>> machine creds >>> Jul 12 01:13:10 server rpc.gssd[31628]: using environment variable >>> to select krb5 ccache FILE:/tmp/krb5cc_machine_WASIELEWSKI.CO.UK >>> Jul 12 01:13:10 server rpc.gssd[31628]: creating context using fsuid >>> 0 (save_uid 0) >>> Jul 12 01:13:10 server rpc.gssd[31628]: creating tcp client for >>> server server.wasielewski.co.uk <http://server.wasielewski.co.uk> >>> Jul 12 01:13:10 server rpc.gssd[31628]: DEBUG: port already set to 2049 >>> Jul 12 01:13:10 server rpc.gssd[31628]: creating context with server >>> n...@server.wasielewski.co.uk <mailto:n...@server.wasielewski.co.uk> >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: leaving poll >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: handling null request >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: >>> svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with >>> 7 enctypes from the kernel >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: sname = >>> nfs/server.wasielewski.co...@wasielewski.co.uk >>> <mailto:nfs/server.wasielewski.co...@wasielewski.co.uk> >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: DEBUG: >>> serialize_krb5_ctx: lucid version! >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: >>> prepare_krb5_rfc4121_buffer: protocol 1 >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: >>> prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and >>> size 32 >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: doing downcall >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: mech: krb5, hndl len: 4, >>> ctx len 52, timeout: 1373659035 (71045 from now), clnt: >>> n...@server.wasielewski.co.uk <mailto:n...@server.wasielewski.co.uk>, >>> uid: -1, gid: -1, num aux grps: 0: >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: sending null reply >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: writing message: \x >>> \x6082029f06092a864886f71201020201006e82028e3082028aa003020105a10302010ea20703050020000000a3820184618201803082017ca003020105a1131b1157415349454c4557534b492e434f2e554ba22a3028a003020103a121301f1b036e66731b187365727665722e77617369656c6577736b692e636f2e756ba38201323082012ea003020112a103020105a28201200482011ccd1627a49a2911b9662144c0c43f9e64d78f4e817846f95884f3f43ea053b3954f22fb2d287d9ad0e24f88e32301d6a6f3f70d0e415b9c957e60e773b45b3a065258f1614451a258e3ce05f5c1fb889882b336223a32db10bea70dd334f22b9e1efaddd8b417994f6168d42a065e160353243de8aa53b4449a477567673212d68c241975300d12be7a756b7d4c7c75f8e5e82d84223ad592f6fec6897baa79b92e7097ecf1237f6c2c8ac2555c7c60782f51c386782eb56147e1ffcc8c4de94fba31d1e7a20f88b2ce88a9eb8059a9fe5731c22075280ec9eaf01fc81fccac841002f65d86e0b7000074b84661cb9ceed5e77ca4bdadfbe345ea41467392441ca5f202db006e019826d81d60e383427b5cd766f23b15b4e4eb8ebc1ba481ec3081e9a003020112a281e10481de69f0cdd8b94ef7123715131198824fa3c953d25f7dfea3b253df9623e44c660e7a96629eb323e5616bd7162e0ba4ec2d6037e3b3409be10410b2d3ffc0e2b1631b5dac718c3dfde170ec050bfc1dde657fcb7f35a7ef38e20477fea9d5f7e1320a77eef539455383080522686d1fbfb7bef8cb200dc8810c56e68bc25ad011aff3397781713aa8b696ec9f94843822449d1930b96530f69203840eab8d8398faf1286fde6edf7ef315489aa6621e1be8ea8375c52084895498f57183ccd0a104e7ac244a3fab12449144499a2308103e432c47d945f80e644f4df17271c0 >>> 1373588050 0 0 \x73000000 >>> \x60819906092a864886f71201020202006f8189308186a003020105a10302010fa27a3078a003020112a271046f87a21e99d0907eadcd179fef73a8a4b38cb8180566d1f2cea453e28b7334b0648a543c3f2588a79f516f7d2238e1cca4ca5ec290b2a5d8b9d570ba47fdc20a2d36bc54928c3addba9b68867028c9adb157e487cc0951bc1270f9f1b96e643bb614589411cc923a9fbe5654beb20d85 >> >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: finished handling null >>> request >>> Jul 12 01:13:10 server rpc.svcgssd[32135]: entering poll >>> Jul 12 01:13:10 server rpc.gssd[31628]: DEBUG: serialize_krb5_ctx: >>> lucid version! >>> Jul 12 01:13:10 server rpc.gssd[31628]: prepare_krb5_rfc4121_buffer: >>> protocol 1 >>> Jul 12 01:13:10 server rpc.gssd[31628]: prepare_krb5_rfc4121_buffer: >>> serializing key with enctype 18 and size 32 >>> Jul 12 01:13:10 server rpc.gssd[31628]: doing downcall >>> >>> >>> Any advice is much appreciated. >>> >>> >>> Andrew >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users@redhat.com <mailto: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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
