system-config-firewall conntrack patch
Howdy folks, saw that you hadn't patched system-config-firewall to support conntrack so I thought I'd send our patch your way. Not a large contribution by any means, but I hope it helps. diff -rupN system-config-firewall-1.2.29.orig/src/fw_iptables.py system-config-firewall-1.2.29/src/fw_iptables.py --- system-config-firewall-1.2.29.orig/src/fw_iptables.py 2012-12-24 14:44:23.094496819 -0500 +++ system-config-firewall-1.2.29/src/fw_iptables.py2012-12-24 14:46:06.040498696 -0500 @@ -362,7 +362,7 @@ class iptablesClass: # accept established and related connections as early as possible # RELATED is extremely important as it matches ICMP error messages -fd.write("-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT\n") +fd.write("-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT\n") # icmp self._icmp(conf, fd, "INPUT", reject_type) @@ -377,7 +377,7 @@ class iptablesClass: for fwd in conf.forward_port: if fwd.has_key("toaddr"): continue -line = "-A INPUT -i %s -m state --state NEW -m %s -p %s" % \ +line = "-A INPUT -i %s -m conntrack --ctstate NEW -m %s -p %s" % \ (fwd["if"], fwd["proto"], fwd["proto"]) if fwd.has_key("toport"): line += " --dport %s" % self._portStr(fwd["toport"]) @@ -394,7 +394,7 @@ class iptablesClass: _dest = "" _port = "" if proto in [ "tcp", "udp" ]: -_state = "-m state --state NEW " +_state = "-m conntrack --ctstate NEW " _proto = "-m %s -p %s " % (proto, proto) else: if self.type == "ipv4": @@ -411,7 +411,7 @@ class iptablesClass: # open ports if conf.ports and len(conf.ports) > 0: for (ports, proto) in conf.ports: -fd.write("-A INPUT -m state --state NEW -m %s -p %s --dport %s " +fd.write("-A INPUT -m conntrack --ctstate NEW -m %s -p %s --dport %s " "-j ACCEPT\n" % (proto, proto, self._portStr(ports))) # FORWARD @@ -419,7 +419,7 @@ class iptablesClass: (self.type == "ipv4" and conf.masq and len(conf.masq) > 0) or \ (self.type == "ipv4" and remote_forward): # accept established and related connections -fd.write("-A FORWARD -m state --state ESTABLISHED,RELATED " +fd.write("-A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED " "-j ACCEPT\n") # icmp self._icmp(conf, fd, "FORWARD", reject_type) @@ -442,7 +442,7 @@ class iptablesClass: port = self._portStr(fwd["toport"]) else: port = self._portStr(fwd["port"]) -fd.write("-A FORWARD -i %s -m state --state NEW " +fd.write("-A FORWARD -i %s -m conntrack --ctstate NEW " "-m %s -p %s -d %s --dport %s " "-j ACCEPT\n" % (fwd["if"], fwd["proto"], fwd["proto"], fwd["toaddr"], -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Miloslav Trmač wrote: > The exceptions were granted to avoid the impact of fixing this on > developers, and more importantly on users (the /usr/lib/systemd paths > for units are in various documentation, and even worse the paths to > binaries in /usr/lib/systemd are embedded in users' copies of units > placed in /etc/; moving the binaries would break users' > configuration). Guess what, the documentation needs to be updated. Systemd as is does not conform to any sane file system structure. This MUST be fixed, even if it means breaking compatibility. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Matthew Garrett wrote: > Unit files need to be in /, so moving them would either require creating > a /share for distributions that haven't merged /usr or putting up with > inconsistent naming between distributions. Consistency is a virtue and > the chances of getting anyone else to accept /share are minimal, so /lib > it is. Meanwhile, libexec's not part of any non-draft version of the FHS > and doesn't exist on most other distributions, and the path of the > helper binaries has ended up in a bunch of unit files. So, similar > problems. > > What benefit do you see in modifying systemd? Consistency WITHIN FEDORA, which should be worlds more important than consistency with other distros, which frankly I don't give a darn about. As for libexec, the FHS explicitly allows lib* under the multilib clause and there's nothing banning * = exec there, so IMHO libexec is already compliant to the letter of the FHS. If the other distros refuse to accept that, that's their problem. Systemd should just require it upstream. libexec is also part of the GNU file system conventions, so it wouldn't just be systemd. If systemd upstream refuses to do that, the systemd maintainers should be forced to change it in Fedora. And a /share also makes a lot of sense for distros which have a separate /usr. There too, systemd should just require it upstream, but again, if they refuse to do that, they should be forced to change it in Fedora. Being strict there might actually end up getting our sane layout enforced through systemd upstream, rather than having it diluted in the name of consistency with other distros. And if it doesn't, it's too bad for the other distros, why should we care? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121224 changes
Compose started at Mon Dec 24 09:17:00 UTC 2012 Summary: Added Packages: 0 Removed Packages: 0 Upgraded Packages: 0 Compose finished at Mon Dec 24 13:18:15 UTC 2012 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20121224 changes
Compose started at Mon Dec 24 08:15:09 UTC 2012 Broken deps for x86_64 -- [Agda] Agda-2.3.0.1-4.fc19.x86_64 requires ghc(Agda-2.3.0.1-ad754944fc95f11aa3b4710387ff959a) [airinv] airinv-0.1.2-5.fc19.i686 requires libstdairuicl.so.0.45 airinv-0.1.2-5.fc19.i686 requires libstdair.so.0.45 airinv-0.1.2-5.fc19.x86_64 requires libstdairuicl.so.0.45()(64bit) airinv-0.1.2-5.fc19.x86_64 requires libstdair.so.0.45()(64bit) [airrac] airrac-0.2.3-5.fc19.i686 requires libstdairuicl.so.0.45 airrac-0.2.3-5.fc19.i686 requires libstdair.so.0.45 airrac-0.2.3-5.fc19.x86_64 requires libstdairuicl.so.0.45()(64bit) airrac-0.2.3-5.fc19.x86_64 requires libstdair.so.0.45()(64bit) [airsched] airsched-0.1.4-5.fc19.i686 requires libstdairuicl.so.0.45 airsched-0.1.4-5.fc19.i686 requires libstdair.so.0.45 airsched-0.1.4-5.fc19.x86_64 requires libstdairuicl.so.0.45()(64bit) airsched-0.1.4-5.fc19.x86_64 requires libstdair.so.0.45()(64bit) [almanah] almanah-0.10.0-3.fc19.x86_64 requires libedataserverui-3.0.so.5()(64bit) almanah-0.10.0-3.fc19.x86_64 requires libcamel-1.2.so.42()(64bit) [ansible] ansible-fireball-0.9-1.fc19.noarch requires python-keyczar ansible-node-fireball-0.9-1.fc19.noarch requires python-keyczar [cp2k] cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpichf90.so.3()(64bit) cp2k-mpich2-2.3-1.fc19.x86_64 requires libmpich.so.3()(64bit) [dogtag-pki] dogtag-pki-10.0.0-0.16.b3.fc19.noarch requires dogtag-pki-server-theme >= 0:10.0.0 [dvdauthor] dvdauthor-0.7.1-1.fc18.x86_64 requires libGraphicsMagick.so.3()(64bit) [ekiga] ekiga-4.0.0-1.fc19.x86_64 requires libcamel-1.2.so.42()(64bit) [ember] ember-0.6.3-3.fc19.x86_64 requires libOgreMain.so.1.7.4()(64bit) [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [evolution-rss] 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libevolution-utils.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemiscwidgets.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemail-utils.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libedataserverui-3.0.so.5()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libcamel-1.2.so.42()(64bit) [freeipa] freeipa-server-3.1.0-1.fc19.x86_64 requires dogtag-pki-server-theme [freewrl] freewrl-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7 freewrl-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit) libEAI-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7 libEAI-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [ghc-wai-extra] ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-conduit-0.4.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-bindings-0.1.0.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-0.5.3.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSwai-1.2.0.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvoid-0.5.6-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvault-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunordered-containers-0.2.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunix-2.5.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-base-0.4.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-0.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStime-1.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStext-0.11.2.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSresourcet-0.3.2.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSparsec-3.1.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-time-1.1.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-locale-1.0.0.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSnetwork-2.3.0.13-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSmtl-2.1.1-ghc7.4.1.so()(64bit)
Fosdem Cross-Distro devroom
Just an update about Fosdem. The dealing for talk submissions at the Cross Distro Devroom got extended until the end of the year [1]. I have already submitted a talk [2], but I think it's the only Fedora related. So anyone interested on doing a presentation, now it's the time to propose it :) [1] https://lists.fosdem.org/pipermail/distributions/2012-December/000169.html [2] https://lists.fosdem.org/pipermail/distributions/2012-December/000160.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prefered way of configuring X11 keyboard layouts in F18
On Fri, 21.12.12 16:11, Adam Williamson (awill...@redhat.com) wrote: > On Fri, 2012-12-21 at 16:57 +0100, Lennart Poettering wrote: > > > > The database is bitrotten and even it it wasn't most modern layouts do not > > > exist kbd-side at all. Most layouts with perfect mapping are old legacy > > > ascii layouts. They are still in xkb-config for historical reasons but in > > > many locales the preferred layout includes changes (unicode…) which have > > > never been ported to kbd. > > > > I doubt it's that rotten. It definitely works fine for the most popular > > keymaps, such as the american and german. > > All this keymap stuff is bending my brain, but I've been poking at it > for the last few days, and I'm rather afraid it *is* that bad. See this > tentatively accepted blocker bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=889562 > > If I have everything right, anaconda is offering a keymap list that it > derives from xkb. I'm having trouble counting precisely how many layouts > it offers, but it looks to be definitely over 400. > > According to 'localectl list-keymaps', systemd-localed has mappings for > 209 keymaps. Well, that's simply a fact that the console keymaps are much fewer than the X keymaps, but that's not really an issue of localed/systemd, but rather a general shortcoming of the classic console keymap system. Also, it's hardly a regression in comparison to older Fedora... > So there's at least 191 keymaps (probably rather more) which anaconda > offers you but which systemd doesn't understand: if you install with any > of these keymaps selected as the default keymap (top of the list in > Keyboard spoke), you will wind up with US as your console keyboard > layout on the installed system. > > We could really do with input from interested parties on exactly how bad > of a problem this is - if people could look through the keyboard layouts > offered in F18's Keyboard spoke and compare them to the list from > 'localectl list-keymaps', and identify particularly important ones that > systemd doesn't seem to grok, it'd really help. "localectl list-keymaps" shows all files below /usr/lib/kbd/keymaps btw, that's all it does... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel