"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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:15 EST