Bug#622146: Same thing happens against lenny nfs servers

Same thing here, against a Lenny nfs server. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4

Bug#622146: (Ugly/temp) workaround

:NORMAL host/lib (probably not needed, but just to stay on the ""safe"" side) HTH, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Ke

Bug#622146: nfs-common: compatibility between squeeze and sid broken

On Tue, Jun 07, 2011 at 01:10:23PM -0400, Sam Hartman wrote: > >>>>> "Luk" == Luk Claes writes: > > Luk> On 06/06/2011 05:37 PM, Alberto Gonzalez Iniesta wrote: > >> Adding the following line in the [libdefaults] section of > >>

Bug#622146: Not working...

) Or just with allow_weak_crypto No way to mount, with the known errors on the server. I'll play with this again in some days, sshfs will do the job for the time being. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software

Bug#622146: nfs-common: compatibility between squeeze and sid broken

$ grep weak /etc/krb5.conf allow_weak_crypto = yes And only the des-cbc-crc:normal key on this hosts' keytab. Regards, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail pref

Bug#675176: svcgssd not working with '-n' option after lenny to squeeze upgrade

May 30 13:06:12 rasca rpc.svcgssd[2761]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_BAD_NAME (An invalid name was supplied) - Unknown error May 30 13:06:12 rasca rpc.svcgssd[2761]: unable to obtain nameless credentials Thanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consult

Bug#675188: Change in rpc.idmapd makes clients unable to resolv users/groups

obably is, don't know the RFC). But it's not the way it used to behave. It would be nice to have a way to have rpc.idmapd report users and groups as it used to, in order to avoid modifying /etc/idmapd.conf in hundreds of nfs clients as well as introducing an extra attribute (for NFSv

Bug#559755: Is forcing users the way to go?

(just like many other software behaves on transitions) would be nicer to our users. Thanks, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key finger