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 <jsmeix@novell.com> 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 <jsmeix@novell.com> 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.