Re: [Savannah-hackers-public] download access for uploading files broken

[Bob Proulx]

> I have the solution! (i think).

Yay!

> This guy deserves a beer!
>  http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/

He did do a good write-up. :-)

> 1. Because we DO use "--manage-gids" in 
> download:/etc/default/nfs-kernel-server ,
> it means that rpc.mountd on download IGNORES the GIDs sent from download0
> and fetches the group-ids by itself.

Yes.  That is definitely true.

> Where do groups come from?
> MySQL on internal0 ! which was just rebooted!

Aha!

> Then, checking download:/var/log/daemon.log shows clearly:
> ===
> Feb 24 03:03:25 download mountd[4812]: libnss-mysql: Connection to server 
> '208.118.235.75' failed: Lost connection to MySQL server at 'reading initial 
> communication packet', system error: 113
> ===
> 
> and 208.118.235.75 is old 'internal' which was shutdown!

But, but, but, internal has been shutdown since November!  That is a
very long time for this to have been hanging out.

> so somehow, "rpc.mountd" running on old download didn't get the memo :)

That is the /etc/libnss-mysql.cfg and /etc/libnss-mysql-root.cfg
files.  But how could they have still be pointing to the old internal?
The database on internal has been shutdown since November and the
machine itself since January.  But certainly if it was pointing there
than that would have been a showstopper problem.

> And while other user-space programs on 'download' did use the correct mysql 
> on 'internal0',
> rpc.mountd did not! or at least, someone the reboot messed things up.
> 
> I would guess that perhaps just restarting rpc/nfs on download would fix it ??
> 
> But 'download' is too delicate for me to touch.
> Also: should the NFS on download0 be unmounted first?

I am fearful of rebooting download but I am good with restarting the
daemons there.  I just freed up to be able to work on this for a bit.
I will restart things there.

Thanks Assaf!  Good debugging work!

Bob