Bringing up NFS server on 64 bits
Fri Jan 10 13:52:00 GMT 2014
On Jan 10 17:35, Pavel Fedin wrote:
> Hello! I'm back with some more news.
> Currently i am building and testing NFS Server for 64 bits. The following
> was done so far:
> - libtirpc package - fixed to always export svc_auth_none (see my previous
> - rpcgen package - successfully rebuilt and tested, works fine, no changes
> - nfs-server package - successfully rebuilt against libtirpc with patching.
> Testing is to be done.
> - rpcbind - ported to Cygwin. Testing is to be done.
Thanks for working on that. It's highly appreciated. Did you already
make yourself familiar with Cygwin package maintainance(*)?
> Obsolete sunrpc package is almost not needed, except public headers in
> include/rpcsvc. The following subset of the is needed by rpcbind (here and
> below i will refer to C code at
> --- cut ---
> #include <rpcsvc/mount.h>
> #include <rpcsvc/rquota.h>
> #include <rpcsvc/nfs_prot.h>
> #include <rpcsvc/yp.h>
> #include <rpcsvc/ypclnt.h>
> #include <rpcsvc/yppasswd.h>
> --- cut ---
> 6 files so far. To tell the truth i feel a bit bad about having to keep the
> complete obsolete package just for 6 files.
> I noticed that mount.h and nfs_prot.h (together with .x from which they are
> generated) are available in a fresh version inside nfs-server source code.
> The only missing thing is copying them to /usr/include during installation,
> which can be easily fixed.
> The rest are: rquota.h, yp.h, ypclnt.h and yppasswd.h. Their definitions
> are used only by check_callit() function, which obviously has something to
> do with security and forcibly denies some actions. There are several things
> to be done with them and i'd like to discuss what's better:
> 1. Keep original sunrpc package in extremely reduced form, containing only
> include/rpcsvc directory (this is how my test build is done).
> 2. Pick up this thing and make a new package out of it:
> 3. Export NFS-related includes from nfs-server package (creating
> nfs-server-devel), and #ifdef the rest out.
> Personally i like (3) most of all because it's the simplest thing to do and
> it won't pollute Cygwin with packages with almost no purpose. After all, who
> uses NIS nowadays ? The only thing that makes me feeling bad - what does
> this code actually do ? Won't disabling NIS-related stuff hurt security ?
(3) sounds right to me. As for NIS, I don't think this is important,
especially not for the NFS server. In theory the OS (Windows) decouples
the NFS server from having to look for NIS stuff by itself. Account
info should be available via the OS (Cygwin) calls anyway and worse,
assuming the NFS server fetches info directly via NIS, the entire
user/group -> uid/gid -> SID mapping might be screwed up.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin