rpc.mountd + rpc.nfsd
Subsystems (2)
Hi,
Why is there 2 daemons for NFS progs? Is it a necessity or just to separate things?
Would it be possible to have only one nfsd daemon that is rpc.mounts + rpc.nfsd + ... ?
Thanks.
-jec
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 5 lines · On Monday September 2, [email protected] wrote:
Hi,
Why is there 2 daemons for NFS progs? Is it a necessity or just to separate things?
Would it be possible to have only one nfsd daemon that is rpc.mounts + rpc.nfsd + ... ?
The serve different protocols (MOUNTD and NFS). Also mountd runs entirely in user space, nfsd runs entirely in kernel space. It really makes sense for them to be separate.
NeilBrown
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 1 line
The serve different protocols (MOUNTD and NFS). Also mountd runs
OK.
Quoted 2 lines
entirely in user space, nfsd runs entirely in kernel space. It really makes sense for them to be separate.
In fact, I thought of a completely userspace daemon. I took nfs-server-userspace-2.2b47 from the net and wondered why there was 2 daemons while one is IMHO enough. So, separating things between things that relates is sometimes good, but sometimes, it add complexity.
Any comment? Why 2 daemons in userspace. And the 2 run as root (I think...)
-jec
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 7 lines · On Tuesday September 3, [email protected] wrote:
In fact, I thought of a completely userspace daemon. I took nfs-server-userspace-2.2b47 from the net and wondered why there was 2 daemons while one is IMHO enough.
So, separating things between things that relates is sometimes good, but sometimes, it add complexity.
Any comment? Why 2 daemons in userspace. And the 2 run as root (I think...)
Probably conceptually simpler.... but you are getting into ancient history here. The user-space NFS server has it's origins well over a decade ago (about 15 years I think) and has passed through many hands on the way. Finding a definitive answer would be hard.
NeilBrown
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
I'm developing (beginning...) an SMB to NFS bridge.
That means an NFS server that gets its data, files, ACLs, etc... to SMB servers (Samba or Windows). To begin, I'll take the sources of nfs-server userspace. But there is 2 daemons while (I think) only one is necessary. Would it be OK (In terms of kernel and RPC interactivity) to have only one daemon that do mountd+nfsd?
The goal of this project is to have a fully browseable /smb directory.
That will be:
/smb --|-- DOMAIN --|-- SERVER --|-- Share --|-- file
And all that authenticate in a per user way. That means that all connected users would be able to access /smb while seeing only what their credentials allow them. Even root in the machine won't be able to see every connected user data (root could always dump memory and find credentials..., but it's a lot harder to do than just su - user and go to the NFS mounted dir...)
What do you think of that?
-jec
PS: There is a similar commercial product called sharity (http://www.obdev.at/products/sharity/)
Quoted 17 lines · Neil Brown
Quoted 5 lines · On Tuesday September 3, [email protected] wrote:
In fact, I thought of a completely userspace daemon. I took nfs-server-userspace-2.2b47 from the net and wondered why there was 2 daemons while one is IMHO enough. So, separating things between things that relates is sometimes good, but sometimes, it add complexity.
Any comment? Why 2 daemons in userspace. And the 2 run as root (I think...)Probably conceptually simpler.... but you are getting into ancient history here. The user-space NFS server has it's origins well over a decade ago (about 15 years I think) and has passed through many hands on the way. Finding a definitive answer would be hard.
NeilBrown
Signature · 20 lines
Jean-Eric Cuendet Linkvest SA Av des Baumettes 19, 1020 Renens Switzerland Tel +41 21 632 9043 Fax +41 21 632 9090 E-mail: [email protected] http://www.linkvest.com -------------------------------------------------------- ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ NFS maillist - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 7 lines · On Tuesday September 3, [email protected] wrote:
I'm developing (beginning...) an SMB to NFS bridge.
That means an NFS server that gets its data, files, ACLs, etc... to SMB servers (Samba or Windows).
To begin, I'll take the sources of nfs-server userspace. But there is 2 daemons while (I think) only one is necessary.
Would it be OK (In terms of kernel and RPC interactivity) to have only one daemon that do mountd+nfsd?
I suspect you would be better off starting with am-utils than nfs-server. (am-utils is a sophisticated auto-mount daemon).
If I understand you correctly, the nfs server will be on the same machine as the nfs client that accesses that server. And then the server reaches out over the network with SMB.
In that case you don't need mountd at all. When the server starts, it mounts itself and then starts responding to NFS requests.
It is much easier not to re-invent the wheel. For the actual file access, don't do that via NFS, simply mount the SMB share using smbfs somewhere and direct the client to that. Only use NFS for the browsing.
I suspect that you could possibly just use am-utils as it is and write some back-end that provided a mount-map that am-utils used. I suggest you talk to Erez Zadok <[email protected]>. He could probably point you in the right direction.
I'm not sure about the 'different-users-see-different-things' bit, but there are elements of that in Erez' hlfsd (Home Link File System) so I suspect he could help there too.
Quoted 11 lines
The goal of this project is to have a fully browseable /smb directory. That will be:
/smb --|-- DOMAIN --|-- SERVER --|-- Share --|-- file
And all that authenticate in a per user way. That means that all connected users would be able to access /smb while seeing only what their credentials allow them. Even root in the machine won't be able to see every connected user data (root could always dump memory and find credentials..., but it's a lot harder to do than just su - user and go to the NFS mounted dir...)
Quoted 6 lines
What do you think of that?
-jec
PS: There is a similar commercial product called sharity
(http://www.obdev.at/products/sharity/)
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 5 lines
I suspect you would be better off starting with am-utils than nfs-server. (am-utils is a sophisticated auto-mount daemon).
Everyone that I ask about that tell me the same: use amd... But (except if I miss something), it's absolutely NOT suitable for that!
Explainations:
amd mounts a smb share in the filesystem (say, mounting //server/share => /smb). To mount, you must provide a user/pwd. Then there is some mount time fixed uid/gid used to "own" the files on the machine. If the authentication is done by user1 and then user2 is accessing files, the permissions will be checked on user1 on the SMB server, and with uid/gid on the client. If user2 has access to files that user1 haven't, user2 will be denied access... If user2 have access that user1 don't , access will be granted anyway (if uid/gid on the client is OK).
The goal is to check the perms on a per access basis. When user1 access files, we use its auth token to check if access is granted. Client doesn't anything, only the SMB server makes checks. Then, if user2 access other files, we use its auth token, which let him access different files.
It's the same as network neighborood in Windows. Only files that the USER (not the machine) have access are acessible.
Am I missing something with amd?
Quoted 4 lines
If I understand you correctly, the nfs server will be on the same machine as the nfs client that accesses that server. And then the server reaches out over the network with SMB.
Yes, that's it! The nfs-server is only a bridge. Access is only provided for 127.0.0.1
Quoted 3 lines
In that case you don't need mountd at all. When the server starts, it mounts itself and then starts responding to NFS requests.
Cooool. It's simpler! So, server mounting itself doesn't need mountd. How do I do that?
- Implementing NFSD RPC calls.
- Starting NFSD
- Mounting the server (mount -t nfs localhost:/ /smb)
Why isn't mountd needed? What does it provide that is not needed?
Quoted 4 lines
It is much easier not to re-invent the wheel. For the actual file access, don't do that via NFS, simply mount the SMB share using smbfs somewhere and direct the client to that. Only use NFS for the browsing.
The same problem as explained before...
Quoted 2 lines
I'm not sure about the 'different-users-see-different-things' bit, but
That's just the point that don't work and that's very important in this thing.
Quoted 3 lines
there are elements of that in Erez' hlfsd (Home Link File System) so I suspect he could help there too.
I'll have a look at that. But I suspect that it won't change things.
Thanks anyway for everything.
-jec
PS: Are you a RedHat employee or not?
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Have you looked at sharity? I have not used it much, but from what I understand, it does exactly what you are asking.
--David Dougall
Quoted 70 lines · Jean-Eric Cuendet
Quoted 5 lines
I suspect you would be better off starting with am-utils than nfs-server. (am-utils is a sophisticated auto-mount daemon).
Everyone that I ask about that tell me the same: use amd... But (except if I miss something), it's absolutely NOT suitable for that!
Explainations:
amd mounts a smb share in the filesystem (say, mounting //server/share => /smb). To mount, you must provide a user/pwd. Then there is some mount time fixed uid/gid used to "own" the files on the machine. If the authentication is done by user1 and then user2 is accessing files, the permissions will be checked on user1 on the SMB server, and with uid/gid on the client. If user2 has access to files that user1 haven't, user2 will be denied access...
If user2 have access that user1 don't , access will be granted anyway (if uid/gid on the client is OK).The goal is to check the perms on a per access basis. When user1 access files, we use its auth token to check if access is granted. Client doesn't anything, only the SMB server makes checks.
Then, if user2 access other files, we use its auth token, which let him access different files.
It's the same as network neighborood in Windows. Only files that the USER (not the machine) have access are acessible.Am I missing something with amd?
Quoted 4 lines
If I understand you correctly, the nfs server will be on the same machine as the nfs client that accesses that server. And then the server reaches out over the network with SMB.
Yes, that's it! The nfs-server is only a bridge. Access is only provided for 127.0.0.1
Quoted 3 lines
In that case you don't need mountd at all. When the server starts, it mounts itself and then starts responding to NFS requests.
Cooool. It's simpler! So, server mounting itself doesn't need mountd. How do I do that?
- Implementing NFSD RPC calls.
- Starting NFSD
- Mounting the server (mount -t nfs localhost:/ /smb)
Why isn't mountd needed? What does it provide that is not needed?Quoted 4 lines
It is much easier not to re-invent the wheel. For the actual file access, don't do that via NFS, simply mount the SMB share using smbfs somewhere and direct the client to that. Only use NFS for the browsing.
The same problem as explained before...
Quoted 2 lines
I'm not sure about the 'different-users-see-different-things' bit, but
That's just the point that don't work and that's very important in this thing.
Quoted 3 lines
there are elements of that in Erez' hlfsd (Home Link File System) so I suspect he could help there too.
I'll have a look at that. But I suspect that it won't change things.
Thanks anyway for everything.
-jecPS: Are you a RedHat employee or not?
Quoted 9 lines
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
______________________________________
Inflex Virus Scanner - installed on mailserver for domain @et.byu.edu Queries to: [email protected]
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 6 lines
Have you looked at sharity? I have not used it much, but from what I understand, it does exactly what you are asking.
--David Dougall
Yes, but it's not free...
Except that, it's exactly what I'd like to do.
-jec
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 27 lines · On Tuesday September 3, [email protected] wrote:
Quoted 5 lines
I suspect you would be better off starting with am-utils than nfs-server. (am-utils is a sophisticated auto-mount daemon).
Everyone that I ask about that tell me the same: use amd... But (except if I miss something), it's absolutely NOT suitable for that!
Explainations:
amd mounts a smb share in the filesystem (say, mounting //server/share => /smb). To mount, you must provide a user/pwd. Then there is some mount time fixed uid/gid used to "own" the files on the machine. If the authentication is done by user1 and then user2 is accessing files, the permissions will be checked on user1 on the SMB server, and with uid/gid on the client. If user2 has access to files that user1 haven't, user2 will be denied access...
If user2 have access that user1 don't , access will be granted anyway (if uid/gid on the client is OK).The goal is to check the perms on a per access basis. When user1 access files, we use its auth token to check if access is granted. Client doesn't anything, only the SMB server makes checks.
Then, if user2 access other files, we use its auth token, which let him access different files.
It's the same as network neighborood in Windows. Only files that the USER (not the machine) have access are acessible.
Quoted 1 line
Am I missing something with amd?
What you could do is arrange that amd mounts a completely separate filesystem tree for each user, using something similar to hlfsd to automatically direct each user to a different tree. Then each tree has smb shares mounted with the user's username and password, and only accessable to that user.
Alternately, you could modify smbfs to open multiple connections to the server, one for each user, and direct different user's requests down different connections.
Alternately you could do the whole thing in an NFS server.
I suspect the last would be the hardest, but maybe that's just me.
Have fun.
NeilBrown
Quoted 3 lines
PS: Are you a RedHat employee or not?
not.
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 8 lines
If I understand you correctly, the nfs server will be on the same machine as the nfs client that accesses that server. And then the server reaches out over the network with SMB.
In that case you don't need mountd at all. When the server starts, it mounts itself and then starts responding to NFS requests.
I REALLY need to know how to mount myself in a directory. I have nfs3_prot.x implemented but not mountd at all. How to do that? When in my program? What to call?
Thanks a lot.
-jec
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Isn't there someone to answer this guy question?... :-)
Quoted 8 lines
Quoted 4 lines
If I understand you correctly, the nfs server will be on the same machine as the nfs client that accesses that server. And then the <..>
mounts itself and then starts responding to NFS requests.I REALLY need to know how to mount myself in a directory. I have nfs3_prot.x implemented but not mountd at all. How to do that? When in my program? What to call?
;-)
-jec
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 8 lines
Quoted 4 lines
If I understand you correctly, the nfs server will be on the same machine as the nfs client that accesses that server. And then the <..>
mounts itself and then starts responding to NFS requests.I REALLY need to know how to mount myself in a directory. I have nfs3_prot.x implemented but not mountd at all. How to do that? When in my program? What to call?
Short answer:
You do not mount yourself in a directory. mountd is used to retrieve the opaque file handle of the directory you wish to mount on the client. Once you have the initial opaque filehandle, you may then call an nfs procedure (ie. LOOKUP, READ, WRITE, READDIR, etc) with the filehandle as one of the arguments.
Better answer:
As suggested by a previous reply, get yourself a copy of "NFS Illustrated" by Brent Callaghan.
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 11 lines · On Thursday September 5, [email protected] wrote:
Isn't there someone to answer this guy question?... :-)
Quoted 8 lines
Quoted 4 lines
If I understand you correctly, the nfs server will be on the same machine as the nfs client that accesses that server. And then the <..>
mounts itself and then starts responding to NFS requests.I REALLY need to know how to mount myself in a directory. I have nfs3_prot.x implemented but not mountd at all. How to do that? When in my program? What to call?
man 2 mount
This explains everything except for the 'void * data' which is nfs specific.
cat /usr/include/linux/nfs_mount.h
If some of the fields aren't obvious, get the source for the mount program and read it, or look at the nfs filesystem code in the kernel to see what it does with those fields.
NeilBrown
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == Neil Brown <[email protected]> writes:
> This explains everything except for the 'void * data' which is > nfs specific.
> cat /usr/include/linux/nfs_mount.h
> If some of the fields aren't obvious, get the source for the > mount program and read it, or look at the nfs filesystem code > in the kernel to see what it does with those fields.
In particular it is worth looking at the NFSroot code (fs/nfs/nfsroot.c). The latter contains basic code for filling in a struct nfs_mount.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == Jean-Eric Cuendet <[email protected]> writes:
The serve different protocols (MOUNTD and NFS). Also mountd runs
> OK.
>> entirely in user space, nfsd runs entirely in kernel space. It >> really makes sense for them to be separate.
> In fact, I thought of a completely userspace daemon. I took > nfs-server-userspace-2.2b47 from the net and wondered why there > was 2 daemons while one is IMHO enough.
IIRC, this was done in order to allow people to do wierd and wonderful things. For instance, you could supposedly run the mountd daemon on one machine, and nfsd on another. We actually have support for this in the client by way of the option "mounthost=" in the standard mount program.
I've never heard of anybody actually using that particular feature though.
Cheers,
Trond
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 13 lines · Trond Myklebust
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == Jean-Eric Cuendet <[email protected]> writes:
The serve different protocols (MOUNTD and NFS). Also mountd runs
> OK.
>> entirely in user space, nfsd runs entirely in kernel space. It >> really makes sense for them to be separate.
> In fact, I thought of a completely userspace daemon. I took > nfs-server-userspace-2.2b47 from the net and wondered why there > was 2 daemons while one is IMHO enough.
Quoted 6 lines
IIRC, this was done in order to allow people to do wierd and wonderful things. For instance, you could supposedly run the mountd daemon on one machine, and nfsd on another. We actually have support for this in the client by way of the option "mounthost=" in the standard mount program.
What would be the benefit of running nfsd and mountd on different hosts ?
Jens
Signature · 12 lines
Jens Beyer System Administrator mailto:[email protected] WEB.DE AG http://webde-ag.de ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ NFS maillist - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs