Hi Ludwig, On Thu, Jan 25, 2018 at 01:40:33PM +0100, Ludwig Nussel wrote:
Or just drop them and generate SuSEfirewall2 files based on the firewalld ones if needed. I suppose the information for most services can't be all that different. Just a collection of ports. Differences need to be looked at and resolved anyways. Anyone actively looking into that?
that could be possible. But I really wouldn't want to put more effort than necessary in keeping SuSEfirewall2 working in the migration phase. Experience with SuSEfirewall2 shows that some difficile corner case will break as a result and bugs start pouring in ;-) I'm not quite sure what you mean with "differences need to be looked at anyways". Basically firewalld users just need to identify the correct service name (which will often be the same as before in SuSEfirewall2) and enable it. The service descriptions of firewalld also cover things like conntrack modules to be loaded for samba-client, for example. Up until now I've found only one major use case that firewalld does not cover any more: Setting up the dynamic rules for NFSv3 portmapper ports. In NFSv4 these aren't needed any more. But for NFSv3 there's no real solution and users need to either configure static ports for NFS services or use some scripting approach.
Just grep ARCHIVES.gz to see what service files exist in the distro, compare that to what firewalld offers and then create the missing ones.
Where do I find this ARCHIVES.gz? I can check the missing ones. And if they're needed anymore at all.
What is the benefit of centralizing that? Wouldn't the UI then display hundreds of entries rather than just offering what is actually on the system?
Well this is what firewalld more or less already does by shipping 119 service definitions with the default install. The benefit would be that global changes to service files can be made in a single package. For example there was/is an issue that many service files for SuSEfirewall2 wrongly stated "RPC=portmap" instead of "RPC=portmapper". Fixing that requires a bunch of package updates that nobody really wants to go for. But that doesn't mean I'm in strictly in favor for centralizing them. I'm just opening it up for discussion. Both approaches have their pros and cons. My hope is, as I initially said, that we won't need any additional service files at all.
If we wanted the UI to display 'everything' it could just as well show /etc/services ;-)
Simply put, yes. But firewalld also adds nice short and long descriptions in XML ;-) Regards Matthias -- Matthias Gerstner <matthias.gerstner@suse.de> Dipl.-Wirtsch.-Inf. (FH), Security Engineer https://www.suse.com/security Telefon: +49 911 740 53 290 GPG Key ID: 0x14C405C971923553 SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nuernberg)