util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ruediger Meier <sweet_f_a@gmx.de>
To: Karel Zak <kzak@redhat.com>
Cc: Ludwig Nussel <ludwig.nussel@suse.de>, util-linux@vger.kernel.org
Subject: Re: agetty /etc/issue handling
Date: Tue, 6 Mar 2018 16:37:08 +0100	[thread overview]
Message-ID: <201803061637.09015.sweet_f_a@gmx.de> (raw)
In-Reply-To: <20180306143323.ssny4nslxnmsuoxu@ws.net.home>

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



  reply	other threads:[~2018-03-06 15:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2fb8c760-3be8-a77f-0ab1-ad67ebca63cb@suse.de>
2018-03-06 10:41 ` agetty /etc/issue handling Karel Zak
2018-03-06 12:27   ` Ludwig Nussel
2018-03-06 13:51     ` Ruediger Meier
2018-03-06 14:33       ` Karel Zak
2018-03-06 15:37         ` Ruediger Meier [this message]
2018-03-08 10:23           ` Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201803061637.09015.sweet_f_a@gmx.de \
    --to=sweet_f_a@gmx.de \
    --cc=kzak@redhat.com \
    --cc=ludwig.nussel@suse.de \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).