Date: Tue, 26 Sep 1995 03:03:07 -0400 From: Coranth Gryphon <gryphon@healer.com> To: peter@taronga.com, terry@lambert.org Cc: hackers@FreeBSD.ORG Subject: Re: ports startup scripts Message-ID: <199509260703.DAA15938@healer.com>
next in thread | raw e-mail | index | archive | help
>From owner-freebsd-hackers@freefall.freebsd.org Tue Sep 26 01:31:47 1995
Subject: Re: ports startup scripts
To: terry@lambert.org (Terry Lambert)
Date: Mon, 25 Sep 1995 23:27:44 -0500 (CDT)
Cc: hackers@FreeBSD.ORG
In-Reply-To: <199509251847.LAA05564@phaeton.artisoft.com> from "Terry Lambert" at Sep 25, 95 11:47:11 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 3035
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk
From: peter@taronga.com (Peter da Silva)
> Let's look at all the things that a package needs to get right to install...
> 1. periodic cleanup scripts.
> Cron does this pretty well, except that you need to give
> each package its own user-id.
Neither proposed startup handles this directly. It can be handled trivially
if we can use the existing granularity and the new "daily/weekly" mechanism.
> 2. startup/shutdown scripts.
Either proposed method covers this. See other debate :-)
> 3. tcp/ip port assignment.
> This one is sticky. It's safe to append to /etc/services,
> but not so safe to extract them.
Granted. I'd actually like to see that as a seperate little command utility.
With options to say "check for conflicts" or "ignore conflicts" or "prompt
if conflicts" (just like "cp").
> 4. inetd-driven services.
> Same problem as /etc/services.
Since anything putting an entry into inetd probably has to add an entry
into services, I'd make it part of the same (above #3) util.
> 5. user and group ids, for things like news.
> User-ids are hard to add. Group ids are harder. A
> tool to do this would be helpful.
We have "adduser" which just needs to be made a little smarter;
or actually a tailored version which is a little dumber for doing
non-user UIDs (like ftp, news, ...).
> 6. setting up spool directories.
> You don't want these to be under /usr/local.
"mkdir /var/spool/NAME" ?
> 7. setting up syslog entries.
> See 3, 4, 5.
Yep. Again, looks like the job for a new command tool.
Why do I keep proposing new little command tools? So that people are
not editing these files by hand. We end up with the same mechanism as
password file (chpass, passwd, chsh, ...).
> 9. device drivers
Out of my range of expertise, so I won't offer advice.
> 10. ... (/etc/daily???)
Look at the new daily/weekly version. It's control file based (well, shrug,
that's the way I like to build things :-) and pretty flexible.
> There's a couple of basic ways to address this. You can have one directory
> per package, with specially named files in them (/var/db/pkg could be a
Actually, I agree with the concept some one came up with to move
the DB info (ie. what packages are installed) to /usr/local/db
as it is one of the few non-volatile things in /var.
> Here's what I propose:
> For each package, create a directory under /etc/package.
Do we really need to keep this information after the package is
installed? Well, yeah, for uninstall purposes. Grrfff.
> After installing a package you use these files (from /etc/package/*)
> to recreate:
> /etc/rc.local
> /etc/shutdown.local
Whatever startup/shutdown model we go with...
> /var/cron/tabs/*
Another non-volatile thing that should be moved out of /var
So /etc/cron/...
> /dev/MAKEDEV
> /sys/i386/conf/LINT
These never need to be undone, unless you care about left-over clutter.
But with the new-install rate (average 2 new releases a year) I don't
think it'll be a problem.
> /sys/i386/conf/GENERIC
But then it's not GENERIC. Besides, just how much are we willing
to automate the install process? I think there comes a point
(and kernel rebuilding should be on the other side of that line)
where we either do everything for them, or tell them how to do
it an let them do it themselves.
A lot of other operatins sytems (SCO comes to mind) has the "package_add"
super util that does everything, including kernel rebuilds. If we want to
do that automated, make it one big intelligent tool (even if most of what
it does it call all the little tools we already built above :-)
> /etc/passwd (for uid<1000)
> /etc/passwd.master (for uid<1000)
"adduser" and "deluser" should be sufficient, with little or no modification,
except as mentioned above.
> /etc/group
Always wondered why there weren't equivalent tools for the groups file.
> /etc/inetd.conf
> /etc/syslog.conf
> /etc/services
As mentioned above....
> /etc/ttys
I guess, for packages that sit an listen on serial lines.
But again, unless we go for the "do-everything" util, how
much do we want to automate?
> This would work better than the current scheme, and better than
> System V, and doesn't need symlinks. *And* the existing package scheme
> works with it...
Ok. We never edit the original master file. Just rebuild the startup
list from the packages (like "whatis" is rebuild from the manpages).
That's neat.
> This lets the BSD people use the files they're familiar with, but
> the files the system uses are secondary... they're rebuilt from packages.
Actually, we can implement either the control file mechanism or the
rcN.d subdir mechanism on top of this cleanly, since either is now
just generated information...
<big smile> Ya think?
-coranth
------------------------------------------+------------------------+
Coranth Gryphon <gryphon@healer.com> | "Faith Manages." |
| - Satai Delenn |
Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+
USMail: 3 Hansom Drive, Merrimack, NH 03054
Disclaimer: All these words are yours, except Europa...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509260703.DAA15938>