"Jeff V. Merkey" wrote: > > Alan, > > I've basically given up on the in-kernel implementation of a daemon for > M2FS and am sticking to a user space daemon instead for the remote file > system server -- the entire security model in Linux appears to be > tightly integrated with the user space networking support, so for Linux > I am focusing there since the normal features provided by hosts.deny, > hosts.allow, etc. are all at this level and it seems pretty dumb to > attempt to circumvent them. The M2FS file system driver is in kernel, > and I've instrumented it to look a lot like NCPFS and NBD, with the > exception that I issue a ->connect() request from the driver instead of > passing a sockets handle down from user space like NCPFS and NBD do > today, which seems to work OK. > > Simple question. I have reviewed the whole etc/services thing and I am > assuming that the mapping of services names, like smptd and pop3d for > example to ports 25 and 110 is controlled from this file. What's messy > here is issues related to deamon startup scripts in versions other than > Caldera. Linux NetWorx uses a lot of Red Hat Linux, and it looks like > the whole /etc/rc.d/init.d scripts startup layout is fairly close to > what's in Caldera Open Linux. Apart from putting a script in > /etc/rc.d/init.d to start the daemon and updating the /etc/services file > with the port mappings, are there any other "gotcha's" related to > current RedHat releases > I need to consider to put a a startup daemon into your releases? > > Thanks > > :-) > > Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
