12.03.2017 18:57, Lew Wolfgang пишет:

On 03/12/2017 05:06 AM, Thorsten Kukuk wrote:

...

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.

Ah, I presume that issue-generator can be uninstalled then?

No. It is hard requirement of openSUSE-release.

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.

You can still do the same, where is the problem?

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.

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

12.03.2017 20:13, Lew Wolfgang пишет:

...

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?

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

On Sunday, 12 March 2017 17:46 Andrei Borzenkov wrote:

12.03.2017 18:57, Lew Wolfgang ?????:

...

Ah, I presume that issue-generator can be uninstalled then?

No. It is hard requirement of openSUSE-release.

Which is totally wrong idea. Michal Kubeček -- 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 Monday, 13 March 2017 7:50 Andrei Borzenkov 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.

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.

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.

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:

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.

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.

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

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 Mon, Mar 13, Michal Kubecek wrote:

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

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-03-13 09:15, Michal Kubecek wrote:

On Monday, 13 March 2017 8:59 Thorsten Kukuk wrote:

...

On Mon, Mar 13, Michal Kubecek wrote:

...

/etc/issue is now replaced by a symlink to /run/issue

Means, you didn't even try it, but you are complaining ...

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.

...

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.

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

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 Monday, 13 March 2017 13:12 Dimstar / Dominique Leuenberger wrote:

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.

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.

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!)

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.

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.

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.

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?

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