You are here: / home

Fri, 18 Nov 2011

Release Critical Bug report for Week 46

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:1812
Affecting Wheezy:1161
Wheezy only:163
Remaining to be fixed in Wheezy:998

Of these 998 bugs, the following tags are set:

Pending in Wheezy:47
Patched in Wheezy:191
Duplicates in Wheezy:47
Can be fixed in a security Update:31
Contrib or non-free in Wheezy:16
Claimed in Wheezy:0
Delayed in Wheezy:4
Otherwise fixed in Wheezy:89

Ignoring all the above (multiple tags possible) 631 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released.

However, with the view of the Release Managers, 1053 need to be dealt with for the release to happen.

Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

postet at 13:01 into [Debian/rc-stats/7.0-wheezy] permanent link


Fri, 11 Nov 2011

Release Critical Bug report for Week 45

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:1869
Affecting Wheezy:1211
Wheezy only:155
Remaining to be fixed in Wheezy:1056

Of these 1056 bugs, the following tags are set:

Pending in Wheezy:54
Patched in Wheezy:197
Duplicates in Wheezy:48
Can be fixed in a security Update:33
Contrib or non-free in Wheezy:12
Claimed in Wheezy:0
Delayed in Wheezy:10
Otherwise fixed in Wheezy:87

Ignoring all the above (multiple tags possible) 684 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released.

However, with the view of the Release Managers, 1105 need to be dealt with for the release to happen.

Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

postet at 13:02 into [Debian/rc-stats/7.0-wheezy] permanent link


Mon, 07 Nov 2011

Release Critical Bug report for Week 45

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:1893
Affecting Wheezy:1250
Wheezy only:180
Remaining to be fixed in Wheezy:1070

Of these 1070 bugs, the following tags are set:

Pending in Wheezy:47
Patched in Wheezy:190
Duplicates in Wheezy:51
Can be fixed in a security Update:33
Contrib or non-free in Wheezy:10
Claimed in Wheezy:0
Delayed in Wheezy:3
Otherwise fixed in Wheezy:87

Ignoring all the above (multiple tags possible) 709 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released.

However, with the view of the Release Managers, 1144 need to be dealt with for the release to happen.

Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

postet at 20:38 into [Debian/rc-stats] permanent link


Weekly RC Bug Statistics enabled again

Friday David Prévot reminded me about the statistics for release critical bugs I used to publish during the squeeze release cycle, and asked if I could enable them again.

After tweaking the script generating the statistics a bit (mainly a s/squeeze/wheezy/g) the stats will be again published weekly, every Friday at 13:05 CET.

The first report is already available, and it seems it is about time, that we got the Wheezy Bug Squashing Party Marathon started! So, see you at the first BSP in Hildesheim.

postet at 12:18 into [Debian/rc-stats] permanent link


Wed, 28 Sep 2011

How to properly route packages on hosts with multiple NICs?

Dear lazyweb,

I'm encountering a routing problem on one of my Linux machine, for which I haven't found a solution so far. I have a machine which has several network interfaces in different network (it's our monitoring system). So I have eth0 with 192.168.1.2 and eth1 with 10.0.0.2, and an dns entry pointing from myname to 192.168.1.2.

Problems occur, if hosts in the 10.x.x.x network try to access the hosts. Accessing it via it's IP address in that network works, however if they try to access him via his other IP address 192.168.1.2 (e.g. because they resolve it via dns), it leads to some problems:

The host send their packet to his IP address (which works), however when my machine sends the answer, it takes a shortcut, and sends them directly via eth1 and with 10.0.0.2 as source IP. This however gets filtered by a (stateful) firewall somewhere in between, as packet send to 192.168.1.2 are suddenly answered by 10.0.0.2.

So far I found two solutions: Adjust the DNS to resolve to different IPs depending on the source of the request (ugly) or tell all firewalls to always let packet from my host pass, despite the changes source IP (also ugly, and probably quite some work).

Is there anything else I can do? What I would really like, would be a way to tell my linux box to always respond with the IP it was talked to, even if there would be a shorter way to the origin according to the routing rable. So, if a host 10.0.0.42 contacts my host via the IP 192.168.1.2, the answer packet should come from 192.168.1.2 via eth0 instead of instead of having a source IP set to 10.0.0.2, it should be send via eth1. Is that somehow possible?

Update: Wow, that was fast! The ink of my blog is still fresh, and I already got the answer! The solution to my problem is policy based routing. Thanks to weasel, Peter and Dale for their pointers! More information available at http://lartc.org/howto/lartc.rpdb.html, http://www.itbuzzer.net/corner/2007/09/how-to-implement-source-routing-with.asp or http://wiki.georgweiss.de/Linux/source_routing.

postet at 13:25 into [Debian] permanent link


<<  1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87  >>

About

Alexander Tolimar Reichle-Schmehl lives in Hildesheim / Germany. He's an official Debian Developer. Beside maintaining various packages, his main task is being spokesman and event organizer of the Debian project.

Links