Re: agetty /etc/issue handling

[Ruediger Meier <sweet_f_a@gmx.de>]

On Tuesday 06 March 2018, Ludwig Nussel wrote:
> Karel Zak wrote:
> > On Tue, Mar 06, 2018 at 10:40:14AM +0100, Ludwig Nussel wrote:
> >> I just noticed that agetty gained support for /etc/issue.d. Very
> >> cool!
> >
> > Thanks, according this feedback
> > https://github.com/karelzak/util-linux/commit/1fc82a1360305f696dc1b
> >e6105c9c56a9ea03f52#commitcomment-27947668
> >
> > it seems that /etc/issue.d may conflict with already existing
> > solutions in OpenSUSE. Is it true?
>
> There is a package called issue-generator
> (https://github.com/thkukuk/issue-generator) that generates
> /etc/issue based on content from /{usr/lib,run,etc}/issue.d. There is
> no real conflict, just some partial overlap in features. IMO
> issue-generator would be mostly obsolete as soon as agetty reads
> those directories itself.
>
> > I'll probably add --disable-agetty-issued to make it fully
> > backwardly compatible.
>
> TBH I don't think that's necessary.
>
> >> Are there any plans to extend the way it reads those files to a
> >> systemd style layering ie with read only parts in /usr,
> >> potentially generated ones in /run etc?
> >
> > Good idea.

> >> Especially the read only part would be interesting. That way
> >> distros wouldn't need to ship /etc/isse at all and packages would
> >> put their extension in /usr. Ie no interference with admin space.
> >
> > What is expected semantic (order)?
> >
> > Note that agetty requires the /etc/issue file, the directory is an
> > extension to the file. The file may be empty or symlink. This is
> > because "rm /etc/issue" is a way how some admins disable agetty
> > output at all.
>
> Alternative semantics would be to only use issue.d if /etc/issue
> does NOT exist. That would assume that if /etc/issue exists, the
> admin created it and doesn't want anything else to be displayed. To
> display nothing the file could be created with zero size by the
> admin.
> Packages would then ship their static issue snippets in /usr and
> generate dynamic ones in /run.
> The admin would then have the option to either
> * create custom content in /etc/issue.d that would be interwoven
>    with what packages provide - or
> * create /etc/issue to only have that one displayed

Yes this would be nice.

There should be a simple way for the *admin* to disable all these issues 
directories to only show his well-maintained and tested /etc/issue, 
regardless what other packages are installed now or in the future.

To be honest, I don't really like that emergency-critical things like 
agetty will need to read dozens of files from many different file 
systems ... just for cosmetical reasons. IMO a 3rd party 
issue-generator is the better way.

cu,
Rudi

> Distributions would then have to stop shipping /etc/issue in order
> to allow the modular approach to take effect.
>
> > with layering:
> >
> >   - verify /etc/issue (access F_OK -- required)
> >   - read /etc/issue.d/*.issue
> >   - read /run/agetty/issue.d/*.issue
> >   - read /usr/lib/agetty/issue.d/*.issue
>
> Is issue.d considered agetty specific or are other gettys expected
> to follow suit? If the latter I'd omit the agetty subdirectory.
> Alternatively for consistency you'd need to use /etc/agetty/issue.d
> I guess :-)
> The ordering of layer is right. In systemd semantics files take
> preference in order, ie if the same file name exists in /etc and
> /usr, only the one in /etc would be displayed.
>
> > use-case:
> >      - /etc = system specific files
>
> ... created by the admin.
>
> >      - /run = generated files
> >      - /usr = installed 3rd party files
>
> Not just third party, that is where packages put static files, ie the
> distribution. So I'd move what we currently have in /etc/issue to
> e.g. /usr/lib(/agetty)/issue.d/10-opensuse.issue