Bug#924425: Patch

2019-05-20 Thread Michael Barkdoll
Ubuntu patched this, can Debian as well?  Package maintainer has been
unresponsive.

https://bugs.launchpad.net/debian/+source/libnfsidmap/+bug/1819197

Michael Barkdoll


Bug#924425: nfsidmap[]: nss_getpwname: nfs4_name_to_uid: final return value is -22

2019-03-12 Thread Michael Barkdoll
Package: libnfsidmap2
Version: 0.25-5.1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
AD realmd join machine unable to see `ls -lan` with proper user mapping.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Only thing that fixed it was upgrading libnfsidmap to version 0.26
   * What was the outcome of this action?
This fixed the isssue.
   * What outcome did you expect instead?
I expected to see proper username and group for file mapping on `ls -lan` 
instead I saw nobody was the owner.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnfsidmap2 depends on:
ii  libc6  2.24-11+deb9u4
ii  libldap-2.4-2  2.4.44+dfsg-5+deb9u2

libnfsidmap2 recommends no packages.

libnfsidmap2 suggests no packages.

-- no debconf information



Bug#924051: nfs-common: Krb5 NFSv4 Realmd AD nfsidmap files owned by nobody group 4294967294

2019-03-12 Thread Michael Barkdoll
I was able to find a solution to this issue that will require a
patch/update to the libnfsidmap version 0.26.

Please see reference to another user that experience the issue.

https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org/thread/SIA6J7IZRWX2FVGHKMS5F3HB7DE3MCFC/

I confirmed after custom compiling and using the newer lib's .so file that
the naming convention was normal.  One directory timed out when I did a
chown but after fixing the file permissions to a user inside AD it seems to
be working alright.

Can you please patch libnfsidmap to use version 0.26 to fix this bug?
Thanks!

Michael Barkdoll


Bug#924051: nfs-common: Krb5 NFSv4 Realmd AD nfsidmap files owned by nobody group 4294967294

2019-03-08 Thread Michael Barkdoll
Package: nfs-common
Version: 1:1.3.4-2.1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Debian box joined to AD with Realmd.  Mounted nfsv4 with kerberos auth.  
UID/GID match on client and server.  File permissions honored by displayed 
incorrected.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The following was observed in /var/log/syslog on the client:
nss_getpwnam: name 'us...@xx.xx.edu@XX.XX.EDU' domain 'XX.XX.EDU': resulting 
localname '(null)' 

uid and gid appear to not map properly from nfsidmap in a nfsv4 with sec=krb5. 
UID and GID are mapping properly on CentOS server and CentOS client. Ubuntu nfs 
client file permissions are honored, but display in `ls -lan` command are 
incorrect.

---
$ cat /var/log/syslog |grep nfsidmap
Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: key: 0x24a1c64d type: uid value: 
us...@xx.xx.edu@XX.XX.EDU timeout 600
Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: calling 
nsswitch->name_to_uid
Mar 8 16:38:34 client nfsidmap[24736]: nss_getpwnam: name 
'us...@xx.xx.edu@XX.XX.EDU' domain 'XX.XX.EDU': resulting localname '(null)'
Mar 8 16:38:34 client nfsidmap[24736]: nss_getpwnam: name 
'us...@xx.xx.edu@XX.XX.EDU' does not map into domain 'XX.XX.EDU'
Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: nsswitch->name_to_uid 
returned -22
Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: final return value is 
-22
Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: calling 
nsswitch->name_to_uid

$
$ mount -v -t nfs4 -o sec=krb5 SP19SRV.XX.XX.EDU:/export /mnt
$ su userX
$ ls -la /mnt
total 4
drwxr-xr-x 5 nobody 4294967294 50 Feb 28 18:04 .
drwxr-xr-x 24 root root 4096 Mar 7 22:34 ..
drwxr-xr-x 2 nobody 4294967294 125 Mar 8 16:27 userX
$



Problem:
nfsmapid isn't showing proper file permissions on the ubuntu nfsv4 client with 
sec=krb



Client:
---
mount -v -t nfs4 -o sec=krb5 SP19SRV.XX.XX.EDU:/export /mnt
---
$ ls -la
total 4
drwxr-xr-x 5 nobody 4294967294 50 Feb 28 18:04 .
drwxr-xr-x 24 root root 4096 Mar 7 20:58 ..
drwxr-xr-x 2 nobody 4294967294 112 Mar 7 14:30 username
usern...@xx.xx.edu@ubuntuclient:/mnt

---
$ cat /etc/idmapd.conf

[General]

Verbosity = 9
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if it differs from FQDN minus hostname
Domain = XX.XXX.EDU

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

---
$ cat /etc/default/nfs-common
STATDOPTS=
NEED_GSSD="yes"
NEED_IDMAPD="yes"
# I've tried commenting out NEED_IDMAPD as well.
# I manually created the following file with ktutil to just have nfs lines.
RPCGSSDARGS="-k /etc/nfs.keytab"
# I've tried with and without the above line (this was shown from redhat 
documentaiton)
---

My nfs server is a Centos 7.

Both machines were joined to active directory with sssd. NFSv4 with krb 
security works on my centos server and client. The nfs server mount works on 
the ubuntu client and file permissions are honored. But, the ls -la command is 
showing the incorrect file permissions.



uid and gid's appear to be in sync from sssd. Note in /etc/sssd/sssd.conf 
ldap_id_mapping = False though I don't think that should matter since ids are 
the same on both client and server from the ldap attributes in AD.



Centos 7 servers /var/log/messages with idmapd.conf verbosity:

Mar 8 16:38:32 sp19srv rpc.idmapd[1224]: Server : (group) id "65534" -> name 
"nfsnob...@xx.xx.edu"
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=user
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: calling 
nsswitch->uid_to_name
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: 
nsswitch->uid_to_name returned 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: final return value 
is 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: Server : (user) id "3872" -> name 
"us...@xx.xx.edu@XX.XX.EDU"
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=group
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: calling 
nsswitch->gid_to_name
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: 
nsswitch->gid_to_name returned 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: final return value 
is 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: Server : (group) id "110" -> name 
"some group g...@xx.xx.edu@XX.XX.EDU"
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=user
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: calling 
nsswitch->uid_to_name
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: 
nsswitch->uid_to_name returned 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: final return value 
is 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: Server : (user) id "0" -> name 
"r...@xx.xx.edu"
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=group
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: calling 

Bug#891410: upstream work is already in progress

2018-10-24 Thread Michael Barkdoll
On Sun, 07 Oct 2018 15:07:32 +0200 "Hein, Jochen" wrote:
> Hello again,
>
> Am 2018-07-02 21:05, schrieb Christoph Biedl:
> > Thanks for reminding me, it's on radar - but given the discussion
> > hasn't
> > been finished yet I'd prefer to wait until this is part of another
> > clevis release. If you'd like to have it cherry-picked so people can
> > start playing with it, let me know.
>
> Hm, the usptream discussion seems to have stalled. Since the
> freeze for buster is nearing I'd like to see it cherry-picked.
> What do you think?
>
> Jochen
>
> --
> The only problem with troubleshooting is that the trouble shoots back.
>
>

I'd also love to see this cherry-picked.


Michael Allen Barkdoll
Computer Systems Architecture Specialist
Office: 618-453-6051 | Email: mbarkd...@cs.siu.edu
**
Department of Computer Science, Southern Illinois University of Carbondale
Engineering A0311C, Mail Code 4511, 1230 Lincoln Drive, Carbondale, IL 62901
Main Office: 618-536-2327 | Fax: 618-453-6044 | Lab Assistants: 618-453-6052
**