Am 23.10.2015 um 12:24 schrieb Richard Brown:

and yast is only a "zypper in" away

No. The way the minimal server pattern is implemented makes it impossible for people not very familiar with SUSE to install yast. I'm seeing this every day at work with cow-orkers who are used to RHEL and not SLES. Having a package / pattern that conflicts with almost everything to work around our "weak requires are way to strong" is certainly one of the worst solutions to the original problem. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2015-10-23 at 12:31 +0200, Per Jessen wrote:

Mind you: the patter is called "Minimum Server Pattern". Minimum

...

sort- of implies that bloat should be left out.

YaST = bloat ?  That's a new one to me. Oh well.

Inside a container, yes, absolutely! It just does not belong there. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stephan Kulow wrote:

On 23.10.2015 12:47, Dominique Leuenberger / DimStar wrote:

...

On Fri, 2015-10-23 at 12:31 +0200, Per Jessen wrote:

...

Mind you: the patter is called "Minimum Server Pattern". Minimum

...

sort- of implies that bloat should be left out.

YaST = bloat ? That's a new one to me. Oh well.

Inside a container, yes, absolutely! It just does not belong there.

We even got bug reports about the minimal pattern requiring a kernel

Fortunately it doesn't :-) The pure sum of installed package sizes of the minimal pattern is less than 500MB. With kernel and grub we have ~800MB. The yast2 package itself including dependencies adds ~60MB to that, plus whatever actual yast modules drag in. The actual file system usage of an installed system may deviate from those numbers though. 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) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dominique Leuenberger / DimStar wrote:

On Fri, 2015-10-23 at 12:31 +0200, Per Jessen wrote:

...

Mind you: the patter is called "Minimum Server Pattern". Minimum

...

sort- of implies that bloat should be left out.

YaST = bloat ?  That's a new one to me. Oh well.

Inside a container, yes, absolutely! It just does not belong there.

I can appreciate that, perhaps it should be deselected for such installs. In my case however, I wasn't installing into a container. -- Per Jessen, Zürich (12.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- 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: SHA1 On 24.10.15 Stefan Seyfried wrote:

Why would you use a "server" pattern with your new shiny bullshit-bingo technology?

Maybe because there is no "minimal container" / "JeOS" / "VM" pattern? Or is there? Johannes (not having installed in a long time, only dup'ed from release to release...) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlYvF4QACgkQzi3gQ/xETbIVUQCgh1XSk7LnwA9YUCZ8zsqxs/Ht duoAn1lB/SLy5pH9tN7GEhrf7qVX6B/b =RC6n -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 27.10.2015 09:44, Jan Engelhardt wrote:

On Tuesday 2015-10-27 07:19, Johannes Kastl wrote:

...

On 24.10.15 Stefan Seyfried wrote:

...

Why would you use a "server" pattern with your new shiny bullshit-bingo technology?

Maybe because there is no "minimal container" / "JeOS" / "VM" pattern? Or is there?

Such a pattern would probably just include "aaa_base" (for /etc/passwd) and /etc/zypp/repos.d (but this generally is not part of a pattern), because containers have no need for bootloaders, kernels, not even an init system, and sometimes not even a shell.

I thought about this during the weekend and while I still believe that Yast is not necessary (if fact, not wanted) in Minimal Server pattern, it should contain everything that is actually needed for a minimal server, which also includes "some kind of Kernel" and bootloader. The fact, that someone misuses Minimal Server pattern for Docker (it's not a server!), or any new technology that comes later, is not a reason for breaking that pattern for anyone else. "Minimal Container" is a nice example of how it should look like, logically. HTH ukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 23.10.2015 12:31, Per Jessen wrote:

...

* Install a server (obvious) There, it's arguable if you need yast or not... most serious server setups will be using other management tools (puppet et.al)

I'm sorry, but "ridiculous" is entirely appropriate. YaST is the one thing that distinguishes openSUSE from the rest, and we decide not to install it. I call it mind boggling.

It's always about how much "minimal" you want it. The fact is, that Yast is not "needed", it's really something additional. Yast belongs to a "standard" server though. Use case for "minimal server" here is (probably): as minimal as possible to be able to install anything else that might be "missing".

...

Mind you: the patter is called "Minimum Server Pattern". Minimum sort- of implies that bloat should be left out.

YaST = bloat ? That's a new one to me. Oh well.

OK, "bloat" sounds a little bit harsh here :) and one might get offended, but in general, he's right. But it's always about use cases, you have different opinion, because you use it for different purpose. Please describe your use case first. Thanks Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Per Jessen wrote:

...

...

...

Mind you: the patter is called "Minimum Server Pattern". Minimum sort- of implies that bloat should be left out.

YaST = bloat ? That's a new one to me. Oh well.

OK, "bloat" sounds a little bit harsh here :) and one might get offended, but in general, he's right. But it's always about use cases, you have different opinion, because you use it for different purpose. Please describe your use case first.

It hasn't changed over the years, not much anyway. I install a new server (physical or Xen) and I don't want any GUI/X primarily because it just makes the install take longer. Cutting away YaST does not reduce the installation time very much at all, it only adds hassle.

If we are to remove other "bloat", how about these: acl - Commands for Manipulating POSIX Access Control Lists audit - User Space Tools for 2.6 Kernel Auditing bc - GNU Command Line Calculator btrfsprogs - Utilities for the Btrfs filesystem ca-certificates - Utilities for system wide CA certificate installation cracklib - Library to crack passwords using dictionaries crda - something regulatory. dirmngr - A Client for Managing and Downloading CRLs efibootmgr - EFI Boot Manager fipscheck - A library for integrity verification of FIPS validated modules joe or vim - two editors?? surely a waste. krb5 - MIT Kerberos5 Implementation--Librarie libselinux1* logrotate mozilla-nspr - Netscape Portable Runtime nfs-client - Support Utilities for NFS ntp - Network Time Protocol daemon rsync strace tcsh - The C SHell tnftp - Enhanced FTP Client traceroute w3m wol - Wake On Lan client xauth - Utility to edit and display the X authorization informatio shim - UEFI shim loader Surely this crud isn't needed on a serious server. But no, instead of the "bloat" above, we remove YaST and we don't even install a firewall, not to mention iptables. A serious server doesn't need a firewall??? -- Per Jessen, Zürich (12.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jim Henderson wrote:

On Fri, 23 Oct 2015 13:22:41 +0200, Per Jessen wrote:

...

Saving disk space is not very relevant, except maybe for xen guests.

One word: Docker.

YaST is completely superfluous in a Docker container.

