Date: Sun, 14 May 2017 10:11:08 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: more default uid/gid for NFS in mountd Message-ID: <20170514071108.GK1188@zxy.spb.ru> In-Reply-To: <YTXPR01MB0189D5B7CADD42D195E9855BDDE00@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> References: <YTXPR01MB01895E8D60DD369C1762785DDDEE0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> <20170508134203.GA3165@zxy.spb.ru> <YTXPR01MB0189D5B7CADD42D195E9855BDDE00@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 14, 2017 at 01:12:11AM +0000, Rick Macklem wrote: > >> It is also the case that mountd.c doesn't look "nobody" up in the password database > >> to set the default. It would be nice to do this, but it could result in the mountd daemon > >> getting "stuck" during a boot waiting for an unresponsive LDAP service or similar. > >> Does doing this sound like a good idea? > > > >This is (stuck at boot) already do for case of using NIS and nfsuserd. > There is a difference here. nfsuserd mpas between uid/names, so it can't work > without the password database. > mountd can work without the password database, so I held off on doing this for now. > > >I am regular see this for case of DNS failed at boot. > >You offer don't impair current behaviour. > As an aside, if you have the critical entries in the local files (/etc/hosts, /etc/passwd, > /etc/group) and then tell the libraries to search these first in /etc/nsswitch.conf, then > you usually avoid this problem. Same as for 'nobody' for mountd? > Thanks for the comments, rick > Thanks!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170514071108.GK1188>