Hello Petr,
I ended up being the owner of mingetty by chance, because I used to maintain it in the OLPC collection and the previous maintainer released the package.
Since you're clearly working on it, I think it would make sense to pass ownership to you. If you agree, I will orphan the package so you can take it over (there doesn't seem a way to do a direct transfer in pkgdb).
On Wed, Nov 10, 2010 at 09:33:26PM -0500, Bernie Innocenti wrote:
I ended up being the owner of mingetty by chance, because I used to maintain it in the OLPC collection and the previous maintainer released the package.
Since you're clearly working on it, I think it would make sense to pass ownership to you. If you agree, I will orphan the package so you can take it over (there doesn't seem a way to do a direct transfer in pkgdb).
Ok. Just orphan mingetty and ping me. I will take it in turn.
-- Petr
On Wed, 10.11.10 21:33, Bernie Innocenti (bernie@codewiz.org) wrote:
Hello Petr,
I ended up being the owner of mingetty by chance, because I used to maintain it in the OLPC collection and the previous maintainer released the package.
Do we really want to keep mingetty around?
We discussed this a couple of times in the systemd context with people form various distros. In the interest of standardizing things across distros we would like to get all distros use the same getty implementation. Now, as it turns out contrary to what the name suggests mingetty actually uses a little bit more runtime memory than agetty, even though mingetty takes up a handful of bytes less disk space. (That said, the difference in memory and disk space is tiny enough to don't matter the tiniest bit on modern machines) Now, agetty is actively maintained inside u-l-ng, and used by most distros, except Fedora and Suse. Since u-l-ng is a core part of every Linux system and the mingetty pkg definitely not we started to work on making everybody use agetty and drop mingetty from the standard install everywhere. That way most distros would only have to install one getty implementation, and can use it for both serial consoles and VCs. Also it would use less disk space (since one getty binary takes less space than two, even if the one we keep is sligtly larger then the other one we remove), and less runtime memory. systemd git now ships with a default config which makes use of agetty, not mingetty -- on all distros.
You apparently see value in keeping two almost identical getty implementations around. Can you elaborate why? Is there any feature missing in agetty that mingetty has?
Lennart
On Thu, Nov 11, 2010 at 08:53:47PM +0100, Lennart Poettering wrote:
On Wed, 10.11.10 21:33, Bernie Innocenti (bernie@codewiz.org) wrote:
Hello Petr,
I ended up being the owner of mingetty by chance, because I used to maintain it in the OLPC collection and the previous maintainer released the package.
Do we really want to keep mingetty around?
Your argument is sound, but this is still a bit off topic for this thread. Even if mingetty is retired it still needs a maintainer for another year until we retire F14 (unless we want to take a risk and try to swap it out in the public releases). I assume OLPC would have a similar issue.
--CJD
On 2010-11-11, Lennart Poettering mzerqung@0pointer.de wrote:
Do we really want to keep mingetty around?
[...]
You apparently see value in keeping two almost identical getty implementations around. Can you elaborate why? Is there any feature missing in agetty that mingetty has?
Till someone uses mingetty or it's part of supported distribution, somebody must maintain it. Currently the somebody is me.
If you think Fedora should switch to different implementation, just discuss it (or do it if the proposal is approved).
After the switch, you can fill report into Bugzilla to remove the package from newer releases. Do not forget to link good arguments like init maintainer's / init scripts maintainer's / FESCo decission.
Then I can ask rel-engs to remove the package from VCS and composes.
My opinion regarding mingetty removal is I'm not against.
-- Petr
On Thu, 11 Nov 2010, Lennart Poettering wrote:
That way most distros would only have to install one getty implementation, and can use it for both serial consoles and VCs.
Yes please.
Bonus points for anaconda configuring a working agetty login if the install console was serial. That is, run agetty using the same linespeed as the install and add the serial device to securetty.
(last install I did, though it was rhel5, on a machine without VGA left me with no way to login to the system after install (kickstart didn't add a non-root user)
Paul
Once upon a time, Paul Wouters paul@xelerance.com said:
Bonus points for anaconda configuring a working agetty login if the install console was serial. That is, run agetty using the same linespeed as the install and add the serial device to securetty.
This is handled automatically now; if the kernel console is serial, a getty is run on the console and added to securetty automatically (in recent Fedora and RHEL 6).
On Wed, 24.11.10 00:06, Paul Wouters (paul@xelerance.com) wrote:
On Thu, 11 Nov 2010, Lennart Poettering wrote:
That way most distros would only have to install one getty implementation, and can use it for both serial consoles and VCs.
Yes please.
Bonus points for anaconda configuring a working agetty login if the install console was serial. That is, run agetty using the same linespeed as the install and add the serial device to securetty.
systemd implicitly adds a serial getty on the console configured on the kernel cmdline with console= and also one on hvc0 if that device exists. That means simply by using console= on the kernel cmdline you should get a getty on it.
We currently still use the old securetty tool to patch those terminals into /etc/securetty on demand. I have submitted a patch to pam_securetty however, to make it look for console= on the kernel cmdline internally, which when merged allows us to get rid of the tool and have this work on r/o root fine as well.
Lennart
Once upon a time, Lennart Poettering mzerqung@0pointer.de said:
We currently still use the old securetty tool to patch those terminals into /etc/securetty on demand. I have submitted a patch to pam_securetty however, to make it look for console= on the kernel cmdline internally, which when merged allows us to get rid of the tool and have this work on r/o root fine as well.
Please don't do that. Not all serial consoles are necessarily secure.
On Wed, 24.11.10 14:29, Chris Adams (cmadams@hiwaay.net) wrote:
Once upon a time, Lennart Poettering mzerqung@0pointer.de said:
We currently still use the old securetty tool to patch those terminals into /etc/securetty on demand. I have submitted a patch to pam_securetty however, to make it look for console= on the kernel cmdline internally, which when merged allows us to get rid of the tool and have this work on r/o root fine as well.
Please don't do that. Not all serial consoles are necessarily secure.
This behaviour has been the default sicne quite some time. I am not the one who's going to change that. As soon as the patch i posted is merged into pam-securetty you can easily disable this behaviour by passing noconsole on the PAM config line.
I think pam_securetty is mostly snake oil anyway. An admin should be smart enough to choose a safe root password instead of relying on this kind of snake oil.
Note that with that pam_securetty patch in place thins become safe anyway, since booting with console on ttyS0 once won't change /etc/securetty for all the future, but only for this one boot.
Lennart
-
Bernie Innocenti -
Casey Dahlin -
Chris Adams -
Lennart Poettering -
Paul Wouters -
Petr Pisar