Re: agetty /etc/issue handling

Re: agetty /etc/issue handling

[Karel Zak]

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/1fc82a1360305f696dc1be6105c9c56a9ea03f52#commitcomment-27947668

it seems that /etc/issue.d may conflict with already existing
solutions in OpenSUSE. Is it true?

I'll probably add --disable-agetty-issued to make it fully backwardly
compatible.

> 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.

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

use-case:
    - /etc = system specific files
    - /run = generated files
    - /usr = installed 3rd party files 

right?

IMHO it's too late to implement it for v2.32.

(CC: to our list)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: agetty /etc/issue handling

[Ludwig Nussel]

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/1fc82a1360305f696dc1be6105c9c56a9ea03f52#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

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

cu
Ludwig

-- 
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)

Re: agetty /etc/issue handling

[Ruediger Meier]

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

Re: agetty /etc/issue handling

[Karel Zak]

On Tue, Mar 06, 2018 at 02:51:36PM +0100, Ruediger Meier wrote:
> 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.

All the stuff should be optional.

The reason is that growing number of use-cases where specific
subsystem or software want to print any information by the issue file.
(I mean containers, virtualization, serial line redirections/switches,
etc.)

We don't want to store generated things in /etc (read-only, state-less
machines, ...), so at least /run (usually tmpfs) seems like good choice.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: agetty /etc/issue handling

[Ruediger Meier]

On Tuesday 06 March 2018, Karel Zak wrote:
> On Tue, Mar 06, 2018 at 02:51:36PM +0100, Ruediger Meier wrote:
> > 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.
>
> All the stuff should be optional.
>
> The reason is that growing number of use-cases where specific
> subsystem or software want to print any information by the issue
> file. (I mean containers, virtualization, serial line
> redirections/switches, etc.)
>
> We don't want to store generated things in /etc (read-only,
> state-less machines, ...), so at least /run (usually tmpfs) seems
> like good choice.

I see the use case but I don't see that we need new functionality inside 
agetty because distros could either use

  agetty --issue-file /run/generated-issues

or

  ln -sf /run/generated-issues /etc/issues

Speaking as an admin I really hate that distros nowadays introduce more 
and more techniques to let 3rd parties change global setup within /usr 
(where I don't see it) instead of using /etc which I track and review 
using git.

I fully understand that this makes it much easier for the distro 
developers. But the resulting systems are more difficult and complex to 
understand and to debug for the admins.

BTW looking over /etc we could actually use the "agetty argument" to 
introduce the "/usr-/run/-/etc merge technique" also for any other 
programs too. Why not moving the distro's default
/etc/hosts, /etc/services, /etc/ntp.conf, /etc/cron.d, *everything* 
to /usr? No more noise in /etc on upgrade/install...

Will admins be more happy when all installations and distros finally 
have the same empty /etc by default but still being completely 
differently configured *somewere* in /run and /usr?

cu,
Rudi

Re: agetty /etc/issue handling

[Karel Zak]

On Tue, Mar 06, 2018 at 04:37:08PM +0100, Ruediger Meier wrote:
> On Tuesday 06 March 2018, Karel Zak wrote:
> > On Tue, Mar 06, 2018 at 02:51:36PM +0100, Ruediger Meier wrote:
> > > 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.
> >
> > All the stuff should be optional.
> >
> > The reason is that growing number of use-cases where specific
> > subsystem or software want to print any information by the issue
> > file. (I mean containers, virtualization, serial line
> > redirections/switches, etc.)
> >
> > We don't want to store generated things in /etc (read-only,
> > state-less machines, ...), so at least /run (usually tmpfs) seems
> > like good choice.
> 
> I see the use case but I don't see that we need new functionality inside 
> agetty because distros could either use
> 
>   agetty --issue-file /run/generated-issues
> 
> or
> 
>   ln -sf /run/generated-issues /etc/issues
> 
> Speaking as an admin I really hate that distros nowadays introduce more 
> and more techniques to let 3rd parties change global setup within /usr 
> (where I don't see it) instead of using /etc which I track and review 
> using git.
> 
> I fully understand that this makes it much easier for the distro 
> developers. But the resulting systems are more difficult and complex to 
> understand and to debug for the admins.

That's all about different update cycles for different setting. The
/etc is place for manually created setup, /run for generated and /usr
for static distro stuff (from packages). You don't want to maintain 
all on the same place.

There is also dramatically growing number of systems where is no admin
at all and all is generated on the fly, root is read-only and after
installation it's expected that system (container) just works with
minimal extra tuning by post-install scripts. We have to reflect these
use-cases too.

Anyway, it's backwardly compatible. You can use /etc/issue as 20 years
ago. This is the most important thing for me. Nobody forces anyone to 
use the new features and it's distro decision if they want to use 
/usr/lib, etc. We're ready for both use-cases.

> BTW looking over /etc we could actually use the "agetty argument" to 
> introduce the "/usr-/run/-/etc merge technique" also for any other 
> programs too. Why not moving the distro's default
> /etc/hosts, /etc/services, /etc/ntp.conf, /etc/cron.d, *everything* 
> to /usr? No more noise in /etc on upgrade/install...

Maybe one day... :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com