On Sun, May 24, 2015, at 10:04 AM, Yamaban wrote:

The crux with this "advise" is the the shorewall packages contain a "Conflict: SuSEfirewall2" tag. Thus your advise may be well meant, but is in practise worse than useless.

Here is a change in the packaging / specfiles needed. e.G shore shorewall could drop the "Conflict: SuSEfirewall2", but include a script that disables "SuSEfirewall2" or, YaST2 should get some code changes that detect the presence of other firewall packages, and then drops the output of "I NEED SuSEfirewall2" messages.

Looking around a bit it looks like there really should be a hard conflict left "in there". Somewhere. I noticed that in the shorewall packages provided for Opensuse the systemd unit file /usr/lib/systemd/system/shorewall.service # The Shoreline Firewall (Shorewall) Packet Filtering Firewall # # Copyright 2011 Jonathan Underwood # [Unit] Description=Shorewall IPv4 firewall Wants=network-online.target After=network-online.target Conflicts=iptables.service firewalld.service [Service] Type=oneshot RemainAfterExit=yes EnvironmentFile=-/etc/sysconfig/shorewall StandardOutput=syslog ExecStart=/usr/sbin/shorewall $OPTIONS start $STARTOPTIONS ExecStop=/usr/sbin/shorewall $OPTIONS stop [Install] WantedBy=basic.target specifies Conflicts=iptables.service firewalld.service to prevent those ^^ daemons' conflicts, but doesn't make ANY mention of Susefirewall2. Should it? I think so ... Looking at the Susefilrewall2 pkg's spec https://build.opensuse.org/package/view_file/openSUSE:13.2/SuSEfirewall2/SuS... It doesn't seem to mention any Conflicts but does provide /usr/lib/systemd/system/SuSEfirewall2.service /usr/lib/systemd/system/SuSEfirewall2_init.service Looking at the tarball SuSEfirewall2.service [Unit] Description=SuSEfirewall2 phase 2 After=network.target ypbind.service nfs.service nfsserver.service rpcbind.service SuSEfirewall2_init.service Wants=SuSEfirewall2_init.service [Service] ExecStart=/usr/sbin/SuSEfirewall2 boot_setup ExecStop=/usr/sbin/SuSEfirewall2 systemd_stop RemainAfterExit=true Type=oneshot [Install] WantedBy=multi-user.target Alias=SuSEfirewall2_setup.service Also=SuSEfirewall2_init.service SuSEfirewall2_init.service [Unit] Description=SuSEfirewall2 phase 1 Before=network.service Before=basic.service [Service] ExecStart=/usr/sbin/SuSEfirewall2 boot_init RemainAfterExit=true Type=oneshot [Install] WantedBy=multi-user.target Also=SuSEfirewall2.service And in /usr/sbin/SuSEfirewall2 ... boot_init) ACTION="init"; create_bootlock=1 ;; ... if [ "$ACTION" = "init" ]; then if [ "$FW_BOOT_FULL_INIT" = 'yes' ]; then ACTION='start' <================================= else ACTION='close' fi fi ... and Options: start generate and load the firewall filter rules from /etc/sysconfig/SuSEfirewall2 Sure looks like that is SuSEfirewall2 is installed & enabled it's gonna try to start the firewall. That WILL conflict with an installed Shorewall. I don't know how to best prevent that in Opensuse. What I'll do for now is (A) add to the Shorewall unit files - Conflicts=iptables.service firewalld.service + Conflicts=iptables.service firewalld.service SuSEfirewall2.service SuSEfirewall2_init.service (B) uninstall the SuSEfirewall2 pkgs (C) add a 'zypper lock' on SuSEfirewall2 to make sure they don't get REinstalled The combination of those is probably effective overkill. What I still don't know is if the "I need SuSEfirewall" dialog in "YaST2 - Network Settings" is just noise, or actually harmful? Cheers, Bob -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, May 24, 2015, at 10:55 AM, Per Jessen wrote:

robert.devanna@nospammail.net wrote:

...

What I still don't know is if the "I need SuSEfirewall" dialog in "YaST2 - Network Settings" is just noise, or actually harmful?

I think it's noise. See bug#898865.

I see no evidence in that bug, or anywhere else yet, that it is, or isn't "just noise". The answer will be in the YaST module's code not in speculation. Cheers Bob -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/24/2015 01:37 PM, robert.devanna@nospammail.net wrote:

to prevent those ^^ daemons' conflicts, but doesn't make ANY mention of Susefirewall2.

The name of the package ("Susefirewall2") is not the name of the service (aka the daemons). -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/24/2015 02:14 PM, robert.devanna@nospammail.net wrote:

On Sun, May 24, 2015, at 10:59 AM, Anton Aylward wrote:

...

On 05/24/2015 01:37 PM, robert.devanna@nospammail.net wrote:

...

to prevent those ^^ daemons' conflicts, but doesn't make ANY mention of Susefirewall2.

The name of the package ("Susefirewall2") is not the name of the service (aka the daemons).

Right. In the case of Susefilrewall2 on systemd, the service/daemons are referred to

SuSEfirewall2.service SuSEfirewall2_init.service

"The map is not the territory" I could refer to Lewis Carrol too, the White Knight's Song. The name, the label is not the content, what its about. What is the 'Exec' line in the unit files. THAT is the "daemon" -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sun, 24 May 2015 10:55:30 -0700 robert.devanna@nospammail.net пишет:

...

Then chose "Cancel" and continue. See https://bugzilla.opensuse.org/show_bug.cgi?id=898865

Advising blindy clicking on anything without an understanding of what the ramifications are is sloppy, if not dangerous.

If you are not going to accept any answer anyway, why ask? I would trust experience of people who have been using openSUSE for a long time. YaST source code is open to anyone to understand ramifications. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/24/2015 03:11 PM, robert.devanna@nospammail.net wrote:

...

If you are not going to accept any answer anyway, why ask? I would trust experience of people who have been using openSUSE for a long time.

Seriously what are you talking about?

Sloppy is sloppy. Doesn't matter to me one bit 'who' someone is.

I'm perfectly open to accepting thoughtful, verifiable answers that are self-consistent. That's why I'm asking.

As for looking at code, that's exactly what I'm doing. Because I apparently have to to get an answer that's pulled out of someone's hat.

I agree with you about "sloppy" but looking at the Ruby code won't help you. The issue is the parameters that code works with which are in the packages. The only way you're going to deal with this is, as I said earlier, forget about yast altogether. Its a constraint that expects things to work in a set way and part of that set way is a dependency tree that it expects is met. Now that's going to be fine for setting up dhcp services as I outlined, but if you want to install Shorewall you're going to have to over-ride yast's expectation about "2". The other approach, which I'm more inclined to take, is to ignore yast altogether. There are many applications I have (I put iem in /opt, which I have as a separate file system so it can survive upgrades) that I install without using yast/zypper. The advantage of have repository reference for an application and the reference in the RPM database is that you can do a 'zypper up' to update it. If you can live without that, or if the application itself notifies you or has a service that notifies you when an update is available then that's good. Perhaps you're happy with the revision you have; perhaps you track bugs/updates by some other method. I can understand yast for newbies, though some seem to expect it to do things without their RTFM or without their willingness to explore its options, especially as an installer and especially when it comes to disk space provisioning, but that's another matter. Yes, like most guis, is a crutch, often a very useful crutch that's easier than doing things 'manually'. But all GUIs embody the GUI designer's concept of what you ought to do, channel what you can do to his model. I can't recall, for example, the last time (except for installation) that I used yast to set up a repository or install a package. The closets was using the web to find the repository (well, ok, in FTP mode) and paste the URL into a zypper command line in a sudo in a kterminal. OK, so in the 85% case yast is doing the same as zypper, but in that extra 15% I want the control I get with zypper or with 'rpm' that I can't do with yast or which would be tedious and awkward with yast. For example, I can extract things from the database using ' rpm', format, filter, produce a list and run a shell loop feeding them to zypper. Yes, i have, Yes it's a "one liner". You might try using zypper or yast to black-list Susefirewall2 and see what happens. Hmm. Its one of the things I have black-listed, along with many language packages, sendmail, exim, kde3 and a variety of 32-bit packages. :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/24/2015 05:46 PM, robert.devanna@nospammail.net wrote:

On Sun, May 24, 2015, at 01:33 PM, Anton Aylward wrote:

...

looking at the Ruby code won't help you. The issue is the parameters that code works with which are in the packages.

Yep, figuring that out as I look around in here.

:-)

...

The only way you're going to deal with this is, as I said earlier, forget about yast altogether. ... The other approach, which I'm more inclined to take, is to ignore yast altogether.

Yeah, that's where I'm ending up.

:-)

Personally I can't see any good reason for a network config tool to be tied to specific firewall tools. At least without a simple option to turn that dependency off.

My mistake was initially assuming that since YaST is so 'hardwired in' to the distro that it'd be flexible enough for pretty standard, mainstream pkgs.

...

You might try using zypper or yast to black-list Susefirewall2

Already done.

Good.

I'll stick with the cmd line & config files approach and avoid gui assumptions that are just getting in the way.

:-)

I'm going to take a look at completely removing YaST. Not sure if that's even doable.

I'm not sure its doable but then I'm not sure its a "dependency". really its a wrapper. At the command line try # yast2 list *SOME* of those might be useful. Some things are just straight forward and it might be easier to use yast than to do the necessary figuring. MAYBE. In some instances. YMMV. It may also be useful to set up the basic config files which you then hand polish.

I'm sure not going to use a tool that's in the way of what I need done, causing more work rather than less.

That's the case here.

The best advice seems to be your " forget about yast altogether".

Specifically for networking, since it seems like wicked IS the future path for network setup here, I'll likely ignore all the compat: mode locations -- regardless of what YaST thinks we should be doing -- and just config manually into the wicked: locations.

And in general, there's nothing that I'm seeing YaST do that's much of an advantage to my usual "do it in shell" approach.

Yast is openSuse's main "value added" and the conversion from a dedicated but obscure language to Ruby was supposed to be a rationalization. I've been using Ruby (& RoR) for a number of years and as regular readers know support a parsimonious approach. I don't know if its architectural decisions or a side effect of the way the automated translation proceeded but the Ruby implementation of yast is far from transparent. Personally I think its tied to the original design and the way the original YCP was written. I've written a number of interpreters and meta-interpreters over the years and I know they can be incredibly powerful, very succinct and also quite transparent. http://opensuseadventures.blogspot.ca/2013/06/yast-is-being-rewritten-in-rub... https://news.opensuse.org/2013/10/10/coming-soon-opensuse-13-1-with-yast-in-...

wicked docs are still a challenge but the option to show the wicked XML config for an existing YaST-generated set up is a useful enough cheat for now.

Well, that kind of cheat is one use for yast :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org