I am not trying to argue that YaST is needed everywhere, I just believe it is part of the minimum toolset for a server, serious or otherwise. -- Per Jessen, Zürich (12.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek wrote:

On Friday 23 of October 2015 17:22:40 Per Jessen wrote:

...

I am not trying to argue that YaST is needed everywhere, I just believe it is part of the minimum toolset for a server, serious or otherwise.

I disagree. On most of my servers, I never ran YaST since the installer finished and there is a good chance I never will.

On the other hand, I can't imagine running a server without tcpdump, netcat or screen. Someone else might feel the same about e.g. kdump. But we have enough sense not to insist those must be part of a minimal server pattern just because we want them on all _our_ servers.

Yet we insist that everyone needs e.g. strace, bc, btrfsutils, shim, wireless stuff and what have you (see my list in my previous posting). For my use, I always have to install tcpdump, postfix, syslog-ng, ipmitool and net-snmp everywhere, but I also realise that many people don't need those. Granted, it's not easy to agree on "what every user of the minimum server pattern" needs, but to focus on "serious server setups" as Dominique suggested earlier would definitely mean including tcpdump, rsyslog/syslog-ng, ipmitool and net-snmp. I have yet to come across a "serious" server without a BMC, as well a "serious" server-shop without SNMP monitoring and audit requirements for logfiles. If you can't read between the lines above, I am arguing that the openSUSE "minimal server pattern" is not at all meant for "serious server setups". IMO, it's meant for hobbyists and professionals alike and should cater to both. Also profesionals who like to use YaST for the odd job now and then :-) -- Per Jessen, Zürich (11.5°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 2015-10-23 20:07, Per Jessen wrote:

Per Jessen wrote:

...

I have yet to come across a "serious" server without a BMC,

Uh, correction - HP Proliants don't have BMC, they have ILOs.

A nice chapter on naming. From Sun/Oracle's side: ILOM, ALOM, RSC. RSC was actually the most honest one - Remote System Control. ALOM/ILO(M) being the "Lights-out manager" conveys a meaning that its primary purpose is turning off stuff, rather than to actually do something "serious" with the machine. :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Oct 23, 2015 at 07:55:55PM +0200, Per Jessen wrote:

Michal Kubecek wrote:

...

On the other hand, I can't imagine running a server without tcpdump, netcat or screen. Someone else might feel the same about e.g. kdump. But we have enough sense not to insist those must be part of a minimal server pattern just because we want them on all _our_ servers.

Yet we insist that everyone needs e.g. strace, bc, btrfsutils, shim, wireless stuff and what have you (see my list in my previous posting).

Hm... do we? I mean: did you submit a request to remove these from the minimal pattern? I guess you might have problem with e.g. btrfsutils (btrfs being the default for root filesystem) but I would be really interested in arguments why bc is a necessity (I don't believe it is; I would rather expect the only reason for it being there is that so far noone formally requested its removal). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 23 Oct 2015 17:22:40 +0200, Per Jessen wrote:

Jim Henderson wrote:

...

On Fri, 23 Oct 2015 13:22:41 +0200, Per Jessen wrote:

...

Saving disk space is not very relevant, except maybe for xen guests.

One word: Docker.

YaST is completely superfluous in a Docker container.

I am not trying to argue that YaST is needed everywhere, I just believe it is part of the minimum toolset for a server, serious or otherwise.

Respectfully, I disagree. A minimum toolset for a server, to me, is the minimum software required for the server to do what it's supposed to do, and that's it. Fewer pieces of software installed = fewer avenues open for an attacker to compromise the system. You'll no doubt disagree, and that's fine. You have the option of adding YaST when you do your installation. Everybody wins. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 23 Oct 2015 19:59:11 +0200, Per Jessen wrote:

...

You'll no doubt disagree, and that's fine. You have the option of adding YaST when you do your installation. Everybody wins.

Everybody won before too - everyone had the option of removing YaST. Nothing gained.

Counterintuitive. It's "Minimal" but I have to remove stuff? By definition, it's not minimal if you have to remove something that's not an absolute requirement.

A show of hands please, in the last 10-15 years, how many of you actually went and removed YaST from your server installations?

Proving what, exactly? That a random sampling of people on one mailing list uses YaST more than doesn't (or vice versa)? Yes, I have - several times. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 23 Oct 2015 20:11:35 +0200, Per Jessen wrote:

Jim Henderson wrote:

...

On Fri, 23 Oct 2015 19:59:11 +0200, Per Jessen wrote:

...

...

You'll no doubt disagree, and that's fine. You have the option of adding YaST when you do your installation. Everybody wins.

Everybody won before too - everyone had the option of removing YaST. Nothing gained.

Counterintuitive.

It has worked very well for years and years. Clearly not counterintuitive.

...

It's "Minimal" but I have to remove stuff?

No, you don't have to. Only if you want to.

...

By definition, it's not minimal if you have to remove something that's not an absolute requirement.

In which case our current "minimum server pattern" isn't minimum. Maybe we can reduce to the point where it's no good to anyone.

I've made my point - enabling you to continue bikeshedding here is not something I'm willing to continue discussing. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 23.10.2015 um 17:40 schrieb Jim Henderson:

You have the option of adding YaST when you do your installation.

No you don't. Try it. Adding stuff not in minimal server means deselecting minimal server, and then lots of other stuff gets included. At least this is how it was a few weeks ago when I tried this last. The way the minimal server pattern is implemented is ridiculous. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 24.10.2015 um 19:15 schrieb Richard Brown:

Perhaps it would be a nice thing to see if we can tie the minimal-server/minimal/whatever-we're-going-to-call-it pattern so it automatically unticks that option, therefore completing the installation with Recommends turned off

It would not be "a nice thing", this is the absoulute minimal requirement to make that minimal pattern usable at all.

That would remove the need for the minimal-base-conflicts blocker package which causes so much confusion (though, when I was recently translating the Release Notes, it seems we're at least mentioning the behaviour of that package in there now)

You really believe anyone is reading the release notes? Nobody does. They call me and ask why they "cannot install anything on that suhhhhseeee installed box" and that I must provide them a RHEL installation instantly. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 24.10.2015 um 21:30 schrieb Jim Henderson:

Then that's a bug and should be fixed.

YaST does have a lot of dependencies, though, so it's perhaps not surprising. But if you want YaST, then arguably (because of the dependencies), you're not looking for a "minimal server". You're looking for a server.

But the only server pattern available is the "minimal server" pattern. All others have X and other *really* bloated stuff inside :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, 25 Oct 2015 14:21:08 +0100, Stefan Seyfried wrote:

Am 24.10.2015 um 21:30 schrieb Jim Henderson:

...

Then that's a bug and should be fixed.

YaST does have a lot of dependencies, though, so it's perhaps not surprising. But if you want YaST, then arguably (because of the dependencies), you're not looking for a "minimal server". You're looking for a server.

But the only server pattern available is the "minimal server" pattern. All others have X and other *really* bloated stuff inside :-)

A quick check of my system shows that I have 60 packages with "yast" in the title on my 13.2 system, with a total of 258 unique requirements (some of them are going to be interdependencies between YaST modules, though - 147 of them do not include 'yast' in the dependency string). Total space consumed by files in the YaST packages on my system is about 45 MB. That doesn't include the dependencies, like perl and the perl modules that YaST depends on. Nor does it include the ruby requirements. For a minimal system, that might be a significant amount of space - especially for something like a docker container. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, 25 Oct 2015 17:55:02 -0400, Greg Freemyer wrote:

On Sun, Oct 25, 2015 at 5:40 PM, Jim Henderson wrote:

...

For a minimal system, that might be a significant amount of space - especially for something like a docker container.

Jim,

I think that is a red-herring.

I really think a docker container is unique enough of a requirement to have its own minimum pattern.

Fine, call it an "appliance image" then - the smaller the image when dealing with VM migration across hosts, the better. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- 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: SHA1 On 25.10.15 Yamaban wrote:

Proposal: "minimum server" (now) to become: "minimal (base for appliance or container)"

This can become the "bare minimum" that the other patterns include as common base, a "standalone server" pattern can be based on this, plus yast(ncurses), firewall, and sshd.

I would think that this is a very rational and fitting approach. Provided it is not to much hassle to have two patterns, but I doubt it is. Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlYvF3wACgkQzi3gQ/xETbKFeACdGfDRXJDJW9RFUctOOXENVemj DsgAmwUkezC8QRJPcTM4CC2nIVfWQKuU =dnGB -----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, Oct 26, 2015 at 10:50 AM, Michael Ströder wrote:

It's not only about disk space. If you have a strict security audit you're happy about every programming language (here Perl and Ruby) you don't have on the system and therefore you don't have to argue about.

perl-Bootloader is implemented in Perl (surprise) which makes it rather hard to remove Perl as dependency. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried wrote:

Am 23.10.2015 um 17:13 schrieb Jim Henderson:

...

On Fri, 23 Oct 2015 13:22:41 +0200, Per Jessen wrote:

...

Saving disk space is not very relevant, except maybe for xen guests.

One word: Docker.

YaST is completely superfluous in a Docker container.

So what? create a docker pattern. Don't cripple the minimal server pattern.

Exactly. I hesitate just writing '+1', so thanks for summing up so succinctly! -- Per Jessen, Zürich (13.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il 23/10/2015 13:22, Per Jessen ha scritto:

It hasn't changed over the years, not much anyway. I install a new server (physical or Xen) and I don't want any GUI/X primarily because it just makes the install take longer. Cutting away YaST does not reduce the installation time very much at all, it only adds hassle. Saving disk space is not very relevant, except maybe for xen guests.

Hi, is the "server" word that is outside. It should be only "minimal text installation". "minimal server installation" means nothing, which kind of server ? Web ? Mail ? File ? Print ? DB ? Web + Mail ? Print + File ? For me, minimal installation means: bash + well known classic *nix tools & utilities, zypper, vi, working network, ssh(d). Debateable: Yast with few selected modules, mc some more tools & utilities.. If you go with minimal installation, you should know what are you doing and what are your needs. You can easyli install needed packages. Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Per Jessen wrote:

Dominique Leuenberger / DimStar wrote:

...

On Fri, 2015-10-23 at 10:44 +0200, Per Jessen wrote:

...

In Milestone 2 it still worked well, but now we don't even install YaST. I'm sorry, but that's just ridiculous.

I'm not sure 'ridiculous' is a valid choice of word here... consider the various usecases for the minimum server pattern:

* Install a server (obvious) There, it's arguable if you need yast or not... most serious server setups will be using other management tools (puppet et.al)

I'm sorry, but "ridiculous" is entirely appropriate. YaST is the one thing that distinguishes openSUSE from the rest, and we decide not to install it. I call it mind boggling.

I'm not a openSUSE developer. But when setting up a minimal server removing yast is always one of the tasks. Ciao, Michael.

On Friday 23 of October 2015 13:33:17 Per Jessen wrote:

Michael Strc3b6der wrote:

...

I'm not a openSUSE developer. But when setting up a minimal server removing yast is always one of the tasks.

Why do you use openSUSE then?

Do you seriously believe YaST is the only possible reason someone could choose openSUSE? If so, you are wrong. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek wrote:

On Friday 23 of October 2015 13:33:17 Per Jessen wrote:

...

Michael Strc3b6der wrote:

...

I'm not a openSUSE developer. But when setting up a minimal server removing yast is always one of the tasks.

Why do you use openSUSE then?

Do you seriously believe YaST is the only possible reason someone could choose openSUSE? If so, you are wrong.

No, I don't believe that is the only reason, I believe it is a very important reason and certainly what truly sets us apart from the rest. -- Per Jessen, Zürich (13.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Oct 23, 2015 at 12:11 PM, Jim Henderson wrote:

On Fri, 23 Oct 2015 16:56:12 +0200, Per Jessen wrote:

...

Michal Kubecek wrote:

...

On Friday 23 of October 2015 13:33:17 Per Jessen wrote:

...

Michael Strc3b6der wrote:

...

I'm not a openSUSE developer. But when setting up a minimal server removing yast is always one of the tasks.

Why do you use openSUSE then?

Do you seriously believe YaST is the only possible reason someone could choose openSUSE? If so, you are wrong.

No, I don't believe that is the only reason, I believe it is a very important reason and certainly what truly sets us apart from the rest.

Perhaps another thing that will set us apart from the rest is being friendly to container-based deployments by not including anything more than is necessary.

Yes, but call the pattern "container minimal". Calling it "server" makes it seem like it's for a... you know... server. Which elicits thoughts of a physical machine in my language. Certainly both use cases are very different when one needs a kernel and another doesn't. Right? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Per Jessen wrote:

Claudio Freire wrote:

...

On Fri, Oct 23, 2015 at 12:11 PM, Jim Henderson wrote:

...

On Fri, 23 Oct 2015 16:56:12 +0200, Per Jessen wrote:

...

Michal Kubecek wrote:

...

On Friday 23 of October 2015 13:33:17 Per Jessen wrote:

...

Michael Strc3b6der wrote: > > I'm not a openSUSE developer. But when setting up a minimal > server removing yast is always one of the tasks.

Why do you use openSUSE then?

Do you seriously believe YaST is the only possible reason someone could choose openSUSE? If so, you are wrong.

No, I don't believe that is the only reason, I believe it is a very important reason and certainly what truly sets us apart from the rest.

Perhaps another thing that will set us apart from the rest is being friendly to container-based deployments by not including anything more than is necessary.

Yes, but call the pattern "container minimal". Calling it "server" makes it seem like it's for a... you know... server. Which elicits thoughts of a physical machine in my language.

Absolutely. A virtual server too, but first and foremost real iron.

From [1]: "A server is a computer program or a machine capable of accepting requests from clients and responding to them." => IMO a pattern name like "minimum server" or "server minimal" is perfect. [1] https://en.wikipedia.org/wiki/Server_%28computing%29 Ciao, Michael.

Michal Kubecek wrote:

On Friday 23 of October 2015 17:30:41 Per Jessen wrote:

...

Claudio Freire wrote:

...

Yes, but call the pattern "container minimal". Calling it "server" makes it seem like it's for a... you know... server. Which elicits thoughts of a physical machine in my language.

Absolutely. A virtual server too, but first and foremost real iron.

Less and less true, these days. Actually, I believe the percentage of server systems running on their dedicated physical machines is already decreasing for 10-15 years.

Maybe not quite that far back, but as Claudio says, the word "server" elicits thoughts of a physical machine. -- Per Jessen, Zürich (11.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg Freemyer wrote:

On Fri, Oct 23, 2015 at 1:11 PM, Per Jessen wrote:

...

Michal Kubecek wrote:

...

On Friday 23 of October 2015 17:30:41 Per Jessen wrote:

...

Claudio Freire wrote:

...

Yes, but call the pattern "container minimal". Calling it "server" makes it seem like it's for a... you know... server. Which elicits thoughts of a physical machine in my language.

Absolutely. A virtual server too, but first and foremost real iron.

Less and less true, these days. Actually, I believe the percentage of server systems running on their dedicated physical machines is already decreasing for 10-15 years.

Maybe not quite that far back, but as Claudio says, the word "server" elicits thoughts of a physical machine.

Roughly 10 years ago I was system architect at Ford (as a consultant).

10 years is probably more accurate - in 2005, Xen was just about getting production ready, but only just.

We were put through a physical to virtual migration. It actually failed for reasons I never understood, but they were certainly aggressively trying to consolidate physical servers into virtual platforms.

There is a lot of power to be saved. I've used virtual systems (hosted on VM/XA) for development for many years of my professional life. (stemming back to the 1980s). I have also recently migrated a number of physical openSUSE systems to virtual Xen guests. -- Per Jessen, Zürich (11.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

Me, seeing the wording "minimal server" would expect it to have more things. Certainly YaST, in text mode at least. Dunno, maybe it is easier to run a command to add yast than it is to remove it :-?

Yes, it is easily added or installed later, but many things are. What I dislike is such a significant change without discussion before or after - until now. It looks like someone just went in and did the changes willy-nilly, without considering the wider impact. This person saw fit to remove YaST, but forgot to remove <list of surplus packages> that I posted earlier. Lazy, mind boggling and irresponsible. There _is_ room for discussing the purpose and contents of the "minimum server pattern". Dominique sort of proposed it is meant for "serious server setups", but imo it certainly isn't suited for that either. It doesn't even include puppet or CFengine :-)

Why would I need yast in a minimal pattern? To configure network, for instance.

Ah, surely "vi" is sufficient, Carlos. :-) -- Per Jessen, Zürich (11.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire wrote:

I decided to get off my lazy ass, and check:

------------------------------------------------------------------- Thu Jun 11 14:01:32 UTC 2015 - lnussel@suse.de

- tweak minimal pattern to make it smaller again: * omit kernel. In theory YaST will add it for real installations. * don't install yast anymore. Should work in theory * remove adjtimex, hopefully not used anymore * remove SuSEfirewall2, needs full perl which is huge * remove eject, ntfs-3g and ntp, sysfsutils not really needed * remove release-notes-openSUSE, pulls in perl * remove vim, needs full perl :-( * require zypper instead of software stack pattern to avoid additional recommends * blacklist perl, python-base and binutils to avoid recommended packages pulling them in

The kernel thing is a bug, then, if not installed on real (or virtual but kernel-needing) installations.

I guess I'll check that.

There's a pattern for yast too, so those wanting yast could simply pick both (minimal+yast)

This all makes perfect sense to me.

I don't really like removing SuSEfirewall2. The rationale, avoiding perl, seems to be the motive.

And I like Perl to be removable. :-)

But a firewall is quite an important part of any installation really, I would consider an installation, even if minimal, without a firewall, quite irresponsible.

Yes, but it does not have to be full SuSEfirewall2 package. In case of config mgmt used the puppet/ansible/chef manifests/playbooks/receipts will setup iptables rules according to knowledge about the service(s) running on/in a system/container. Ciao, Michael.

Claudio Freire wrote:

On Fri, Oct 23, 2015 at 3:44 PM, Per Jessen wrote:

...

Carlos E. R. wrote:

...

Me, seeing the wording "minimal server" would expect it to have more things. Certainly YaST, in text mode at least. Dunno, maybe it is easier to run a command to add yast than it is to remove it :-? Yes, it is easily added or installed later, but many things are. What I dislike is such a significant change without discussion before or after - until now.

It looks like someone just went in and did the changes willy-nilly, without considering the wider impact. This person saw fit to remove YaST, but forgot to remove <list of surplus packages> that I posted earlier. Lazy, mind boggling and irresponsible.

I decided to get off my lazy ass, and check:

Thanks.

------------------------------------------------------------------- Thu Jun 11 14:01:32 UTC 2015 - lnussel@suse.de

- tweak minimal pattern to make it smaller again: * omit kernel. In theory YaST will add it for real installations. * don't install yast anymore. Should work in theory * remove adjtimex, hopefully not used anymore

I seem to recall seeing that being installed, only just this afternoon. Yep, sure enough: adjtimex-1.29-7.1.x86_64

* remove eject, ntfs-3g and ntp, sysfsutils not really needed

Well, ntp was clearly kept after all. With a default config that most serious server setups would want to change anyway.

* remove release-notes-openSUSE, pulls in perl * remove vim, needs full perl :-(

vim is still being installed.

There's a pattern for yast too, so those wanting yast could simply pick both (minimal+yast)

I did add yast and yast-network to my install earlier today. Did the trick. I think it was a total of 82Mb.

I don't really like removing SuSEfirewall2. The rationale, avoiding perl, seems to be the motive. Most of that is to avoid pulling in perl. But a firewall is quite an important part of any installation really, I would consider an installation, even if minimal, without a firewall, quite irresponsible.

Exactly!

But selecting it back is easy, and it is indeed the minimal pattern, which strives to be minimal. Pulling in full perl would indeed hurt that objective.

It's not the "minimal pattern", it's the "minimal server pattern". A very important distinction, IMHO.

So lets just add this as a warning on the release notes?

How about: "If you want YaST or a default firewall, you have to add them yourselves". TBH, that would be the worst thing to do, but I'm slowly getting past caring. /Per -- 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 10/23/2015 5:21 PM, Felix Miata wrote:

Per Jessen composed on 2015-10-23 21:22 (UTC+0200):

...

Claudio Freire wrote:

...

...

I don't really like removing SuSEfirewall2. The rationale, avoiding perl, seems to be the motive. Most of that is to avoid pulling in perl. But a firewall is quite an important part of any installation really, I would consider an installation, even if minimal, without a firewall, quite irresponsible.

...

Exactly!

That presumes the instant server isn't behind a firewall already. It should be up to those who need to be behind one or more firewalls to ensure it/they happen on purpose, and not by accident of an installer's defaults when the goal is "minimal".

I'd personally consider zypper to be essential. The zypp framework isn't tiny, but it's necessary to perform key package management tasks on a SUSE system such as updating in a reasonably easy manner. Same goes for things like aaa_base, and we'd still need things like mv/cp and a compact text editor such as nano. I wouldn't recommend using busybox to replace the core system utilities as that could break scripts that expect a full bash shell. I'd consider the kernel non-essential in a paravirtualized environment provided by Xen or KVM, since a kernel is supplied by the hypervisor itself at boot time. Of course, this wouldn't work in a fully virtualized or bare-metal environment. Perhaps we need separate patterns for paravirtualized/container and bare-metal/fully-virtualized environments, and have the system choose the right pattern depending on the detected platform? If an extremely small installation is designed in such a way that certain administrative tools are not available, it's best to note that in /etc/motd to ensure that the user isn't left helpless when programs like YaST and vi aren't available. - -- Brian "DragonLord" Wong http://www.fierydragonlord.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWKqgdAAoJEEUv29mnaAr0LA4QAM2tQ4HP5znV7KXbwZdPH8fo yKjXQwTPTCsuqVVQCvsN7gmFfeguOTYGRCvIsbXV+B7Q0AYC0kXYcOO0ttbLj5vZ wToXGc2Ay3Xlw3TWnAcrValj2MYVbifyajDqWmDNemmwBKWTF+AQ9Nu+34mVG0XC 3NcJaCEZH0nuQi4w1BDEl5a7No4ST88CBWumj0+ulgt4+fg1uruR7XiVHzD5Lk7Q t42YkyqFm2NxZcsH3ZRB0FGlcodBnc2DHOG84GiEV5rfkTbxyzV33upTc9Eh6NQ0 qZz1LsG2S17p2gDGe6yu908m/e0E8+vcfDiqc2EX3EJ7YfCtN8ci7XvDZx2bRBOZ QyR0Psb9cwIMJCIHm5g4T6yudebrdbt9rKXGsAN4RN+jiCV3GsAU46S534I392Kq ddMuHDKQ+deKphWoUpniQxQ0DwIZR5rkrXMCbhhlpUEB2VYBE0Ns6Ulqap9NZ9EN z3fRakbP2C9Nm2RljAPC8vsYXtJLhSNjMZkVngvfQWdN4VJ6AUGjMZDZ1iIljtDf s5RUNazQQ5gWLftnKDbv4VXWyCqL84+If9mUEI79d3ii9fu8jRsqit17uNTJ/dvd R6ec94flOneZ1Y4silFEY7W5ooH4tWDfkfdIdarK1rWe28OkNdNtFHYO83x7XU9q +sSaP0qY4EmVMZBfjgPB =ZvNt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

But a firewall is quite an important part of any installation really, I would consider an installation, even if minimal, without a firewall, quite irresponsible. But selecting it back is easy, and it is indeed the minimal pattern, which strives to be minimal. Pulling in full perl would indeed hurt that objective.

Really? Sorry - no: I have NEVER worked in an enterprise where the firewall was not centralized BEFORE the server farm... maintaining firewall rules in every single instance is certain to give you headaches which you do not need. Do yourself a favor, get an IDS/IPS and live happily ever after. THEN we talk about serious implementations with servers. SUSE Firewall is nice for what it can do... but installing / configuring it on every single VM instance in your network is mind numbing and means you do your job in a way to extort money from your employer - and not to do a good job. (this is my personal opinion, not related to any employer of past, present of future). Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Oct 23, 2015 at 7:32 PM, Dominique Leuenberger / DimStar wrote:

...

But a firewall is quite an important part of any installation really, I would consider an installation, even if minimal, without a firewall, quite irresponsible. But selecting it back is easy, and it is indeed the minimal pattern, which strives to be minimal. Pulling in full perl would indeed hurt that objective.

Really? Sorry - no: I have NEVER worked in an enterprise where the firewall was not centralized BEFORE the server farm... maintaining firewall rules in every single instance is certain to give you headaches which you do not need.

Do yourself a favor, get an IDS/IPS and live happily ever after. THEN we talk about serious implementations with servers.

What Jim said, plus:

SUSE Firewall is nice for what it can do... but installing / configuring it on every single VM instance in your network is mind numbing and means you do your job in a way to extort money from your employer - and not to do a good job.

Ok, you don't like working with SUSE firewall, then don't talk about it. The whole point of it is that it's quite easy to set up for simple stuff (most servers will have simple firwall setups). But regardless of preference, firewall by default -> no firewall by default, is a change that can bite a lot of people unaware. Hence my suggestion to put it on the release notes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire wrote:

But regardless of preference, firewall by default -> no firewall by default, is a change that can bite a lot of people unaware. Hence my suggestion to put it on the release notes.

It's certainly a significant change, but no matter where you put it, it'll likely still bite people - when they neglect to study the release notes in detail. -- Per Jessen, Zürich (11.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Claudio Freire wrote:

On Mon, Oct 26, 2015 at 1:50 PM, Per Jessen wrote:

...

Claudio Freire wrote:

...

But regardless of preference, firewall by default -> no firewall by default, is a change that can bite a lot of people unaware. Hence my suggestion to put it on the release notes.

It's certainly a significant change, but no matter where you put it, it'll likely still bite people - when they neglect to study the release notes in detail.

Nothing can be done to fix that, but at least if added, it won't bite people that apply due diligence when performing the upgrade/install.

I don't believe we ought to guide our choices by thinking of the other group. The other group will always find a way to screw up, and a minimal install isn't something newbies are likely to attempt, so for the target audience missing the warning would be inexcusable in any case.

Well, I think we ought err on the side of caution and keep the firewall by default. It's by far the safest option. Removing it and putting that in the release notes is corporate style CYA. No offence to anyone. -- Per Jessen, Zürich (9.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26 October 2015 at 19:29, Per Jessen wrote:

Per Jessen wrote:

...

Well, I think we ought err on the side of caution and keep the firewall by default. It's by far the safest option.

I forget, it's too late for that, sorry.

I hate to be the grumpy (old?) man pointing out the obvious but I'd like to remind everyone that every single user of Leap, as part of every single install, will be informed of their impending installations firewall status (whether it be on or off) as part of the Installation Settings page https://openqa.opensuse.org/tests/96220/modules/installation_overview/steps/... https://openqa.opensuse.org/tests/96213/modules/installation_overview/steps/... If it's on and they want it off, they can click that disable link next to "Firewall will be enabled" If it's off and they want it on, they can click that enable link next to "Firewall will be disabled" Considering that, I think the idea of putting a comment in the release notes is theoretically unnecessary, but nice to do. With the built in information provided to every user upon installation regarding the status of their installation, and maybe an extra reminder in release notes, I really do not think this topic is worth too many more posts.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26 October 2015 at 20:58, Per Jessen wrote:

Yeah you're absolutely right. A newbie would carefully be checking every setting, the experienced admin would be more into assuming everything is as last time. We provide the defaults more for the newbie than for the experienced admin.

Assuming your tone is intentionally sarcastic, I think it's fair to say that we cannot and should not always "optimise for absolute beginners" In this day and age, an individuals computer security should be considered at least somewhat of their own responsibility. We provide the tools for that, and we provide sensible defaults for the scenarios we offer But lets entertain the thought of ensuring our newbie experience is sensible For newbies, they are likely to install KDE or GNOME, where the firewall is enabled by default Yes, it's disabled by default in the minimal install, but if you truly believe a newbie can handle a console-only installation, but needs to have a firewall automatically enabled by default because it's too hard..then you must have a very different definition of newbie than I do.. I'd consider that an 'advanced' scenario, and I think our defaults fit that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello Dominique and all, On 2015-10-24 T 00:32 Dominique Leuenberger / DimStar wrote:

...

But a firewall is quite an important part of any installation really, I would consider an installation, even if minimal, without a firewall, quite irresponsible. But selecting it back is easy, and it is indeed the minimal pattern, which strives to be minimal. Pulling in full perl would indeed hurt that objective.

Really? Sorry - no: I have NEVER worked in an enterprise where the firewall was not centralized BEFORE the server farm... maintaining firewall rules in every single instance is certain to give you headaches which you do not need.

Do yourself a favor, get an IDS/IPS and live happily ever after. THEN we talk about serious implementations with servers.

SUSE Firewall is nice for what it can do... but installing / configuring it on every single VM instance in your network is mind numbing and means you do your job in a way to extort money from your employer - and not to do a good job.

while I do not disagree with your assessment and advice in general, the challenge is that many companies expect or even require that on every system a firewall is installed and active, otherwise the system would not be considered "compliant". Now, obviously this is more important to the SUSE Linux Enterprise world than to the openSUSE universe, yet it should be considered, as otherwise the use and acceptance of any "minimal" selection would be unnecessarily limited / prohibited. To put this more generally: I suggest to not start from the view, what can be left out to achieve a minimal selection, but to agree on the minimum functionality that should be available, to allow an adminitrator with "average experience" to successfully start a secure production server from that "minimal". In addition, mixing the requirements of a (full) operating system (either bare metal or as a VM) with the (even more reduced) needs of an application container such as Docker, does not necessarily lead to the best results on either end. Back to the question of SuSEFirewall2: I wholeheartedly agree that its dependency on perl leaves room for improvement, aeh, well, size reduction; however, perl might be needed anyways. ... Do you know? So long - MgE -- Matthias G. Eckermann - Senior Product Manager SUSE® Linux Enterprise SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Oct 24 01:10 Matthias G. Eckermann wrote (excerpt):

... agree on the minimum functionality that should be available, to allow an adminitrator with "average experience" to successfully start a secure production server from that "minimal". ... perl might be needed anyways

Perhaps perl is already needed in practice for an adminitrator with "average experience" to let him successfully do his work as he is used to do it. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - 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

Hello, On Oct 26 19:48 Michael Ströder wrote (excerpt):

Johannes Meixner wrote:

...

On Oct 24 01:10 Matthias G. Eckermann wrote (excerpt):

...

... agree on the minimum functionality that should be available, to allow an adminitrator with "average experience" to successfully start a secure production server from that "minimal". ... perl might be needed anyways

Perhaps perl is already needed in practice for an adminitrator with "average experience" to let him successfully do his work as he is used to do it.

Then he/she should be able to install it

Which is what I had already written in this thread: "Basically with a really minimum pattern the only thing that must work is bash and 'zypper install'." But I think this contradicts what Matthias G. Eckermann had meant - as far as I understand him. It seems it is going in circles (as often). Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg)

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2015-10-24 00:32, Dominique Leuenberger / DimStar wrote:

...

...

But a firewall is quite an important part of any installation really, I would consider an installation, even if minimal, without a firewall, quite irresponsible. But selecting it back is easy, and it is indeed the minimal pattern, which strives to be minimal. Pulling in full perl would indeed hurt that objective.

Really? Sorry - no: I have NEVER worked in an enterprise where the firewall was not centralized BEFORE the server farm... maintaining firewall rules in every single instance is certain to give you headaches which you do not need.

Well, not every openSUSE user is installing servers in such enterprises. It can be very small setups and homes, too.

Yes, a webserver with owncloud on a dynamic IP for instance. I also don't install the SUSEfirewall because we have a central firewall, but most customers will likely want the firewall on their rented servers. -- Per Jessen, Zürich (11.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 23.10.2015 um 21:09 schrieb Claudio Freire:

There's a pattern for yast too, so those wanting yast could simply pick both (minimal+yast)

No, they can't. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 24.10.2015 um 20:10 schrieb Jan Engelhardt:

On Saturday 2015-10-24 18:59, Stefan Seyfried wrote:

...

Am 23.10.2015 um 21:09 schrieb Claudio Freire:

...

There's a pattern for yast too, so those wanting yast could simply pick both (minimal+yast)

No, they can't.

Why is that actually? Fedora and Debian allow choosing one's favorite set of patterns...

Try it. The implementation is ... ... ahem ... "suboptimal". Selecting "minimal server" installs a pattern that conflicts with almost everything (probably in order to fend off the ... ... ahem ... "suboptimal" handling of weak requires (Suggests/recommends). So if you select another pattern, you always need to deselect "minimal server". And if you later, in the installed system try to insstall something, you are told that you need to remove the minimal server selection. Which most people, who are not use to this, ... ahem ... "suboptimal" implementation will not do (of course you do not want to remove the "minimal requirements for a server", because of course you think you need them). That's the moment they call me and tell me they cannot use "my" SLES and that they need RHEL instead. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 26.10.2015 um 15:07 schrieb Dominique Leuenberger / DimStar:

On Sat, 2015-10-24 at 20:15 +0200, Stefan Seyfried wrote:

...

That's the moment they call me and tell me they cannot use "my" SLES and that they need RHEL instead.

so if YOU install the SLE and/or RHEL for them,

I'm the one telling them they should use SLE instead of RHEL, not the one installing it for them :-)

(fixing those patterns won't happen before Leap 42.1 I'm afraid.. but that topic should certainly be kept warm for post-release)

My Leap installs will most likely not be minimal, so I'm already happy if I get a proper minimal pattern with SP1 :-P And there probably is a reason why the minimal pattern was implemented the way it is many moons ago -- and because "it worked so well", the underlying issues are probably still the same, so fixing the pattern might not be easy. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Strc3b6der wrote:

Per Jessen wrote:

...

Carlos E. R. wrote:

...

Me, seeing the wording "minimal server" would expect it to have more things. Certainly YaST, in text mode at least. Dunno, maybe it is easier to run a command to add yast than it is to remove it :-?

Yes, it is easily added or installed later, but many things are. What I dislike is such a significant change without discussion before or after - until now.

It looks like someone just went in and did the changes willy-nilly, without considering the wider impact. This person saw fit to remove YaST, but forgot to remove <list of surplus packages> that I posted earlier. Lazy, mind boggling and irresponsible.

There _is_ room for discussing the purpose and contents of the "minimum server pattern". Dominique sort of proposed it is meant for "serious server setups", but imo it certainly isn't suited for that either. It doesn't even include puppet or CFengine :-)

I'd vote for a minimal pattern which just boots the OS. The term "JEOS" is already used which also might be a suitable pattern name.

For mass deployment with configuration management this could be used by admins as a base for PXE installation boot. After that only the favourite config mgmt system has to be installed and it will take over for the rest.

My suggestion is that mass deployment is not the prevalent use case amongst openSUSE users of the "minimum server pattern". -- Per Jessen, Zürich (11.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 24.10.2015 um 00:26 schrieb Francisco J. Tsao Santin:

I think the discussion is very interesting, but it's much more quick enabling yast patterns at the installer than reading near 80 emails :-D

If it would work, then yes. But it doesnt. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2015-10-23 20:44, Per Jessen wrote:

Carlos E. R. wrote:

Ah, surely "vi" is sufficient, Carlos. :-)

Nay :-) I can't work with it. I'd need network to get zypper running, then install "joe" for further edits, then Midnight Commander. Joe has been included even in the minimal rescue image since many years. True, seasoned "unix" admins will know how to handle vi easily and efficiently, but those of us coming from Windows will not. So, a good choice to add "joe" to the pattern. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Fri, Oct 23, 2015 at 12:38 PM, Jim Henderson wrote:

On Fri, 23 Oct 2015 12:19:30 -0300, Claudio Freire wrote:

...

Yes, but call the pattern "container minimal". Calling it "server" makes it seem like it's for a... you know... server. Which elicits thoughts of a physical machine in my language.

It doesn't in mine. Certainly, I have had occasion to create virtual servers where having YaST also was something that wasn't necessary because it was purpose-built for a specific purpose.

When using virtualization orchestration technologies (for example), a really, really minimal image is essential to being able to (for example) move a VM from one host to another when doing load balancing of compute resources.

Alright. But, VMs still require kernels, and that's the critical distinction I was trying to make. Containers don't. In essence, a container is a special case of environment that would be wrong to conflate with the case of full machines, either physical or virtual. Usually, a system can ignore the presence of a hypervisor, but a container cannot ignore the host it runs on. In fact, I would bet it's very tricky getting an openSUSE "minimal server" running in a CentOS docker. So separate patterns seem make sense IMO. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Oct 23, 2015 at 1:52 PM, Jim Henderson wrote:

On Fri, 23 Oct 2015 13:01:42 -0300, Claudio Freire wrote:

...

On Fri, Oct 23, 2015 at 12:38 PM, Jim Henderson wrote:

...

On Fri, 23 Oct 2015 12:19:30 -0300, Claudio Freire wrote:

...

Yes, but call the pattern "container minimal". Calling it "server" makes it seem like it's for a... you know... server. Which elicits thoughts of a physical machine in my language.

It doesn't in mine. Certainly, I have had occasion to create virtual servers where having YaST also was something that wasn't necessary because it was purpose-built for a specific purpose.

When using virtualization orchestration technologies (for example), a really, really minimal image is essential to being able to (for example) move a VM from one host to another when doing load balancing of compute resources.

Alright. But, VMs still require kernels, and that's the critical distinction I was trying to make.

Containers don't.

In essence, a container is a special case of environment that would be wrong to conflate with the case of full machines, either physical or virtual. Usually, a system can ignore the presence of a hypervisor, but a container cannot ignore the host it runs on. In fact, I would bet it's very tricky getting an openSUSE "minimal server" running in a CentOS docker.

So separate patterns seem make sense IMO.

I don't entirely disagree with that assessment.

But there is a point where having lots of different patterns would create more confusion (not to mention maintenance).

Maybe a better approach is needed - layered patterns or something like that.

AFAIK patterns can require patterns, so it would be possible to factor out the common parts of both minimal variants into a minimal base pattern. But I do see the potential confusion lots of patterns would create. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2015-10-23 at 19:19 +0200, Per Jessen wrote:

Jim Henderson wrote:

...

On Fri, 23 Oct 2015 13:01:42 -0300, Claudio Freire wrote:

...

On Fri, Oct 23, 2015 at 12:38 PM, Jim Henderson wrote:

...

On Fri, 23 Oct 2015 12:19:30 -0300, Claudio Freire wrote:

Would you guys mind moving this discussion to the forums?  This is generating a lot of mail traffic for a lot of people, while only a few are engaged in the conversation. I'm much prefer to read the outcome on the forums, than keep hitting delete in my mail client every few minutes ;-) -- James Mason Technical Architect, Public Cloud openSUSE Member SUSE jmason@suse.com ------------------------------------- SUSECon 2015: Register at susecon.com

23.10.2015 21:06, Per Jessen пишет:

James Mason wrote:

...

On Fri, 2015-10-23 at 19:19 +0200, Per Jessen wrote:

...

Jim Henderson wrote:

...

On Fri, 23 Oct 2015 13:01:42 -0300, Claudio Freire wrote:

...

On Fri, Oct 23, 2015 at 12:38 PM, Jim Henderson wrote:

...

On Fri, 23 Oct 2015 12:19:30 -0300, Claudio Freire wrote:

Would you guys mind moving this discussion to the forums?

Yes.

Yes you will mind or yes you will move? :p -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 23 Oct 2015 19:19:28 +0200, Per Jessen wrote:

...

But there is a point where having lots of different patterns would create more confusion (not to mention maintenance).

Yes, we don't want too many either, but we should cater to a handful of most often used patterns. Personally speaking, I use the "minimum server pattern" frequently, either on real iron or (less frequently) on xen.

I think, then, ultimately, that the goal of a minimal pattern should be to be truly minimal for all use cases, and then permit the user to add to it as they need to. To me, "minimal" means "absolute core required components". In that spirit, YaST isn't part of an *absolute* requirement, so leaving it out makes perfect sense. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Jim Henderson [10-23-15 12:54]: [...]

But there is a point where having lots of different patterns would create more confusion (not to mention maintenance).

Maybe a better approach is needed - layered patterns or something like that.

So, perhaps a better approach would be constructions such as: minimal which is only enough to provide a running instance and following with additional "patterns" server-web server-mail video-games video-photography ... and the system built on these components which complement each other. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello Michael, On Oct 23 13:24 Michael Ströder wrote (excerpt):

But when setting up a minimal server removing yast is always one of the tasks.

Could you provide your personal reasons why you do not want to have YaST on your servers. I know this is often the case and I can imagine various reasons for it but I like to learn what various actual reasons are. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg)

Michael Strc3b6der wrote:

Johannes Meixner wrote:

...

On Oct 23 13:24 Michael Ströder wrote (excerpt):

...

But when setting up a minimal server removing yast is always one of the tasks.

Could you provide your personal reasons why you do not want to have YaST on your servers.

I know this is often the case and I can imagine various reasons for it but I like to learn what various actual reasons are.

My personal reasons:

1. When I started to use Linux (also SuSE Linux) professionally back in '96 there were no tools like yast.

When did YaST turn up? - I also got my first SuSE Linux back then (4.4.1 I think it was), ISTR YaST being a great help. (I was a Linux newbie, until then I'd been working with mainframes).

As said: Just personal opinion and no offense against yast. But I do appreciate that it's possible to remove it.

Which is fair enough - but how many users are like you and prefer to remove YaST from their servers? -- Per Jessen, Zürich (11.5°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Strc3b6der wrote:

Per Jessen wrote:

...

Michael Strc3b6der wrote:

...

Johannes Meixner wrote:

...

On Oct 23 13:24 Michael Ströder wrote (excerpt):

...

But when setting up a minimal server removing yast is always one of the tasks.

Could you provide your personal reasons why you do not want to have YaST on your servers.

I know this is often the case and I can imagine various reasons for it but I like to learn what various actual reasons are.

My personal reasons:

1. When I started to use Linux (also SuSE Linux) professionally back in '96 there were no tools like yast.

When did YaST turn up?

Not sure. At least it was not usable for my installations back then.

I can't remember, but I'm pretty certain YaST was one of the reasons I chose to stay with SuSE.

...

...

As said: Just personal opinion and no offense against yast. But I do appreciate that it's possible to remove it.

Which is fair enough - but how many users are like you and prefer to remove YaST from their servers?

I can't tell. But does it matter?

Of course it does - unless the majority of people installing servers remove YaST afterwards, we should include it. The "minimum server pattern" should cater to the majority. -- Per Jessen, Zürich (11.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Strc3b6der wrote:

Per Jessen wrote:

...

Of course it does - unless the majority of people installing servers remove YaST afterwards, we should include it. The "minimum server pattern" should cater to the majority.

The decision "yast or not" is not sufficient. You would also have to decide on the various yast modules.

I agree, my proposal would be to revert to what we had in 13.2. -- Per Jessen, Zürich (11.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

On Friday 2015-10-23 14:05, Johannes Meixner wrote:

...

On Oct 23 13:24 Michael Ströder wrote (excerpt):

...

But when setting up a minimal server removing yast is always one of the tasks.

Could you provide your personal reasons why you do not want to have YaST on your servers.

It takes "ages" to start (yast2 firewall => 4 to 5 seconds), and I am just quicker (and have the necessary experience) to just edit the appropriate configuration files directly to, say, add a port to the don't-filter list.

I only resort(ed) to yast when the configuration of a component is overly clumsy -- pppd is one of those cases. But by now, the days of ISDN and PPPoE are gone. (It's all DHCP and and/or NAT by now.)

I use YaST for network config (because I can't remember all those parameters) and udev ditto (for renaming to unpredicable device names). As an aside - with Leap we have returned to unpredictable network interface naming, but nobody seems to have complained? I guess it wasn't really that important after all. -- Per Jessen, Zürich (11.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

On Friday 2015-10-23 19:41, Per Jessen wrote:

...

As an aside - with Leap we have returned to unpredictable network interface naming, but nobody seems to have complained? I guess it wasn't really that important after all.

We did not return to - we never left.

Huh? AFAICT, openSUSE 13.2 had predictable network interface naming and Leap42 doesn't. (unless our opinions of "predictable" differ).

Leap 42.1 still has systemd-210 (and everything surrounding that), like openSUSE 13.2.

But in Leap42 I get "eth0", in openSUSE 13.2 I get "enps0f1q4" ? Don't misunderstand me, I much prefer "ethX" instead of "enps0f1q4" but I am surprised noone has complained about this obvious regression. -- Per Jessen, Zürich (11.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Oct 23, 2015 at 10:01:44PM +0200, Jan Engelhardt wrote:

On Friday 2015-10-23 20:28, Per Jessen wrote:

...

...

We did not return to - we never left.

Huh? AFAICT, openSUSE 13.2 had predictable network interface naming and Leap42 doesn't. (unless our opinions of "predictable" differ).

...

Leap 42.1 still has systemd-210 (and everything surrounding that), like openSUSE 13.2.

But in Leap42 I get "eth0", in openSUSE 13.2 I get "enps0f1q4" ?

13.2 and 42.1 have that ominous patch entitled 1021-udev-re-add-persistent-net-rules.patch. TW does not.

Yet, 13.2 and TW are the ones where one can see the predictable enp* interfaces. Go figure :-(

Leap is SLES-12 based and most (nearly all) customers and vendors of SLES-12 had insist on using the persistent net rules. The predictable naming scheme had resulted in a lot of complaints. It should be noted that to respect those complaints was not my decision but as SLES-12 is product for customers and vendors I can live with it. This depends on the configuration of the project, that is this can be changed by setting the suse_version != 1315. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

On Sat, Oct 24, 2015 at 12:45:27PM +0200, Jan Engelhardt wrote:

On Saturday 2015-10-24 11:38, Dr. Werner Fink wrote:

...

Leap is SLES-12 based and most (nearly all) customers and vendors of SLES-12 had insist on using the persistent net rules. The predictable naming scheme had resulted in a lot of complaints.

It should be noted that to respect those complaints was not my decision but as SLES-12 is product for customers and vendors I can live with it.

This depends on the configuration of the project, that is this can be changed by setting the suse_version != 1315.

So the %if line should in fact include %is_opensuse rather than just suse_version=1315.

Where can I find this macro? grep is_opensuse /abuild/oscbuild/{SLE-12-SP1,openSUSE_Factory}/{usr/lib,etc}/rpm/ -rs show nothing here. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

On Sun, Oct 25, 2015 at 05:14:49PM +0100, Jan Engelhardt wrote:

On Sunday 2015-10-25 14:05, Dr. Werner Fink wrote:

...

...

So the %if line should in fact include %is_opensuse rather than just suse_version=1315.

Where can I find this macro?

grep is_opensuse /abuild/oscbuild/{SLE-12-SP1,openSUSE_Factory}/{usr/lib,etc}/rpm/ -rs

$ osc meta prjconf openSUSE:Factory | grep is_op %define is_opensuse 1 %is_opensuse 1

(also for Leap:42.1)

Nive but for local builds this seems not to be true as is_opensuse seems not to be defined anywhere below .osc/__buildconfig* I'd like to have exactly the same results on OBS as for local build in chroot environments. Otherwise debugging is not possible: systemd/Legacy> osc meta prjconf openSUSE:Factory | grep is_op %define is_opensuse 1 %is_opensuse 1 systemd/Legacy> grep -rs is_opensuse .osc/ systemd/Legacy> such configurations are very annoying. Beside this a public-opinion poll would be an option For Leap 42.1 do you prefere [ ] Persistent network device naming like eth0, ... http://www.tldp.org/LDP/nag2/x-087-2-hwconfig.tour.html [ ] Predictable network device naming enp0s3, ... http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface... [ ] I do not care about network device naming [ ] I do not know what this is about ... becasue this is for the users and system adminstrators out there. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

On Mon, Oct 26, 2015 at 11:41:06AM +0100, Andreas Schwab wrote:

"Dr. Werner Fink" writes:

...

systemd/Legacy> osc meta prjconf openSUSE:Factory | grep is_op %define is_opensuse 1 %is_opensuse 1 systemd/Legacy> grep -rs is_opensuse .osc/ systemd/Legacy>

Base:System:Legacy which indeed should be build for Leap as well as for SLES-12 and SLES-12-SP1 ... openSUSE:Factory is not required as systemd-210 is not for openSUSE:Factory. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

On Mon, Oct 26, 2015 at 12:54:05PM +0100, Andreas Schwab wrote:

"Dr. Werner Fink" writes:

...

osc build --root /abuild/oscbuild/openSUSE_13.1 openSUSE_13.1 systemd.spec osc build --root /abuild/oscbuild/openSUSE_13.2 openSUSE_13.2 systemd.spec

do not exit ...

As expected.

Indeed ... is_opensuse is useless -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

On Mon, 2015-10-26 at 14:23 +0100, Dr. Werner Fink wrote:

On Mon, Oct 26, 2015 at 12:54:05PM +0100, Andreas Schwab wrote:

...

"Dr. Werner Fink" writes:

...

  osc build --root /abuild/oscbuild/openSUSE_13.1 openSUSE_13.1 systemd.spec   osc build --root /abuild/oscbuild/openSUSE_13.2 openSUSE_13.2 systemd.spec

do not exit ...

As expected.

Indeed ... is_opensuse is useless

is_opensuse is a new introduction for Leap, as the differentiation from SLE needed to be easier achieved, without solely relying on suse_version (sle12 and Leap both share 1315). Changing the configuration of release products sounds like a plan - and will cause all kind of different behaviour that are not expected by other spec file writers. The feature is there, it's up to the .spec file writers to make use of it or let it be... Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Oct 26, 2015 at 02:50:53PM +0100, Jan Engelhardt wrote:

On Monday 2015-10-26 14:23, Dr. Werner Fink wrote:

...

On Mon, Oct 26, 2015 at 12:54:05PM +0100, Andreas Schwab wrote:

...

"Dr. Werner Fink" writes:

...

osc build --root /abuild/oscbuild/openSUSE_13.1 openSUSE_13.1 systemd.spec osc build --root /abuild/oscbuild/openSUSE_13.2 openSUSE_13.2 systemd.spec

do not exit ...

As expected.

Obviously, %is_opensuse is for leap & tw. classic_opensuse (%suse_version <= 1320 && %suse_version != 1315) is not touched.

Then %is_opensuse is not a replacement for %suse_version == 1315 -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

On Mon, 2015-10-26 at 15:48 +0100, Dr. Werner Fink wrote:

 

...

Obviously, %is_opensuse is for leap & tw. classic_opensuse (%suse_version <= 1320 && %suse_version != 1315) is not touched.

Then %is_opensuse is not a replacement for %suse_version == 1315

No, it's an addition... you could never replace an int with a boolean. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Oct 26, 2015 at 04:06:36PM +0100, Jan Engelhardt wrote:

On Monday 2015-10-26 15:48, Dr. Werner Fink wrote:

...

On Mon, Oct 26, 2015 at 02:50:53PM +0100, Jan Engelhardt wrote:

...

On Monday 2015-10-26 14:23, Dr. Werner Fink wrote:

...

On Mon, Oct 26, 2015 at 12:54:05PM +0100, Andreas Schwab wrote:

...

"Dr. Werner Fink" writes:

...

osc build --root /abuild/oscbuild/openSUSE_13.1 openSUSE_13.1 systemd.spec osc build --root /abuild/oscbuild/openSUSE_13.2 openSUSE_13.2 systemd.spec

do not exit ...

As expected.

Obviously, %is_opensuse is for leap & tw. classic_opensuse (%suse_version <= 1320 && %suse_version != 1315) is not touched.

Then %is_opensuse is not a replacement for %suse_version == 1315

%if 0%{?suse_version} == 1315 && !0%{?is_opensuse} /* SLE12 */ eth* %else enp* %endif

1315 is not used for *any* openSUSE product but *only* for SLES-12 based products. And the core of Leap is SLES-12 based AFAIU ;P Therefore I'd like to know what the users say about the network schemes. *Is* there a majority of the users which indeed prefere to use the predictable networl naming. I had already post a ballot paper and I'd like to see some results. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

+1 On 10/26/2015 10:12 AM, Jan Engelhardt wrote:

On Monday 2015-10-26 11:12, Dr. Werner Fink wrote:

...

Beside this a public-opinion poll would be an option

For Leap 42.1 do you prefere (choose one) ... becasue this is for the users and system adminstrators out there. [ ] Persistent network device naming like eth0, ... http://www.tldp.org/LDP/nag2/x-087-2-hwconfig.tour.html [x] Predictable network device naming enp0s3, ... http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface... [ ] I do not care about network device naming [ ] I do not know what this is about

More specifically, [x] Do as upstream does.

-- Cameron Seader Systems Engineer SUSE cs@suse.com (w)208-572-0095 (M)208-420-2167 Register for SUSECon 2015 www.susecon.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

G'day all, As long as there is a choice and it is easy, I don't think it matters. Perhaps a nice "tick box" in YaST would be a good feature one day, but probably not (see the last point below). As for what should be default, I personally thing it should be Predictable since: * It is easy to change to Persistent from Predictable, but not necessarily as easy the other way. (To disable Predictable IF naming, just add "net.ifnames=0" to your boot cmdline). * It is what most other distros are doing. * It is supported in upstream. * People have started to get used to it and rely on it. * People who get bugged by it probably have specific reasons for it and are also the people who will have no problems disabling it. If having eth0 instead of enp0s25 causes problems with some program, then it should be (and is) classed as a bug and you can (and probably should) report it. I run Tumbleweed as my day-to-day on my laptop and I use Persistent naming since I am just used to typing eth0/wlan0/wwan0 etc. My main server that runs CentOS usually uses br0, br1 etc since I am bridging for VMs and I also use LACP and VLANs etc so the network config is fairly crazy. Other servers I have use Predictable since I can't be stuffed changing it and my network config is fairly static (particularly in VM guests). Some of the other guys here run with Predictable and I find it a nuisance that I have to first find the name of the device before I can do anything with it, but in general it doesn't exactly take up my entire day and they guys who run Predictable really seem to like it (one of them also runs Gnome 3 since he is a masochist). Just my 0.02. -- Ben Ben Holmes Customer Engineer Interactive Pty Ltd Telephone +61 7 3323 0800 Facsimile +61 7 3323 0899 Mobile +61 421 406 456 www.interactive.com.au ------Confidentiality & Legal Privilege------------- "This email is intended for the named recipient only. The information contained in this message may be confidential, or commercially sensitive. If you are not the intended recipient you must not reproduce or distribute any part of the email, disclose its contents to any other party, or take any action in reliance on it. If you have received this email in error, please contact the sender immediately. Please delete this message from your computer. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you." ________________________________________ From: ilmehtar@gmail.com [ilmehtar@gmail.com] on behalf of Richard Brown [RBrownCCB@opensuse.org] Sent: 27 October 2015 05:44 Cc: oS-fctry; werner@suse.de Subject: Re: [opensuse-factory] Re: eth0 Vote On 26 October 2015 at 20:08, Cameron Seader wrote:

+1

On 10/26/2015 10:12 AM, Jan Engelhardt wrote:

...

On Monday 2015-10-26 11:12, Dr. Werner Fink wrote:

...

Beside this a public-opinion poll would be an option

For Leap 42.1 do you prefere (choose one) ... becasue this is for the users and system adminstrators out there. [ ] Persistent network device naming like eth0, ... http://www.tldp.org/LDP/nag2/x-087-2-hwconfig.tour.html [x] Predictable network device naming enp0s3, ... http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface... [ ] I do not care about network device naming [ ] I do not know what this is about

More specifically, [x] Do as upstream does.

I vote for Predictable network device naming On my servers it makes endless sense, but also on my laptop - my not-that-fancy laptop has 3 network devices and some of those can be plugged and unplugged - I dont want to have to deal with the 'persistent' naming nonsense that I used to for years -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 27 of October 2015 09:04:58 Andrei Borzenkov wrote:

...

As for what should be default, I personally thing it should be Predictable since: * It is easy to change to Persistent from Predictable, but not necessarily as easy the other way. (To disable Predictable IF naming, just add "net.ifnames=0" to your boot cmdline). No, you cannot change it this way. There is no code in udev to do

On Tue, Oct 27, 2015 at 2:49 AM, Ben Holmes wrote: old-style renaming. You can disable use of net_id names, that's true, but then you are responsible for providing alternate solution to reliably rename interfaces if you want it. Disabling Predictable does not automatically give you Persistent.

The code exists in SLE12 and SLE12-SP1 so that unless someone deliberately took it away, it should also be present in Leap 42.1. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I'm for persistent networking. This has been the default since...I don't know, back in the early 90s? Most end user devices have only one Ethernet card anyway. Maybe two. This whole predictable naming imho makes only sense for systems with many more cards. -- Kind regards Michael Melcher Sent from my phone Am 26. Oktober 2015 17:12:22 MEZ, schrieb Jan Engelhardt :

On Monday 2015-10-26 11:12, Dr. Werner Fink wrote:

...

Beside this a public-opinion poll would be an option

For Leap 42.1 do you prefere (choose one) ... becasue this is for the users and system adminstrators out there.

[ ] Persistent network device naming like eth0, ... http://www.tldp.org/LDP/nag2/x-087-2-hwconfig.tour.html [x] Predictable network device naming enp0s3, ... http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface... [ ] I do not care about network device naming [ ] I do not know what this is about

More specifically, [x] Do as upstream does.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2015-10-26 21:32, Thorolf Godawa wrote:

That is what I see too, laptops have three network ports maximum (eth0, wlan0, ... ), desktops often only one and for server with several IFs, you do not want that the name changes, just because the extra card goes into an other slot.

Adding or removing a card does not change the naming of others when going Predictable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2015-10-26 22:38, Bernhard Held wrote:

...

Adding or removing a card does not change the naming of others when going Predictable.

The only built-in ethernet port on my Gigabyte G33-DS3R sometimes comes up with enp3s0 instead of enp4s0. The presence of e.g. a Firewire adapter influences the naming too.

Interesting case. If you get the chance, could you provide the output of `lspci -tv; lsusb; lsusb -tv` for the two cases when it happens again? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Oct 28, 2015 at 1:14 AM, Bernhard Held wrote:

Am 27.10.2015 um 11:31 schrieb Jan Engelhardt:

...

On Monday 2015-10-26 22:38, Bernhard Held wrote:

...

...

Adding or removing a card does not change the naming of others when going Predictable.

The only built-in ethernet port on my Gigabyte G33-DS3R sometimes comes up with enp3s0 instead of enp4s0. The presence of e.g. a Firewire adapter influences the naming too.

Interesting case. If you get the chance, could you provide the output of `lspci -tv; lsusb; lsusb -tv` for the two cases when it happens again?

The outputs are attached: enp3s0: after removing the HD5450 GPU and using the integrated GPU enp4s0: my normal situation enp5s0: after adding an USB3 adapter

In my case it might be predictable but certainly not persistent. Is this expected?

See my other reply. You added additional PCI bridge(s) which caused all subsequent numbers to be shifted. Basically the same case as having /dev/sda becoming /dev/sdb after adding disk. Note that *tree* path actually remains persistent, in all cases it is 0000:00 - 1c.4 - 00.0, but unfortunately it is not what is used to identify device. OTOH I suspect the answer from upstream would be "we do not guarantee persistence if hardware configuration changes". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org