Bug 1110763 - Fedora Server: Include cockpit url in /etc/issue
Summary: Fedora Server: Include cockpit url in /etc/issue
Keywords:
Status: CLOSED DUPLICATE of bug 1239089
Alias: None
Product: Fedora
Classification: Fedora
Component: cockpit
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stef Walter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: cockpit-F21-tracker 1108258
TreeView+ depends on / blocked
 
Reported: 2014-06-18 11:46 UTC by Stef Walter
Modified: 2016-01-20 09:49 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-01 15:00:02 UTC


Attachments (Terms of Use)

Description Stef Walter 2014-06-18 11:46:50 UTC
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.

Comment 1 Stef Walter 2014-06-18 11:47:36 UTC
Not sure what component is best for this. So please update if necessary.

Comment 2 Dennis Gilmore 2014-06-18 15:44:52 UTC
/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

Comment 3 Stef Walter 2014-07-01 11:02:26 UTC
Reassigning to cockpit for now, until there's a fedora server component.

Comment 4 Colin Walters 2014-07-01 13:13:57 UTC
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.

Comment 5 Stef Walter 2014-07-01 13:21:12 UTC
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).

Comment 6 Stef Walter 2014-07-01 13:24:31 UTC
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.

Comment 7 Stef Walter 2014-07-03 10:19:27 UTC
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.

Comment 9 Lennart Poettering 2014-07-07 10:35:49 UTC
(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.

Comment 10 Stef Walter 2014-07-07 11:02:54 UTC
(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.

Comment 11 Lennart Poettering 2014-07-07 12:01:59 UTC
(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?

Comment 12 Stef Walter 2014-07-07 12:33:48 UTC
(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).

Comment 14 Colin Walters 2014-07-07 13:37:11 UTC
Have agetty use inotify to monitor some file?  /run/agetty/reload ?

Comment 15 Stef Walter 2014-07-07 15:54:07 UTC
(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?

Comment 16 Stef Walter 2014-07-15 16:18:06 UTC
inotify implementation: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/9343/focus=9429

Comment 17 Karel Zak 2014-07-28 14:39:03 UTC
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!

Comment 18 Jaroslav Reznik 2015-03-03 17:08:48 UTC
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

Comment 19 Jan Kurik 2015-07-15 14:39:49 UTC
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

Comment 20 Stef Walter 2015-09-30 20:12:34 UTC
This is now present.

*** This bug has been marked as a duplicate of bug 1239089 ***

Comment 21 Stephen Gallagher 2015-09-30 20:14:59 UTC
Actually, we do not have the certificate fingerprint. Should we reopen for that?

Comment 22 Stef Walter 2015-09-30 20:22:34 UTC
Hmmm, I guess so. Would a script in Cockpit's unit file update /etc/issue after preparing the certificate?

Comment 23 Stephen Gallagher 2015-10-01 12:22:34 UTC
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.

Comment 24 Karel Zak 2015-10-01 13:13:11 UTC
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 :-)

Comment 25 Stef Walter 2015-10-01 13:51:20 UTC
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.

Comment 26 Stephen Gallagher 2015-10-01 13:57:09 UTC
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.

Comment 27 Stef Walter 2015-10-01 15:00:02 UTC
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 ***


Note You need to log in before you can comment on or make changes to this bug.