Re: Proposal: A config file for runlevels (DRAFT)
On Fri, 3 Jan 1997, Winfried Truemper wrote:
>
>
> On Fri, 3 Jan 1997, Richard G. Roberto wrote:
>
> > Only on a Debian system. My Solaris system has all mulit-user,
> > networking CLIENT stuff in runlevel two. Run level three
> > contains server realted stuff (usually just nfs server and maybe
> > sybase). Everything else is EMPTY!
>
> Yes, but the client/server scheme of Solaris still keeps the messy
> practice of expressing the setup through (hard-)links.
That doesn't mean debian has to use hard links. Anyway, there
seem to be two camps as SunSoft on this as many of the layered
products Sun sells (such as ODS) use symbolic links.
>
> Solaris provides a certain order for packages in and through runlevels -
> thats another point and independent of what I suggested (-> making it
> easier to handle the configuration manually, the automated tools remain
> the same).
You lost me on that one, but OK.
>
>
> > Run level 2 should be configured as a mulituser/networked/client
> > run level and runlevel 3 its server compliment. Then packages
> > just need to be flagged as falling into either one of these two
> > groups.
>
> Furthermore:
>
> Runlevel 3 only starts processes, there are no K-links in /etc/rc3.d/. The
> other way round, runlevel 2 only kills the processes started in runlevel
> 3, not the processes of 0,1 ("S" under Solaris) or 6.
I think you missed my point, but I cut my hair this weekend, so
its much more visible now. Just in case though, I'll clarify. I
don't want to make debian a solaris clone, I just wanted to point
out that this can be made manageable. K scripts get run before S
scripts, so they belong in any run level that would need to have
stuff stopped before other stuff gets started. Thats all. It
can also be used to do anything else you want, but thats up to
the administrator. In another life I wrote a similar system to
SysV init for SunOS where one of the K scripts that got run when
enetering a failover run level killed open filehandles on a list
of NFS mounts. We could have put that in an S script, but it
seemd like it should be a K script kind of thing ;-)
>
> Correct me if I'm wrong (hey, it's long ago I did that): the installation
> procedure Solaris offers 2 main setups: client or server.
> A "client" in this sense is a NFS-client and a "server" is a fileserver
> (not limited to NFS). This is something which is not nativly supported by
> Debian and so I can't figure out how we could take advantage of it in the
> meantime.
> [Daemons providing server functionality are still started in runlevel 2
> like "inetd", "portmapper" and "sendmail".]
Yes you're wrong. You're thinking of the install profiles they
have that have different directory structures, package lists, and
services started. The run levels are still "2" for clients (i.e.
any client daemons programs that need to run) and "3" for
services (i.e. any server processes that need to run, such as
nfsd, sybase, httpd, etc.).
>
>
> > packages.. This could be a rarely used run level of say "7". The
> > idea would be for people to install experimental packages there
> > so they don't get run by default.
>
> We could achieve even finer granularity by introducing a variable
> "RUN_<package>_ON_STARTUP" which is evalutated in the script. This way you
> don't have to mess around with runlevels (even if this may become very
> easy in the future). This is currently discussed in debian-admintool.
Yes, the possibilities are endless. Once a mechanism is in
place to allow for a clean interface to this stuff, we can offer
a multitude of solutions. It sounds like the cfgtool could be
the thing, but I haven't seen anything on it yet. I'm not on
debian-admintool. Is that just
"debian-admintool-REQUEST@lists.debian.org" with "subscribe" and
"richr@bear.com" in the body? There isn't an entry for it on the
web page.
Thanks.
Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan
--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: