https://bugzilla.novell.com/show_bug.cgi?id=468426 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Info Provider| |jsmeix@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=468426 User locilka@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=468426#c1 Lukas Ocilka changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW CC| |locilka@novell.com Info Provider|locilka@novell.com | --- Comment #1 from Lukas Ocilka 2009-01-22 08:01:32 MST --- SuSEfirewall newly uses services defined by packages. These services are defined by separate files in /etc/sysconfig/SuSEfirewall2.d/services directory. These services are different to the previous firewall settings because they add one another level of transparency. You don't check the ports anymore, you just check the availability of a service in configuration (of allowed services). See "FW_CONFIGURATIONS_EXT":"cups dhcp-server sshd", Your printer configuration checks the low level settings, what you need is the higher level of checking, for instance: * IsServiceSupportedInZone IsServiceSupportedInZone ("service:irc-server", "EXT") -> true * GetServicesInZones GetServicesInZones (["samba-server"]) -> $["samba-server":$["eth1":false]] See http://forgeftp.novell.com/yast/doc/SL11.1/modules/SuSEFirewall.html for more information. You are currently using this: SuSEFirewall::HaveService( "631", "UDP", "INT" ) SuSEFirewall::HaveService( "631", "TCP", "EXT" ) By the way, Miso uses an agent for tuning the configuration defined by service (that sysconfig file in /etc/sysconfig/SuSEfirewall2.d/services directory) for apache configuration. You can use the same approach for fine-tuning of the printer configuration. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=468426 User jsmeix@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=468426#c6 Johannes Meixner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW CC| |jsmeix@novell.com AssignedTo|jsmeix@novell.com |locilka@novell.com Summary|yast2-printer shows wrong |yast2-firewall: |SuSEFirewall state |inconsistent configuration | |data --- Comment #6 from Johannes Meixner 2009-01-23 01:49:24 MST --- Many thanks for comment #5! I think I have now a much better understanding of what actually happened. But I need to experiment a bit with it before I change my code in yast2-printer and yast2-scanner. As far as it understand it currently (based on comment #5) this is actually no incompatible change (because the old stuf still works) but is is a new and different (alternative) way to set it up. The only issuze was that up to now I was not aware of the stuff in https://bugzilla.novell.com/show_bug.cgi?id=247746 in particular not aware that this means that my old code (which does intentionally a low-level port/protocol/zone check to be independent of any higher-level stuff) does no longer work. As far as it understand it currently I can keep the old checks via SuSEFirewall::HaveService(...) but I must add new checks via SuSEFirewall::IsServiceSupportedInZone("service:cups", "EXT") to test also for the new and different way. According to http://forgeftp.novell.com/yast/doc/SL11.0/modules/SuSEFirewall.html and http://forgeftp.novell.com/yast/doc/SL10.3/modules/SuSEFirewall.html#IsServi... SuSEFirewall::IsServiceSupportedInZone works even for openSUSE 11.0 and openSUSE 10.3 so that there is sufficient backward compatibility even for previous openSUSE versions which makes me really happy! What I need to test is what happens if there are several sysconfig file like /etc/sysconfig/SuSEfirewall2.d/services/cups-browsing (which has only UDP="ipp" set) and /etc/sysconfig/SuSEfirewall2.d/services/cups-share-printers (which has only TCP="ipp" set). I guess that in this case I would have to test for SuSEFirewall::IsServiceSupportedInZone("service:cups-browsing", "EXT") and SuSEFirewall::IsServiceSupportedInZone("service:cups-share-printers", "EXT") which makes it unpredictable for me because my code then depends on file names in /etc/sysconfig/SuSEfirewall2.d/services/ (or on the "## Name:" entries in those files) which can both change without any notification to me and/or which can be changed manually by an experienced user but my YaST modules cannot adapt automatically to such changes. Therefore I would very much prefer if only a low-level port/protocol/zone check would be sufficient to test if a particular port is open for a particular protocol in a particular zone regardless how this was set up on a higher level. Because the /etc/sysconfig/SuSEfirewall2.d/services/ files contain port and protocol information and during setup the user defines the zone, the YaST firewall module should maintain the low-level port/protocol/zone information so that the low-level port/protocol/zone check still works correctly regardless of the way how it was set up. I assume YaST firewall module could during startup read /etc/sysconfig/SuSEfirewall2 and the /etc/sysconfig/SuSEfirewall2.d/services/ files to generate the low-level port/protocol/zone information. In particular on the user interface there should be no difference if the user has allowed "cups" for EXT or if he allowed port 631 for TCP and UDP for EXT. I tested what happens when I allow "cups" for EXT and allow port 631 for TCP and UDP for EXT in the YaST firewall module. I get then in y2log (shortened): ------------------------------------------------------------ SuSEFirewall.ycp:2372 Firewall configuration has been read: .. "FW_CONFIGURATIONS_EXT":"cups sshd", .. "FW_SERVICES_EXT_TCP":"631 ssh", "FW_SERVICES_EXT_UDP":"631", ------------------------------------------------------------ and the YaST printer module shows the right state. While the values of the Firewall configuration are now consistent, there is confusion on the user interface because when I run the YaST firewall module a second time, there are no longer any entries in the "Advanced" popup for port 631 for TCP and UDP for EXT but a second run of the YaST printer module shows still in y2log the same ------------------------------------------------------------ SuSEFirewall.ycp:2372 Firewall configuration has been read: .. "FW_CONFIGURATIONS_EXT":"cups sshd", .. "FW_SERVICES_EXT_TCP":"631 ssh", "FW_SERVICES_EXT_UDP":"631", ------------------------------------------------------------ and the YaST printer module shows the right state. Now I run YaST firewall module a third time and delete "cups" for EXT (but do nothing else) and re-run the YaST printer module it results in y2log ------------------------------------------------------------ SuSEFirewall.ycp:2372 Firewall configuration has been read: .. "FW_CONFIGURATIONS_EXT":"sshd", .. "FW_SERVICES_EXT_TCP":"631 ssh", "FW_SERVICES_EXT_UDP":"631", ------------------------------------------------------------ and the YaST printer module shows the right state. Meanwhile I think the main bug is in the YaST firewall module because it does not keep consistency. As far as I can see to keep consistency, the YaST firewall module must maintain the low-level port/protocol/zone information. But when it does this, a positive side-effect is that it also provides consistency when other YaST modules do intentionally a low-level port/protocol/zone check via SuSEFirewall::HaveService(...) to get intentionally a result which is independent of the way how the user may have set it up. Therefore I reassign it now to you. Nevertheless to be on the safe side I will add new checks in yast2-printer and yast2-scanner via SuSEFirewall::IsServiceSupportedInZone("service:cups", "EXT") to test also for the new and different way. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=468426 User jsmeix@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=468426#c8 --- Comment #8 from Johannes Meixner 2009-02-17 06:17:41 MST --- In yast2-printer version 2.18.5 (i.e. for openSUSE 11.2) I removed the firewall settings which I added in version 2.17.29 because it is not possible to implement it so that it works correct and future-proof because it has become unpredictable for me (see comment #6). Additionally a generic solution can also not be implemented because it is not possible to test on the local host if remote access via port 631 TCP/UDP would be allowed (there is no replacement for "ipchains --check"). Finally any kind of firewall check would not make much sense because the user could first set up printing with firewall settings which allow printing so that the check would have a positive result but later he may change the firewall so that printing does no longer work. Therefore in the end all I could do was to add at least generic static notification texts regarding firewall directly in the dialogs and I added also explanatory help texts regarding firewall so that the users are at least informed what to do manually regarding firewall. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.