We should have the Cockpit URL and certificate fingerprint displayed on the VT before login. In addition it should be shown by default when a user logs in via HTTP.
Not sure what component is best for this. So please update if necessary.
/etc/issue is provided by fedora-release. /etc/motd is provided by setup. you will need to reassign this bug to one and clone it for the other. we do not have any way today to differentiate products
Reassigning to cockpit for now, until there's a fedora server component.
I love the idea of doing something nicer at the login prompt. Two quick thoughts: * cloud-init has significant useful info it dumps to syslog. * Is there a way to actually have the agetty output be *dynamic* though? Otherwise we'd have to block login until we got a DHCP response for example.
Hmmm, good point. Start up of agetty for each VT is "dynamic" in that it only happens when happens when the VT is requested (via Ctrl-Alt-FX keys, for example). However that doesn't help us for the 1st getty instance (unless X starts).
Oh, and to clarify there are dynamic fields in /etc/issue (see man 8 agetty), but they are only read when agetty is started for a given VT, and don't update later.
Hmmm, maybe we should try and add a custom signal to agetty so that it updates its display when it receives it, unless the user has started typing a user name or otherwise started.
Patch for agetty here: https://github.com/stefwalter/util-linux/commit/5c5479c73f4b3e82ee01393278d21a921dad1c35
(In reply to Stef Walter from comment #8) > Patch for agetty here: > https://github.com/stefwalter/util-linux/commit/ > 5c5479c73f4b3e82ee01393278d21a921dad1c35 How's that supposed to work? How do you determine which processes to kill? "agetty" is replaced by "login" as soon as the user type in his usersname. How do you make sure you don't accidentally send SIGUSR1 to login instead of agetty? I mean, that's a race you cannot fix. I don't think this can workd really, sorry.
(In reply to Lennart Poettering from comment #9) > (In reply to Stef Walter from comment #8) > > Patch for agetty here: > > https://github.com/stefwalter/util-linux/commit/ > > 5c5479c73f4b3e82ee01393278d21a921dad1c35 > > How's that supposed to work? How do you determine which processes to > kill? Ideally there would be a way to 'systemctl reload getty@*.service'. But in the absence of that, 'killall agetty' is an alternative. > "agetty" is replaced by "login" as soon as the user type in his > usersname. How do you make sure you don't accidentally send SIGUSR1 to > login instead of agetty? I mean, that's a race you cannot fix. I guess we could make login ignore SIGUSR1.
(In reply to Stef Walter from comment #10) > (In reply to Lennart Poettering from comment #9) > > (In reply to Stef Walter from comment #8) > > > Patch for agetty here: > > > https://github.com/stefwalter/util-linux/commit/ > > > 5c5479c73f4b3e82ee01393278d21a921dad1c35 > > > > How's that supposed to work? How do you determine which processes to > > kill? > > Ideally there would be a way to 'systemctl reload getty@*.service'. But > in the absence of that, 'killall agetty' is an alternative. No, please don't. This will kill any process that is called agetty, and that's way too broad. Everybody can name his processes that way, you can even dynamically change your name with prctl() at any time. This is not an OK thing to do. > > "agetty" is replaced by "login" as soon as the user type in his > > usersname. How do you make sure you don't accidentally send SIGUSR1 to > > login instead of agetty? I mean, that's a race you cannot fix. > > I guess we could make login ignore SIGUSR1. That's a hack, not more than that. What precisely are you trying to do? Why do you need to redisplay the issue output anyway?
(In reply to Lennart Poettering from comment #11) > (In reply to Stef Walter from comment #10) > > (In reply to Lennart Poettering from comment #9) > > > (In reply to Stef Walter from comment #8) > > > > Patch for agetty here: > > > > https://github.com/stefwalter/util-linux/commit/ > > > > 5c5479c73f4b3e82ee01393278d21a921dad1c35 > > > > > > How's that supposed to work? How do you determine which processes to > > > kill? > > > > Ideally there would be a way to 'systemctl reload getty@*.service'. But > > in the absence of that, 'killall agetty' is an alternative. > > No, please don't. This will kill any process that is called agetty, and > that's way too broad. Everybody can name his processes that way, you can > even dynamically change your name with prctl() at any time. This is not an > OK thing to do. It certainly would be nice to be able to run commands on all running instances of getty@.service, but systemd doesn't seem to currently be capable of that. Should I try and submit a patch for doing that in systemd? > > > "agetty" is replaced by "login" as soon as the user type in his > > > usersname. How do you make sure you don't accidentally send SIGUSR1 to > > > login instead of agetty? I mean, that's a race you cannot fix. > > > > I guess we could make login ignore SIGUSR1. > > That's a hack, not more than that. It's a way to fix the "race you cannot fix". Since you can make this purely in agetty.c, "hack" is subjective. > What precisely are you trying to do? Why do you need to redisplay the issue > output anyway? As noted in the description above. We want to include a remote access URL on the VT before login, and other useful information. agetty contains support to implement this, via escapes such as \4 and \S in /etc/issue. See 'man agetty'. These can be used to display a URL with the server's IP address, for instance. However this races on startup with DHCP addresses, and similar problems occur with other changeable information. It would be good to be able to tell agetty to display it's prompt when the information it depends on changes (such as the system IP address, or the contents of the file it uses to build its prompt).
Have agetty use inotify to monitor some file? /run/agetty/reload ?
(In reply to Colin Walters from comment #14) > Have agetty use inotify to monitor some file? /run/agetty/reload ? Sure, that could work. Is this approach being taken elsewhere?
inotify implementation: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/9343/focus=9429
Merged with minor changes (commit 6443dd43da28885302449aaca4b9c69c7f9585af). Now, "agetty --reload" reloads /etc/issue in all agetty instances. So, no signals, no public files or so. The APi is just the --reload option. Thanks Stef!
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This is now present. *** This bug has been marked as a duplicate of bug 1239089 ***
Actually, we do not have the certificate fingerprint. Should we reopen for that?
Hmmm, I guess so. Would a script in Cockpit's unit file update /etc/issue after preparing the certificate?
So the way we handled this in Fedora was to make /etc/issue a symlink to /usr/lib/issue which in turn is a symlink to one of /usr/lib/os.release.d/issue-fedora or /usr/lib/os.release.d/issue-server The actual /etc/issue file is also %config(noreplace) in the spec file, because it's intended that end-users are able to delete the symlink to /usr/lib/issue and replace it with a custom issue file on their system. So, we *could* implement one of two potential solutions: 1) Have Cockpit delete the symlink, and create its own /etc/issue file with the appropriate links and certificate information. (Down-side: we need to manually keep this in-sync with any changes we make to the standard Fedora /etc/issue) 2) Enhance agetty to support generic variable substitution coming from an environment file. This shouldn't be too difficult, as it can already do this with /etc/os-release (see agetty(8) and search for S{VARIABLE}). So we could create \V to allow it to search /etc/sysconfig/agetty in the exact same way. Then we could simply update /usr/lib/os.release.d/issue-server to read: \S Kernel \r on an \m (\l) Admin Console: https://\4:9090/ or https://[\6]:9090/ Certificate fingerprint: \V{COCKPIT_CERT_FINGERPRINT} I'm obviously in favor of 2), since it's a more generic solution that may help others down the road and leads to less synchronization trouble.
I'd like to avoid /etc/sysconfig RH-ism in agetty code, but it would be possible to use something more generic: \V{<filename>:<variable_name>} where <filename> is a file in NAME=VALUE\n format (like /etc/os-release). for example: \V{/etc/sysconfig/cockpit:COCKPIT_CERT_FINGERPRINT} This is so generic that (I hope) nobody else will ask for any issue file extension any more :-)
Karel ... that makes sense. But Stephen, I don't know about the value of having the cert fingerprint there? Whenever /etc/issue is displayed, you're typically within hands reach of the server anyway (the Server is a VM or you have a monitor hooked up to it). The cases where you really want to know the cert fingerprint are the cases where the server is far away, and cases where you won't see /etc/issue. So, IMO, this doesn't add a lot of value for the effort involved.
I was only describing ways to meet the request as originally specified. If there's insufficient value to including it, by all means re-close this bug.
Closing. If we ever want to put a cert fingerprint, lets open another bug. *** This bug has been marked as a duplicate of bug 1239089 ***