Please backport ufw from Jaunty

Bug #268931 reported by Didier Roche-Tolomelli
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Hardy Backports
Won't Fix
Undecided
Unassigned
iptables (Ubuntu)
Won't Fix
Undecided
Didier Roche-Tolomelli
ufw (Ubuntu)
Fix Released
Wishlist
Jamie Strandboge

Bug Description

As request on the ubuntu-server ML, ufw 0.16.2 is the current version in hardy.

Newer versions of ufw add some new exciting stuffs that are needs by a bunch of people.
I will try to handle the backport.

Here is the mail received on ubuntu-server ML:
"I’m in need of opening up a port range on one of my servers, and would rather use UFW then IPTables at the moment. I’m using 8.04.1 and can’t seem to upgrade to 0.20 (which per the wiki can manage ranges), is there a single repository I could change/edit to sudo apt-get dist-upgrade ufw and then edit back to hardy repositories in order to upgrade to the latest UFW? Thank in advance."

Related branches

Changed in hardy-backports:
assignee: nobody → didrocks
status: New → In Progress
Changed in ufw:
assignee: nobody → didrocks
status: New → In Progress
Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

  * Dependencies:

Build-Depends-Indep: python-central (>= 0.5.6), sed (>= 3.95), netbase, po-debconf
Depends: debconf, ${python:Depends}, iptables (>= 1.4.0), ucf

All are ok, but iptable (1.3.8 in hardy) -> have to backport iptables.

* apt-cache rdepends ufw

-> ubuntu-standard (metapackage). Ok.

* apt-cache rdepends iptables

for each rdepends:

for i in $(cat toto)
do
   echo $i": "$(apt-cache show $i | grep iptables | grep "<")
done

=>

util-vserver:
uruk:
uif:
specter:
shorewall-lite:
shaperd:
pyroman:
psad:
p3scan:
network-config:
netscript-2.4:
lokkit:
libabz0:
kvpnc:
knetfilter:
ipset:
ipmasq: Conflicts: iptables (<< 1.2.1-1)
ipkungfu:
heartbeat:
guidedog:
grml-btnet:
gpe-shield:
fwanalog:
firestarter:
firehol:
fiaif:
ferm:
fail2ban:
education-thin-client-server:
education-main-server:
ebtables:
ebox-network: Depends: dhcp3-client, dnsutils, ebox (>= 0.11.99), ebox (<< 0.12), ebox-objects, gconf2 (>= 2.10.1-2), iproute, iptables, jnettop, libnet-arp-perl, libnet-ip-perl, librrds-perl, net-tools, rrdtool, vlan
ebox-firewall: Depends: ebox (>= 0.11.99), ebox (<< 0.12), ebox-network, ebox-objects, ebox-services, gconf2 (>= 2.10.1-2), iptables
arno-iptables-firewall:
ubuntu-standard:
shorewall-common:
ppp:
libvirt-bin:

=> Seems ok.

So, we have just to try to compile iptables and ufw.

Changed in hardy-backports:
status: In Progress → New
Changed in ufw:
status: In Progress → New
Changed in iptables:
assignee: nobody → didrocks
Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Changes in iptables:
iptables (1.4.0-4ubuntu2~hardy1) hardy-backports; urgency=low

  * Revert specific change for libc6 for intrepid in
    debian/paches/0900-compile-against-linux-libc-dev.patch (LP: #268931)

 -- Didier Roche <email address hidden> Tue, 16 Sep 2008 08:36:44 +0200

ufw 0.22 compiles successfully and work with this version of iptables.

Changed in iptables:
status: New → Confirmed
Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Marking this Triaged since it has been test built and appears to work, however, I'm not sure if we should backport ufw and iptables; it feels like a rather invasive change.

Changed in hardy-backports:
status: New → Triaged
Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Yes Michael,

There is no really problem for ufw, but its dependency, iptables, is very difficult to test.
I have personnaly no issue here running with it, but a larger group of people would be better as this latter has a lot of reverse dependencies, and so, potentially conflicting version…

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Another option that occurred to me is to patch ufw to not use application profiles for ipv6 (the requirement on iptables 1.4 is due to how ufw uses a new ip6tables feature, present in iptables in hardy). Application profiles could be removed altogether for hardy. Since none are shipped in hardy, this shouldn't be a big deal.

If I were really good (and I might be, I'm not sure yet), I would have ufw detect the iptables version and make a decision as to whether application profiles are supported.

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

It is such a pleasure to dive into your code (;)) that I propose to you that I take a big breath and go through it to see what is possible. I need more information (for instance, what is speciffically used from the new iptable, I reckon only the ipv6 support) and some time to achieve it (until the intrepid release, it will be hard for me to find long continuous time for that), but I can take a test without any problem.

If it is related to application profiling only, I think we could disable it for this backport and the time for me to try this will be surely a lot shorter :)

Changed in ufw:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Didier, can you test the ufw/trunk (need at least rev 331)? I just committed a patch to support running ufw on systems with iptables < 1.4. This feature will be in ufw 0.26 which I will eventually upload to Jaunty.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Marking the iptables task as "Won't Fix" as it is too intrusive and ufw in Jaunty can run without the newer iptables.

Changed in iptables:
status: Confirmed → Won't Fix
description: updated
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Marking the ufw portion of the bug as Fix Released, and assigning to me, as the changes required for later versions of ufw to run on Hardy have been incorporated in Jaunty. Leaving the Hardy Backports task to Didier.

Changed in ufw:
assignee: didrocks → jdstrand
status: Confirmed → Fix Released
Changed in hardy-backports:
assignee: Didier Roche (didrocks) → nobody
Revision history for this message
Evan Broder (broder) wrote :

It looks like this bug requests a backport from Ubuntu 9.04 (Jaunty Jackalope). However, as Jaunty is no longer supported, such a backport is no longer possible.

This bug is being set to "Won't Fix". If you would still like to move forward with this backport request, please re-open the bug and adjust it to request a backport from a current release.

(This change is being made by an automated bot run by Evan Broder, who is now subscribed to the bug; if you think the change was made in error, please feel free to re-open the bug)

Changed in hardy-backports:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.