* Re: agetty /etc/issue handling [not found] <2fb8c760-3be8-a77f-0ab1-ad67ebca63cb@suse.de> @ 2018-03-06 10:41 ` Karel Zak 2018-03-06 12:27 ` Ludwig Nussel 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2018-03-06 10:41 UTC (permalink / raw) To: Ludwig Nussel; +Cc: util-linux 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: agetty /etc/issue handling 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 0 siblings, 1 reply; 6+ messages in thread From: Ludwig Nussel @ 2018-03-06 12:27 UTC (permalink / raw) To: Karel Zak; +Cc: util-linux 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) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: agetty /etc/issue handling 2018-03-06 12:27 ` Ludwig Nussel @ 2018-03-06 13:51 ` Ruediger Meier 2018-03-06 14:33 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: Ruediger Meier @ 2018-03-06 13:51 UTC (permalink / raw) To: Ludwig Nussel; +Cc: Karel Zak, util-linux 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: agetty /etc/issue handling 2018-03-06 13:51 ` Ruediger Meier @ 2018-03-06 14:33 ` Karel Zak 2018-03-06 15:37 ` Ruediger Meier 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2018-03-06 14:33 UTC (permalink / raw) To: Ruediger Meier; +Cc: Ludwig Nussel, util-linux 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: agetty /etc/issue handling 2018-03-06 14:33 ` Karel Zak @ 2018-03-06 15:37 ` Ruediger Meier 2018-03-08 10:23 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: Ruediger Meier @ 2018-03-06 15:37 UTC (permalink / raw) To: Karel Zak; +Cc: Ludwig Nussel, util-linux 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: agetty /etc/issue handling 2018-03-06 15:37 ` Ruediger Meier @ 2018-03-08 10:23 ` Karel Zak 0 siblings, 0 replies; 6+ messages in thread From: Karel Zak @ 2018-03-08 10:23 UTC (permalink / raw) To: Ruediger Meier; +Cc: Ludwig Nussel, util-linux 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-03-08 10:23 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 2018-03-08 10:23 ` Karel Zak
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).