* Re: trouble using kerberos between linux client and server [not found] <4BCFE979.2000406@inria.fr> @ 2010-05-05 21:18 ` Guillaume Rousse 2010-05-12 21:37 ` Guillaume Rousse 0 siblings, 1 reply; 9+ messages in thread From: Guillaume Rousse @ 2010-05-05 21:18 UTC (permalink / raw) To: linux-nfs [-- Attachment #1: Type: text/plain, Size: 8089 bytes --] Le 22/04/2010 08:15, Guillaume Rousse a écrit : > Hello list. > > I've been using kerberized NFS with NetApp filer without > kerberos-specific troubles so far. However, I'm currently trying to > setup a Linux kerberized server for the first time, and I'm facing > Kerberos issues. I managed to get rid of the two initial errors (failure to select the correct key if more than one key was present in the keytab, and failure to reply to pre-authentication request) by generating principals with DES keys right from the start, instead of adding a DES key to an already-existing principal later. There isn't any error in kerberos logs anymore. However, mount still doesn't succeed, for unknown failure in rpc.svcgssd (apparently): May 3 22:07:07 loubianka rpc.svcgssd[5729]: leaving poll May 3 22:07:07 loubianka rpc.svcgssd[5729]: handling null request May 3 22:07:07 loubianka rpc.svcgssd[5729]: sname = nfs/beria.zarb.home@ZARB.HOME May 3 22:07:07 loubianka rpc.svcgssd[5729]: nfs4_gss_princ_to_ids: calling nsswitch->princ_to_ids May 3 22:07:07 loubianka rpc.svcgssd[5729]: nss_getpwnam: name 'nfs/beria.zarb.home@ZARB.HOME' domain '(null)': resulting localname 'nfs/beria.zarb.home' May 3 22:07:07 loubianka rpc.svcgssd[5729]: nfs4_gss_princ_to_ids: nsswitch->princ_to_ids returned -2 May 3 22:07:07 loubianka rpc.svcgssd[5729]: nfs4_gss_princ_to_ids: final return value is -2 May 3 22:07:07 loubianka rpc.svcgssd[5729]: DEBUG: serialize_krb5_ctx: lucid version! May 3 22:07:07 loubianka rpc.svcgssd[5729]: prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 May 3 22:07:07 loubianka rpc.svcgssd[5729]: doing downcall May 3 22:07:07 loubianka rpc.svcgssd[5729]: mech: krb5, hndl len: 4, ctx len 85, timeout: 1273002810 (85583 from now), clnt: nfs@beria.zarb.home, uid: -1, gid: -1, num aux grps: 0: May 3 22:07:07 loubianka rpc.svcgssd[5729]: qword_eol: fflush failed: errno 95 (Operation not supported) May 3 22:07:07 loubianka rpc.svcgssd[5729]: WARNING: error writing to downcall channel /proc/net/rpc/auth.rpcsec.context/channel: Operation not supported May 3 22:07:07 loubianka rpc.svcgssd[5729]: sending null reply May 3 22:07:07 loubianka rpc.svcgssd[5729]: writing message: \x \x6082023606092a864886f71201020201006e82022530820221a003020105a10302010ea20703050020000000a38201516182014d30820149a003020105a10b1b095a4152422e484f4d45a2253023a003020103a11c301a1b036e66731b136c6f756269616e6b612e7a6172622e686f6d65a382010c30820108a003020101a103020102a281fb0481f87e4272c666342bb6b0b15e9cd002e38a80a61c6ff22f4c36906f55ed954826c7f5cf47f014d6994a4bbbb26c94b235bd2652e6887ee77b4efc90d1ff704e905ac0b25fc411f0f86208c533ed2c8d8c080dc04cd6498a50a23e15ba5035135cdb7517e89abda282bb258987aeb62c9555e406cf8c0461faf3eaf1d4b2cb9f62c9ea3bd67522294ecfc204247b46b96aa744dbc374bc5e371589a89bdfaee12a7865f97c1693cd42e581ce457df7400412580d2d3418e7c67f193adf19d8f9a2ee4101743ad50760d8cc36e778b936a7e2c11b11320a06b6399c8ab358853a4ad6e35ecca2f5974b224ec1c9c97262312043cdc8f938125492a481b63081b3a003020101a281ab0481a83ed20fcc8c164138b903cd084a73d8cb5443b925bb1574a976ea02cb5cc428b4045e246f9d4127c3bd85e23e319b9b538ae428951b05f02fd2fc550cb4189e8aeb6b9b8565393a6553f5d54b6ca2dbe6c1b8167e84d3612334969c9e 7adda30b4b9b0b516dfb95cc681c336ed961c67eb9ff5979d1cbe8b25346ee3b9b831e4dfb2886c3532cf265d38d5f0f425b1de71e715cb5577496e2fa57347ba24e8328fe60181cede1a8db 1272917287 0 0 \x08000000 \x607006092a864886f71201020202006f61305fa003020105a10302010fa2533051a003020101a24a0448dbfcd096f64638016b06d173c349533a18516fae606f6e49952bb4bcb47d4b90cdf2fe787d2522e3c52271f249e9c29a2566ddfffa27d562ba3e98c10f9ac30ca79127a244810e91 May 3 22:07:07 loubianka rpc.svcgssd[5729]: finished handling null request May 3 22:07:07 loubianka rpc.svcgssd[5729]: entering poll The same output appears twice for each attempt. Googling for 'qword_eol' refers to changes in nfs-utils last year adding more logs message in case of failure, and a strong feeling the issue occurs in server kernel (2.6.33.2). Here are clients logs: May 3 22:07:14 beria rpc.gssd[17990]: handle_gssd_upcall: 'mech=krb5 uid=0 ' May 3 22:07:14 beria rpc.gssd[17990]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt6) May 3 22:07:14 beria rpc.gssd[17990]: process_krb5_upcall: service is '<null>' May 3 22:07:14 beria rpc.gssd[17990]: Full hostname for 'loubianka.zarb.home' is 'loubianka.zarb.home' May 3 22:07:14 beria rpc.gssd[17990]: Full hostname for 'beria.zarb.home' is 'beria.zarb.home' May 3 22:07:14 beria rpc.gssd[17990]: Key table entry not found while getting keytab entry for 'root/beria.zarb.home@ZARB.HOME' May 3 22:07:14 beria rpc.gssd[17990]: Success getting keytab entry for 'nfs/beria.zarb.home@ZARB.HOME' May 3 22:07:14 beria rpc.gssd[17990]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_ZARB.HOME' are good until 1273002810 May 3 22:07:14 beria rpc.gssd[17990]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_ZARB.HOME' are good until 1273002810 May 3 22:07:14 beria rpc.gssd[17990]: using FILE:/tmp/krb5cc_machine_ZARB.HOME as credentials cache for machine creds May 3 22:07:14 beria rpc.gssd[17990]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_ZARB.HOME May 3 22:07:14 beria rpc.gssd[17990]: creating context using fsuid 0 (save_uid 0) May 3 22:07:14 beria rpc.gssd[17990]: creating tcp client for server loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: DEBUG: port already set to 2049 May 3 22:07:14 beria rpc.gssd[17990]: creating context with server nfs@loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: WARNING: Failed to create krb5 context for user with uid 0 for server loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_ZARB.HOME for server loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: Full hostname for 'loubianka.zarb.home' is 'loubianka.zarb.home' May 3 22:07:14 beria rpc.gssd[17990]: Full hostname for 'beria.zarb.home' is 'beria.zarb.home' May 3 22:07:14 beria rpc.gssd[17990]: Key table entry not found while getting keytab entry for 'root/beria.zarb.home@ZARB.HOME' May 3 22:07:14 beria rpc.gssd[17990]: Success getting keytab entry for 'nfs/beria.zarb.home@ZARB.HOME' May 3 22:07:14 beria rpc.gssd[17990]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_ZARB.HOME' are good until 1273002810 May 3 22:07:14 beria rpc.gssd[17990]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_ZARB.HOME' are good until 1273002810 May 3 22:07:14 beria rpc.gssd[17990]: using FILE:/tmp/krb5cc_machine_ZARB.HOME as credentials cache for machine creds May 3 22:07:14 beria rpc.gssd[17990]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_ZARB.HOME May 3 22:07:14 beria rpc.gssd[17990]: creating context using fsuid 0 (save_uid 0) May 3 22:07:14 beria rpc.gssd[17990]: creating tcp client for server loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: DEBUG: port already set to 2049 May 3 22:07:14 beria rpc.gssd[17990]: creating context with server nfs@loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: WARNING: Failed to create krb5 context for user with uid 0 for server loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_ZARB.HOME for server loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: WARNING: Failed to create machine krb5 context with any credentials cache for server loubianka.zarb.home May 3 22:07:14 beria rpc.gssd[17990]: doing error downcall May 3 22:07:14 beria rpc.gssd[17990]: destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt7 May 3 22:07:14 beria rpc.gssd[17990]: destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt6 I'm attaching network capture, even I can't figure additional information from it by myself. -- BOFH excuse #412: Radial Telemetry Infiltration [-- Attachment #2: out --] [-- Type: application/octet-stream, Size: 4220 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: trouble using kerberos between linux client and server 2010-05-05 21:18 ` trouble using kerberos between linux client and server Guillaume Rousse @ 2010-05-12 21:37 ` Guillaume Rousse 2010-05-12 23:21 ` Kevin Coffman 0 siblings, 1 reply; 9+ messages in thread From: Guillaume Rousse @ 2010-05-12 21:37 UTC (permalink / raw) To: linux-nfs [-- Attachment #1: Type: text/plain, Size: 390 bytes --] Le 05/05/2010 23:18, Guillaume Rousse a écrit : > I'm attaching network capture, even I can't figure additional > information from it by myself. Reading https://bugzilla.redhat.com/show_bug.cgi?id=562807, I rebuild libtirpc with patch applied and -DDEBUG. Unfortunatly, it doesn't bring additional information about the server-side failure :( -- BOFH excuse #60: system has been recalled [-- Attachment #2: client.out --] [-- Type: text/plain, Size: 9175 bytes --] beginning poll handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt37) handle_gssd_upcall: 'mech=krb5 uid=0 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt37) process_krb5_upcall: service is '<null>' Full hostname for 'loubianka.zarb.home' is 'loubianka.zarb.home' Full hostname for 'beria.zarb.home' is 'beria.zarb.home' Key table entry not found while getting keytab entry for 'root/beria.zarb.home@ZARB.HOME' Success getting keytab entry for 'nfs/beria.zarb.home@ZARB.HOME' Successfully obtained machine credentials for principal 'nfs/beria.zarb.home@ZARB.HOME' stored in ccache 'FILE:/tmp/krb5cc_machine_ZARB.HOME' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_ZARB.HOME' are good until 1273786473 using FILE:/tmp/krb5cc_machine_ZARB.HOME as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_ZARB.HOME creating context using fsuid 0 (save_uid 0) creating tcp client for server loubianka.zarb.home DEBUG: port already set to 2049 creating context with server nfs@loubianka.zarb.home rpcsec_gss: in authgss_create_default() rpcsec_gss: in authgss_create() authgss_create: name is 0x1a0f980 authgss_create: gd->name is 0x1a0b450 rpcsec_gss: in authgss_refresh() rpcsec_gss: rpc_gss_sec: mechanism_OID: { 1 2 134 72 134 247 18 1 2 2 } qop: 0 service: 1 cred: 0x1a0f2d0 rpcsec_gss: The token being sent (length 552): 0000: 6082 0224 0609 2a86 4886 f712 0102 0201 `..$..*.H....... 0010: 006e 8202 1330 8202 0fa0 0302 0105 a103 .n...0.......... 0020: 0201 0ea2 0703 0500 2000 0000 a382 013f ........ ......? 0030: 6182 013b 3082 0137 a003 0201 05a1 0b1b a..;0..7........ 0040: 095a 4152 422e 484f 4d45 a225 3023 a003 .ZARB.HOME.%0#.. 0050: 0201 03a1 1c30 1a1b 036e 6673 1b13 6c6f .....0...nfs..lo 0060: 7562 6961 6e6b 612e 7a61 7262 2e68 6f6d ubianka.zarb.hom 0070: 65a3 81fb 3081 f8a0 0302 0101 a103 0201 e...0........... 0080: 02a2 81eb 0481 e825 b158 7e3b e709 a61a .......%.X~;.... 0090: 82c4 8f6c a741 9885 8c0b 634c a32c f091 ...l.A....cL.,.. 00a0: 02f1 8ecf b46c d7dc 5ef1 a949 3ef4 b7c7 .....l..^..I>... 00b0: 2a45 f1de ff72 3ab8 8239 3aae 1ac3 fb19 *E...r:..9:..... 00c0: 949b c4e3 46b9 6956 1e91 3ed5 1d48 72cb ....F.iV..>..Hr. 00d0: 33a6 95b6 09e8 b104 28be a1cb 14a3 5d7d 3.......(.....]} 00e0: 8c14 2a8d 3aa9 d90c 2e81 cc05 bd00 9a51 ..*.:..........Q 00f0: 8916 3375 1cf6 66ab 4fe7 4d8b bcbf 6ccc ..3u..f.O.M...l. 0100: 957b 3100 e4bb b0c8 e5cc c8ca 3b08 34dd .{1.........;.4. 0110: 66b6 913f c38a 746e f62d dbe2 a6e5 5fd8 f..?..tn.-...._. 0120: 5afb b977 1fe4 470d 78ba 6cbc e7a9 9553 Z..w..G.x.l....S 0130: 0889 7e9a ee26 0542 1494 e1fd cb50 f581 ..~..&.B.....P.. 0140: 9aa6 19ab ba09 30a2 ca23 2922 91d3 fce0 ......0..#)".... 0150: 3f32 ec5f 819b f142 e449 ad07 8d49 2263 ?2._...B.I...I"c 0160: cafa 491d e743 ad15 4a49 d72b 6562 98a4 ..I..C..JI.+eb.. 0170: 81b6 3081 b3a0 0302 0101 a281 ab04 81a8 ..0............. 0180: 3ad3 49a2 2443 5f54 c8cb fd04 2c66 279b :.I.$C_T....,f'. 0190: 58bd 522e 5e9e c0e0 f7b0 e32d c1b8 2a93 X.R.^......-..*. 01a0: da22 569d 3290 bbcd e7ed 2b84 812d 2022 ."V.2.....+..- " 01b0: 9f06 b6f9 bef2 53cd 4760 b28c 7029 4456 ......S.G`..p)DV 01c0: 59f9 057b cbce 5dc2 5aab 6979 6519 a6b3 Y..{..].Z.iye... 01d0: c5e1 f575 23e8 1b16 e008 5d91 2dd1 8a97 ...u#.....].-... 01e0: ed53 2b9a c9e6 53ab 59f0 928b 8fc7 a19d .S+...S.Y....... 01f0: 3f8a 050e fba9 c929 ca86 4940 93fd 1205 ?......)..I@.... 0200: a21e 077e d035 9f0f 72bd 1928 885e 45ef ...~.5..r..(.^E. 0210: 47f0 f627 cc58 5b35 55d4 3175 1390 0e9e G..'.X[5U.1u.... 0220: c558 9320 48bb ee96 .X. H... rpcsec_gss: in authgss_marshal() rpcsec_gss: xdr_rpc_gss_buf: encode success ((nil):0) rpcsec_gss: xdr_rpc_gss_cred: encode success (v 1, proc 1, seq 0, svc 1, ctx (nil):0) rpcsec_gss: xdr_rpc_gss_buf: encode success (0x1a43140:552) rpcsec_gss: xdr_rpc_gss_init_args: encode success (token 0x1a43140:552) rpcsec_gss: in authgss_validate() rpcsec_gss: xdr_rpc_gss_buf: decode success (0x1a0d0e0:4) rpcsec_gss: xdr_rpc_gss_buf: decode success (0x1a42d30:114) rpcsec_gss: xdr_rpc_gss_init_res decode success (ctx 0x1a0d0e0:4, maj 524288, min 0, win 128, token 0x1a42d30:114) authgss_create_default: freeing name 0x1a0f980 WARNING: Failed to create krb5 context for user with uid 0 for server loubianka.zarb.home WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_ZARB.HOME for server loubianka.zarb.home WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server loubianka.zarb.home Full hostname for 'loubianka.zarb.home' is 'loubianka.zarb.home' Full hostname for 'beria.zarb.home' is 'beria.zarb.home' Key table entry not found while getting keytab entry for 'root/beria.zarb.home@ZARB.HOME' Success getting keytab entry for 'nfs/beria.zarb.home@ZARB.HOME' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_ZARB.HOME' are good until 1273786473 INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_ZARB.HOME' are good until 1273786473 using FILE:/tmp/krb5cc_machine_ZARB.HOME as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_ZARB.HOME creating context using fsuid 0 (save_uid 0) creating tcp client for server loubianka.zarb.home DEBUG: port already set to 2049 creating context with server nfs@loubianka.zarb.home rpcsec_gss: in authgss_create_default() rpcsec_gss: in authgss_create() authgss_create: name is 0x1a0d890 authgss_create: gd->name is 0x1a42ec0 rpcsec_gss: in authgss_refresh() rpcsec_gss: rpc_gss_sec: mechanism_OID: { 1 2 134 72 134 247 18 1 2 2 } qop: 0 service: 1 cred: 0x1a0e910 rpcsec_gss: The token being sent (length 552): 0000: 6082 0224 0609 2a86 4886 f712 0102 0201 `..$..*.H....... 0010: 006e 8202 1330 8202 0fa0 0302 0105 a103 .n...0.......... 0020: 0201 0ea2 0703 0500 2000 0000 a382 013f ........ ......? 0030: 6182 013b 3082 0137 a003 0201 05a1 0b1b a..;0..7........ 0040: 095a 4152 422e 484f 4d45 a225 3023 a003 .ZARB.HOME.%0#.. 0050: 0201 03a1 1c30 1a1b 036e 6673 1b13 6c6f .....0...nfs..lo 0060: 7562 6961 6e6b 612e 7a61 7262 2e68 6f6d ubianka.zarb.hom 0070: 65a3 81fb 3081 f8a0 0302 0101 a103 0201 e...0........... 0080: 02a2 81eb 0481 e825 b158 7e3b e709 a61a .......%.X~;.... 0090: 82c4 8f6c a741 9885 8c0b 634c a32c f091 ...l.A....cL.,.. 00a0: 02f1 8ecf b46c d7dc 5ef1 a949 3ef4 b7c7 .....l..^..I>... 00b0: 2a45 f1de ff72 3ab8 8239 3aae 1ac3 fb19 *E...r:..9:..... 00c0: 949b c4e3 46b9 6956 1e91 3ed5 1d48 72cb ....F.iV..>..Hr. 00d0: 33a6 95b6 09e8 b104 28be a1cb 14a3 5d7d 3.......(.....]} 00e0: 8c14 2a8d 3aa9 d90c 2e81 cc05 bd00 9a51 ..*.:..........Q 00f0: 8916 3375 1cf6 66ab 4fe7 4d8b bcbf 6ccc ..3u..f.O.M...l. 0100: 957b 3100 e4bb b0c8 e5cc c8ca 3b08 34dd .{1.........;.4. 0110: 66b6 913f c38a 746e f62d dbe2 a6e5 5fd8 f..?..tn.-...._. 0120: 5afb b977 1fe4 470d 78ba 6cbc e7a9 9553 Z..w..G.x.l....S 0130: 0889 7e9a ee26 0542 1494 e1fd cb50 f581 ..~..&.B.....P.. 0140: 9aa6 19ab ba09 30a2 ca23 2922 91d3 fce0 ......0..#)".... 0150: 3f32 ec5f 819b f142 e449 ad07 8d49 2263 ?2._...B.I...I"c 0160: cafa 491d e743 ad15 4a49 d72b 6562 98a4 ..I..C..JI.+eb.. 0170: 81b6 3081 b3a0 0302 0101 a281 ab04 81a8 ..0............. 0180: 1dad 9916 ee93 d883 6ca4 146e eef3 2854 ........l..n..(T 0190: 1b11 06f1 2866 e976 7f78 8caa 130b 6d39 ....(f.v.x....m9 01a0: aba4 395e 4a3d e631 29a4 ce7c afd8 bd18 ..9^J=.1)..|.... 01b0: 7507 47c8 5cc6 e6d4 aabd 0512 1cd1 61ad u.G.\.........a. 01c0: 8b14 e64e b45b 6679 4381 820c 2a68 d396 ...N.[fyC...*h.. 01d0: d971 7a92 e289 bd99 170b 3b96 88ac 2ed7 .qz.......;..... 01e0: db03 e594 3624 8658 29be 3dc8 b415 9801 ....6$.X).=..... 01f0: ba9e 5363 d223 8b6d fb9f 9f41 6fe6 5d99 ..Sc.#.m...Ao.]. 0200: 2cf4 6749 5204 7f50 9695 6ff1 7346 ab69 ,.gIR..P..o.sF.i 0210: ab51 0ca3 7287 bb79 5ef0 a1f2 3e1c 83b0 .Q..r..y^...>... 0220: 0cc1 cf39 fc82 8764 ...9...d rpcsec_gss: in authgss_marshal() rpcsec_gss: xdr_rpc_gss_buf: encode success ((nil):0) rpcsec_gss: xdr_rpc_gss_cred: encode success (v 1, proc 1, seq 0, svc 1, ctx (nil):0) rpcsec_gss: xdr_rpc_gss_buf: encode success (0x1a332c0:552) rpcsec_gss: xdr_rpc_gss_init_args: encode success (token 0x1a332c0:552) rpcsec_gss: in authgss_validate() rpcsec_gss: xdr_rpc_gss_buf: decode success (0x1a33050:4) rpcsec_gss: xdr_rpc_gss_buf: decode success (0x1a0d100:114) rpcsec_gss: xdr_rpc_gss_init_res decode success (ctx 0x1a33050:4, maj 524288, min 0, win 128, token 0x1a0d100:114) authgss_create_default: freeing name 0x1a0d890 WARNING: Failed to create krb5 context for user with uid 0 for server loubianka.zarb.home WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_ZARB.HOME for server loubianka.zarb.home WARNING: Failed to create machine krb5 context with any credentials cache for server loubianka.zarb.home doing error downcall destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt38 destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt37 [-- Attachment #3: server.out --] [-- Type: text/plain, Size: 7919 bytes --] entering poll leaving poll handling null request sname = nfs/beria.zarb.home@ZARB.HOME DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall mech: krb5, hndl len: 4, ctx len 85, timeout: 1273786282 (86368 from now), clnt: nfs@beria.zarb.home, uid: -1, gid: -1, num aux grps: 0: : qword_eol: fflush failed: errno 95 (Operation not supported) WARNING: error writing to downcall channel /proc/net/rpc/auth.rpcsec.context/channel: Operation not supported sending null reply writing message: \x \x6082022406092a864886f71201020201006e8202133082020fa003020105a10302010ea20703050020000000a382013f6182013b30820137a003020105a10b1b095a4152422e484f4d45a2253023a003020103a11c301a1b036e66731b136c6f756269616e6b612e7a6172622e686f6d65a381fb3081f8a003020101a103020102a281eb0481e8f147ea9d87f2a69ac17f6268886ca4d4b4b49b23e1c66b98e327a7dbdafad7f94a0ef88f6875d136986d72a5171d233f01deb76e38ff04c85f69deb82f4c6429c07c682d7b01119f7a8cd31cb6082666dc008396cb8fc04023821164537ee775b989d65707f67d9ff88a9c2d35e6faef9f286c50d75248123f5eb9f333792c5e8e6d68e54aab748cea1beb87e1636749c918d3e9073eedb36cb8d8fce5a3e5e6ec7a02d4017290ba2bfbeff75e4dfda5717c5ec3dfe63d3875c9b1c905490dba2457b8264729691526a58aade0773cd91bd66489a3fc159cb645d1e0dfd36eaab80eff251261ec84a481b63081b3a003020101a281ab0481a860e34f864e6b135c060cc54b265e6cb489df0f8c592ed1057ff77245b9fd4edd1c84e6bdc14da6133993e58e8657893c36af8f39f6e98eb7f4ad3542662d9477344e58fe73e94fa74a97f58c2018e1703f1aa1481dd97a8ea067aa57a447a565f6344007cf74068757b8992209772fdfb5e4dbac8cf3381be336e410e2513b9c3b96bad26c761af72f010bc0a5208ccbbfac1b50c6e8e6491a3cdea8f3bdb6768fd5dba099fcd4bb 1273699974 0 0 \x01000000 \x607006092a864886f71201020202006f61305fa003020105a10302010fa2533051a003020101a24a0448cba3a2be2aea1045e13550745c947c13328798420d87e7b68107aa1eaddc686e92265a4277550af4a6658aad21b7ab1993c1f9fa503581a8eaa12f5648582100259cb1f633bfea10 finished handling null request entering poll leaving poll handling null request sname = nfs/beria.zarb.home@ZARB.HOME DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall mech: krb5, hndl len: 4, ctx len 85, timeout: 1273786282 (86368 from now), clnt: nfs@beria.zarb.home, uid: -1, gid: -1, num aux grps: 0: : qword_eol: fflush failed: errno 95 (Operation not supported) WARNING: error writing to downcall channel /proc/net/rpc/auth.rpcsec.context/channel: Operation not supported sending null reply writing message: \x \x6082022406092a864886f71201020201006e8202133082020fa003020105a10302010ea20703050020000000a382013f6182013b30820137a003020105a10b1b095a4152422e484f4d45a2253023a003020103a11c301a1b036e66731b136c6f756269616e6b612e7a6172622e686f6d65a381fb3081f8a003020101a103020102a281eb0481e8f147ea9d87f2a69ac17f6268886ca4d4b4b49b23e1c66b98e327a7dbdafad7f94a0ef88f6875d136986d72a5171d233f01deb76e38ff04c85f69deb82f4c6429c07c682d7b01119f7a8cd31cb6082666dc008396cb8fc04023821164537ee775b989d65707f67d9ff88a9c2d35e6faef9f286c50d75248123f5eb9f333792c5e8e6d68e54aab748cea1beb87e1636749c918d3e9073eedb36cb8d8fce5a3e5e6ec7a02d4017290ba2bfbeff75e4dfda5717c5ec3dfe63d3875c9b1c905490dba2457b8264729691526a58aade0773cd91bd66489a3fc159cb645d1e0dfd36eaab80eff251261ec84a481b63081b3a003020101a281ab0481a8c6dff980a14e5a4fabc3e8578adf1984884005392e43e4835b75129503e56c5e7276a80c4b03280b57645b6443a588f61ece121f62d2dc8e14d6af4dcbd2a57a5d32f010656678f432e54e6ce5150ae3938a8a5f76c4f17274bfa9314620f0f32a66ac4d84f014a653b237f035e65efbba1f7b1193a65e5d305ab60ccea21da4be2d7da64be91d4b9fcd1b9dd7ef6afcde6acd77e89477a652bc2fce94d529c6252deefffa2faa2c 1273699974 0 0 \x02000000 \x607006092a864886f71201020202006f61305fa003020105a10302010fa2533051a003020101a24a0448b34692835c0e0a2ab0d9503e7a9684738be89813e3701d039511146c6c471d69dbfbd624dd43a0537cb25d60511040baf656ae60da28b34fd77bdd46326b3b460b28e439f5663954 finished handling null request entering poll leaving poll handling null request sname = nfs/beria.zarb.home@ZARB.HOME DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall mech: krb5, hndl len: 4, ctx len 85, timeout: 1273786473 (86401 from now), clnt: nfs@beria.zarb.home, uid: -1, gid: -1, num aux grps: 0: : qword_eol: fflush failed: errno 95 (Operation not supported) WARNING: error writing to downcall channel /proc/net/rpc/auth.rpcsec.context/channel: Operation not supported sending null reply writing message: \x \x6082022406092a864886f71201020201006e8202133082020fa003020105a10302010ea20703050020000000a382013f6182013b30820137a003020105a10b1b095a4152422e484f4d45a2253023a003020103a11c301a1b036e66731b136c6f756269616e6b612e7a6172622e686f6d65a381fb3081f8a003020101a103020102a281eb0481e825b1587e3be709a61a82c48f6ca74198858c0b634ca32cf09102f18ecfb46cd7dc5ef1a9493ef4b7c72a45f1deff723ab882393aae1ac3fb19949bc4e346b969561e913ed51d4872cb33a695b609e8b10428bea1cb14a35d7d8c142a8d3aa9d90c2e81cc05bd009a51891633751cf666ab4fe74d8bbcbf6ccc957b3100e4bbb0c8e5ccc8ca3b0834dd66b6913fc38a746ef62ddbe2a6e55fd85afbb9771fe4470d78ba6cbce7a9955308897e9aee2605421494e1fdcb50f5819aa619abba0930a2ca23292291d3fce03f32ec5f819bf142e449ad078d492263cafa491de743ad154a49d72b656298a481b63081b3a003020101a281ab0481a83ad349a224435f54c8cbfd042c66279b58bd522e5e9ec0e0f7b0e32dc1b82a93da22569d3290bbcde7ed2b84812d20229f06b6f9bef253cd4760b28c7029445659f9057bcbce5dc25aab69796519a6b3c5e1f57523e81b16e0085d912dd18a97ed532b9ac9e653ab59f0928b8fc7a19d3f8a050efba9c929ca86494093fd1205a21e077ed0359f0f72bd1928885e45ef47f0f627cc585b3555d4317513900e9ec558932048bbee96 1273700132 0 0 \x03000000 \x607006092a864886f71201020202006f61305fa003020105a10302010fa2533051a003020101a24a04485eea3ec8d3a72acdbad4238ce5d2ad72880de63fd814140df70591d5d391ac24c3cae241a4bf5ab21473cc2850daedd24185acf0e8daa696fbde56590b9c50d105676c7b0fc1d2b6 finished handling null request entering poll leaving poll handling null request sname = nfs/beria.zarb.home@ZARB.HOME DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall mech: krb5, hndl len: 4, ctx len 85, timeout: 1273786473 (86401 from now), clnt: nfs@beria.zarb.home, uid: -1, gid: -1, num aux grps: 0: : qword_eol: fflush failed: errno 95 (Operation not supported) WARNING: error writing to downcall channel /proc/net/rpc/auth.rpcsec.context/channel: Operation not supported sending null reply writing message: \x \x6082022406092a864886f71201020201006e8202133082020fa003020105a10302010ea20703050020000000a382013f6182013b30820137a003020105a10b1b095a4152422e484f4d45a2253023a003020103a11c301a1b036e66731b136c6f756269616e6b612e7a6172622e686f6d65a381fb3081f8a003020101a103020102a281eb0481e825b1587e3be709a61a82c48f6ca74198858c0b634ca32cf09102f18ecfb46cd7dc5ef1a9493ef4b7c72a45f1deff723ab882393aae1ac3fb19949bc4e346b969561e913ed51d4872cb33a695b609e8b10428bea1cb14a35d7d8c142a8d3aa9d90c2e81cc05bd009a51891633751cf666ab4fe74d8bbcbf6ccc957b3100e4bbb0c8e5ccc8ca3b0834dd66b6913fc38a746ef62ddbe2a6e55fd85afbb9771fe4470d78ba6cbce7a9955308897e9aee2605421494e1fdcb50f5819aa619abba0930a2ca23292291d3fce03f32ec5f819bf142e449ad078d492263cafa491de743ad154a49d72b656298a481b63081b3a003020101a281ab0481a81dad9916ee93d8836ca4146eeef328541b1106f12866e9767f788caa130b6d39aba4395e4a3de63129a4ce7cafd8bd18750747c85cc6e6d4aabd05121cd161ad8b14e64eb45b66794381820c2a68d396d9717a92e289bd99170b3b9688ac2ed7db03e5943624865829be3dc8b4159801ba9e5363d2238b6dfb9f9f416fe65d992cf4674952047f5096956ff17346ab69ab510ca37287bb795ef0a1f23e1c83b00cc1cf39fc828764 1273700132 0 0 \x04000000 \x607006092a864886f71201020202006f61305fa003020105a10302010fa2533051a003020101a24a04489b34d71277a39e36a8c5733778e89320f138ca15024a65803b9f91283ee321267f3424e183282c31c386c4a34f64c6e89400b58122a036b98176f3ee658dd1a0af1d83f9cef6bd87 finished handling null request entering poll ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: trouble using kerberos between linux client and server 2010-05-12 21:37 ` Guillaume Rousse @ 2010-05-12 23:21 ` Kevin Coffman [not found] ` <AANLkTinNTYrEe9G6urXBxv-hogZPatOe9zWbbjnVTbWz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 9+ messages in thread From: Kevin Coffman @ 2010-05-12 23:21 UTC (permalink / raw) To: Guillaume Rousse; +Cc: linux-nfs On Wed, May 12, 2010 at 5:37 PM, Guillaume Rousse <Guillaume.Rousse@inria.fr> wrote: > Le 05/05/2010 23:18, Guillaume Rousse a écrit : >> I'm attaching network capture, even I can't figure additional >> information from it by myself. > Reading https://bugzilla.redhat.com/show_bug.cgi?id=562807, I rebuild > libtirpc with patch applied and -DDEBUG. Unfortunatly, it doesn't bring > additional information about the server-side failure :( It looks to me like fflush(), called in qword_eol(), may be returning the number of bytes flushed (95) rather than zero for success? I don't immediately see any changes that would cause this. But I haven't looked extensively... K.C. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <AANLkTinNTYrEe9G6urXBxv-hogZPatOe9zWbbjnVTbWz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: trouble using kerberos between linux client and server [not found] ` <AANLkTinNTYrEe9G6urXBxv-hogZPatOe9zWbbjnVTbWz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-05-13 9:09 ` Guillaume Rousse 2010-05-13 12:55 ` Kevin Coffman 0 siblings, 1 reply; 9+ messages in thread From: Guillaume Rousse @ 2010-05-13 9:09 UTC (permalink / raw) To: Kevin Coffman; +Cc: linux-nfs Le 13/05/2010 01:21, Kevin Coffman a =E9crit : > On Wed, May 12, 2010 at 5:37 PM, Guillaume Rousse > <Guillaume.Rousse-MZpvjPyXg2s@public.gmane.org> wrote: >> Le 05/05/2010 23:18, Guillaume Rousse a =E9crit : >>> I'm attaching network capture, even I can't figure additional >>> information from it by myself. >> Reading https://bugzilla.redhat.com/show_bug.cgi?id=3D562807, I rebu= ild >> libtirpc with patch applied and -DDEBUG. Unfortunatly, it doesn't br= ing >> additional information about the server-side failure :( >=20 > It looks to me like fflush(), called in qword_eol(), may be returning > the number of bytes flushed (95) rather than zero for success? I > don't immediately see any changes that would cause this. But I > haven't looked extensively... Not necessarily a change: I never used a kerberized server sofar, only clients. --=20 BOFH excuse #164: root rot ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: trouble using kerberos between linux client and server 2010-05-13 9:09 ` Guillaume Rousse @ 2010-05-13 12:55 ` Kevin Coffman 2010-05-13 21:13 ` Guillaume Rousse 0 siblings, 1 reply; 9+ messages in thread From: Kevin Coffman @ 2010-05-13 12:55 UTC (permalink / raw) To: Guillaume Rousse; +Cc: linux-nfs On Thu, May 13, 2010 at 5:09 AM, Guillaume Rousse <Guillaume.Rousse@inria.fr> wrote: > Le 13/05/2010 01:21, Kevin Coffman a écrit : >> On Wed, May 12, 2010 at 5:37 PM, Guillaume Rousse >> <Guillaume.Rousse@inria.fr> wrote: >>> Le 05/05/2010 23:18, Guillaume Rousse a écrit : >>>> I'm attaching network capture, even I can't figure additional >>>> information from it by myself. >>> Reading https://bugzilla.redhat.com/show_bug.cgi?id=562807, I rebuild >>> libtirpc with patch applied and -DDEBUG. Unfortunatly, it doesn't bring >>> additional information about the server-side failure :( >> >> It looks to me like fflush(), called in qword_eol(), may be returning >> the number of bytes flushed (95) rather than zero for success? I >> don't immediately see any changes that would cause this. But I >> haven't looked extensively... > Not necessarily a change: I never used a kerberized server sofar, only > clients. Well, I've not seen that issue before, so I assumed it was a change. I looked back a bit, but didn't see: what versions of nfs-utils and kernel are on the server? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: trouble using kerberos between linux client and server 2010-05-13 12:55 ` Kevin Coffman @ 2010-05-13 21:13 ` Guillaume Rousse 2010-08-14 15:11 ` Guillaume Rousse 0 siblings, 1 reply; 9+ messages in thread From: Guillaume Rousse @ 2010-05-13 21:13 UTC (permalink / raw) To: Kevin Coffman; +Cc: linux-nfs Le 13/05/2010 14:55, Kevin Coffman a écrit : > On Thu, May 13, 2010 at 5:09 AM, Guillaume Rousse > <Guillaume.Rousse@inria.fr> wrote: >> Le 13/05/2010 01:21, Kevin Coffman a écrit : >>> On Wed, May 12, 2010 at 5:37 PM, Guillaume Rousse >>> <Guillaume.Rousse@inria.fr> wrote: >>>> Le 05/05/2010 23:18, Guillaume Rousse a écrit : >>>>> I'm attaching network capture, even I can't figure additional >>>>> information from it by myself. >>>> Reading https://bugzilla.redhat.com/show_bug.cgi?id=562807, I rebuild >>>> libtirpc with patch applied and -DDEBUG. Unfortunatly, it doesn't bring >>>> additional information about the server-side failure :( >>> >>> It looks to me like fflush(), called in qword_eol(), may be returning >>> the number of bytes flushed (95) rather than zero for success? I >>> don't immediately see any changes that would cause this. But I >>> haven't looked extensively... >> Not necessarily a change: I never used a kerberized server sofar, only >> clients. > > Well, I've not seen that issue before, so I assumed it was a change. > I looked back a bit, but didn't see: what versions of nfs-utils and > kernel are on the server? The same on both sides: kernel 2.6.33.3 + nfs-utils 1.2.2 I just rebuild nfs-utils with -DDEBUG flag, here is the trace: [root@loubianka ~]# rpc.svcgssd -f -vvvvv entering poll leaving poll handling null request in_handle (length 0) in_tok (length 552) 0000: 6082 0224 0609 2a86 4886 f712 0102 0201 `..$..*.H....... 0010: 006e 8202 1330 8202 0fa0 0302 0105 a103 .n...0.......... 0020: 0201 0ea2 0703 0500 2000 0000 a382 013f ........ ......? 0030: 6182 013b 3082 0137 a003 0201 05a1 0b1b a..;0..7........ 0040: 095a 4152 422e 484f 4d45 a225 3023 a003 .ZARB.HOME.%0#.. 0050: 0201 03a1 1c30 1a1b 036e 6673 1b13 6c6f .....0...nfs..lo 0060: 7562 6961 6e6b 612e 7a61 7262 2e68 6f6d ubianka.zarb.hom 0070: 65a3 81fb 3081 f8a0 0302 0101 a103 0201 e...0........... 0080: 02a2 81eb 0481 e87f 7aab 72a5 f0c5 3967 ........z.r...9g 0090: ad82 1f96 8e90 1ba3 a540 030d 4da0 73b4 .........@..M.s. 00a0: 5dc1 8226 0658 2907 11b6 7a2d e763 2809 ]..&.X)...z-.c(. 00b0: e7d5 d12e ebd3 956b fe6d 4b7e 9e88 ca23 .......k.mK~...# 00c0: d503 7516 ced5 819f fc9a 1381 e890 2459 ..u...........$Y 00d0: 712c c035 7e37 f797 faff d4d5 5980 6d04 q,.5~7......Y.m. 00e0: 1881 ac03 a997 0cca 10ea 3f00 070a 70e6 ..........?...p. 00f0: d86c b1cf 0fe7 e4c2 a1bb a91c 0165 73f2 .l...........es. 0100: 6e88 d676 d5d9 2f69 0b84 ea33 9ac8 13ce n..v../i...3.... 0110: d014 2977 ce2b 5154 e7a8 22df 34d2 f32f ..)w.+QT..".4../ 0120: 6de7 f18f 2fcf 3f1d f503 aa36 cc0f 1c37 m.../.?....6...7 0130: 251b 784e 4187 218b df0f b276 e3a3 09c6 %.xNA.!....v.... 0140: 27bc 1776 b54d 7295 a432 16f9 d1fe 7766 '..v.Mr..2....wf 0150: c588 48ac 6657 8c86 a1c7 f7bf f2fb 6945 ..H.fW........iE 0160: 2f51 661f b7a9 b8d1 c7ea 9667 0928 f1a4 /Qf........g.(.. 0170: 81b6 3081 b3a0 0302 0101 a281 ab04 81a8 ..0............. 0180: 0996 dd55 17a9 25be e6d9 fc11 1ae2 f460 ...U..%........` 0190: 2fa2 46f2 cf1b 710b 2f83 2c94 93b0 f0d4 /.F...q./.,..... 01a0: 9ae9 ae94 bbb7 2a9f 7c91 db19 d107 f3ea ......*.|....... 01b0: afeb 8f92 4575 2f4f 5a8e 3616 5ffe ae76 ....Eu/OZ.6._..v 01c0: 1f96 ecfe bf2d 499e f140 3d91 b68c e4f1 .....-I..@=..... 01d0: b24d f1b6 2057 0ce1 471d b9fb d7b9 44fc .M.. W..G.....D. 01e0: 24f5 9757 1374 8c93 d7fb 1786 a3bc bc81 $..W.t.......... 01f0: 4877 ac8e 19eb 7269 6478 d9b5 72b9 4c54 Hw....ridx..r.LT 0200: 5357 8cf0 9610 8a3d 71de 809e bddd 1fd7 SW.....=q....... 0210: ee05 3501 3750 4146 c9db 7976 a973 623e ..5.7PAF..yv.sb> 0220: 87d6 2337 cdcb cb40 ..#7...@ sname = nfs/beria.zarb.home@ZARB.HOME DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall mech: krb5, hndl len: 4, ctx len 85, timeout: 1273870075 (84939 from now), clnt: nfs@beria.zarb.home, uid: -1, gid: -1, num aux grps: 0: : qword_eol: fflush failed: errno 95 (Operation not supported) WARNING: error writing to downcall channel /proc/net/rpc/auth.rpcsec.context/channel: Operation not supported sending null reply writing message: \x \x6082022406092a864886f71201020201006e8202133082020fa003020105a10302010ea20703050020000000a382013f6182013b30820137a003020105a10b1b095a4152422e484f4d45a2253023a003020103a11c301a1b036e66731b136c6f756269616e6b612e7a6172622e686f6d65a381fb3081f8a003020101a103020102a281eb0481e87f7aab72a5f0c53967ad821f968e901ba3a540030d4da073b45dc182260658290711b67a2de7632809e7d5d12eebd3956bfe6d4b7e9e88ca23d5037516ced5819ffc9a1381e8902459712cc0357e37f797faffd4d559806d041881ac03a9970cca10ea3f00070a70e6d86cb1cf0fe7e4c2a1bba91c016573f26e88d676d5d92f690b84ea339ac813ced0142977ce2b5154e7a822df34d2f32f6de7f18f2fcf3f1df503aa36cc0f1c37251b784e4187218bdf0fb276e3a309c627bc1776b54d7295a43216f9d1fe7766c58848ac66578c86a1c7f7bff2fb69452f51661fb7a9b8d1c7ea96670928f1a481b63081b3a003020101a281ab0481a80996dd5517a925bee6d9fc111ae2f4602fa246f2cf1b710b2f832c9493b0f0d49ae9ae94bbb72a9f7c91db19d107f3eaafeb8f9245752f4f5a8e36165ffeae761f96ecfebf2d499ef1403d91b68ce4f1b24df1b620570ce1471db9fbd7b944fc24f5975713748c93d7fb1786a3bc bc814877ac8e19eb72696478d9b572b94c5453578cf096108a3d71de809ebddd1fd7ee05350137504146c9db7976a973623e87d62337cdcbcb40 1273785196 0 0 \x01000000 \x607006092a864886f71201020202006f61305fa003020105a10302010fa2533051a003020101a24a0448ba282fe905b53fbd556c771446c691f46c3879fed41f67dc822fc13bccf60d9c4020181a1de4a2ca4da7f52fd89b68f1d1e266eb5c38305eb4e12af5cc675ead822c35c1fb7639b5 finished handling null request entering poll leaving poll handling null request in_handle (length 0) in_tok (length 552) 0000: 6082 0224 0609 2a86 4886 f712 0102 0201 `..$..*.H....... 0010: 006e 8202 1330 8202 0fa0 0302 0105 a103 .n...0.......... 0020: 0201 0ea2 0703 0500 2000 0000 a382 013f ........ ......? 0030: 6182 013b 3082 0137 a003 0201 05a1 0b1b a..;0..7........ 0040: 095a 4152 422e 484f 4d45 a225 3023 a003 .ZARB.HOME.%0#.. 0050: 0201 03a1 1c30 1a1b 036e 6673 1b13 6c6f .....0...nfs..lo 0060: 7562 6961 6e6b 612e 7a61 7262 2e68 6f6d ubianka.zarb.hom 0070: 65a3 81fb 3081 f8a0 0302 0101 a103 0201 e...0........... 0080: 02a2 81eb 0481 e87f 7aab 72a5 f0c5 3967 ........z.r...9g 0090: ad82 1f96 8e90 1ba3 a540 030d 4da0 73b4 .........@..M.s. 00a0: 5dc1 8226 0658 2907 11b6 7a2d e763 2809 ]..&.X)...z-.c(. 00b0: e7d5 d12e ebd3 956b fe6d 4b7e 9e88 ca23 .......k.mK~...# 00c0: d503 7516 ced5 819f fc9a 1381 e890 2459 ..u...........$Y 00d0: 712c c035 7e37 f797 faff d4d5 5980 6d04 q,.5~7......Y.m. 00e0: 1881 ac03 a997 0cca 10ea 3f00 070a 70e6 ..........?...p. 00f0: d86c b1cf 0fe7 e4c2 a1bb a91c 0165 73f2 .l...........es. 0100: 6e88 d676 d5d9 2f69 0b84 ea33 9ac8 13ce n..v../i...3.... 0110: d014 2977 ce2b 5154 e7a8 22df 34d2 f32f ..)w.+QT..".4../ 0120: 6de7 f18f 2fcf 3f1d f503 aa36 cc0f 1c37 m.../.?....6...7 0130: 251b 784e 4187 218b df0f b276 e3a3 09c6 %.xNA.!....v.... 0140: 27bc 1776 b54d 7295 a432 16f9 d1fe 7766 '..v.Mr..2....wf 0150: c588 48ac 6657 8c86 a1c7 f7bf f2fb 6945 ..H.fW........iE 0160: 2f51 661f b7a9 b8d1 c7ea 9667 0928 f1a4 /Qf........g.(.. 0170: 81b6 3081 b3a0 0302 0101 a281 ab04 81a8 ..0............. 0180: 2fc0 6153 e878 e685 d5dc f447 ab2a 37b8 /.aS.x.....G.*7. 0190: f1be d30e edb6 dbdc c549 9fbc f58c abe7 .........I...... 01a0: 9b70 8efc 1588 c362 9bac 5c44 8cc5 72e1 .p.....b..\D..r. 01b0: 3f22 3726 b144 9303 52cd 9c75 dc65 5671 ?"7&.D..R..u.eVq 01c0: cd2b dc52 9d7f 9d21 ab87 b01e 35bb 1655 .+.R...!....5..U 01d0: 7ba6 cdc5 3d14 d82b 5140 7831 2cc4 ce9b {...=..+Q@x1,... 01e0: eb42 4614 2b8b 5ce4 0ffe 160f 85ef 0d9a .BF.+.\......... 01f0: 84d3 aa5f 3360 2557 120c 1f80 b7fc edaf ..._3`%W........ 0200: fb93 64df 137b f16d 60c6 b7f8 4e50 f582 ..d..{.m`...NP.. 0210: 6f59 88f4 13c0 0507 8fb7 e176 2c0b 17a1 oY.........v,... 0220: b1f3 005f 089d 8560 ..._...` sname = nfs/beria.zarb.home@ZARB.HOME DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall mech: krb5, hndl len: 4, ctx len 85, timeout: 1273870075 (84939 from now), clnt: nfs@beria.zarb.home, uid: -1, gid: -1, num aux grps: 0: : qword_eol: fflush failed: errno 95 (Operation not supported) WARNING: error writing to downcall channel /proc/net/rpc/auth.rpcsec.context/channel: Operation not supported sending null reply writing message: \x \x6082022406092a864886f71201020201006e8202133082020fa003020105a10302010ea20703050020000000a382013f6182013b30820137a003020105a10b1b095a4152422e484f4d45a2253023a003020103a11c301a1b036e66731b136c6f756269616e6b612e7a6172622e686f6d65a381fb3081f8a003020101a103020102a281eb0481e87f7aab72a5f0c53967ad821f968e901ba3a540030d4da073b45dc182260658290711b67a2de7632809e7d5d12eebd3956bfe6d4b7e9e88ca23d5037516ced5819ffc9a1381e8902459712cc0357e37f797faffd4d559806d041881ac03a9970cca10ea3f00070a70e6d86cb1cf0fe7e4c2a1bba91c016573f26e88d676d5d92f690b84ea339ac813ced0142977ce2b5154e7a822df34d2f32f6de7f18f2fcf3f1df503aa36cc0f1c37251b784e4187218bdf0fb276e3a309c627bc1776b54d7295a43216f9d1fe7766c58848ac66578c86a1c7f7bff2fb69452f51661fb7a9b8d1c7ea96670928f1a481b63081b3a003020101a281ab0481a82fc06153e878e685d5dcf447ab2a37b8f1bed30eedb6dbdcc5499fbcf58cabe79b708efc1588c3629bac5c448cc572e13f223726b144930352cd9c75dc655671cd2bdc529d7f9d21ab87b01e35bb16557ba6cdc53d14d82b514078312cc4ce9beb4246142b8b5ce40ffe160f85ef 0d9a84d3aa5f33602557120c1f80b7fcedaffb9364df137bf16d60c6b7f84e50f5826f5988f413c005078fb7e1762c0b17a1b1f3005f089d8560 1273785196 0 0 \x02000000 \x607006092a864886f71201020202006f61305fa003020105a10302010fa2533051a003020101a24a0448dda178816b2563207402c75826cb9098f5bcc8d02b7f229f5316d047875a3bfc7643aa96dffae46a0b14c79ab55f2ad0419af006960bd444da016079fb3ec601414abbf1070e154a finished handling null request entering poll -- BOFH excuse #42: spaghetti cable cause packet failure ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: trouble using kerberos between linux client and server 2010-05-13 21:13 ` Guillaume Rousse @ 2010-08-14 15:11 ` Guillaume Rousse 2010-08-17 17:45 ` J. Bruce Fields 2010-08-17 17:56 ` Kevin Coffman 0 siblings, 2 replies; 9+ messages in thread From: Guillaume Rousse @ 2010-08-14 15:11 UTC (permalink / raw) To: Kevin Coffman; +Cc: linux-nfs [-- Attachment #1: Type: text/plain, Size: 1639 bytes --] Le 13/05/2010 23:13, Guillaume Rousse a écrit : > Le 13/05/2010 14:55, Kevin Coffman a écrit : >> On Thu, May 13, 2010 at 5:09 AM, Guillaume Rousse >> <Guillaume.Rousse@inria.fr> wrote: >>> Le 13/05/2010 01:21, Kevin Coffman a écrit : >>>> On Wed, May 12, 2010 at 5:37 PM, Guillaume Rousse >>>> <Guillaume.Rousse@inria.fr> wrote: >>>>> Le 05/05/2010 23:18, Guillaume Rousse a écrit : >>>>>> I'm attaching network capture, even I can't figure additional >>>>>> information from it by myself. >>>>> Reading https://bugzilla.redhat.com/show_bug.cgi?id=562807, I rebuild >>>>> libtirpc with patch applied and -DDEBUG. Unfortunatly, it doesn't bring >>>>> additional information about the server-side failure :( >>>> >>>> It looks to me like fflush(), called in qword_eol(), may be returning >>>> the number of bytes flushed (95) rather than zero for success? I >>>> don't immediately see any changes that would cause this. But I >>>> haven't looked extensively... >>> Not necessarily a change: I never used a kerberized server sofar, only >>> clients. >> >> Well, I've not seen that issue before, so I assumed it was a change. >> I looked back a bit, but didn't see: what versions of nfs-utils and >> kernel are on the server? > The same on both sides: kernel 2.6.33.3 + nfs-utils 1.2.2 Hello. I finally managed to understand the issue: I also need rpc.svcgssd _and_ rpc.gssd on server side, whereas I thought rpc.gssd was needed on client side only (http://wiki.linux-nfs.org/wiki/index.php/Enduser_doc_kerberos). Is this expected behaviour ? -- BOFH excuse #255: Standing room only on the bus. [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4251 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: trouble using kerberos between linux client and server 2010-08-14 15:11 ` Guillaume Rousse @ 2010-08-17 17:45 ` J. Bruce Fields 2010-08-17 17:56 ` Kevin Coffman 1 sibling, 0 replies; 9+ messages in thread From: J. Bruce Fields @ 2010-08-17 17:45 UTC (permalink / raw) To: Guillaume Rousse; +Cc: Kevin Coffman, linux-nfs On Sat, Aug 14, 2010 at 05:11:03PM +0200, Guillaume Rousse wrote: > Le 13/05/2010 23:13, Guillaume Rousse a écrit : > > Le 13/05/2010 14:55, Kevin Coffman a écrit : > >> On Thu, May 13, 2010 at 5:09 AM, Guillaume Rousse > >> <Guillaume.Rousse@inria.fr> wrote: > >>> Le 13/05/2010 01:21, Kevin Coffman a écrit : > >>>> On Wed, May 12, 2010 at 5:37 PM, Guillaume Rousse > >>>> <Guillaume.Rousse@inria.fr> wrote: > >>>>> Le 05/05/2010 23:18, Guillaume Rousse a écrit : > >>>>>> I'm attaching network capture, even I can't figure additional > >>>>>> information from it by myself. > >>>>> Reading https://bugzilla.redhat.com/show_bug.cgi?id=562807, I rebuild > >>>>> libtirpc with patch applied and -DDEBUG. Unfortunatly, it doesn't bring > >>>>> additional information about the server-side failure :( > >>>> > >>>> It looks to me like fflush(), called in qword_eol(), may be returning > >>>> the number of bytes flushed (95) rather than zero for success? I > >>>> don't immediately see any changes that would cause this. But I > >>>> haven't looked extensively... > >>> Not necessarily a change: I never used a kerberized server sofar, only > >>> clients. > >> > >> Well, I've not seen that issue before, so I assumed it was a change. > >> I looked back a bit, but didn't see: what versions of nfs-utils and > >> kernel are on the server? > > The same on both sides: kernel 2.6.33.3 + nfs-utils 1.2.2 > Hello. > > I finally managed to understand the issue: I also need rpc.svcgssd _and_ > rpc.gssd on server side, whereas I thought rpc.gssd was needed on client > side only > (http://wiki.linux-nfs.org/wiki/index.php/Enduser_doc_kerberos). Is this > expected behaviour ? If you want krb5 callbacks to work (for example, if you want delegations to be granted when using krb5 with NFSv4.0), then rpc.gssd needs to be run on the server. If rpc.gssd isn't running on the server, then I'd expect the only symptom to be that delegations aren't given out; if you're seeing a more serious failure than that, then that's a bug. --b. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: trouble using kerberos between linux client and server 2010-08-14 15:11 ` Guillaume Rousse 2010-08-17 17:45 ` J. Bruce Fields @ 2010-08-17 17:56 ` Kevin Coffman 1 sibling, 0 replies; 9+ messages in thread From: Kevin Coffman @ 2010-08-17 17:56 UTC (permalink / raw) To: Guillaume Rousse; +Cc: linux-nfs On Sat, Aug 14, 2010 at 11:11 AM, Guillaume Rousse <Guillaume.Rousse@inria.fr> wrote: > Le 13/05/2010 23:13, Guillaume Rousse a écrit : >> Le 13/05/2010 14:55, Kevin Coffman a écrit : >>> On Thu, May 13, 2010 at 5:09 AM, Guillaume Rousse >>> <Guillaume.Rousse@inria.fr> wrote: >>>> Le 13/05/2010 01:21, Kevin Coffman a écrit : >>>>> On Wed, May 12, 2010 at 5:37 PM, Guillaume Rousse >>>>> <Guillaume.Rousse@inria.fr> wrote: >>>>>> Le 05/05/2010 23:18, Guillaume Rousse a écrit : >>>>>>> I'm attaching network capture, even I can't figure additional >>>>>>> information from it by myself. >>>>>> Reading https://bugzilla.redhat.com/show_bug.cgi?id=562807, I rebuild >>>>>> libtirpc with patch applied and -DDEBUG. Unfortunatly, it doesn't bring >>>>>> additional information about the server-side failure :( >>>>> >>>>> It looks to me like fflush(), called in qword_eol(), may be returning >>>>> the number of bytes flushed (95) rather than zero for success? I >>>>> don't immediately see any changes that would cause this. But I >>>>> haven't looked extensively... >>>> Not necessarily a change: I never used a kerberized server sofar, only >>>> clients. >>> >>> Well, I've not seen that issue before, so I assumed it was a change. >>> I looked back a bit, but didn't see: what versions of nfs-utils and >>> kernel are on the server? >> The same on both sides: kernel 2.6.33.3 + nfs-utils 1.2.2 > Hello. > > I finally managed to understand the issue: I also need rpc.svcgssd _and_ > rpc.gssd on server side, whereas I thought rpc.gssd was needed on client > side only > (http://wiki.linux-nfs.org/wiki/index.php/Enduser_doc_kerberos). Is this > expected behaviour ? Wow, I'm glad you finally found it. rpc.svcgssd is always required on the server if you are using Kerberos. rpc.gssd is required on the server if you want delegations to work when using Kerberos (requires authenticated callback from the server to the client). It was my understanding that no ill effects should be seen if you do not run rpc.gssd on the server, you just wouldn't be able to give out delegations. However, I may be mis-remembering something. K.C. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-08-17 17:56 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4BCFE979.2000406@inria.fr>
2010-05-05 21:18 ` trouble using kerberos between linux client and server Guillaume Rousse
2010-05-12 21:37 ` Guillaume Rousse
2010-05-12 23:21 ` Kevin Coffman
[not found] ` <AANLkTinNTYrEe9G6urXBxv-hogZPatOe9zWbbjnVTbWz-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-05-13 9:09 ` Guillaume Rousse
2010-05-13 12:55 ` Kevin Coffman
2010-05-13 21:13 ` Guillaume Rousse
2010-08-14 15:11 ` Guillaume Rousse
2010-08-17 17:45 ` J. Bruce Fields
2010-08-17 17:56 ` Kevin Coffman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).