[opensuse-factory] /etc/issue issues
I didn't check this carefully, until recently when I start seeing network adapter and ip show in the tty login screen. I discover that /etc/issue is now generated with /usr/lib/issue.d/10- openSUSE.conf which contain Welcome to openSUSE Tumbleweed 20170309 - Kernel \r (\l). But I didn't find from where come the ip, if I modify my /etc/issue and issue.net according to my needs, issue is overwriten after reboot. man /etc/issue is the man page I know this more a decade. /etc/issue doesn't belong to a package. Anybody knows which componant is taking over my changes in /etc/issue ? There's cases where important notice have to be published in this file. Thanks for help -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday, 12 March 2017 10:02:53 CET Bruno Friedmann wrote:
$ rpm -qf /etc/issue openSUSE-release-42.2-1.150.x86_64 on my openSUSE Leap 42.2 so /etc/issue *does* belong to a package.
Anybody knows which componant is taking over my changes in /etc/issue ? There's cases where important notice have to be published in this file.
I guess the package upgrade of openSUSE-release-… is doing the overwriting with the help of /usr/sbin/issue-generator in the package generation, see https://build.opensuse.org/package/view_file/openSUSE:Factory/ _product:openSUSE-release/openSUSE-release.spec?expand=1 for details -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 12.03.2017 um 10:02 schrieb Bruno Friedmann:
In the forum you can find a discussion about that: https://forums.opensuse.org/showthread.php/523674-Network-interfaces-names-d... TL;DR: a udev rule controls this: /usr/lib/udev/rules.d/90-issue-generator.rules Hendrik -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Sun, Mar 12, Bruno Friedmann wrote:
But I didn't find from where come the ip, if I modify my /etc/issue and issue.net according to my needs, issue is overwriten after reboot.
That's issue-generator, see "man issue-generator" and "man issue.d" And it is exactly from advantage for your case: that you want to provide additional informations in the issue file. With the old way, if you edited /etc/issue, you always get a conflict on the next update and upstream changes were ignored. Now you can easy add additional informations. I agree that the IP numbers and ssh keys are not from that interest on desktop machines or notebooks, but on this machines, you normally don't see them anyways, since they are hidden by the graphical login manager. But in other cases, they are very helpfull. But in the end, that's easy changeable and now you can put your own informations in that file, and you will get the changes from the release packages, too. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/12/2017 05:06 AM, Thorsten Kukuk wrote:
Ah, I presume that issue-generator can be uninstalled then? My environment requires a large multi-line warning banner to be displayed before actual login, with the user required to "click to accept" the conditions "before" login is completed. I've satisfied the requirement for remote ssh and local console logins with /etc/issue. Entering username/password satisfies the click-to-accept requirement. I've solved the problem with graphical logins by using kdm and zenity. I haven't been able to determine if sddm would work. Also, display of IP addresses before login would be totally forbidden by IA policy here. We even have to configure the graphical logins to NOT display anything about usernames and current logins. Arguments about how useless this kind of information would be to an adversary is moot. IA policy trumps all. That being said, is there a better way to display a click-through warning banner before actual login? Console logins, remote ssh logins, and graphical logins? Regards, Lew -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
12.03.2017 18:57, Lew Wolfgang пишет:
No. It is hard requirement of openSUSE-release.
You can still do the same, where is the problem?
You can disable it. At leas two different ways. I described them in the forum thread so won't repeat it here. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/12/2017 09:46 AM, Andrei Borzenkov wrote:
There's no problem yet, but if an IA control that we've been using for fifteen years changes we'd like to anticipate the issue before it becomes a problem.
You can disable it. At leas two different ways. I described them in the forum thread so won't repeat it here.
I couldn't locate your description, would you mind giving us a link for the record? Regards, Lew -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
12.03.2017 20:13, Lew Wolfgang пишет:
Well, it was the same thread in which you posted your comment :) https://forums.opensuse.org/showthread.php/523674-Network-interfaces-names-d... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Отправлено с iPhone
Why? If you replace static file (that was provided by openSUSE-release) with generator, it is logical to require generator. Otherwise you end up without any /etc/issue at all. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, 13 March 2017 7:04 Andrei Borzenkov wrote:
Why? If you replace static file (that was provided by openSUSE-release) with generator, it is logical to require generator.
I find the very idea of replacing /etc/issue unconditionally by a generator wrong. What would make much more sense to me would be a simple static issue file which could be overriden (or appended to) by an _optional_ generator. Forcing a generator on everyone is wrong. And that's not talking about the implementation which I find questionable at best. First, man page of agetty itself says it shows "the IPv4/IPv6 address" of an interface. Since 1999, there is no such thing as "the address of an interface". Network interfaces have lists of 0 or more addresses, none of them being "the one". So what does agetty actually do? Pick one of them randomly? Second, take a look at the udev rule: it adds a line for each interface with name starting with "b", "e" or "w". Can anyone explain me the logic behind this arbitrary choice? Why should e.g. a vlan interface be listed if its named "eth0.11" but not if the same interface is named "vlan11"? Why should be "bond1" and "br1" listed but "team1" or "virbr1" not? Not to mention that even on my machine at home, I would end up with 8 extra lines in my login prompt. I don't want to imagine what it's going to look like on systems of our customers if this thing ever hits SLES (let's hope it won't). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Mar 13, 2017 at 9:27 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
That's more or less what happens now. There is single base file that corresponds to old static /etc/issue. Which is actually installed by openSUSE-release as before. As for the part that adds IP addresses - yes, I find it questionable as well. But then framework is flexible enough so you can easily disable it. Whether it should be enabled by default is certainly subject to discussion. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, 13 March 2017 7:50 Andrei Borzenkov wrote:
I don't think it is. From what I've seen on Friday, the issue-generator package replaces /etc/issue by a symlink to /run/issue which is generated dynamically. And issue-generator is a hard requirement of opensuse-release. Thus if you want a static /etc/issue, you have to (a) break dependencies, (b) create a fake package named "issue-generator" or (c) create a static /etc/issue, make it immutable and hope it's enough to stop issue-generator updates from replacing it. I would understand if issue-generator generated its /run/issue but allowed users to write their own /etc/issue which would override it. Unfortunately this is not the case, it was designed with the mindset "what is good for my system is good for everyone", like many other recent changes.
I don't really like the idea of having to create an empty shadowing udev rule file to disable unwanted features as that means every slight change of name of the original file will break my system. (And such changes do happen, I already encountered that with "predictable" names rule file.) Thus I would strongly prefer making the generator as such optional. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Mar 13, Michal Kubecek wrote:
I would understand if issue-generator generated its /run/issue but allowed users to write their own /etc/issue which would override it.
It does allow that. Just do that.
That's plain wrong. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Mar 13, Michal Kubecek wrote:
If you have a better idea how to implement this, feel free to speak up. But in the end, the generator is just doing this if you disable the additional parts: take a static file and put it to /etc/issue.
Bad luck for you, it is already part of some of our enterprise products and something similar is part of enterprise products of competitors since a longer time, too. But exactly this is why it is now also part of openSUSE: to learn and that everybody can bring in his improvements. And I'm pretty sure that there are areas of improvement, since e.q. not everybody follows the automatic generated network device names of SLE. So, instead of complaining, please switch to productive mode and come with real improvements. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, 13 March 2017 7:55 Thorsten Kukuk wrote:
But in the end, the generator is just doing this if you disable the additional parts: take a static file and put it to /etc/issue.
/etc/issue is now replaced by a symlink to /run/issue
For e.g. cloud guests, containers etc., it can certainly be useful. But we also have customers running systems with hundreds or even thousands network interfaces. Those wouldn't be happy with login prompt hundreds of lines long (on a serial console).
But exactly this is why it is now also part of openSUSE: to learn and that everybody can bring in his improvements.
I don't object to having issue-generator part of openSUSE. I don't even object to having it installed (and active) by default, I'm used to the fact that I'm less and less a typical user. (OK, I do, but I could easily live with having it installed by default but possible to uninstall.) What I object to is making it hard requirement because it's - by far - not something openSUSE system couldn't live without. I must admit I don't understand it. There are people who try to weed out optional stuff by removing packages like util-linux, shadow or procps from minimal and base patterns because there are very specific systems that can live without them. And at the same time there are other people who make packages which are way more expendable than those hard dependency of the distribution itself.
This is another alarming pattern repeating in recent openSUSE development: create a questionable feature which is cool for some and annoying for others; make it obligatory and if someone complains, tell them to improve it. I don't want to spend my time on improving features that I don't want at all just because someone thought they are so cool they should be forced on everyone. Fancy extra stuff should be opt-in or at least opt-out and only those who actually want it should be asked to improve it. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Mar 13, Michal Kubecek wrote:
Means, you didn't even try it, but you are complaining ... If a /etc/issue file exists, it will not be replaced with a symlink. Except systemd changed meanwhile their behavior or there is meanwhile somewhere else a bug introduced. issue-generator was designed to be fully flexible and configureable. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, 13 March 2017 8:59 Thorsten Kukuk wrote:
Yes I didn't. In the past, I used to try fighting with installed packages and it often caused trouble later. That's why I learned to prefer cleaner solutions. In this case, uninstalling a package I have little or no use for seemed to be the cleanest one.
And there will still be file /run/issue regenerated each time list of matching devices changes. If I shadow the rule file, I have to hope its name is not going to change. If I was allowed to simply uninstall the package, everything would be much easier.
issue-generator was designed to be fully flexible and configureable.
Except for the most important part: possibility to not have it installed at all. OK, I start to see that you are strictly opposed to the very idea of someone not wanting to install your package. I'm going to create a fake empty package with the same name and sufficiently high version then. :-( Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-03-13 09:15, Michal Kubecek wrote:
Please document the current status in "man issue". - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAljGdH4ACgkQja8UbcUWM1ywkwD+IXZ3AEsW59yRwcH4xQCazWX2 q4/aeQTYYsmjYmxpxmMA/Rwjm+ooZjosEKXgoR3rLSfQRah3XPDmaViru6I4gd0P =t9/D -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2017-03-13 at 08:50 +0100, Michal Kubecek wrote:
Let's remain fair here, shall we? Thorsten did introduce the feature back in November: http://lists.opens use.org/opensuse-factory/2016-11/msg00325.html There was not a single reply to his mail - so he took the natural step forward and went ahead with the integration. Now for some this might come to a surprise, but if somebody asks for feedback and gets none, this means silent acceptance. The package in its current form is indeed a dependency to openSUSe- release, as we do want to have an 'issue' file present. /etc/issue is no longer owned by any package (as rpm -qf /etc/issue will confirm) In order to maintain a defacto working status, openSUSE-release will put a symlink in place if /etc/issue does not exist (which is at the point where openSUSe-release was updated from containing the file to no longer shipping it) From that point forward, it is now FINALLY in the admins hand to have /etc/issue show what he wants it to show, without the distro actually messing with his files (that's a good thing, isn't it?) So, you stay with the default, you have the issue-generator putting a file in /run/issue and have /etc/issue symlinked to it. in the current form, network addresses are being added (and optionally ssh key info) An admin that does not want this auto-generated can replace /etc/issue with a file of his liking - and have control over his system. As for the network address being added or not, i agree, there is room for discussion (which does not mean verbal abuse of the people doing the work!) What is missing, in my opinion, is an optin/optout feature for the network address (which does not imply shadowing uder rules) Also, in a proper long-run, agetty and 'all other tools' should learn to use /etc/issue and, if not found, fall back to /run/issue - then we could properly integrate this as a service that can be dis- and en- abled on request. I'd love to see the attitude on this mailing list to get back into a co-operative wording. Let's give credit to the people DOING the works. That does not mean we blindly accept what everybody is doing, but that we help find the optimal solution. Not everything has to be a first- time right (I wish it was) - but in actually communicating and putting use-cases down, corner cases that were missed in one iteration can be fixed. If you start your emails with claiming how bad all the work that has been done is, you will usually get exactly nothing in return, other than disgruntled devs, leading to them just going to their chambers and do things in the dark and really forcing it on you. Most of the readers on this list have been around long enough to know about this phenomen. So why push for it? -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
On Monday, 13 March 2017 13:12 Dimstar / Dominique Leuenberger wrote:
I'm sorry but I don't agree with this kind of alibism. I don't believe there is a single person who is able to follow each and every proposal sent to all openSUSE related mailing lists (except perhaps those few who have openSUSE as their daily job). There should still be some common sense telling people that such "bells and whistles" type feature should be optional. Moreover, I read the e-mail now and couldn't find any warning about the package having to be hard requirement that can't be uninstalled. Sure, there is slightly confusing part about having to modify opensuse-release but no mention of generator package not allowed to be uninstalled.
An admin that does not want this auto-generated can replace /etc/issue with a file of his liking - and have control over his system.
Except someone in the behind still doing the useless job of updating /etc/issue.d/* and /run/issue.
Verbal abuse of the _people_? Seriously? If you accused me of verbally abusing the _feature_ (or rather its implementation), I would understand. But I'm not aware of verbally abusing _people_ (or at least not here, but I hope you don't really have a microphone near my desk).
What is missing, in my opinion, is an optin/optout feature for the network address (which does not imply shadowing uder rules)
And the option not to install the issue-generator package at all.
I'd love to see the attitude on this mailing list to get back into a co-operative wording. Let's give credit to the people DOING the works.
I'm sorry again but I'm not going to give people credit for work which causes me harm (even if minor - but I already spent nontrivial amount of time by just trying to find out what the hell is going on and why). And to paraphrase your words, I would love the attitude on this maling list to get back from requiring me to credit people's work just for the work done, even if the result of that work is making my life worse.
To make myself completely clear: I consider making such "bells and whistles" feature hard requirement of every single installation wrong. If current implementation doesn't allow to make it optional, it's not ready for showtime.
I don't say all the work is bad. What I find fundamentally wrong is the "let's force it down on everyone" part. If I could just run rpm -e issue-generator zypper al issue-generator like I've done with other annoying packages I find annoying, this whole discussion would have probably never taken place. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday, 12 March 2017 10:02:53 CET Bruno Friedmann wrote:
$ rpm -qf /etc/issue openSUSE-release-42.2-1.150.x86_64 on my openSUSE Leap 42.2 so /etc/issue *does* belong to a package.
Anybody knows which componant is taking over my changes in /etc/issue ? There's cases where important notice have to be published in this file.
I guess the package upgrade of openSUSE-release-… is doing the overwriting with the help of /usr/sbin/issue-generator in the package generation, see https://build.opensuse.org/package/view_file/openSUSE:Factory/ _product:openSUSE-release/openSUSE-release.spec?expand=1 for details -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 12.03.2017 um 10:02 schrieb Bruno Friedmann:
In the forum you can find a discussion about that: https://forums.opensuse.org/showthread.php/523674-Network-interfaces-names-d... TL;DR: a udev rule controls this: /usr/lib/udev/rules.d/90-issue-generator.rules Hendrik -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Sun, Mar 12, Bruno Friedmann wrote:
But I didn't find from where come the ip, if I modify my /etc/issue and issue.net according to my needs, issue is overwriten after reboot.
That's issue-generator, see "man issue-generator" and "man issue.d" And it is exactly from advantage for your case: that you want to provide additional informations in the issue file. With the old way, if you edited /etc/issue, you always get a conflict on the next update and upstream changes were ignored. Now you can easy add additional informations. I agree that the IP numbers and ssh keys are not from that interest on desktop machines or notebooks, but on this machines, you normally don't see them anyways, since they are hidden by the graphical login manager. But in other cases, they are very helpfull. But in the end, that's easy changeable and now you can put your own informations in that file, and you will get the changes from the release packages, too. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/12/2017 05:06 AM, Thorsten Kukuk wrote:
Ah, I presume that issue-generator can be uninstalled then? My environment requires a large multi-line warning banner to be displayed before actual login, with the user required to "click to accept" the conditions "before" login is completed. I've satisfied the requirement for remote ssh and local console logins with /etc/issue. Entering username/password satisfies the click-to-accept requirement. I've solved the problem with graphical logins by using kdm and zenity. I haven't been able to determine if sddm would work. Also, display of IP addresses before login would be totally forbidden by IA policy here. We even have to configure the graphical logins to NOT display anything about usernames and current logins. Arguments about how useless this kind of information would be to an adversary is moot. IA policy trumps all. That being said, is there a better way to display a click-through warning banner before actual login? Console logins, remote ssh logins, and graphical logins? Regards, Lew -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
12.03.2017 18:57, Lew Wolfgang пишет:
No. It is hard requirement of openSUSE-release.
You can still do the same, where is the problem?
You can disable it. At leas two different ways. I described them in the forum thread so won't repeat it here. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/12/2017 09:46 AM, Andrei Borzenkov wrote:
There's no problem yet, but if an IA control that we've been using for fifteen years changes we'd like to anticipate the issue before it becomes a problem.
You can disable it. At leas two different ways. I described them in the forum thread so won't repeat it here.
I couldn't locate your description, would you mind giving us a link for the record? Regards, Lew -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Andrei Borzenkov
-
Bruno Friedmann
-
Carlos E. R.
-
Dimstar / Dominique Leuenberger
-
Hendrik Woltersdorf
-
Lew Wolfgang
-
Michal Kubecek
-
Oliver Kurz
-
Thorsten Kukuk