[ANNOUNCE] poeigl-1.7 and admutil-1.4 available
Peter Orbaek
and tsx-11.mit.edu
Init now has support for a singleuser mode, and it doesn't ignore the termcap
field in /etc/inittab for console tty's anymore. After version 0.98.3
the TERM variable handed over from the kernel is not very interesting.
Login now supports the -h <hostname> switch used by telnetd and such.
Getty will now write an entry to /etc/wtmp each time it is started, so
"last" won't show "still logged in" until another logs in on that tty.
I fixed "last" so it would work properly with the fixed getty.
Shutdown now does a better job of umounting filesystems upon shutdown, it
should even be able to handle NFS volumes. Shutdown also supports singleuser
mode by way of a "-s" switch. A new "-f" switch has also been provided as
well as two more links to shutdown for a fastboot option.
There's an example of a /etc/rc file that takes advantage of the fastboot
option, and LILO's ability to pass environment variables to it.
Acknowledgements:
-----------------
Werner Almesberger helped me get the singleuser mode right with suggestions
and patches.
Mitchum DSouza suggested the fix for getty.
Rick Sladkey <j...@world.std.com> provided the umount code for shutdown.
Remy Card <ca...@masi.ibp.fr> provided the patches for the fastboot option.
My thanks to all of them.
As always, the packages contains only sourcecode. The binaries can be built
under Linux 0.97P4 or later with at least gcc-2.2.2
To those that do not already know, the poeigl package contains:
init, getty, login, hostname, mesg, users, who, write
and admutils contains:
chsh, ctrlaltdel, init, last, newgrp, passwd, shutdown, reboot,
halt, fastboot, fasthalt, su, example /etc/rc
I have put the packages out for anon ftp at:
ftp.daimi.aau.dk:/pub/Linux-source
tsx-11.mit.edu:/pub/linux/<whereever tytso puts them>
nic.funet.fi:/pub/OS/Linux/<whereever arl puts them>
- Peter. <p...@daimi.aau.dk>
--
Peter Orbaek <p...@daimi.aau.dk>
Hasle Ringvej 122, DK-8200 Aarhus N, DENMARK
Michael Haardt
> Init now has support for a singleuser mode, and it doesn't ignore the termcap
> field in /etc/inittab for console tty's anymore. After version 0.98.3
> the TERM variable handed over from the kernel is not very interesting.
Your own init, I guess? There are two versions (well, three to be
precise: yours, the older sysv-compatible init and the newer
sysv-compatible init).
> To those that do not already know, the poeigl package contains:
>
> init, getty, login, hostname, mesg, users, who, write
>
> and admutils contains:
>
> chsh, ctrlaltdel, init, last, newgrp, passwd, shutdown, reboot,
> halt, fastboot, fasthalt, su, example /etc/rc
Unfortunately there is now a conflict between your package and the sysv
compatible package. We should try to work something out. I don't like
that I have to decide which utilities from which package are better each
time.
Why is there a su? If I am right, the GNU shellutils also have one, and
it works fine.
Michael
David Engel
: In article <1992Nov3.0...@daimi.aau.dk>, p...@daimi.aau.dk (Peter Orbaek) writes:
: > To those that do not already know, the poeigl package contains:
: >
: > init, getty, login, hostname, mesg, users, who, write
: Why is there a su? If I am right, the GNU shellutils also have one, and
: it works fine.
GNU also has a who.
David
--
David Engel Optical Data Systems, Inc.
da...@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Sebastian Lederer
: Getty will now write an entry to /etc/wtmp each time it is started, so
: "last" won't show "still logged in" until another logs in on that tty.
:
: I fixed "last" so it would work properly with the fixed getty.
Hmm...no offense intended, but the logout records should be the job of init,
not of getty. The SystemV-compatible init-process from your admutils-package
does exactly this whenever a child of init dies. After I made some slight
modifications, I have been running it since 0.96 without any problems, and
none of the three flavours of "last" I have had to be changed. I think this
is a more "standard" solution to the problem, since not everyone uses the
getty-program of the admutils-package. By the way, the SysV-Init does not
only have a single-user-mode, but different runlevels, which can be very
handy, for example, to enable logins on a modem line, I have to change the
runlevel only instead of editing inittab etc. .
Talking of your admutils package, the shutdown program should write a
"shutdown" record to /etc/wtmp even if a reboot is requested. The "reboot"
record should be written by init after (re-)boot. Again, the SysV-Init does
this correctly.
I am not at all in favour of System V or anything, but I think there's
nothing wrong in keeping up with usual UN*X standards...and writing the
logout-records in getty is a little bit unusual.
If anyone should be interested in the patched version of the SysV-init, mail
me...
--
Sebastian Lederer "And crawling on the planets face - Some insects, called
se...@avatar.GUN.de the human race. Lost in time and lost in space -and in
------------------- meaning" - The Narrator of the Rocky Horror Picture Show
Robert Chen
>Peter Orbaek (p...@daimi.aau.dk) wrote:
>: Getty will now write an entry to /etc/wtmp each time it is started, so
>: "last" won't show "still logged in" until another logs in on that tty.
>:
>: I fixed "last" so it would work properly with the fixed getty.
>
>Hmm...no offense intended, but the logout records should be the job of init,
>not of getty. The SystemV-compatible init-process from your admutils-package
>does exactly this whenever a child of init dies. After I made some slight
>modifications, I have been running it since 0.96 without any problems, and
>none of the three flavours of "last" I have had to be changed. I think this
>is a more "standard" solution to the problem, since not everyone uses the
>getty-program of the admutils-package. By the way, the SysV-Init does not
>only have a single-user-mode, but different runlevels, which can be very
>handy, for example, to enable logins on a modem line, I have to change the
>runlevel only instead of editing inittab etc. .
>I am not at all in favour of System V or anything, but I think there's
>nothing wrong in keeping up with usual UN*X standards...and writing the
>logout-records in getty is a little bit unusual.
>If anyone should be interested in the patched version of the SysV-init, mail
>me...
>
>--
>Sebastian Lederer "And crawling on the planets face - Some insects, called
>se...@avatar.GUN.de the human race. Lost in time and lost in space -and in
>------------------- meaning" - The Narrator of the Rocky Horror Picture Show
I agree that the SysV compatible stuff is "better" because of the
reasons outlined above. Is there any reason that we cannot use the
ysV init as the Standard init for Linux? I think having two inits
around is a Bad Thing (tm) anyway - it confuses matters for no really
good reason.
Peter: Would it be possible for you to fold Sebastian's patches back
into the admutils package? Would you consider just providing the SysV
init? You pretty much control what Linux's login sequence looks like
(realistically).
Please let up know what you think.
- Ken
Peter Orbaek
>In article <9211...@avatar.GUN.de> se...@avatar.GUN.de (Sebastian Lederer) writes:
[... about the benefits of using the sysv compatible init instead of the
simple one, runlevels and all ...]
Robert Chen:
>I agree that the SysV compatible stuff is "better" because of the
>reasons outlined above. Is there any reason that we cannot use the
>ysV init as the Standard init for Linux? I think having two inits
>around is a Bad Thing (tm) anyway - it confuses matters for no really
>good reason.
>Peter: Would it be possible for you to fold Sebastian's patches back
>into the admutils package? Would you consider just providing the SysV
>init? You pretty much control what Linux's login sequence looks like
>(realistically).
I already mailed Sebastian asking him for his patches. There will
have to be a few more changes to sysvinit though, such as handling
the INT signal from the kernel to initiate a reboot.
I think that sysvinit will be the default to install in the next
version of the poeigl package unless I encounter overwhelming
problems with it.
Simpleinit was getting too big after all, so I might as well give in to
the featuritis that I think a sysv init represents. :-)
>Please let us know what you think.
>- Ken
- Peter.
Greg Wettstein
it may be important to provide a short set of documentation that explains
the ins and outs of a run-level init. With the fundamental important of
init there could very well be a flood of new-user problems when they
suddenly find out that this beast reacts radically different than what
they have been used to. There have been plenty of horror stories about
whacked inits and inittab's already. Luckily everyone seems to have a
sufficiently healthy respect for problems to keep a bootable-rootable
floppy around.
As always,
Dr. G.W. Wettstein
Oncology Research Division Computing Facility
Fargo Clinic / MeritCare
UUCP: uunet!plains!wind!greg
INTERNET: greg%wind...@plains.nodak.edu
Phone: 701-234-2833
`The truest mark of a man's wisdom is his ability to listen to other
men expound their wisdom.'
Michael Haardt
> If a move is made toward using a Sys-V compatible init as the default init
> it may be important to provide a short set of documentation that explains
> the ins and outs of a run-level init. With the fundamental important of
> init there could very well be a flood of new-user problems when they
> suddenly find out that this beast reacts radically different than what
> they have been used to.
There is a detailed manual page for init and the SYS V distribution
comes with an example initttab. I use the SYS V init since I first saw
it and I am very satisfied. admutils only contain an old version, which
has a subtile bug which sometimes leads to a deadlock, but that is
corrected in the current version.
> they have been used to. There have been plenty of horror stories about
> whacked inits and inittab's already. Luckily everyone seems to have a
> sufficiently healthy respect for problems to keep a bootable-rootable
> floppy around.
Or old Minix floppies ... :)
Michael