Bug#1011146: Autoremoval of non related package
Same problem with the "arno-iptables-firewall"-package: It also got tagged for auto removal due to this. And again: no relationship whatsoever On Mon, 30 May 2022 18:38:47 +0100 Kartik Kulkarni wrote: > Hello, > I received an email for auto removal for source-highlight which has nothing > to do with nvidia-graphics-drivers. If my assumption is wrong, please let > me know what sort of changes you would expect me to make. > Regards, > Kartik
Bug#956552: arno-iptables-firewall: 90-rpc.plugin causes arno to fail to start.
Upstream fix here:
https://github.com/arno-iptables-firewall/aif/commit/d145f9b665ae3573055470cd45c750e63e7bebf6
On 12-04-2020 21:05, Julia Longtin wrote:
Package: arno-iptables-firewall
Version: 2.1.0-2
Severity: normal
Tags: patch upstream
Dear Maintainer,
90-rpc.plugin does not see carriage return as a line break when running rpcinfo -p |awk
"/tcp.*$service/"' { print $4 }' |uniq
this causes arno to fail to start if you have NFS services, and have turned
this plugin on.
--- 90rpc.plugin~ 2020-01-03 10:38:03.0 +
+++ 90rpc.plugin2020-04-10 20:34:11.124131255 +0100
@@ -38,7 +38,7 @@
echo "${INDENT}Enabling RPC service(s) $RPC_SERVICES for net(s) $RPC_NETS"
- IFS=' ,'
+ IFS=$" ,\n"
for service in $RPC_SERVICES; do
ports="$(rpcinfo -p |awk "/tcp.*$service/"' { print $4 }' |uniq)"
echo "${INDENT}Adding TCP ports $ports for RPC service $service"
fixes it.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages arno-iptables-firewall depends on:
ii debconf [debconf-2.0] 1.5.73
ii iproute2 5.6.0-1
ii iptables 1.8.4-3
ii kmod 27-2
ii procps 2:3.3.16-4
Versions of packages arno-iptables-firewall recommends:
ii bind9-dnsutils [dnsutils] 1:9.16.1-2
ii curl 7.68.0-1
ii dnsutils 1:9.16.1-2
ii rsyslog8.2002.0-2
arno-iptables-firewall suggests no packages.
-- Configuration Files:
/etc/arno-iptables-firewall/plugins/rpc.conf changed:
ENABLED=1
RPC_SERVICES="portmapper status statd nfs mountd nlockmgr"
RPC_NETS="10.0.2.0/24"
-- debconf information excluded
-- debsums errors found:
debsums: changed file /usr/share/arno-iptables-firewall/plugins/90rpc.plugin
(from arno-iptables-firewall package)
Bug#956552: arno-iptables-firewall: 90-rpc.plugin causes arno to fail to start.
Thanks for the report. We will fix it upstream as well. Please note that
the patch you provided is not POSIX-compatible since $'\n' is not POSIX.
The correct fix should be something like:
IFS=" ,
"
cheers,
Arno
On 12-04-2020 21:05, Julia Longtin wrote:
Package: arno-iptables-firewall
Version: 2.1.0-2
Severity: normal
Tags: patch upstream
Dear Maintainer,
90-rpc.plugin does not see carriage return as a line break when running rpcinfo -p |awk
"/tcp.*$service/"' { print $4 }' |uniq
this causes arno to fail to start if you have NFS services, and have turned
this plugin on.
--- 90rpc.plugin~ 2020-01-03 10:38:03.0 +
+++ 90rpc.plugin2020-04-10 20:34:11.124131255 +0100
@@ -38,7 +38,7 @@
echo "${INDENT}Enabling RPC service(s) $RPC_SERVICES for net(s) $RPC_NETS"
- IFS=' ,'
+ IFS=$" ,\n"
for service in $RPC_SERVICES; do
ports="$(rpcinfo -p |awk "/tcp.*$service/"' { print $4 }' |uniq)"
echo "${INDENT}Adding TCP ports $ports for RPC service $service"
fixes it.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages arno-iptables-firewall depends on:
ii debconf [debconf-2.0] 1.5.73
ii iproute2 5.6.0-1
ii iptables 1.8.4-3
ii kmod 27-2
ii procps 2:3.3.16-4
Versions of packages arno-iptables-firewall recommends:
ii bind9-dnsutils [dnsutils] 1:9.16.1-2
ii curl 7.68.0-1
ii dnsutils 1:9.16.1-2
ii rsyslog8.2002.0-2
arno-iptables-firewall suggests no packages.
-- Configuration Files:
/etc/arno-iptables-firewall/plugins/rpc.conf changed:
ENABLED=1
RPC_SERVICES="portmapper status statd nfs mountd nlockmgr"
RPC_NETS="10.0.2.0/24"
-- debconf information excluded
-- debsums errors found:
debsums: changed file /usr/share/arno-iptables-firewall/plugins/90rpc.plugin
(from arno-iptables-firewall package)
Bug#824684: arno-iptables-firewall: Please fix the startup problem!
This has already been fixed upstream in version 2.0.2a. Unfortunately it seems this package is no longer maintained on Debian. The fix is simply using the newer systemd service file (/lib/systemd/system/arno-iptables-firewall.service) that comes with 2.0.2a. You can either manually overwrite this file it or instead of the Debian package use the upstream version to fix this issue. On 17/02/18 21:07, Odd Martin Baanrud wrote: Package: arno-iptables-firewall Version: 2.0.1.f-1.1 Followup-For: Bug #824684 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please fix the problem which causes the script not "starting" upon system reboot. And if possible, please backport it to Stretch. One should not have to log in to the system just to "start" a script like 'arno-iptables-firewall'. - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.65 ii gawk 1:4.1.4+dfsg-1+b1 ii iproute2 4.14.1-2 ii iptables 1.6.2-1 Versions of packages arno-iptables-firewall recommends: ii curl 7.58.0-2 ii dnsutils 1:9.11.2.P1-1 ii rsyslog 8.32.0-1 arno-iptables-firewall suggests no packages. - -- Configuration Files: /etc/arno-iptables-firewall/custom-rules changed [not included] /etc/arno-iptables-firewall/firewall.conf changed [not included] /etc/arno-iptables-firewall/plugins/dyndns-host-open.conf changed [not included] /etc/arno-iptables-firewall/plugins/ssh-brute-force-protection.conf changed [not included] /etc/arno-iptables-firewall/plugins/traffic-shaper.conf changed [not included] - -- debconf information excluded -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEnp1Ho3Mxq+xtrc2yL2O/igQUx+IFAlqIi1kACgkQL2O/igQU x+I3iA/+JzBoGJCSEhVmSnZ63jQ9i/HuLRSA4XD/L4/oPaG9DXxHersLjg9+Bd5e eR0NzlVyu8mqEPV5rkckUcVttRBKf5Z3LuRMdkCLGPp+CI8AODok/ot9iLKKsfBL uSr2SnRJny80fJfDGaG3s5opbZ4De6dgYQoYJMUaZFL+sO/oNC6Wy8RtCILhLC7I 6gz3bOCDmbNaUBCoWzaNFRAaOIVwJz9OjkTz70Ed3Dlb5ntyyalOhbU8eBbllrOB 1EZnBq2LWIhtpdnDbg7fcrM/7LdbzaPuJJyyM6qmrLqqtn1NpLfcLRPoThBHXkXw v0jUeBbUpMYJLk9XRX4OX0kjNVYSGY/8cjVbqsLE1BV0199a+zntzF3lhoTAj/eS RPnJr006TdRKS3C/zhHi8jgv1PGEo9ntXA39nM1Asdc0sfKt7M4lNqv3UGgaWKBs 5tSSJbwwHLU8myh6kWoe8dbyy/tvRgc1mdKaYhPy0t3KZRL2/6VvqlconzS1/31n iTwK92uxos7DtmSyIz2ikAVqilSJyVBSHtGbgaGUq+UBNVy7tcwlQEltQOH8xJGG Yy9e6UTEsOQ03bwccDjjoHA0KJOU0CnOhaDN8R00Id9YGCYkl35IfPGHMIToVCSX qsJ/ozNljtG+1vd/Y9e7umiCvkNT8AAuezkmUe2waIvXCsYDGXY= =ZNSl -END PGP SIGNATURE-
Bug#886991: New upstream version of arno-iptables-firewall
Package: arno-iptables-firewall Version: 2.0.1.f-1 A new upstream version (v2.0.2a) of arno-iptables-firewall is available. It corrects/improves a few things. Most important fix concerns boot start failures on some systemd-enabled systems. I therefor strongly recommend to update Debian's version to the latest version. It's also strongly recommended to backport the systemd start file to the current stable version of Debian (9) to fix the boot start failures some systems are experiencing. The new version can be found here: https://github.com/arno-iptables-firewall/aif/releases cheers, Arno -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl
Bug#684424: arno-iptables-firewall: Spurious error messages because kmod doesn't print a "Module not found" error.
Although the actual problem is in kmod, I still think this change is sane enough to stay in AIF, at least for now. -arno On 8/14/2012 16:10, Wojciech Kusiak wrote: On Tue, Aug 14, 2012 at 07:43:18AM +0200, Arno van Amersfoort wrote: Thanks, I also changed it for modprobe_multi(). But you're right: kmod should really show some kind of error when it fails to load a module, although the reasoning behind it, could be that it somehow detects that the module is build-in and therefor silences its error... Wouldn't hurt to report this to the maintainer though. And apparently, usually it does display the very same error message as old modprobe did, so you may want to undo this -e '^$' check you added. There's a bug in the kmod version that causes it to abort silently when /lib/modules/$(uname -r)/modules.alias.bin doesn't exist. Like when you're using a Xen system with monolithic kernel loaded from outside of the VM's disk, which's how this machine is. My fault, obviously, for not checking on a more "regular" configuration first. I'm just too used to my VPSes, I guess... I owe both you and Debian an apology here, for filing bug against wrong package. Your script is a victim here. Sorry for wasting your time. Opened a bug against kmod (Bug#684901), and well, waiting for the consequences of my mistake. Sincerely, -- Wojciech -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684920: tried to just do NAT, blocks protocol 41
I think the ipv6-over-ipv4-plugin that comes with my firewall should probably implement the behaviour you want. Since you're using 1.9.2k, I'm not 100% sure this functionality/plugin was already available at the time. Please check out the latest version (2.0+) on my website to verify, if still doesn't fix your problem, drop a line on the AIF mailing-list... cheers, Arno On 8/14/2012 21:02, Barak A. Pearlmutter wrote: Package: arno-iptables-firewall Version: 1.9.2.k-4 With the ipmasq package gone the way of the dodo, I needed NAT functionality on a computer w/ a first-class IPv4 address to run an iodine server on that host. That host already had IPv6 connectivity using the auto6to4 package (in experimental) which sets up a standard 6to4 tunnel to the standard IPv4 anycast address, which uses IPv4 protocol 41 packets. (Note, *protocol* 41, not port 41.) Installing arno-iptables-firewall and configuring it for NAT functionality and *nothing else* blocked the IPv4 protocol 41 packets and thus killed the 6to4 tunnel. When I tried the miredo package instead, that was also broken, for similar reasons. It would be nice if arno-iptables-firewall had a "NAT and no blocking" option, so it could be used as a plug-in replacement for ipmasq, and would be guaranteed not to mess up IPv6 connectivity via IPv4 tunnels. Or at least, if there were documentation. (Of course, this was on a "stable" machine running an old version. If this is fixed in more recent versions --- it doesn't seem to be judging from just changelog entries --- my apologies.) --Barak. -- Barak A. Pearlmutter Hamilton Institute& Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684424: arno-iptables-firewall: Spurious error messages because kmod doesn't print a "Module not found" error.
Thanks, I also changed it for modprobe_multi(). But you're right: kmod should really show some kind of error when it fails to load a module, although the reasoning behind it, could be that it somehow detects that the module is build-in and therefor silences its error... Wouldn't hurt to report this to the maintainer though. cheers, Arno On 10-Aug-12 19:16, Wojciech Kusiak wrote: On Fri, Aug 10, 2012 at 07:40:27AM +0200, Arno van Amersfoort wrote: I think I managed to work around the issue, although I think kmod should of course return a more descriptive (error) message when a module is not found. Totally agreed . If it's documented somewhere that return 1 means "module not found" in particular, and other errors use different codes, it's slightly less wrong, but still, interactive-use programs should print a message on errors. Not many people have their shells set to print last command's return value. Of course, this is software with bugs like #665873 and #676387... Since I don't have a system with kmod here I can't test the fix. If you like you can grab the latest nightly from http://rocky.eld.leidenuniv.nl/arno-iptables-firewall/arno-iptables-firewall_nightly.tar.gz and report back. Well, actually, it doesn't solve it as you added the empty message check only to modprobe() and not to modprobe_multi(). But copying it to down there indeed silences the printouts. Of course, now it will not print any warning if kmod (or modprobe, for that matter) will return another error code without a message. Lose-lose situation, I guess. :( Thanks a lot for looking into this, and for the script itself too. :) Regards, -- Wojciech -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684424: arno-iptables-firewall: Spurious error messages because kmod doesn't print a "Module not found" error.
I think I managed to work around the issue, although I think kmod should of course return a more descriptive (error) message when a module is not found. Since I don't have a system with kmod here I can't test the fix. If you like you can grab the latest nightly from http://rocky.eld.leidenuniv.nl/arno-iptables-firewall/arno-iptables-firewall_nightly.tar.gz and report back. cheers, Arno On 09-Aug-12 21:57, Wojciech Kusiak wrote: Package: arno-iptables-firewall Version: 2.0.1.c-1 Severity: minor Hello. The modprobe() and modprobe_multi() functions inside /usr/share/arno-iptables-firewall/environment contain this check: if ! echo "$result" |grep -q -e "Module .* not found" -e "Can't locate module"; if it matches, either the "Assuming compiled-in" message, or nothing (depending on config switch setting) is printed. All other messages trigger a red ERROR printout. Except, this check works only with "old" modprobe which printed that message. Kmod when called through modprobe symlink just returns 1 with no error message when the module is missing. Well, at least that's what happens on the monolithic module-less Linode kernel. Thus, whenever I reload the firewall I get a screenful of red /sbin/modprobe ERROR (1): messages, without anything after the colon (as kmod didn't print a thing) To emphasize, this bypasses the $COMPILED_IN_KERNEL_MESSAGES check. This false error prints in any case. Kmod version 8-2, current from testing. If you consider this "silent" return of 1 to be a bug in kmod, please reassign this bug. Best regards, -- Wojciech -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.4.2-linode44 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.44 ii gawk 1:4.0.1+dfsg-2 ii iproute20120521-3 ii iptables 1.4.14-3 Versions of packages arno-iptables-firewall recommends: ii curl 7.26.0-1 ii dnsutils 1:9.8.1.dfsg.P1-4.2 ii rsyslog 5.8.11-1+b1 arno-iptables-firewall suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658499: arno-iptables-firewall syntax changes
I never suggested this was a security vulnerability. Clearly it isn't. I think Julia's frustration is that when reloading the firewall rules after the upgrade she gets a broken firewall and a WARNING message. Is there a way to prevent loading of the rules entirely and preserving the original firewall state in the case of a parsing error? Maybe that's reaching a little; I'm just curious if that might be a good path forward to prevent future updates from blowing away currently running firewalls when the administrator is unaware of configuration file changes (even parser fixes)? This will happen again I'm sure(completely by accident). See the history of bash for more examples(and bash upgrades are generally really clean). Well, you can simply use the "check-conf" argument to test your configuration prior to actually applying it. Having the firewall falling back to its previous configuration is not possible due to the way it's implemented -arno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658499: arno-iptables-firewall syntax changes
Dear Zac,
Your assumption is wrong. One can still use the short form
"SRC_PORT>INT_IP~INT_PORT". So the only real problem is when people
use(d) the undocumented, no longer working, "~SRC_PORT>INT_IP~INT_PORT"
form. The version that no longer allowed this form, is ALSO the version
that introduced rule sanity checking which IS mentioned in the
CHANGELOG. This means, as I also told Julia, that the firewall does
report that it was unable to parse *ALL* rules properly. It even reports
which rule fails and it certainly doesn´t cause any security issues.
Furthermore it's impossible for us to (regression) test any previously
undocumented/unintended functionality and report it in the CHANGELOG
accordingly.
cheers,
Arno
On 24-2-2012 18:21, Slade, Zac wrote:
Arno,
It sounds to me like you made a change to the software that changes the behavior of the
NAT_FORWARD_TCP setting to no longer allow a missing source IP address. In previous versions you allowed
"~SRC_PORT>INT_IP~INT_PORT" and now you must explicitly use the more complete form of
"SRC_IP~SRC_PORT>INT_IP~INT_PORT" or you will have ignored port forwarding rules.
Correct me if I'm wrong Arno, you seem to indicate in this bug report that
the earlier behavior is a bug. If so a note in the CHANGELOG stating that you
addressed a parser BUG would be helpful to anyone. I also understand that you
probably won't be able to do this for the current upload as amending CHANGELOG
entries isn't usually done. Maybe just a note in your upstream CHANGELOG
noting the bug fix.
Julia,
Looking at the current form of the firewall.conf that ships with arno in
sid I see the following:
# NAT TCP/UDP/IP forwards. Forward ports or protocols from the gateway to
# an internal client through (D)NAT. Note that you can also use these
# variables to forward ports to DMZ hosts.
#
# TCP/UDP form:
# "{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port} \
#{SRCIP3,...~}PORT3,...>DESTIP2{~port}"
#
# IP form:
# "{SRCIP1,SRCIP2,...~}PROTO1,PROTO2,...>DESTIP1 \
#{SRCIP3~}PROTO3,PROTO4,...>DESTIP2"
#
# TCP/UDP port forward examples:
# Simple (forward port 80 to internal host 192.168.0.10):
# NAT_FORWARD_xxx="80>192.168.0.10 20,21>192.168.0.10"
# Advanced (forward port 20& 21 to 192.168.0.10 and
# forward from 1.2.3.4 port 81 to 192.168.0.11 port 80:
# NAT_FORWARD_xxx="1.2.3.4~81>192.168.0.11~80"
#
# IP protocol forward example:
#(forward protocols 47& 48 to 192.168.0.10)
#NAT_FORWARD_IP="47,48>192.168.0.10"
#
# NOTE 1: {~port} is optional. Use it to redirect a specific port to a
# different port on the internal client.
# NOTE 2: {SRCIPx} is optional. Use it to restrict access for specific source
# (inet) IP addresses.
# (IPv4 Only)
# -
This does not seem to allow the syntax you were using. Notice the form
"{SRCIP1,SRCIP2,...~}PORT1,PORT2-PORT3,...>DESTIP1{~port}". This seems to
indicate to me that the ~ in your previous examples is what caused your breakage. Can you
confirm that the documentation is correct and that you can set
NAT_FORWARD_TCP=SRC_PORT>INT_IP~INT_PORT and it work correctly?
Thank you,
Zac Slade
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658499: arno-iptables-firewall: after upgrade, gives warning and does not apply NAT_FORWARD_TCP rules.
Well, again, the fact that it worked before doesn't mean it's a bug and
therefor needs special handling.
This bug can be closed as WONTFIX.
a.
On 06-Feb-12 17:07, Julia Longtin wrote:
No, i mean something in the changes file, so you know *before* you
restart your firewall, and the port forwards are dropped. an outage and
warning that does not tell one what to do to fix it is certainly an issue.
Julia Longtin
On Mon, Feb 6, 2012 at 12:28 PM, Arno van Amersfoort
mailto:arn...@rocky.eld.leidenuniv.nl>>
wrote:
Well it does do that:
Restarting Arno's Iptables Firewall...
** WARNING: In Variable NAT_FORWARD_TCP, Rule:
"~>10.100.__0.117~80" is ignored.
Feb 06 13:27:41 WARNING: Not all firewall rules are applied.
a.
On 06-Feb-12 12:54, Julia Longtin wrote:
Oh, that makes sense to me... except since it WAS valid syntax,
it means
that when it STOPPED being valid syntax, i need a little more
warning
than "oh, all your port forwards no longer exist, have a nice
day!". I
read debchanges, so at least a warning to sysadmins that the
syntax that
used to be valid is no longer valid makes sense to me.
Luckily, there will at least be this thread to guide other
sysadmins. I
had to use bash -x to trace through things and discover the
'fix' for my
perfectly 'valid' syntax not working.
Julia Longtin
On Mon, Feb 6, 2012 at 6:17 AM, Arno van Amersfoort
mailto:arn...@rocky.eld.leidenuniv.nl>
<mailto:arn...@rocky.eld.__leidenuniv.nl
<mailto:arn...@rocky.eld.leidenuniv.nl>>>
wrote:
Hello Julia,
Ah you mean that the first WITH the "~" in front of the
used to
be a valid syntax? If so, this was never intended and it
certainly
doesn't serve any purpose. The fix is simple, as you already
know,
get rid of it ;-), unless I'm missing something here.
cheers,
Arno
On 03-Feb-12 17:25, Julia Longtin wrote:
I mean that going from
"NAT_FORWARD_TCP=~>10.100.0.117~80"
causes
the problem. you have the fix correct.
Its possibly my syntax is wrong.. but it used to work
this way.
Julia Longtin
On Fri, Feb 3, 2012 at 2:56 PM, Arno van Amersfoort
mailto:arn...@rocky.eld.__leidenuniv.nl
<mailto:arn...@rocky.eld.leidenuniv.nl>>
<mailto:arn...@rocky.eld.
<mailto:arn...@rocky.eld.>__lei__denuniv.nl <http://leidenuniv.nl>
<mailto:arn...@rocky.eld.__leidenuniv.nl
<mailto:arn...@rocky.eld.leidenuniv.nl>>>>
wrote:
You mean that
"NAT_FORWARD_TCP=">10.100.__0.117~80"
causes the
problem and
"NAT_FORWARD_TCP="0/0~>10.__100.0.117~80"
fixes
that? I tried reproducing it, but I can't get it to
fail.
Could you
provide a snippet of the error?
thanks.
Arno
On 03-Feb-12 15:37, Julia Longtin wrote:
Package: arno-iptables-firewall
Version: 2.0.1-1
Severity: important
Dear Maintainer,
After performing an upgrade, i have found that the
format of the
rules expected in firewall.conf have changed.
Instead of accepting a blank source IP, it now
requires
a source
IP, or parse_rules fails, and gives a WARNING:
rule will be
ignored..
see the '0/0' that has been added to my
NAT_FORWARD_TCP
rules.
Julia Longtin
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
(charmap=locale:
Cannot set LC_CTYPE to default locale: No such
file or
directory
locale: Cannot set LC_MESSAGES to default locale: No
such file
Bug#658458: support for /etc/arno*/firewall.conf.d
Just implemented conf.d support in svn r612 so the next stable should have this included. cheers, Arno On 03-Feb-12 11:23, Michael Hanke wrote: On Fri, Feb 03, 2012 at 10:46:21AM +0100, Arno van Amersfoort wrote: Fixing this before April, shouldn't be a problem. Only thing I'm wondering about: Can't you use LOCAL_CONFIG_FILE (I don't think version 1.9.x already has this) to do/implement what you want or is it too restricted? LOCAL_CONFIG_FILE points to a single file. The idea of a config.d/ directory is that other packages can drop config snippets in there and alter the configuration. Separate config snippet files having the advantage that packages wouldn't conflict with each other and an admin can still alter any package-provided configuration with yet another snippet that is loaded at the end. michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658499: arno-iptables-firewall: after upgrade, gives warning and does not apply NAT_FORWARD_TCP rules.
Well it does do that: Restarting Arno's Iptables Firewall... ** WARNING: In Variable NAT_FORWARD_TCP, Rule: "~>10.100.__0.117~80" is ignored. Feb 06 13:27:41 WARNING: Not all firewall rules are applied. a. On 06-Feb-12 12:54, Julia Longtin wrote: Oh, that makes sense to me... except since it WAS valid syntax, it means that when it STOPPED being valid syntax, i need a little more warning than "oh, all your port forwards no longer exist, have a nice day!". I read debchanges, so at least a warning to sysadmins that the syntax that used to be valid is no longer valid makes sense to me. Luckily, there will at least be this thread to guide other sysadmins. I had to use bash -x to trace through things and discover the 'fix' for my perfectly 'valid' syntax not working. Julia Longtin On Mon, Feb 6, 2012 at 6:17 AM, Arno van Amersfoort mailto:arn...@rocky.eld.leidenuniv.nl>> wrote: Hello Julia, Ah you mean that the first WITH the "~" in front of the used to be a valid syntax? If so, this was never intended and it certainly doesn't serve any purpose. The fix is simple, as you already know, get rid of it ;-), unless I'm missing something here. cheers, Arno On 03-Feb-12 17:25, Julia Longtin wrote: I mean that going from "NAT_FORWARD_TCP=~>10.100.__0.117~80" causes the problem. you have the fix correct. Its possibly my syntax is wrong.. but it used to work this way. Julia Longtin On Fri, Feb 3, 2012 at 2:56 PM, Arno van Amersfoort mailto:arn...@rocky.eld.leidenuniv.nl> <mailto:arn...@rocky.eld.__leidenuniv.nl <mailto:arn...@rocky.eld.leidenuniv.nl>>> wrote: You mean that "NAT_FORWARD_TCP=">10.100.0.117~80" causes the problem and "NAT_FORWARD_TCP="0/0~>10.100.0.117~80" fixes that? I tried reproducing it, but I can't get it to fail. Could you provide a snippet of the error? thanks. Arno On 03-Feb-12 15:37, Julia Longtin wrote: Package: arno-iptables-firewall Version: 2.0.1-1 Severity: important Dear Maintainer, After performing an upgrade, i have found that the format of the rules expected in firewall.conf have changed. Instead of accepting a blank source IP, it now requires a source IP, or parse_rules fails, and gives a WARNING: rule will be ignored.. see the '0/0' that has been added to my NAT_FORWARD_TCP rules. Julia Longtin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.41 ii gawk 1:3.1.8+dfsg-0.1 ii iproute20120105-1 ii iptables 1.4.12.2-1 Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.8.1.dfsg.P1-2 ii lynx 2.8.8dev.9-3 ii rsyslog 5.8.6-1 arno-iptables-firewall suggests no packages. -- Configuration Files: /etc/arno-iptables-firewall/firewall.conf changed: EXT_IF="$DC_EXT_IF" EXT_IF_DHCP_IP=$DC_EXT_IF_DHCP_IP EXTERNAL_DHCP_SERVER=0 EXTERNAL_DHCPV6_SERVER=0 INT_IF="$DC_INT_IF" INTERNAL_NET="$DC_INTERNAL_NET" INTERNAL_NET_ANTISPOOF=1 DMZ_IF="" DMZ_NET="" DMZ_NET_ANTISPOOF=1 NAT=$DC_NAT NAT_INTERNAL_NET="$DC_NAT_INTERNAL_NET" NAT_LOCAL_REDIRECT=1 NAT_FORWARD_TCP="0/0~>10.100.0.1
Bug#658499: arno-iptables-firewall: after upgrade, gives warning and does not apply NAT_FORWARD_TCP rules.
You mean that "NAT_FORWARD_TCP=">10.100.0.117~80" causes the problem and "NAT_FORWARD_TCP="0/0~>10.100.0.117~80" fixes that? I tried reproducing it, but I can't get it to fail. Could you provide a snippet of the error? thanks. Arno On 03-Feb-12 15:37, Julia Longtin wrote: Package: arno-iptables-firewall Version: 2.0.1-1 Severity: important Dear Maintainer, After performing an upgrade, i have found that the format of the rules expected in firewall.conf have changed. Instead of accepting a blank source IP, it now requires a source IP, or parse_rules fails, and gives a WARNING: rule will be ignored.. see the '0/0' that has been added to my NAT_FORWARD_TCP rules. Julia Longtin -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.41 ii gawk 1:3.1.8+dfsg-0.1 ii iproute20120105-1 ii iptables 1.4.12.2-1 Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.8.1.dfsg.P1-2 ii lynx 2.8.8dev.9-3 ii rsyslog 5.8.6-1 arno-iptables-firewall suggests no packages. -- Configuration Files: /etc/arno-iptables-firewall/firewall.conf changed: EXT_IF="$DC_EXT_IF" EXT_IF_DHCP_IP=$DC_EXT_IF_DHCP_IP EXTERNAL_DHCP_SERVER=0 EXTERNAL_DHCPV6_SERVER=0 INT_IF="$DC_INT_IF" INTERNAL_NET="$DC_INTERNAL_NET" INTERNAL_NET_ANTISPOOF=1 DMZ_IF="" DMZ_NET="" DMZ_NET_ANTISPOOF=1 NAT=$DC_NAT NAT_INTERNAL_NET="$DC_NAT_INTERNAL_NET" NAT_LOCAL_REDIRECT=1 NAT_FORWARD_TCP="0/0~>10.100.0.117~80 \ 0/0~8889>10.100.0.88~80 \ 0/0~8890>10.100.0.40~80 \ 0/0~8891>10.100.0.58~80 \ 0/0~8892>10.100.0.100~80 \ 0/0~8893>10.100.0.20~80 \ 0/0~2280>10.100.0.44~22 \ 0/0~2281>10.100.0.75~22 \ 0/0~8333>10.100.0.95~8333 " NAT_FORWARD_UDP="" NAT_FORWARD_IP="" INET_FORWARD_TCP="" INET_FORWARD_UDP="" INET_FORWARD_IP="" IP4TABLES="/sbin/iptables" IP6TABLES="/sbin/ip6tables" ENV_FILE="/usr/share/arno-iptables-firewall/environment" PLUGIN_BIN_PATH="/usr/share/arno-iptables-firewall/plugins" PLUGIN_CONF_PATH="/etc/arno-iptables-firewall/plugins" DMESG_PANIC_ONLY=1 MANGLE_TOS=1 SET_MSS=1 TTL_INC=0 USE_IRC=0 LOOSE_FORWARD=0 FORWARD_LINK_LOCAL=0 IPV6_DROP_RH_ZERO=1 RESERVED_NET_DROP=0 DRDOS_PROTECT=0 IPV6_SUPPORT=0 NMB_BROADCAST_FIX=0 COMPILED_IN_KERNEL_MESSAGES=1 DEFAULT_POLICY_DROP=1 TRUSTED_IF="" IF_TRUSTS="" CUSTOM_RULES="/etc/arno-iptables-firewall/custom-rules" LOCAL_CONFIG_FILE="" DISABLE_IPTABLES_BATCH=0 TRACE=0 BLOCKED_HOST_LOG=1 SCAN_LOG=1 POSSIBLE_SCAN_LOG=1 BAD_FLAGS_LOG=1 INVALID_TCP_LOG=0 INVALID_UDP_LOG=0 INVALID_ICMP_LOG=0 RESERVED_NET_LOG=0 FRAG_LOG=1 INET_OUTPUT_DENY_LOG=1 LAN_OUTPUT_DENY_LOG=1 LAN_INPUT_DENY_LOG=1 DMZ_OUTPUT_DENY_LOG=1 DMZ_INPUT_DENY_LOG=1 FORWARD_DROP_LOG=1 LINK_LOCAL_DROP_LOG=1 ICMP_REQUEST_LOG=1 ICMP_OTHER_LOG=1 PRIV_TCP_LOG=1 PRIV_UDP_LOG=1 UNPRIV_TCP_LOG=1 UNPRIV_UDP_LOG=1 IGMP_LOG=1 OTHER_IP_LOG=1 ICMP_FLOOD_LOG=1 FIREWALL_LOG="/var/log/arno-iptables-firewall" LOGLEVEL="info" LOG_HOST_INPUT_TCP="" LOG_HOST_INPUT_UDP="" LOG_HOST_INPUT_IP="" LOG_HOST_OUTPUT_TCP="" LOG_HOST_OUTPUT_UDP="" LOG_HOST_OUTPUT_IP="" LOG_INPUT_TCP="" LOG_INPUT_UDP="" LOG_INPUT_IP="" LOG_OUTPUT_TCP="" LOG_OUTPUT_UDP="" LOG_OUTPUT_IP="" LOG_HOST_INPUT="" LOG_HOST_OUTPUT="" SYN_PROT=1 REDUCE_DOS_ABILITY=1 ECHO_IGNORE=0 LOG_MARTIANS=1 IP_FORWARDING=1 IPV6_AUTO_CONFIGURATION=1 ICMP_REDIRECT=0 CONNTRACK=16384 ECN=1 RP_FILTER=1 SOURCE_ROUTE_PROTECTION=1 LOCAL_PORT_RANGE="32768 61000" DEFAULT_TTL=64 NO_PMTU_DISCOVERY=0 LAN_OPEN_ICMP=1 LAN_OPEN_TCP="21 22 80" LAN_OPEN_UDP="53 67 69" LAN_OPEN_IP="" LAN_DENY_TCP="" LAN_DENY_UDP="" LAN_DENY_IP="" LAN_HOST_OPEN_TCP="" LAN_HOST_OPEN_UDP="" LAN_HOST_OPEN_IP="" LAN_HOST_DENY_TCP="" LAN_HOST_DENY_UDP="" LAN_HOST_DENY_IP="" LAN_INET_OPEN_ICMP=1 LAN_INET_OPEN_TCP="" LAN_INET_OPEN_UDP="" LAN_INET_OPEN_IP="" LAN_INET_DENY_TCP="" LAN_INET_DENY_UDP="" LAN_INET_DENY_IP="" LAN_INET_HOST_OPEN_TCP="" LAN_INET_HOST_OPEN_UDP="" LAN_INET_HOST_OPEN_IP="" LAN_INET_HOST_DENY_TCP="" LAN_INET_HOST_DENY_UDP="" LAN_INET_HOST_DENY_IP="" DMZ_OPEN_ICMP=1 DMZ_OPEN_TCP="" DMZ_OPEN_UDP="" DMZ_OPEN_IP="" DMZ_HOST_OPEN_TCP="" DMZ_HOST_OPEN_UDP="" DMZ_HOST_OPEN_IP="" INET_DMZ_OPEN_ICMP=0 INET_DMZ_OPEN_TCP="" INET_DMZ_OPEN_UDP="" INET_DMZ_OPEN_IP="" INET_DMZ_DENY_TCP="" INET_DMZ_DENY_UDP="" INET_DMZ_DENY_IP="" INET_DMZ_HOST_OPEN_TCP="" INET_DMZ_HOST_OPEN_UDP="" INET_DMZ_HOST_OPEN_IP="" INET_DMZ_HOST_DENY_TCP="" INET_DMZ_HOST_DENY_UDP="" INET_DMZ_HOST_DENY_IP="" DMZ_INET_OPEN_ICMP=1 DMZ_INET_OPEN_TCP="" DMZ_I
Bug#658458: support for /etc/arno*/firewall.conf.d
Totally makes sense. I think we'll replace LOCAL_CONF_FILE with the conf.d/ implementation. cheers, Arno On 03-Feb-12 11:23, Michael Hanke wrote: On Fri, Feb 03, 2012 at 10:46:21AM +0100, Arno van Amersfoort wrote: Fixing this before April, shouldn't be a problem. Only thing I'm wondering about: Can't you use LOCAL_CONFIG_FILE (I don't think version 1.9.x already has this) to do/implement what you want or is it too restricted? LOCAL_CONFIG_FILE points to a single file. The idea of a config.d/ directory is that other packages can drop config snippets in there and alter the configuration. Separate config snippet files having the advantage that packages wouldn't conflict with each other and an admin can still alter any package-provided configuration with yet another snippet that is loaded at the end. michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658458: support for /etc/arno*/firewall.conf.d
Fixing this before April, shouldn't be a problem. Only thing I'm wondering about: Can't you use LOCAL_CONFIG_FILE (I don't think version 1.9.x already has this) to do/implement what you want or is it too restricted? -arno On 03-Feb-12 10:10, Michael Hanke wrote: On Fri, Feb 03, 2012 at 09:59:32AM +0100, Arno van Amersfoort wrote: cc'ed in my fellow dev. I think it's a good idea and should be fairly easy to implement. Would probably also make things easier for debconf, would it Michael? It sure would! Michael PS: Debian stable freeze is coming up. It would be nice to get this in. But it would need to happen sometime before April to leave enough time for testing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658458: support for /etc/arno*/firewall.conf.d
cc'ed in my fellow dev. I think it's a good idea and should be fairly easy to implement. Would probably also make things easier for debconf, would it Michael? cheers, Arno On 03-Feb-12 9:53, Michael Hanke wrote: On Fri, Feb 03, 2012 at 09:17:46AM +0100, Harald Dunkel wrote: Package: arno-iptables-firewall Version: 1.9.2.k-4 Severity: wishlist It would be nice if I could add my own config file to /etc/arno-iptables-firewall/firewall.conf.d (e.g. to override logging). The idea is to keep default configuration and local modifications separate to avoid conflicts on the next upgrade, and to support meta packages fine tuning the default firewall.conf file. I agree. But this shouldn't be a Debian-specific thing. Arno, what do you think? Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#653421: [demo@qemuhost: arno-iptables-firewall: rpc services blocked to internal network]
This has been fixed/included upstream (by us). The next stable version has it included. -arno On 28-Dec-11 3:58, fai demo user wrote: Package: arno-iptables-firewall Version: 2.0.0.c-1 Severity: normal Dear Maintainer, I have discovered that arno is blocking rpc services to my internal network, which makes it hard to network boot clients. ;) A friend of mine has created a script to fix this: https://gitorious.org/fai-cd-configs/fai-cd-configs/blobs/raw/master/files/usr/share/arno-iptables-firewall/plugins/90rpc.plugin/DEFAULT Thanks, Julia Longtin *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.41 ii gawk 1:3.1.8+dfsg-0.1 ii iproute2017-1 ii iptables 1.4.12-1 Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.8.1.dfsg-1.1 ii lynx 2.8.8dev.9-2 ii rsyslog 5.8.6-1 arno-iptables-firewall suggests no packages. -- Configuration Files: /etc/arno-iptables-firewall/firewall.conf changed: EXT_IF="$DC_EXT_IF" EXT_IF_DHCP_IP=$DC_EXT_IF_DHCP_IP EXTERNAL_DHCP_SERVER=0 EXTERNAL_DHCPV6_SERVER=0 INT_IF="$DC_INT_IF" INTERNAL_NET="$DC_INTERNAL_NET" INTERNAL_NET_ANTISPOOF=1 DMZ_IF="" DMZ_NET="" DMZ_NET_ANTISPOOF=1 NAT=$DC_NAT NAT_INTERNAL_NET="$DC_NAT_INTERNAL_NET" NAT_LOCAL_REDIRECT=1 NAT_FORWARD_TCP="~>10.100.0.117~80 ~8889>10.100.0.88~80 ~8890>10.100.0.40~80 ~8891>10.100.0.58~80 ~8892>10.100.0.100~80 ~8893>10.100.0.20~80 ~2280>10.100.0.44~22 ~2281>10.100.0.75~22 ~8333>10.100.0.95~8333" NAT_FORWARD_UDP="" NAT_FORWARD_IP="" INET_FORWARD_TCP="" INET_FORWARD_UDP="" INET_FORWARD_IP="" IP4TABLES="/sbin/iptables" IP6TABLES="/sbin/ip6tables" ENV_FILE="/usr/share/arno-iptables-firewall/environment" PLUGIN_BIN_PATH="/usr/share/arno-iptables-firewall/plugins" PLUGIN_CONF_PATH="/etc/arno-iptables-firewall/plugins" DMESG_PANIC_ONLY=1 MANGLE_TOS=1 SET_MSS=1 TTL_INC=0 RESOLV_IPS=0 DNS_FAST_FAIL=0 USE_IRC=0 LOOSE_FORWARD=0 FORWARD_LINK_LOCAL=0 DROP_PRIVATE_ADDRESSES=0 DRDOS_PROTECT=0 IPV6_SUPPORT=0 NMB_BROADCAST_FIX=0 COMPILED_IN_KERNEL_MESSAGES=1 DEFAULT_POLICY_DROP=1 TRUSTED_IF="" IF_TRUSTS="" CUSTOM_RULES="/etc/arno-iptables-firewall/custom-rules" LOCAL_CONFIG_FILE="" DISABLE_IPTABLES_BATCH=0 TRACE=0 BLOCKED_HOST_LOG=1 SCAN_LOG=1 POSSIBLE_SCAN_LOG=1 BAD_FLAGS_LOG=1 INVALID_TCP_LOG=0 INVALID_UDP_LOG=0 INVALID_ICMP_LOG=0 RESERVED_NET_LOG=0 FRAG_LOG=1 INET_OUTPUT_DENY_LOG=1 LAN_OUTPUT_DENY_LOG=1 LAN_INPUT_DENY_LOG=1 DMZ_OUTPUT_DENY_LOG=1 DMZ_INPUT_DENY_LOG=1 FORWARD_DROP_LOG=1 LINK_LOCAL_DROP_LOG=1 ICMP_REQUEST_LOG=1 ICMP_OTHER_LOG=1 PRIV_TCP_LOG=1 PRIV_UDP_LOG=1 UNPRIV_TCP_LOG=1 UNPRIV_UDP_LOG=1 IGMP_LOG=1 OTHER_IP_LOG=1 ICMP_FLOOD_LOG=1 FIREWALL_LOG="/var/log/arno-iptables-firewall" LOGLEVEL="info" LOG_HOST_INPUT_TCP="" LOG_HOST_INPUT_UDP="" LOG_HOST_INPUT_IP="" LOG_HOST_OUTPUT_TCP="" LOG_HOST_OUTPUT_UDP="" LOG_HOST_OUTPUT_IP="" LOG_INPUT_TCP="" LOG_INPUT_UDP="" LOG_INPUT_IP="" LOG_OUTPUT_TCP="" LOG_OUTPUT_UDP="" LOG_OUTPUT_IP="" LOG_HOST_INPUT="" LOG_HOST_OUTPUT="" SYN_PROT=1 REDUCE_DOS_ABILITY=1 ECHO_IGNORE=0 LOG_MARTIANS=1 IP_FORWARDING=1 IPV6_AUTO_CONFIGURATION=1 ICMP_REDIRECT=0 CONNTRACK=16384 ECN=0 RP_FILTER=1 SOURCE_ROUTE_PROTECTION=1 LOCAL_PORT_RANGE="32768 61000" DEFAULT_TTL=64 NO_PMTU_DISCOVERY=0 LAN_OPEN_ICMP=1 LAN_OPEN_TCP="21 22 80 1234" LAN_OPEN_UDP="53 67 69" LAN_OPEN_IP="" LAN_DENY_TCP="" LAN_DENY_UDP="" LAN_DENY_IP="" LAN_HOST_OPEN_TCP="" LAN_HOST_OPEN_UDP="" LAN_HOST_OPEN_IP="" LAN_HOST_DENY_TCP="" LAN_HOST_DENY_UDP="" LAN_HOST_DENY_IP="" LAN_INET_OPEN_ICMP=1 LAN_INET_OPEN_TCP="" LAN_INET_OPEN_UDP="" LAN_INET_OPEN_IP="" LAN_INET_DENY_TCP="" LAN_INET_DENY_UDP="" LAN_INET_DENY_IP="" LAN_INET_HOST_OPEN_TCP="" LAN_INET_HOST_OPEN_UDP="" LAN_INET_HOST_OPEN_IP="" LAN_INET_HOST_DENY_TCP="" LAN_INET_HOST_DENY_UDP="" LAN_INET_HOST_DENY_IP="" DMZ_OPEN_ICMP=1 DMZ_OPEN_TCP="" DMZ_OPEN_UDP="" DMZ_OPEN_IP="" DMZ_HOST_OPEN_TCP="" DMZ_HOST_OPEN_UDP="" DMZ_HOST_OPEN_IP="" INET_DMZ_OPEN_ICMP=0 INET_DMZ_OPEN_TCP="" INET_DMZ_OPEN_UDP="" INET_DMZ_OPEN_IP="" INET_DMZ_DENY_TCP="" INET_DMZ_DENY_UDP="" INET_DMZ_DENY_IP="" INET_DMZ_HOST_OPEN_TCP="" INET_DMZ_H
Bug#645863: how to configure "all interfaces" in postinst?
Just put this in your EXT, that should cover about all cases: EXT_IF="eth+ br+ wlan+" -arno On 17-Jan-12 9:12, Michael Hanke wrote: Hi, I just realized that I never replied to this one, but better late than never... On Wed, Oct 19, 2011 at 08:59:25AM +0200, Harald Dunkel wrote: I would like to restrict traffic on all interfaces except for lo0, even if new interfaces are introduced later (by adding a wlan USB stick or a br0 interface, for example). How can I tell the postinst script? I cannot tell you from the top of my head. But in any case this is not really a wishlist bug either. I rather seems like a usage-related question that should be asked on upstream's support mailing list for this software, see http://rocky.eld.leidenuniv.nl Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#653421: [demo@qemuhost: arno-iptables-firewall: rpc services blocked to internal network]
Thanks, I'll inspect it and consider it for inclusion. Do note that: if [ -z "RPC_SERVICES" ]; then needs to be: if [ -z "$RPC_SERVICES" ]; then cheers, Arno On 28-Dec-11 3:58, fai demo user wrote: Package: arno-iptables-firewall Version: 2.0.0.c-1 Severity: normal Dear Maintainer, I have discovered that arno is blocking rpc services to my internal network, which makes it hard to network boot clients. ;) A friend of mine has created a script to fix this: https://gitorious.org/fai-cd-configs/fai-cd-configs/blobs/raw/master/files/usr/share/arno-iptables-firewall/plugins/90rpc.plugin/DEFAULT Thanks, Julia Longtin *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.41 ii gawk 1:3.1.8+dfsg-0.1 ii iproute2017-1 ii iptables 1.4.12-1 Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.8.1.dfsg-1.1 ii lynx 2.8.8dev.9-2 ii rsyslog 5.8.6-1 arno-iptables-firewall suggests no packages. -- Configuration Files: /etc/arno-iptables-firewall/firewall.conf changed: EXT_IF="$DC_EXT_IF" EXT_IF_DHCP_IP=$DC_EXT_IF_DHCP_IP EXTERNAL_DHCP_SERVER=0 EXTERNAL_DHCPV6_SERVER=0 INT_IF="$DC_INT_IF" INTERNAL_NET="$DC_INTERNAL_NET" INTERNAL_NET_ANTISPOOF=1 DMZ_IF="" DMZ_NET="" DMZ_NET_ANTISPOOF=1 NAT=$DC_NAT NAT_INTERNAL_NET="$DC_NAT_INTERNAL_NET" NAT_LOCAL_REDIRECT=1 NAT_FORWARD_TCP="~>10.100.0.117~80 ~8889>10.100.0.88~80 ~8890>10.100.0.40~80 ~8891>10.100.0.58~80 ~8892>10.100.0.100~80 ~8893>10.100.0.20~80 ~2280>10.100.0.44~22 ~2281>10.100.0.75~22 ~8333>10.100.0.95~8333" NAT_FORWARD_UDP="" NAT_FORWARD_IP="" INET_FORWARD_TCP="" INET_FORWARD_UDP="" INET_FORWARD_IP="" IP4TABLES="/sbin/iptables" IP6TABLES="/sbin/ip6tables" ENV_FILE="/usr/share/arno-iptables-firewall/environment" PLUGIN_BIN_PATH="/usr/share/arno-iptables-firewall/plugins" PLUGIN_CONF_PATH="/etc/arno-iptables-firewall/plugins" DMESG_PANIC_ONLY=1 MANGLE_TOS=1 SET_MSS=1 TTL_INC=0 RESOLV_IPS=0 DNS_FAST_FAIL=0 USE_IRC=0 LOOSE_FORWARD=0 FORWARD_LINK_LOCAL=0 DROP_PRIVATE_ADDRESSES=0 DRDOS_PROTECT=0 IPV6_SUPPORT=0 NMB_BROADCAST_FIX=0 COMPILED_IN_KERNEL_MESSAGES=1 DEFAULT_POLICY_DROP=1 TRUSTED_IF="" IF_TRUSTS="" CUSTOM_RULES="/etc/arno-iptables-firewall/custom-rules" LOCAL_CONFIG_FILE="" DISABLE_IPTABLES_BATCH=0 TRACE=0 BLOCKED_HOST_LOG=1 SCAN_LOG=1 POSSIBLE_SCAN_LOG=1 BAD_FLAGS_LOG=1 INVALID_TCP_LOG=0 INVALID_UDP_LOG=0 INVALID_ICMP_LOG=0 RESERVED_NET_LOG=0 FRAG_LOG=1 INET_OUTPUT_DENY_LOG=1 LAN_OUTPUT_DENY_LOG=1 LAN_INPUT_DENY_LOG=1 DMZ_OUTPUT_DENY_LOG=1 DMZ_INPUT_DENY_LOG=1 FORWARD_DROP_LOG=1 LINK_LOCAL_DROP_LOG=1 ICMP_REQUEST_LOG=1 ICMP_OTHER_LOG=1 PRIV_TCP_LOG=1 PRIV_UDP_LOG=1 UNPRIV_TCP_LOG=1 UNPRIV_UDP_LOG=1 IGMP_LOG=1 OTHER_IP_LOG=1 ICMP_FLOOD_LOG=1 FIREWALL_LOG="/var/log/arno-iptables-firewall" LOGLEVEL="info" LOG_HOST_INPUT_TCP="" LOG_HOST_INPUT_UDP="" LOG_HOST_INPUT_IP="" LOG_HOST_OUTPUT_TCP="" LOG_HOST_OUTPUT_UDP="" LOG_HOST_OUTPUT_IP="" LOG_INPUT_TCP="" LOG_INPUT_UDP="" LOG_INPUT_IP="" LOG_OUTPUT_TCP="" LOG_OUTPUT_UDP="" LOG_OUTPUT_IP="" LOG_HOST_INPUT="" LOG_HOST_OUTPUT="" SYN_PROT=1 REDUCE_DOS_ABILITY=1 ECHO_IGNORE=0 LOG_MARTIANS=1 IP_FORWARDING=1 IPV6_AUTO_CONFIGURATION=1 ICMP_REDIRECT=0 CONNTRACK=16384 ECN=0 RP_FILTER=1 SOURCE_ROUTE_PROTECTION=1 LOCAL_PORT_RANGE="32768 61000" DEFAULT_TTL=64 NO_PMTU_DISCOVERY=0 LAN_OPEN_ICMP=1 LAN_OPEN_TCP="21 22 80 1234" LAN_OPEN_UDP="53 67 69" LAN_OPEN_IP="" LAN_DENY_TCP="" LAN_DENY_UDP="" LAN_DENY_IP="" LAN_HOST_OPEN_TCP="" LAN_HOST_OPEN_UDP="" LAN_HOST_OPEN_IP="" LAN_HOST_DENY_TCP="" LAN_HOST_DENY_UDP="" LAN_HOST_DENY_IP="" LAN_INET_OPEN_ICMP=1 LAN_INET_OPEN_TCP="" LAN_INET_OPEN_UDP="" LAN_INET_OPEN_IP="" LAN_INET_DENY_TCP="" LAN_INET_DENY_UDP="" LAN_INET_DENY_IP="" LAN_INET_HOST_OPEN_TCP="" LAN_INET_HOST_OPEN_UDP="" LAN_INET_HOST_OPEN_IP="" LAN_INET_HOST_DENY_TCP="" LAN_INET_HOST_DENY_UDP="" LAN_INET_HOST_DENY_IP="" DMZ_OPEN_ICMP=1 DMZ_OPEN_TCP="" DMZ_OPEN_UDP="" DMZ_OPEN_IP="" DMZ_HOST_OPEN_TCP="" DMZ_HOST_OPEN_UDP="" DMZ_HOST_OPEN_IP="" INET_DMZ_OPEN_ICMP=0 INET_DMZ_OPEN_TCP="" INET_DMZ_OPEN_UDP="" INET_DMZ_OPEN_IP="" INET_DMZ_DENY_TCP="" INET_DM
Bug#655212: Updated mdadd.sh (alias /usr/share/doc/mdadm/examples/newdisk.gz)
Package: mdadm Version: 3.1.4-1+8efb9d1 There is an updated version (1.52) of my mdadd.sh script available (packed as /usr/share/doc/mdadm/examples/newdisk.gz in the mdadm package). You can obtain it from http://rocky.eld.leidenuniv.nl/scripts/mdadd.sh Could it please be updated in the mdadm package? Thanks! -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: a.c.j.van.amersfo...@eld.physics.leidenuniv.nl Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631424: arno-iptables-firewall: Firewall blocks multicast traffic completely without any configuration option
(I think) I've fixed this issue in 2.0.0c-DEVEL. The upcoming 2.0.0c will have the fix which can be used downstream. -arno On 6/23/2011 20:43, S. G. wrote: Package: arno-iptables-firewall Version: 2.0.0.a-2 Severity: important Tags: upstream After updating from arno-iptables-firewall 1.9.2.k-4 zeroconf (MDNS) does work any more. Investigations brought up this set of rules Chain EXT_MULTICAST_CHAIN (2 references) pkts bytes target prot opt in out source destination 00 LOGtcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:0:1023 limit: avg 6/min burst 2 LOG flags 0 level 6 prefix `AIF:PRIV TCP multicast: ' 00 LOGudp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:0:1023 limit: avg 6/min burst 2 LOG flags 0 level 6 prefix `AIF:PRIV UDP multicast: ' 00 LOGtcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 limit: avg 6/min burst 2 LOG flags 0 level 6 prefix `AIF:UNPRIV TCP multicast: ' 00 LOGudp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1024 limit: avg 6/min burst 2 LOG flags 0 level 6 prefix `AIF:UNPRIV UDP multicast: ' 00 LOGicmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: avg 3/min burst 1 LOG flags 0 level 6 prefix `AIF:ICMP-multicast-request: ' 00 LOGicmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp !type 8 limit: avg 12/hour burst 1 LOG flags 0 level 6 prefix `AIF:ICMP-multicast-other: ' 00 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 which obviously blocks all multicast packets. The configuration files doesn't offer a way to let in zeroconf traffic (MDNS, UDP Port 5353) again. With the stable version of the packet it was sufficient to open UDP Port 5353 via debconf.cfg. Zeroconf is installed and enabled by default on a freshly installed system. So the firewall should not block it without a remedy to reenable it. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.39 Debian configuration management sy ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr ii iproute 20110315-1 networking and traffic control too ii iptables 1.4.10-1 administration tools for packet fi Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.7.3.dfsg-1+b1 Clients provided with BIND ii lynx 2.8.8dev.8-1 Text-mode WWW Browser (transitiona arno-iptables-firewall suggests no packages. -- debconf information: arno-iptables-firewall/config-int-nat-net: arno-iptables-firewall/dynamic-ip: true arno-iptables-firewall/config-int-net: arno-iptables-firewall/icmp-echo: false * arno-iptables-firewall/services-udp: 631 5353 arno-iptables-firewall/title: * arno-iptables-firewall/config-ext-if: eth0 wlan0 * arno-iptables-firewall/services-tcp: * arno-iptables-firewall/restart: true * arno-iptables-firewall/config-int-if: arno-iptables-firewall/nat: false * arno-iptables-firewall/debconf-wanted: true -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619496: arno-iptables-firewall: interface wildcard expansion in traffic-shaper plugin fails when sh isn't bash
We've fixed this in 2.0.0b-DEVEL. Thanks for the report. cheers, Arno On 3/24/2011 13:44, Tim Small wrote: Package: arno-iptables-firewall Version: 1.9.2.k-4 Severity: normal Network interface wildcard expansion (e.g. ppp+ etc.) in traffic-shaper plugin fails when /bin/sh is /bin/dash. Things work again if /bin/bash is substituted. Also ref: https://bugs.launchpad.net/ubuntu/+source/arno-iptables-firewall/+bug/693115 Tim. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr ii iproute 20100519-3 networking and traffic control too ii iptables 1.4.8-3administration tools for packet fi Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.7.2.dfsg.P3-1.1 Clients provided with BIND ii lynx 2.8.8dev.5-1Text-mode WWW Browser (transitiona arno-iptables-firewall suggests no packages. -- Configuration Files: /etc/arno-iptables-firewall/custom-rules changed [not included] /etc/arno-iptables-firewall/firewall.conf changed [not included] /etc/arno-iptables-firewall/plugins/traffic-shaper.conf changed [not included] -- debconf information excluded -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#617510: arno-iptables-firewall: bashisms in 50ipsec-vpn.plugin
This has been fixed by us. The upcoming 2.0.0b release will have the fix. Thanks for reporting this. cheers, Arno On 3/9/2011 15:05, Michael Hanke wrote: Package: arno-iptables-firewall Version: 1.9.2.k-4 Severity: normal Tags: squeeze upstream Forwarding a bugreport received in private email: after upgrading a server from lenny to squeeze arno got an error: kagami:~# /etc/init.d/arno-iptables-firewall restart Restarting Arno's Iptables Firewall... /sbin/iptables: (1) iptables: Chain already exists. /sbin/iptables: (1) iptables: Chain already exists. /sbin/iptables: (1) iptables: Chain already exists. local: 23: -i: bad variable name /usr/share/arno-iptables-firewall/plugins/50ipsec-vpn.plugin: 23: let: not found /usr/share/arno-iptables-firewall/plugins/50ipsec-vpn.plugin: 23: let: not found /usr/share/arno-iptables-firewall/plugins/50ipsec-vpn.plugin: 23: let: not found /usr/share/arno-iptables-firewall/plugins/50ipsec-vpn.plugin: 23: let: not found Mar 09 16:34:28 WARNING: Not all firewall rules are applied. FAILED! kagami:~# looks like the script /usr/share/arno-iptables-firewall/plugins/50ipsec-vpn.plugin that we use has some bash-isms in it. we did dpkg-reconfigure dash and changed the default shell back to bash. everything works for us now, but well, it's not fine. The report is correct. There are bashisms that need to be removed. Michael -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600990: Updated mdadd.sh for mdadm
Package: mdadm Version: 3.1.4 There is an updated (bugfix) version (1.47e) of my mdadd.sh script available. You can obtain it from http://rocky.eld.leidenuniv.nl/scripts/mdadd.sh Could it please be updated in the mdadm package? Thanks! -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: a.c.j.van.amersfo...@eld.physics.leidenuniv.nl Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596170: arno-iptables-firewall: local ipv6 no longer works
Problem fixed upstream in r297. For patch see: https://rocky.eld.leidenuniv.nl/trac/aif/changeset/297?format=diff&new=297 Unfortunately it's not a oneline fix. Carlos: Can you test this? Michael: Can you apply these changes to our aif version in Sqeeuze? cheers, Arno On 9/9/2010 20:55, Arno van Amersfoort wrote: I'll fix this upstream too, tomorrow. Thanks for testing & reporting back. I'll keep you posted. kind regards, Arno Carlos Fonseca wrote: On Thu, 9 Sep 2010, Carlos Fonseca wrote: I have not yet checked whether interfaces declared as internal are affected. I will do, and report again. OK, declaring an interface as internal using debconf seems to work as expected (ipv6 traffic is allowed on that interface). However, reconfiguring the package to declare it external again (and restarting the firewall) has no effect, because the old ipv6 rules are still there... Carlos -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596170: arno-iptables-firewall: local ipv6 no longer works
I'll fix this upstream too, tomorrow. Thanks for testing & reporting back. I'll keep you posted. kind regards, Arno Carlos Fonseca wrote: On Thu, 9 Sep 2010, Carlos Fonseca wrote: I have not yet checked whether interfaces declared as internal are affected. I will do, and report again. OK, declaring an interface as internal using debconf seems to work as expected (ipv6 traffic is allowed on that interface). However, reconfiguring the package to declare it external again (and restarting the firewall) has no effect, because the old ipv6 rules are still there... Carlos -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596170: arno-iptables-firewall: local ipv6 no longer works
Better patch attached On 9/9/2010 12:35, Michael Hanke wrote: On Thu, Sep 09, 2010 at 11:59:55AM +0200, Arno van Amersfoort wrote: Should be fixed upstream in 1.9.2m-DEVEL. Thanks for the report. I am afraid that this fix would also need to get into Debian squeeze. Could you post the relevant patch to this bug? Thanks, Michael -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl Index: /trunk/bin/arno-iptables-firewall === --- /trunk/bin/arno-iptables-firewall (revision 289) +++ /trunk/bin/arno-iptables-firewall (revision 295) @@ -4385,20 +4385,38 @@ # When IPv4 support is active, disable IPv6 traffic if [ "$IPV6_SUPPORT" = "1" ]; then -echo "NOTE: IPv6 support enabled, setting default policy for IPv4 to DROP" +echo "NOTE: IPv6 support enabled, setting simple default policy for IPv4" ip4tables -P INPUT DROP ip4tables -P FORWARD DROP -ip4tables -P OUTPUT DROP +ip4tables -P OUTPUT ACCEPT - else + +ip4tables -A INPUT -i lo -j ACCEPT +ip4tables -A FORWARD -i lo -j ACCEPT + +IFS=' ,' +for interface in $INT_IF $TRUSTED_IF; do + ip4tables -A INPUT -i $interface -j ACCEPT +done + elif sysctl_key net.ipv6.conf; then # IPv6 support available on the system? -if sysctl_key net.ipv6.conf; then - if [ -x "$IP6TABLES" ]; then -echo "NOTE: IPv4 support enabled, setting default policy for IPv6 to DROP" -ip6tables -P INPUT DROP -ip6tables -P FORWARD DROP -ip6tables -P OUTPUT DROP - else -printf "\033[40m\033[1;31mWARNING: IPv4 support enabled, but unable to set the default policy\033[0m\n" >&2 -printf "\033[40m\033[1;31m for IPv6 to DROP as the ip6tables-binary is not available!\033[0m\n" >&2 - fi +if [ -x "$IP6TABLES" ]; then + echo "NOTE: IPv4 support enabled, setting simple default policy for IPv6" + ip6tables -P INPUT DROP + ip6tables -P FORWARD DROP + ip6tables -P OUTPUT ACCEPT + + ip6tables -A INPUT -i lo -j ACCEPT + ip6tables -A FORWARD -i lo -j ACCEPT + + IFS=' ,' + for interface in $INT_IF $TRUSTED_IF; do +ip6tables -A INPUT -i $interface -j ACCEPT + done +else + printf "\033[40m\033[1;31mWARNING: IPv4 support enabled, but unable to set the default policy\033[0m\n" >&2 + printf "\033[40m\033[1;31m for IPv6 to DROP as the ip6tables-binary is not available!\033[0m\n" >&2 fi fi
Bug#596170: arno-iptables-firewall: local ipv6 no longer works
There you go: https://rocky.eld.leidenuniv.nl/trac/aif/changeset/294?format=diff&new=294 Carlos, could you please first test whether this fixes your issue since I don't have an IPv6 environment. Thanks. cheers, Arno On 9/9/2010 12:35, Michael Hanke wrote: On Thu, Sep 09, 2010 at 11:59:55AM +0200, Arno van Amersfoort wrote: Should be fixed upstream in 1.9.2m-DEVEL. Thanks for the report. I am afraid that this fix would also need to get into Debian squeeze. Could you post the relevant patch to this bug? Thanks, Michael -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596170: arno-iptables-firewall: local ipv6 no longer works
Should be fixed upstream in 1.9.2m-DEVEL. Thanks for the report. kind regards, Arno On 9/9/2010 1:50, Carlos Fonseca wrote: Package: arno-iptables-firewall Version: 1.9.2.k-3 Severity: important Tags: ipv6 After upgrading to this version, wxmaxima has become unusable. The reason is that, when it starts, it tries to connect to ip6-localhost:ipp and the connection gets stuck in SYN_SENT. Similarly, 'ping6 ::1' reports ping: sendmsg: Operation not permitted This seems to be a direct result of the fix for bug 594326, but shouldn't incoming ipv6 traffic be blocked only on *external* interfaces? Note that there is nothing listening on port ipp on this machine. Previously, wxmaxima would just report an error and continue...) Thanks, Carlos -- System Information: Debian Release: squeeze/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=pt_PT.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.35 Debian configuration management sy ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr ii iproute 20100519-3 networking and traffic control too ii iptables 1.4.8-3administration tools for packet fi Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.7.1.dfsg.P2-2 Clients provided with BIND ii lynx 2.8.8dev.5-1 Text-mode WWW Browser (transitiona arno-iptables-firewall suggests no packages. -- debconf information: arno-iptables-firewall/title: * arno-iptables-firewall/debconf-wanted: true arno-iptables-firewall/config-int-nat-net: * arno-iptables-firewall/dynamic-ip: true * arno-iptables-firewall/config-int-net: * arno-iptables-firewall/icmp-echo: false * arno-iptables-firewall/services-udp: * arno-iptables-firewall/config-ext-if: eth0 wlan0 ppp+ eth1 eth2 * arno-iptables-firewall/services-tcp: * arno-iptables-firewall/restart: true * arno-iptables-firewall/config-int-if: * arno-iptables-firewall/nat: false -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594345: Several bug (fixes) in arno-iptables-firewall
Package: arno-iptables-firewall Version: 1.9.2k The current version has several important bugs that have been corrected in the latest upstream version (1.9.2l). These are: 1) Due to a bug, the firewall is wide open for IPv6 when IPv4 mode is enabled. The intended behaviour should be that IPv6 is blocked, when IPv4 is used. 2) Recent kernel changes (I believe 2.6.30+) have caused some sysctl (and thus /proc) options not be set correctly. This problem has also been addressed in the latest version (1.9.2l). More info can be found here: http://forums.gentoo.org/viewtopic-t-830040-start-0-postdays-0-postorder-asc-highlight-.html?sid=a9e553289f9f360c42993d360f3ca839 http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-09/msg04929.html I therefor strongly recommend to accept 1.9.2l for Sqeeuze or at least backport the above fixes (one of them is already in bug report #594326) cheers, Arno -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594326: arno-iptables-firewall leaves Debian hosts open on ipv6 without warning the user
Modified: trunk/share/arno-iptables-firewall/environment
===
--- trunk/share/arno-iptables-firewall/environment 2010-08-25 07:50:13
UTC (rev 274)
+++ trunk/share/arno-iptables-firewall/environment 2010-08-25 12:01:51
UTC (rev 275)
@@ -391,7 +391,11 @@
printf "\033[40m\033[1;31msysctl $@: ($retval) $result\033[0m\n" >&2
return $retval
fi
- echo "${INDENT}sysctl $@"
+
+ if [ -n "$result" ]; then
+echo "${INDENT}$result"
+ fi
+
return 0
}
@@ -424,7 +428,9 @@
retval=$?
if [ "$retval" = "0" ]; then
-echo "${INDENT}${sysctl_commandline}"
+if [ -n "$result" ]; then
+ echo "${INDENT}$result"
+fi
return 0
else
printf "\033[40m\033[1;31m${sysctl_commandline}: ($retval)
$result\033[0m\n" >&2
This is the patch for 1.9.2l-DEVEL. Maybe it doesn't work on 1.9.2k
properly, but the bottomline line is that sysctl() should only output
its result when it's non-empty, and only that, not it's full commandline
as it breaks grep's using the result.
cheers,
Arno
On 8/25/2010 14:15, Michael Hanke wrote:
Hi Arno,
On Wed, Aug 25, 2010 at 01:33:08PM +0200, Arno van Amersfoort wrote:
This was the intended behaviour, but due to a bug it doesn't work.
I'll fix it today, hopefully Debian will backport the fix or allow
upcoming 1.9.2k to enter Sqeeuze.
Could you please provide me with a bugfix patch for the current -k
release that fixes this. I'm not sure that a complete new upstream
release will make it into squeeze (unless it doesn't have anything but
bugfixes).
Thanks,
Arno
--
Arno van Amersfoort
E-mail: arn...@rocky.eld.leidenuniv.nl
Donations are welcome through Paypal!
---
Arno's (Linux IPTABLES Firewall) Homepage:
http://rocky.eld.leidenuniv.nl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594326: arno-iptables-firewall leaves Debian hosts open on ipv6 without warning the user
This was the intended behaviour, but due to a bug it doesn't work. I'll fix it today, hopefully Debian will backport the fix or allow upcoming 1.9.2k to enter Sqeeuze. cheers, Arno Thanks for the report On 8/25/2010 12:09, Tim Small wrote: Package: arno-iptables-firewall Version: 1.9.2.k-2 Severity: normal Tags: upstream ipv6 Although the version of arno-iptables-firewall contains preliminary ipv6 support, it is turned off by default, and it doesn't appear thta it can be enabled at the same time as ipv4 support is enabled. Running arno-iptables-firewall on a default squeeze install leaves the following firewall policy in place for IPv6 packets: r...@ermintrude:/home/tim# ip6tables -L -v Chain INPUT (policy ACCEPT 18163 packets, 3581K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 17501 packets, 3428K bytes) pkts bytes target prot opt in out source destination As IPv6 is enabled by default in Debian, this leaves hosts vulnerable to attacks via IPv6. e.g. without any IPv6 infrastructure in place it leaves machines open to the local LAN via the IPv6 automatic link-local IP addresses: r...@ermintrude:/home/tim# ping6 -c 2 -I eth0 ff02::1 PING ff02::1(ff02::1) from fe80::201:3ff:fe48:4f1e ethInet: 56 data bytes 64 bytes from fe80::201:3ff:fe48:4f1e: icmp_seq=1 ttl=64 time=0.020 ms 64 bytes from fe80::2e0:81ff:fe74:9783: icmp_seq=1 ttl=64 time=0.302 ms (DUP!) 64 bytes from fe80::240:48ff:feb1:175e: icmp_seq=1 ttl=64 time=0.414 ms (DUP!) 64 bytes from fe80::20c:29ff:fef8:aa3: icmp_seq=1 ttl=64 time=0.528 ms (DUP!) 64 bytes from fe80::20c:29ff:fecb:3cac: icmp_seq=1 ttl=64 time=0.642 ms (DUP!) [...] r...@ermintrude:/home/tim# nmap -PN -6 fe80::240:48ff:feb1:175e%eth0 Starting Nmap 5.00 ( http://nmap.org ) at 2010-08-25 10:57 BST Interesting ports on fe80::240:48ff:feb1:175e: Not shown: 998 closed ports PORTSTATE SERVICE 22/tcp open ssh 179/tcp open bgp [...] but with fully routable IPv6 in place (as may well become commonplace during the lifetime of newly installed machines), attacks against machines would be possible from the Internet at large. Whilst not intrinsically a problem with arno-iptables-firewall, it is at the very least probably not what the user was expecting, and it would very useful if the user was alerted to this current behaviour (i.e. arno-iptables-firewall will not block any inbound IPv6 traffic, even when tight controls on IPv4 exist), along with information on how to block or disable IPv6, if that's what they wish to do (in the absense of useful IPv6 support by the package). Thanks, Tim. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages arno-iptables-firewall depends on: ii debconf 1.5.35 Debian configuration management sy ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr ii iproute 20100519-3 networking and traffic control too ii iptables 1.4.8-3administration tools for packet fi Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.7.1.dfsg.P2-2 Clients provided with BIND ii lynx 2.8.8dev.4-2 Text-mode WWW Browser (transitiona arno-iptables-firewall suggests no packages. -- Configuration Files: /etc/arno-iptables-firewall/custom-rules changed [not included] /etc/arno-iptables-firewall/firewall.conf changed [not included] -- debconf information excluded -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550222: arno-iptables-firewall: unify date format in the log
It has been fixed upstream in SVN rev36. cheers, Arno Yaroslav Halchenko wrote: Package: arno-iptables-firewall Version: 1.9.2.d-1 Severity: minor Please unify format of datestamp in the logs, now it looks like: Oct 08 9:11:04 ** Restarting Arno's Iptables Firewall v1.9.2d ** Oct 8 09:11:06 sandbox kernel: [58090.896697] AIF:UNPRIV -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii gawk 1:3.1.6.dfsg-3 GNU awk, a pattern scanning and pr ii iptables 1.4.4-2administration tools for packet fi Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.5.1.dfsg.P2-1 Clients provided with BIND ii iproute20090324-1networking and traffic control too ii lynx 2.8.7pre6-1 Text-mode WWW Browser (transitiona arno-iptables-firewall suggests no packages. -- debconf information: arno-iptables-firewall/config-int-nat-net: arno-iptables-firewall/dynamic-ip: true arno-iptables-firewall/config-int-net: arno-iptables-firewall/icmp-echo: false * arno-iptables-firewall/services-udp: arno-iptables-firewall/title: * arno-iptables-firewall/config-ext-if: eth0 * arno-iptables-firewall/services-tcp: 0 * arno-iptables-firewall/restart: true * arno-iptables-firewall/config-int-if: arno-iptables-firewall/nat: false * arno-iptables-firewall/debconf-wanted: true -- Arno van Amersfoort E-mail: arn...@rocky.eld.leidenuniv.nl Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553036: arno-iptables-firewall: iptables complains while starting firewall: Bad rule (does a matching rule exist in that chain?)
Thanks for reporting this. It has been fixed in the current SVN version. cheers, Arno Yaroslav Halchenko wrote: Package: arno-iptables-firewall Version: 1.9.2.d-1 Severity: normal Per your recommendations/directions installed the beast... configuration was to be managed by debconf, resultatant debconf.conf is: DC_EXT_IF="eth0 wlan0" DC_EXT_IF_DHCP_IP=1 DC_OPEN_TCP="0" DC_OPEN_UDP="" DC_INT_IF="" DC_NAT=0 DC_INTERNAL_NET="" DC_NAT_INTERNAL_NET="" DC_OPEN_ICMP=1 it pukes at + unset IFS + unset IFS + '[' 0 -eq 0 ']' + iptables -D EXT_INPUT_CHAIN -m conntrack --ctstate DNAT -j ACCEPT ++ trace /sbin/iptables -D EXT_INPUT_CHAIN -m conntrack --ctstate DNAT -j ACCEPT + result='++ '\''['\'' -n '\'''\'' '\'']'\'' ++ /sbin/iptables -D EXT_INPUT_CHAIN -m conntrack --ctstate DNAT -j ACCEPT iptables: Bad rule (does a matching rule exist in that chain?).' + retval=1 + '[' 1 '!=' 0 ']' + printf '\033[40m\033[1;31m(1) ++ '\''['\'' -n '\'''\'' '\'']'\'' ++ /sbin/iptables -D EXT_INPUT_CHAIN -m conntrack --ctstate DNAT -j ACCEPT iptables: Bad rule (does a matching rule exist in that chain?).\033[0m\n' (1) ++ '[' -n '' ']' ++ /sbin/iptables -D EXT_INPUT_CHAIN -m conntrack --ctstate DNAT -j ACCEPT iptables: Bad rule (does a matching rule exist in that chain?). + note_iptables_error -D EXT_INPUT_CHAIN -m conntrack --ctstate DNAT -j ACCEPT + unset IFS + for arg in '$*' + '[' -D = -A ']' + '[' -D = -I ']' + for arg in '$*' + '[' EXT_INPUT_CHAIN = -A ']' + '[' EXT_INPUT_CHAIN = -I ']' + for arg in '$*' + '[' -m = -A ']' iptables rules otherwise seems to be ok at this moment I am connected to eth0 and ifconfig is: eth0 Link encap:Ethernet HWaddr 00:24:7e:15:78:19 inet addr:129.170.31.123 Bcast:129.170.31.255 Mask:255.255.254.0 inet6 addr: fe80::224:7eff:fe15:7819/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1928795 errors:0 dropped:0 overruns:0 frame:0 TX packets:1195840 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:431294620 (411.3 MiB) TX bytes:473536704 (451.5 MiB) Memory:f060-f062 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:894905 errors:0 dropped:0 overruns:0 frame:0 TX packets:894905 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:604682570 (576.6 MiB) TX bytes:604682570 (576.6 MiB) teredoLink encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet6 addr: fe80::::/64 Scope:Link inet6 addr: 2001:0:53aa:64c:1880:46d5:7e55:e093/32 Scope:Global UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1 RX packets:123 errors:0 dropped:0 overruns:0 frame:0 TX packets:156 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:94152 (91.9 KiB) TX bytes:21012 (20.5 KiB) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (901, 'unstable'), (900, 'testing'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.2-rt13-1-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii gawk 1:3.1.6.dfsg-3 GNU awk, a pattern scanning and pr ii iptables 1.4.4-2administration tools for packet fi Versions of packages arno-iptables-firewall recommends: ii dnsutils 1:9.6.1.dfsg.P1-3 Clients provided with BIND ii iproute20090324-1networking and traffic control too ii lynx 2.8.7pre1-1 Text-mode WWW Browser (transitiona arno-iptables-firewall suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539103: Updated mdadd.sh (alias /usr/share/doc/mdadm/examples/newdisk.gz)
Package: mdadm Version: 2.6.7.2-3 There is an updated (bugfix) version (1.46) of my mdadd.sh script available (packed as /usr/share/doc/mdadm/examples/newdisk.gz in the mdadm package). You can obtain it from http://rocky.eld.leidenuniv.nl/scripts/mdadd.sh Could it please be updated in the mdadm package? Thanks! -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: a.c.j.van.amersfo...@eld.physics.leidenuniv.nl Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#468148: Kernel/iptables bug
This is certainly a problem within either the kernel or iptables, I've seen it happen myself and isolated it to being one of these. Looks like some endian issue, which is beyond the scope of aif. cheers, Arno -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : a.c.j.van.amersfo...@eld.physics.leidenuniv.nl Homepage : http://rocky.eld.leidenuniv.nl
Bug#520011: Fixed upstream
This has been fixed upstream. Thanks for reporting it. cheers, Arno -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : a.c.j.van.amersfo...@eld.physics.leidenuniv.nl Homepage : http://rocky.eld.leidenuniv.nl
Bug#428733: Coming back on this locking problem or samba with executables called from logon scripts
I can't reproduce it with my current setup. Just close this one (for now). Thanks. ps. Sorry for the delay Christian Perrier wrote: Now that I've changed some of the settings you suggested I'll recheck whether it fixes the problem. I'll report back ASAP. Any progress? -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : a.c.j.van.amersfo...@eld.physics.leidenuniv.nl Homepage : http://rocky.eld.leidenuniv.nl
Bug#494696: RAID_WORKAROUND causes raid resync/rebuild to stall at 0K/s
I'm pretty sure too it's a kernel bug. I now it was introduced somewhere around 2.6.26 (or 2.6.25, not sure). We're now running 2.6.24 on that machine and all is fine. I don't know whether they fixed this in newer kernels yet. cheers, arno Stephen Gran wrote: This one time, at band camp, Arno van Amersfoort said: Currently I'm unable to reproduce this previous reproducable bug. As soon as it problem re-appears I will re-test and let know my findings. Any luck with reproducing it? As it's been 4 or so months without any follow up, my personal feeling is that this was probably a kernel bug that has since been fixed, and nothing to do with hdparm. I'm inclined to close this, but I'm willing to leave it open if you think that you can reproduce it again. Cheers, -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : a.c.j.van.amersfo...@eld.physics.leidenuniv.nl Homepage : http://rocky.eld.leidenuniv.nl
Bug#520011: arno-iptables-firewall: New mac-address-filter plugins failed :<(
This has already been fixed upstream. The fix will be in 1.9.0c. Thanks
for reporting it though
cheers,
Arno
Joel Soete wrote:
Package: arno-iptables-firewall
Version: 1.9.0.b-1
Severity: important
Tags: patch
Hello Michael,
After the update of your new kind iptables firewall, internal network
connections failed :<( with following messages:
+ /sbin/iptables -A MAC_FILTER -m mac --mac-source '00:14:22:f9:53:a2
00:60:B0:07:0A:AA
00:d0:59:08:65:ca
00:05:5D:6B:DC:4B
00:30:6e:0a:cb:92
00:50:04:1b:2c:17
00:50:5d:6b:dc:4b
00:1e:33:7a:b8:90' -s 0/0 -j RETURN
iptables v1.4.2: Bad mac address `00:14:22:f9:53:a2
00:60:B0:07:0A:AA
00:d0:59:08:65:ca
00:05:5D:6B:DC:4B
00:30:6e:0a:cb:92
00:50:04:1b:2c:17
00:50:5d:6b:dc:4b
00:1e:33:7a:b8:90'
Try `iptables -h' or 'iptables --help' for more information.
After some debuging, I figure out what seems to me a typo in config file
and may be another way implement this new filter as per this proposed
patch:
--- ./etc/arno-iptables-firewall/plugins/mac-address-filter.conf.orig
2009-02-26 09:51:12.0 +
+++ ./etc/arno-iptables-firewall/plugins/mac-address-filter.conf
2009-03-15 09:15:22.0 +
@@ -8,7 +8,7 @@
# Specify here the port(s) you want to SSH checks to apply to
#
--
-MAC_ADDRESS_IF="$INF_IF"
+MAC_ADDRESS_IF="$INT_IF"
# Enable logging for not-allowed MAC addresses (if used).
#
-
---
./share/arno-iptables-firewall/plugins/10mac-address-filter.plugin.orig
2009-02-27 20:29:17.0 +
+++ ./share/arno-iptables-firewall/plugins/10mac-address-filter.plugin
2009-03-15 09:16:41.0 +
@@ -85,7 +85,8 @@
MCOUNT=0
IFS="$(printf '\n')"
- for LINE in `cat "$MAC_ADDRESS_FILE" |sed -e 's|#.*||' -e 's| *$||'`;
do
+ cat "$MAC_ADDRESS_FILE" |sed -e 's|#.*||' -e 's| *$||' | \
+ while read LINE; do
if [ -n "$LINE" ]; then
src_mac="$(echo "$LINE" |awk '{ print $1 }')"
src_ip="$(echo "$LINE" |awk '{ print $2 }')"
=== <> ===
What's your opinion?
Thanks in advance for your kind attention,
J.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.28.7-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages arno-iptables-firewall depends on:
ii debconf [debconf-2.0] 1.5.26 Debian configuration
management sy
ii gawk1:3.1.5.dfsg-4.1 GNU awk, a pattern scanning
and pr
ii iptables1.4.2-6 administration tools for
packet fi
Versions of packages arno-iptables-firewall recommends:
ii dnsutils 1:9.5.1.dfsg.P1-1 Clients provided with BIND
ii iproute20090115-1networking and traffic
control too
ii lynx 2.8.7dev13-1 Text-mode WWW Browser
(transitiona
arno-iptables-firewall suggests no packages.
-- debconf information:
* arno-iptables-firewall/config-int-nat-net: 192.168.248.0/24
* arno-iptables-firewall/dynamic-ip: true
* arno-iptables-firewall/config-int-net: 192.168.248.0/24
* arno-iptables-firewall/icmp-echo: false
* arno-iptables-firewall/services-udp:
arno-iptables-firewall/title:
* arno-iptables-firewall/config-ext-if: ppp0
* arno-iptables-firewall/services-tcp: 22
* arno-iptables-firewall/restart: false
* arno-iptables-firewall/config-int-if: eth1
* arno-iptables-firewall/nat: true
* arno-iptables-firewall/debconf-wanted: true
--
Arno van Amersfoort
E-mail: arn...@rocky.eld.leidenuniv.nl
Donations are welcome through Paypal!
---
Arno's (Linux IPTABLES Firewall) Homepage:
http://rocky.eld.leidenuniv.nl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#428733: Coming back on this locking problem or samba with executables called from logon scripts
Hello Christian, Christian Perrier wrote: retitle 428733 Samba keeps locks on executable files when launched from logon scripts by Windows clients tags 428733 moreinfo thanks Hello Arno, While doing a mass bug triage of bugs in the samba package, I went on the issue you reported in http://bugs.debian.org/428733, where executable files launched from Windows during logon scripts were kept locked by samba. I went on your very very long smb.conf file and first piped it through testparm so that only parameters that differ from the default settings are kept. See attached file. To narrow down this problem, I would first recommend you to drop the following parameters unless you have a very good reason for having them: [global] smb ports = 139 I've already disabled this a while back. name resolve order = lmhosts hosts bcast I disabled this one too now. deadtime = 10 I also already this a while back. socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192 Same thing. enhanced browsing = No Same thing. strict locking = No I have disabled this now. Now that I think of it this could potentiolly fix the problem. dos filetime resolution = Yes I disabled this too. From discussions with Samba developers, tweaking those is generally not recommendedwhatever you may find on so-called well-informed sites (the socket options, specifically) I'd also like to know whether you still experience that problem and are in position to do further testing. At the moment you reported the problem, i was mostly ignored, unfortunately, after you provided a very big level 10 debug log. Now that I've changed some of the settings you suggested I'll recheck whether it fixes the problem. I'll report back ASAP. Thanks for your efforts. cheers, Arno -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : a.c.j.van.amersfo...@eld.physics.leidenuniv.nl Homepage : http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#436959: Moreinfo needed for this samba/winbind bug
Dear Christian, Sorry that I didn't respond any time sooner. I've been really tied up at work for a while and these emails tend to move to the bottom of my mailbox. AFAIK the problem has been fixed upstream/with a newer Samba version. I am now running Debian-Lenny on the same machine and the problem seems solved. Thanks again. cheers, Arno Christian Perrier wrote: tags 426959 moreinfo thanks Hello Arno, again. In Debian bug #436959, Steve Langasek asked you about more information, specifically the winbind logs when you face the problem with hanged winbind. However, we never got this information, which prevents us from properly processing the bug report. Please also note that the output of "testparm" would help as well, to be able to catch potential settings that could cause the bug (using testparm is much preferred over providing your smb.conf file as it will drop settings that are the default). Without further information we might need to simply close the bug. -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496121: arno-iptables-firewall: Plugin support not working on etch
This bug has been fixed upstream ages ago (see the (already) closed bug report about it). The package that comes with Debian 5.0 (Lenny) no longer has this issue. But thanks for reporting the problem anyway Arno ps. Michael this report can be closed, but you were probably already aware of this. Charles Brunet wrote: Package: arno-iptables-firewall Version: 1.8.8.c-1 Severity: normal On file /etc/arno-iptables/firewall/custom-rules, the first step is to check the existence of plugins in the plugin directory. The current script does: if [ -e /etc/arno-iptables-firewall/plugins/* ]; then but this line will fail if there are more than one file into the plugin directory. A solution would be to replace that line with: if [ -n "$(find /etc/arno-iptables-firewall/pl;ugins -maxdepth 1 -name "*.plugin" 2>/dev/null)" ]; then -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.11etch2 Debian configuration management sy ii gawk1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii iptables1.3.6.0debian1-5 administration tools for packet fi arno-iptables-firewall recommends no packages. -- debconf information excluded
Bug#494696: RAID_WORKAROUND causes raid resync/rebuild to stall at 0K/s
Currently I'm unable to reproduce this previous reproducable bug. As soon as it problem re-appears I will re-test and let know my findings. Thanks Arno Stephen Gran wrote: This one time, at band camp, Arno van Amersfoort said: Package: hdparm Version: 8.9-1 I'm running a system with several soft RAID1 & RAID6 devices. I experienced a problem where the resync/rebuild of my new array's stalled at 0K/s speed like this: md3 : active raid1 sdb6[2](F) sda6[0] 126953536 blocks [2/1] [U_] [>] recovery = 0.0% (103296/126953536) finish=634251.2min speed=0K/sec md4 : active raid6 sdf1[3] sde1[2] sdd1[1] sdc1[0] 976767872 blocks level 6, 64k chunk, algorithm 2 [4/4] [] [>] resync = 0.2% (1037056/488383936) finish=289250.7min speed=0K/sec Now it turns out that his is caused by /etc/default/hdparm's "RAID_WORKAROUND" (if it's enabled/set to 1). The min/max construction speeds get set to 0 (by the hdparm init script) at boot but are never restored to their original value's OR the kernel doesn't like this behaviour, I don't know (yet). I don't see a code path where the original value isn't restored. Can you do a few things for me: The output of: cat /proc/sys/dev/raid/speed_limit_min cat /proc/sys/dev/raid/speed_limit_max If the value is 0 here, skip ahead. If hte value is non-zero, run and send me the output of: sh -x /etc/init.d/hdparm start cat /proc/sys/dev/raid/speed_limit_min cat /proc/sys/dev/raid/speed_limit_max If the value of either of those files is 0 after this, then there is pretty definitely a bug. If they have a non-zero value here, then it might be something else. Finally, if the values are zero, can you run: echo 6000 > /proc/sys/dev/raid/speed_limit_min echo 6000 > /proc/sys/dev/raid/speed_limit_max and send me the output of: cat /proc/sys/dev/raid/speed_limit_min cat /proc/sys/dev/raid/speed_limit_max Hopefully that's clear enough. Thanks, -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl
Bug#494806: Samba: "winbind use default domain" not working properly for users in groups
Package: samba Version: 2:3.2.0-4 I used to use Samba 3.0.14a (on Etch) but recently I moved to Lenny with Samba 3.2.0 but suddenly the "winbind use default domain" option partially broke. Note that I also changed my setup to move to the new "idmap config " settings. When I enable "winbind use default domain" and I issue a "getent passwd" everything is ok: I get a list of all users WITHOUT the default domain in front of it (user instead of default_domain\user). But now when I issue "getent group", the group name is also properly shown without the default domain in front of it, but the users in the group still have the default domain in front of it, like this (where PHYSICS is the domain): manage_fmd_printers:x:11445:PHYSICS+Egmondr,PHYSICS+Verpoorten My winbind config looks like this: idmap domains = PHYSICS idmap config PHYSICS:default = no idmap config PHYSICS:backend = rid idmap config PHYSICS:base_rid = 0 idmap config PHYSICS:range =1-6 allow trusted domains = no winbind enum users = yes winbind enum groups = yes winbind use default domain = no winbind nested groups = no winbind normalize names = yes winbind offline logon = true winbind refresh tickets = true -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494803: Samba: "winbind normalize names" not working
Package: samba Version: 2:3.2.0-4 The option "winbind normalize names = yes" in smb.conf is NOT working. Neither any spaces get replaced with _ and higher case characters are also not converted to lower case. It simply doesn't seem to do anything. My winbind config looks like this: idmap domains = PHYSICS idmap config PHYSICS:default = no idmap config PHYSICS:backend = rid idmap config PHYSICS:base_rid = 0 idmap config PHYSICS:range =1-6 allow trusted domains = no winbind enum users = yes winbind enum groups = yes winbind use default domain = no winbind nested groups = no winbind normalize names = yes winbind offline logon = true winbind refresh tickets = true template homedir = /mnt/data Whenever I issue 'getent group' or 'getent passwd' the non-normalized names are shown like ie.: "PHYSICS\epo alert" and "PHYSICS\domain users" -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494660: Last argument in harddisks-variable in /etc/default/hdparm is always ignored
Now I (suddenly) see what's happing: +(525 /etc/default)# /etc/init.d/hdparm start ([EMAIL PROTECTED]) Setting parameters of disc: setting standby to 60 (5 minutes) /dev/sda setting standby to 60 (5 minutes) /dev/sdb . The lines "setting standby to" are screwed up / the lines containing /dev/sda en /dev/sdb are not the same (although their settings are). So hdparm does apply the setting but the output of the init script is incorrect, are at least misleading -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#494696: RAID_WORKAROUND causes raid resync/rebuild to stall at 0K/s
Package: hdparm Version: 8.9-1 I'm running a system with several soft RAID1 & RAID6 devices. I experienced a problem where the resync/rebuild of my new array's stalled at 0K/s speed like this: md3 : active raid1 sdb6[2](F) sda6[0] 126953536 blocks [2/1] [U_] [>] recovery = 0.0% (103296/126953536) finish=634251.2min speed=0K/sec md4 : active raid6 sdf1[3] sde1[2] sdd1[1] sdc1[0] 976767872 blocks level 6, 64k chunk, algorithm 2 [4/4] [] [>] resync = 0.2% (1037056/488383936) finish=289250.7min speed=0K/sec Now it turns out that his is caused by /etc/default/hdparm's "RAID_WORKAROUND" (if it's enabled/set to 1). The min/max construction speeds get set to 0 (by the hdparm init script) at boot but are never restored to their original value's OR the kernel doesn't like this behaviour, I don't know (yet). -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462543: Quick 'n dirty fix
I experience the same problem here, I'm on ISO8859-15 and samba fails to enumerate the printers. However I am able to fix this by settings "printcap name = /etc/printcap" in smb.conf I don't know whether there are any drawbacks of doing this, but I guess it's about time to look at a move to UTF8. -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl
Bug#494471: The problem is caused by hdparm (/etc/default/hdparm: RAID_WORKAROUND)
It turns out the problem is caused by hdparm's RAID_WORKAROUND option in /etc/default/hdparm. I'm still not sure whether it's a kernel bug or a bug in hdparm, but at least disabling this option fixes the problem -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl
Bug#494660: Last argument in harddisks-variable in /etc/default/hdparm is always ignored
Package: hdparm Version: 8.9-1 I've setup several SATA disks in /etc/default/hdparm like this: harddisks="/dev/sda /dev/sdb /dev/sdc /dev/sdd" hdparm_opts="-W0 -S60" But the last harddisks-argument is always ignored. I tried removing sdd, but then sdc gets ignored and so on. When I configure them in /etc/hdparm.conf, then it does work. -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493805: Please append "$network" in LSB Required-Start and Required-Stop
Hi Michael, I've already merged it upstream, although I'm not sure whether there will be an officially updated 1.8.8 version, as I'm retiring 1.8 ASAP But at least the next 1.9 will have the patch included... cheers, Arno Michael Hanke wrote: Hi, [ CC'ing upstream (Hi Arno!). Full quote below. ] Thanks a lot for the patch, I will add it to the package as soon as I'm back at work (next week). Cheers, Michael On Tue, Aug 05, 2008 at 01:27:14AM +0100, Chris Lamb wrote: Package: arno-iptables-firewall Version: 1.8.8.o-2 Tags: patch Hi, Please append "$network" to arno-iptables-firewall's LSB Required-Start and Required-Stop lines. When using a concurrent boot method, I have experienced race conditions whereby the interface is not fully configured before arno-iptables-firewall starts (for example, due to a slow-responding DHCP server or by having a number of interfaces to configure). This does not affect arno-iptables-firewall in its default shipped state as /sbin/iptables will happily add rules to unconfigured interfaces. However, plugins that use commands such as /sbin/ip and friends (including the shipped multiroute plugin) and anything that relies on an IP address being assigned will race with the "ifup" calls. (I encountered this with a custom plugin of mine, not with multiroute, however.) Patch attached. Regards, -- Chris Lamb, UK [EMAIL PROTECTED] GPG: 0x634F9A20 diff -urNad arno-iptables-firewall-1.8.8.o.orig/arno-iptables-firewall arno-iptables-firewall-1.8.8.o/arno-iptables-firewall --- arno-iptables-firewall-1.8.8.o.orig/arno-iptables-firewall 2008-08-05 01:01:52.0 +0100 +++ arno-iptables-firewall-1.8.8.o/arno-iptables-firewall 2008-08-05 01:02:05.0 +0100 @@ -5,8 +5,8 @@ ### BEGIN INIT INFO # Provides: arno-iptables-firewall -# Required-Start:$syslog $local_fs -# Required-Stop: $syslog $local_fs +# Required-Start:$syslog $local_fs $network +# Required-Stop: $syslog $local_fs $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Setup iptables firewall configuration
Bug#494471: kernel-2.6.25 unable to resync (new) md array's
Package: linux-image Version: 2.6.25-2-686 I tried to create several software raid(md) array's on my Lenny system, but unfortunately the resync/recovery of the array's hangs like this: md3 : active raid1 sdb6[2](F) sda6[0] 126953536 blocks [2/1] [U_] [>] recovery = 0.0% (103296/126953536) finish=634251.2min speed=0K/sec md4 : active raid6 sdf1[3] sde1[2] sdd1[1] sdc1[0] 976767872 blocks level 6, 64k chunk, algorithm 2 [4/4] [] [>] resync = 0.2% (1037056/488383936) finish=289250.7min speed=0K/sec I also tried a 2.6.25.14 vanilla kernel, which I built myself but this one suffers from the same problem. Downgrading to Lenny's 2.6.24 kernel, however, fixes the problem! I guess it should (could?) be fixed upstream. But at least we want this fixed before the final release of Lenny, right? I don't know if it is related to the type of hardware I'm using, here are the relevant details of my setup: - Pentium III 500E - 2x Promise TX4 SATA controller - 4x Seagate 500Gb SATA disk - 2x Samsung 640Gb SATA disk -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493685: Linux-igd plugin should be disabled by default
Package: arno-iptables-firewall Version: 1.8.8o Somehow the Linux-igd plugin in my upstream version was enabled by default. By default any plugin should be disabled, including this one. It can simply be fixed by setting ENABLED=0 in /etc/arno-iptables-firewall/plugins/linuxigd.conf Although not a real bug, it would be nice to have this fixed. Arno -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#491155: New upstream version available
The author of uvccapture just released a new version of uvccapture, which also fixes the problem. I hope it can be updated here as well, as the current version in lenny (0.4) is useless in its current state Thanks. -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl
Bug#491155: Patch to fix the problem
I had contact with one of the kernel developers regarding this issue and he provided a fix for uvccapture to fix this issue. The patch can be obtained here: http://bugzilla.kernel.org/attachment.cgi?id=16916&action=view So it turns out to be a problem in uvccapture after all. It would be nice if this patch could be merged in the Debian version of uvccapture as well, preferebally before the release of Lenny. Thanks. -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl
Bug#491155: Quickcam Fusion segfaults uvccapture
Package: uvccapture Version: 0.4-1 Since I've upgraded to Lenny/testing, my Logitech Quickcam Fusion stopped working. What I get in the kernel log is: uvcvideo: Failed to query (130) UVC control 2 (unit 2) : -32 (exp. 2). __ratelimit: 29 messages suppressed uvccapture[31885]: segfault at 0 ip b7f7f32d sp bf9822a0 error 4 in libc-2.7.so[b7ee9000+148000] uvccapture[31886]: segfault at 0 ip b7f7f32d sp bf9822a0 error 4 in libc-2.7.so[b7ee9000+148000] uvccapture[31887]: segfault at 0 ip b7f7f32d sp bf9822a0 error 4 in libc-2.7.so[b7ee9000+148000] uvccapture[31888]: segfault at 0 ip b7f7f32d sp bf9822a0 error 4 in libc-2.7.so[b7ee9000+148000] __ratelimit: 21 messages suppressed uvccapture[31910]: segfault at 0 ip b7f7f32d sp bf9822a0 error 4 in libc-2.7.so[b7ee9000+148000] I am not 100% sure that the problem is in uvccapture itself, it could also be the uvcvideo-module, although I tried kernel 2.6.24, 2.6.25 and even 2.6.26 (vanilla), which all fail to work. -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490955: Updated mdadd.sh (alias /usr/share/doc/mdadm/examples/newdisk.gz)
Package: mdadm Version: 2.6.4-2 There is an updated (bugfix) version (1.40) of my mdadd.sh script available (packed as /usr/share/doc/mdadm/examples/newdisk.gz in the mdadm package). You can obtain it from http://rocky.eld.leidenuniv.nl/scripts/mdadd.sh Could it please be updated in the mdadm package? Thanks! -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474367: Info received (Bug#474367: tmpreaper removes lost+found directory from /tmp)
It turns out that the problem is not caused by tmpreaper but by zshell (or its configuration). Sorry for all the noise, but therefor this bug report can be closed :-D kind regards, Arno Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Paul Slootman <[EMAIL PROTECTED]> If you wish to submit further information on this problem, please send it to [EMAIL PROTECTED], as before. Please do not send mail to [EMAIL PROTECTED] unless you wish to report a problem with the Bug-tracking system. -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl
Bug#489421: mkfs.xfs can't make filesystem on block device with sector size other than 512 bytes
One other thing I just noticed: xfs_repair also has problems with this !=512byte-sector device: +(550 /...8/repair)# ./xfs_repair /dev/sdc ([EMAIL PROTECTED]) xfs_repair: warning - cannot set blocksize on block device /dev/sdc: Invalid argument Phase 1 - find and verify superblock... Phase 2 - using internal log I don't know whether this is a problem, but xfs_repair is complaining that it can't set the blocksize. I don't what this is used for and whether it's important but I don't like my fs checker/fixer spitting out warnings (if you know what I mean). Note that I used the latest 2.9.8 xfs-repair. The one that comes with Etch simply segfaults: +(551 /...8/repair)# xfs_repair /dev/sdc ret:130 sig:int ([EMAIL PROTECTED]) xfs_repair: warning - cannot set blocksize on block device /dev/sdc: Invalid argument Phase 1 - find and verify superblock... xfs_repair: read failed: Invalid argument [1]7523 segmentation fault xfs_repair /dev/sdc Nathan Scott wrote: On Mon, 2008-07-07 at 08:24 +0200, Arno van Amersfoort wrote: And I guess most people expect mkfs.xfs to properly detect the sector Indeed. I'll let the XFS developers know (CCd) - if devices say they support only >512 byte sectors, mkfs.xfs should silently switch to the minimum sector size supported. size (and choose the "ssize") automatically like ie. mkfs.ext3 does, right? I'd expect ext3 mkfs does not check this - ext3 doesn't distinguish between filesystem blocks (smallest unit of allocation) and device sectors (smallest allowed I/O size to a device) like XFS does. cheers. -- Nathan -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl
Bug#489421: mkfs.xfs can't make filesystem on block device with sector size other than 512 bytes
Just tried with both the current Etch-version and the latest version available (from Lenny) compiled from source (2.9.8). This is what I get: 2.8.11-1 Etch version with --size=4k (note that you still get the warning): +(532 /...9.8/mkfs)# mkfs.xfs -f -ssize=4k /dev/sdc ([EMAIL PROTECTED]) mkfs.xfs: warning - cannot set blocksize on block device /dev/sdc: Invalid argument meta-data=/dev/sdc isize=256agcount=32, agsize=42865797 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=1371705504, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks realtime =none extsz=65536 blocks=0, rtextents=0 2.9.8 Lenny version with --size=4k: +(531 /...9.8/mkfs)# ./mkfs.xfs -f -ssize=4k /dev/sdc ret:1 ([EMAIL PROTECTED]) meta-data=/dev/sdc isize=256agcount=6, agsize=268435455 blks = sectsz=4096 attr=2 data = bsize=4096 blocks=1371705504, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 The Lenny version no longer complains when --size=4k is provided but mkfs.xfs still can't properly detect it hisself: +(530 /...9.8/mkfs)# ./mkfs.xfs -f /dev/sdc ret:1 ([EMAIL PROTECTED]) mkfs.xfs: warning - cannot set blocksize on block device /dev/sdc: Invalid argument Warning: the data subvolume sector size 512 is less than the sector size reported by the device (4096). meta-data=/dev/sdc isize=256agcount=6, agsize=268435455 blks = sectsz=512 attr=2 data = bsize=4096 blocks=1371705504, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 existing superblock read failed: Invalid argument mkfs.xfs: pwrite64 failed: Invalid argument mkfs.xfs: read failed: Invalid argument And I guess most people expect mkfs.xfs to properly detect the sector size (and choose the "ssize") automatically like ie. mkfs.ext3 does, right? If you need additional info/testing don't hesitate to contact me. Nathan Scott wrote: On Sat, 2008-07-05 at 17:48 +0200, Arno van Amersfoort wrote: Package: xfsprogs Version: 2.8.11-1 Platform: 32bit x86 You should be able to use -ssize=4k on the mkfs command line to work around this. In more recent versions of xfsprogs, mkfs.xfs does a better job of handling this automatically... could you try the most recent version 2.9.5 or so, and let me know if it works for you? I don't have access to such hardware, so can't really confirm. thanks. -- Nathan -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl
Bug#489421: mkfs.xfs can't make filesystem on block device with sector size other than 512 bytes
Package: xfsprogs Version: 2.8.11-1 Platform: 32bit x86 It seems that mkfs.xfs can't (properly) create a filesystem on a block device which has a sector size other than 512bytes. In my case I tried with both 2k and 4k sectors, but this failed. The device used is a Promise Vtrak610M iSCSI SAN. I can't rule out that it has something to do with the SAN but I think the problem is either caused by the mkfs-xfs binary or the XFS kernel part. This is what I get: #mkfs.xfs /dev/sdc mkfs.xfs: warning - cannot set blocksize on block device /dev/sdc: Invalid argument Warning: the data subvolume sector size 512 is less than the sector size reported by the device (2048). meta-data=/dev/sdc isize=256agcount=32, agsize=74386585 blks = sectsz=512 attr=0 data = bsize=4096 blocks=2380370720, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 mkfs.xfs: pwrite64 failed: Invalid argument mkfs.xfs: read failed: Invalid argument -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#480068: Does not call plugin_stop when restarting
The plugin_stop is called from plugins_stop(), which is called when the firewall script is issued with the "stop" argument, so as it currently is, is correct. You probably missed the plugin stop() below... Arno Chris Lamb wrote: Package: arno-iptables-firewall Version: 1.8.8.o-2 Tags: patch Hi, Although plugins can implement a 'plugin_stop' method so that changes can be removed on "restart" or "stop" events, the script seems to omit calling them. A patch is attached. Regards, -- Arno van Amersfoort - E-mail: [EMAIL PROTECTED]
Bug#474367: tmpreaper removes lost+found directory from /tmp
Unfortunately I haven't been able to reproduce this problem yet. As soon as I know more (and have some spare time) on this issue, I'll let you know. Paul Slootman wrote: On Sat 05 Apr 2008, Arno van Amersfoort wrote: I have my /tmp mounted on a seperate partition and I noticed that everytime fsck runs, the lost+found directory for this filesystem is missing. Now it turns out that tmpreaper is responsible for this. Although tmpreaper should exclude the lost+found directory, I also tried to explicitly exclude lost+found, but this doesn't seem to work either: it still gets removed. Any clue on what could be causing this? I haven't had this happening to me... It would be helpful if you could reproduce this while tmpreaper is running under strace, and then send me the strace output. thanks, Paul Slootman -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl
Bug#468148: arno-iptables-firewall: "Errors starting on Sparc build"
Nope, we can't work around it. The problem is the 64bits kernel on Sparc64 icw. an incompatible iptables-binary. Only way to fix this problem on etch is by building a new 2.6.19+ kernel. This is the bug report I filed against the iptables-package (although in fact it is a kernel bug as we now know) : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468170 Michael Hanke wrote: tag 468148 + etch confirmed thanks Hi, On Fri, Apr 18, 2008 at 01:37:57PM +0200, Arno van Amersfoort wrote: Hi, Oh, sorry forgot to update the info here. The problem is caused by a bug in Debian's 2.6.18-kernel. For Lenny, a 2.6.19+ kernel will fix the problem... ah, thanks. But is there anything we could do in this package to address/workaround it? Or maybe there is a report about the actual problem in the etch kernel where we can point people to (including myself ;-)? Thanks, Michael Michael Hanke wrote: Hi, I just wondered: Is there any update? Is the problem identified or even solved? Should this report be closed or merged with another bug? Thanks, Michael On Wed, Feb 27, 2008 at 02:29:38PM +0100, Arno van Amersfoort wrote: Michael, I'm already looking into this problem (the submitter provided a SUN sparc machine I can use for testing). I've already somehat isolated the problem, but as it looks now the issue is probably in the iptables binary (or kernel) used by Debian/Sparc. I will also post a bug against the iptables-package, and see what they can come up with cheers, Arno Michael Hanke wrote: Hi Marco, thanks for your report. Could you please provide your configuration files: /etc/arno-iptables-firewall/debconf.cfg /etc/arno-iptables-firewall/firewall.conf Please be sure to remove any possibly confidential information from it before posting. Thanks, Michael On Wed, Feb 27, 2008 at 11:58:21AM +0100, Marco Rijnsburger wrote: Package: arno-iptables-firewall Version: 1.8.8.i-2 Severity: important -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: sparc (sparc64) Kernel: Linux 2.6.18-3-sparc64-smp (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.19 Debian configuration management sy ii gawk1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii iptables1.3.8.0debian1-1 administration tools for packet fi ii lynx2.8.6-2 Text-mode WWW Browser Versions of packages arno-iptables-firewall recommends: ii iproute 20080108-1 Professional tools to control the -- debconf information: * arno-iptables-firewall/config-int-nat-net: 172.16.2.0 * arno-iptables-firewall/dynamic-ip: false * arno-iptables-firewall/config-int-net: 255.255.255.0 * arno-iptables-firewall/icmp-echo: true * arno-iptables-firewall/services-udp: 53 arno-iptables-firewall/title: * arno-iptables-firewall/config-ext-if: eth0 * arno-iptables-firewall/services-tcp: 25 53 110 143 443 1 * arno-iptables-firewall/restart: true * arno-iptables-firewall/config-int-if: eth1 * arno-iptables-firewall/nat: true * arno-iptables-firewall/debconf-wanted: true # ./arno-iptables-firewall start Arno's Iptables Firewall Script 1.8.8.i-2 --- Sanity checks passed...OK Detected IPTABLES module... Loading additional IPTABLES modules: All IPTABLES modules loaded! Setting the kernel ring buffer to only log panic messages to the console Configuring /proc/ settings: Enabling anti-spoof with rp_filter Enabling SYN-flood protection via SYN-cookies Disabling the logging of martians Disabling the acception of ICMP-redirect messages Setting the max. amount of simultaneous connections to 16384 Enabling protection against source routed packets Setting default conntrack timeouts Enabling reduction of the DoS'ing ability Setting Default TTL=64 Disabling ECN (Explicit Congestion Notification) Enabling support for dynamic IP's Flushing route table /proc/ setup done... Flushing rules in the filter table Setting default (secure) policies Using loglevel "info" for syslogd Setting up firewall rules: --- Accepting packets from the local loopback device Enabling setting the maximum packet size via MSS Enabling mangling TOS Logging of stealth scans (nmap probes etc.) enabled iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument Logging of packets with bad TCP-flags enabled iptables: Invalid argument iptable
Bug#468148: arno-iptables-firewall: "Errors starting on Sparc build"
Hi, Oh, sorry forgot to update the info here. The problem is caused by a bug in Debian's 2.6.18-kernel. For Lenny, a 2.6.19+ kernel will fix the problem... Arno Michael Hanke wrote: Hi, I just wondered: Is there any update? Is the problem identified or even solved? Should this report be closed or merged with another bug? Thanks, Michael On Wed, Feb 27, 2008 at 02:29:38PM +0100, Arno van Amersfoort wrote: Michael, I'm already looking into this problem (the submitter provided a SUN sparc machine I can use for testing). I've already somehat isolated the problem, but as it looks now the issue is probably in the iptables binary (or kernel) used by Debian/Sparc. I will also post a bug against the iptables-package, and see what they can come up with cheers, Arno Michael Hanke wrote: Hi Marco, thanks for your report. Could you please provide your configuration files: /etc/arno-iptables-firewall/debconf.cfg /etc/arno-iptables-firewall/firewall.conf Please be sure to remove any possibly confidential information from it before posting. Thanks, Michael On Wed, Feb 27, 2008 at 11:58:21AM +0100, Marco Rijnsburger wrote: Package: arno-iptables-firewall Version: 1.8.8.i-2 Severity: important -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: sparc (sparc64) Kernel: Linux 2.6.18-3-sparc64-smp (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.19 Debian configuration management sy ii gawk1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii iptables1.3.8.0debian1-1 administration tools for packet fi ii lynx2.8.6-2 Text-mode WWW Browser Versions of packages arno-iptables-firewall recommends: ii iproute 20080108-1 Professional tools to control the -- debconf information: * arno-iptables-firewall/config-int-nat-net: 172.16.2.0 * arno-iptables-firewall/dynamic-ip: false * arno-iptables-firewall/config-int-net: 255.255.255.0 * arno-iptables-firewall/icmp-echo: true * arno-iptables-firewall/services-udp: 53 arno-iptables-firewall/title: * arno-iptables-firewall/config-ext-if: eth0 * arno-iptables-firewall/services-tcp: 25 53 110 143 443 1 * arno-iptables-firewall/restart: true * arno-iptables-firewall/config-int-if: eth1 * arno-iptables-firewall/nat: true * arno-iptables-firewall/debconf-wanted: true # ./arno-iptables-firewall start Arno's Iptables Firewall Script 1.8.8.i-2 --- Sanity checks passed...OK Detected IPTABLES module... Loading additional IPTABLES modules: All IPTABLES modules loaded! Setting the kernel ring buffer to only log panic messages to the console Configuring /proc/ settings: Enabling anti-spoof with rp_filter Enabling SYN-flood protection via SYN-cookies Disabling the logging of martians Disabling the acception of ICMP-redirect messages Setting the max. amount of simultaneous connections to 16384 Enabling protection against source routed packets Setting default conntrack timeouts Enabling reduction of the DoS'ing ability Setting Default TTL=64 Disabling ECN (Explicit Congestion Notification) Enabling support for dynamic IP's Flushing route table /proc/ setup done... Flushing rules in the filter table Setting default (secure) policies Using loglevel "info" for syslogd Setting up firewall rules: --- Accepting packets from the local loopback device Enabling setting the maximum packet size via MSS Enabling mangling TOS Logging of stealth scans (nmap probes etc.) enabled iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument Logging of packets with bad TCP-flags enabled iptables: Invalid argument iptables: Invalid argument Logging of INVALID packets disabled Logging of fragmented packets enabled iptables: Invalid argument Logging of access from reserved addresses enabled iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument Setting up anti-spoof rules Reading custom IPTABLES rules from /etc/arno-iptables-firewall/custom-rules Loading (user) plugins iptables: Invalid argument Setting up INPUT policy for the external net (INET): iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument Enabling support for a DHCP assigned IP on external interface(s): eth0 Logging of explicitly blocked hosts enabled Logging of denied local output connections enabled Packets will NOT be check
Bug#474367: tmpreaper removes lost+found directory from /tmp
Package: tmpreaper Version: 1.6.7 I have my /tmp mounted on a seperate partition and I noticed that everytime fsck runs, the lost+found directory for this filesystem is missing. Now it turns out that tmpreaper is responsible for this. Although tmpreaper should exclude the lost+found directory, I also tried to explicitly exclude lost+found, but this doesn't seem to work either: it still gets removed. Any clue on what could be causing this? -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471430: Arno's Iptables Firewall should have package "dns-utils" as recommended
Package: arno-iptables-firewall Version: 1.8 branch I just noticed that the package for my firewall is lacking "dns-utils" as recommended package. IMHO it should, as the "dig" binary is used by both arno-fwfilter and arno-iptables-firewall when either one has name-resolving enabled. Note that for both scripts name-resolving is disabled by default (because of performance reasons), which is why dns-utils should be "recommended" and not "required". Arno -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470883: Arno's Iptables Firewall should not have "lynx" as dependency
Package: arno-iptables-firewall Version: 1.8 branch IMHO Lynx should NOT be a requirement of arno-iptables-firewall, but rather a "recommended" package as it is only required when name resolving is enabled in the arno-iptables-firewall and/or arno-fwfilter. Arno -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469322: New upstream version of Arno's Iptables Firewall available
Package: arno-iptables-firewall Version: 1.8 branch There is a new stable upstream version (1.8.8o) available. It contains an important fix for new-generation plugins. Again, I like to get it in ASAP because of a possible (soft) freeze of Lenny. Arno -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468170: Kernel message
I also noticed this in my kernel messages: ip_tables: limit match: invalid size 40 != 32 I don't know what it means but I hope it helps -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468170: iptables -m limit doesn't work on UltraSparc (64 bit)
Package: iptables Version: 1.3.6.0debian1-5 I am the author of "arno-iptables-firewall" and somebody filed a bug against my firewall about it not working properly on Debian/Sparc64. I've been debugging the problem, but the problem can be isolated to the iptables binary not accepting a syntax like "iptables -m limit " -> ie. "iptables -A INPUT -m limit --limit 3/m -j DROP" doesn't work, where it DOES work on x86 Debian. This could also be a problem with the limit module, I'm not sure. The latter would (obviously) mean a kernel bug and not a bug in iptables itself. Note that ie. "iptables -A INPUT -m state --state INVALID -j DROP" DOES work. And executing "modprobe -v ipt_limit" also shows no error. Additional info: [EMAIL PROTECTED]:~$ uname -a Linux arnodev 2.6.18-5-sparc64 #1 Sat Dec 22 03:07:31 UTC 2007 sparc64 GNU/Linux Hopefully someone can clear this matter up? Thanks, Arno -- Arno van Amersfoort E-mail: [EMAIL PROTECTED] Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468148: arno-iptables-firewall: "Errors starting on Sparc build"
Michael, I'm already looking into this problem (the submitter provided a SUN sparc machine I can use for testing). I've already somehat isolated the problem, but as it looks now the issue is probably in the iptables binary (or kernel) used by Debian/Sparc. I will also post a bug against the iptables-package, and see what they can come up with cheers, Arno Michael Hanke wrote: Hi Marco, thanks for your report. Could you please provide your configuration files: /etc/arno-iptables-firewall/debconf.cfg /etc/arno-iptables-firewall/firewall.conf Please be sure to remove any possibly confidential information from it before posting. Thanks, Michael On Wed, Feb 27, 2008 at 11:58:21AM +0100, Marco Rijnsburger wrote: Package: arno-iptables-firewall Version: 1.8.8.i-2 Severity: important -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: sparc (sparc64) Kernel: Linux 2.6.18-3-sparc64-smp (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.19 Debian configuration management sy ii gawk1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii iptables1.3.8.0debian1-1 administration tools for packet fi ii lynx2.8.6-2 Text-mode WWW Browser Versions of packages arno-iptables-firewall recommends: ii iproute 20080108-1 Professional tools to control the -- debconf information: * arno-iptables-firewall/config-int-nat-net: 172.16.2.0 * arno-iptables-firewall/dynamic-ip: false * arno-iptables-firewall/config-int-net: 255.255.255.0 * arno-iptables-firewall/icmp-echo: true * arno-iptables-firewall/services-udp: 53 arno-iptables-firewall/title: * arno-iptables-firewall/config-ext-if: eth0 * arno-iptables-firewall/services-tcp: 25 53 110 143 443 1 * arno-iptables-firewall/restart: true * arno-iptables-firewall/config-int-if: eth1 * arno-iptables-firewall/nat: true * arno-iptables-firewall/debconf-wanted: true # ./arno-iptables-firewall start Arno's Iptables Firewall Script 1.8.8.i-2 --- Sanity checks passed...OK Detected IPTABLES module... Loading additional IPTABLES modules: All IPTABLES modules loaded! Setting the kernel ring buffer to only log panic messages to the console Configuring /proc/ settings: Enabling anti-spoof with rp_filter Enabling SYN-flood protection via SYN-cookies Disabling the logging of martians Disabling the acception of ICMP-redirect messages Setting the max. amount of simultaneous connections to 16384 Enabling protection against source routed packets Setting default conntrack timeouts Enabling reduction of the DoS'ing ability Setting Default TTL=64 Disabling ECN (Explicit Congestion Notification) Enabling support for dynamic IP's Flushing route table /proc/ setup done... Flushing rules in the filter table Setting default (secure) policies Using loglevel "info" for syslogd Setting up firewall rules: --- Accepting packets from the local loopback device Enabling setting the maximum packet size via MSS Enabling mangling TOS Logging of stealth scans (nmap probes etc.) enabled iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument Logging of packets with bad TCP-flags enabled iptables: Invalid argument iptables: Invalid argument Logging of INVALID packets disabled Logging of fragmented packets enabled iptables: Invalid argument Logging of access from reserved addresses enabled iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument Setting up anti-spoof rules Reading custom IPTABLES rules from /etc/arno-iptables-firewall/custom-rules Loading (user) plugins iptables: Invalid argument Setting up INPUT policy for the external net (INET): iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument Enabling support for a DHCP assigned IP on external interface(s): eth0 Logging of explicitly blocked hosts enabled Logging of denied local output connections enabled Packets will NOT be checked for private source addresses Allowing the whole world to connect to TCP port(s): 22 Allowing the whole world to send ICMP-requests(ping) iptables: Invalid argument Logging of dropped ICMP-request(ping) packets enabled iptables: Invalid argument Logging of dropped other ICMP packets enabled iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument Logging of possible stealth scans enabled iptables: Invalid argument iptables: Invalid argument
Bug#466972: New upstream version of Arno's Iptables Firewall available
Package: arno-iptables-firewall Version: 1.8 branch There is a new stable upstream version (1.8.8n) available. It contains some important bug fixes, thus I like to get it in before the (soft) freeze of Lenny. Michael, you probably already knew this, but I decided to file a bug report just as a reminder Arno -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453050: Same problem here
Same problem here. Just upgraded to 3.0.24-6etch7 and my Windows machine's refuse to show several directories. Note that smbclient (//localhost/...) does show the directories, so this is really weird. I also noticed that the info smbclient shows is all screwed up: +(521 ~)# smbclient //localhost/projects -U arnova ([EMAIL PROTECTED]) Password: Domain=[EINSTEIN] OS=[] Server=[___] smb: \> Notice what the "OS=" "Server=" show. This was previously: Domain=[EINSTEIN] OS=[Unix] Server=[Samba 3.0.24] So I don't know what changed in this security update, but things seem *really* screwed up. Downgrading to 3.0.24-6etch5 also solved my problem here. I have several machine's here running Debian 4.0/i386 and ALL suffer from the same issue. -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444973: libpam-mount shouldn't mount for non-user accounts
Package: libpam-mount Version: 0.26-1 I've noticed some strange behaviour with libpam-mount here on my Etch installation. The problem occured when I did an "aptitude install clamav-freshclam", as then a clamav user is created and rightafter a shell for this user is called to start the freshclam daemon. But it fails to do so because before the shell is started one gets a pam prompt asking for a password (required for clamav), eventhough use_first_pass is enabled for the pammount module. But as the clamav user doesn't have a password (system account), one cannot escape this. I think the correct behaviour should be that pam_mount simply ignores any accounts that don't have a password (when use_first_pass is used). Another solution could be that when pam_mount detects the mount directory doesn't exist, it simply skips all checking etc. -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442022: marked as done (Internal network can't access internal server accessed via external ip)
It's not a bug, it is more like how it's implemented in Linux (and I think in other unix'es too) You can simply use the transparant-dnat plugin to fix this. You can grab it from: http://rocky.eld.leidenuniv.nl/iptables-firewall/plugins/transparent-dnat/ Arno Debian Bug Tracking System wrote: Your message dated Thu, 13 Sep 2007 20:01:39 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#442022: Internal network can't access internal server accessed via external ip has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) Subject: Internal network can't access internal server accessed via external ip From: Ognyan Kulev <[EMAIL PROTECTED]> Date: Wed, 12 Sep 2007 18:31:48 +0300 To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Package: arno-iptables-firewall Version: 1.8.8.c-1 When the package is used as gateway for internal network and some servers should be visible from outside, there is a problem with accessing these servers from inside (when external ip is used). Let's suppose port 80 is forwarded to internal server 192.168.0.2, internal gateway is 192.168.0.1, and external ip of the gateway is 1.2.3.4. DC_OPEN_TCP has 80, and NAT_TCP_FORWARD is used to forward port 80 to 192.168.0.2. (BTW it's good if the relationship between these variables is written.) Hosts in internal network can't access this server via external ip 1.2.3.4. The situation is described in http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-10.html . What I use to solve this problem is the following plugin: iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp --dport 80 -j DNAT --to 192.168.0.2 iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.2 -p tcp --dport 80 -j SNAT --to 1.2.3.4 I think such hand-written iptables should not be needed. Regards, Ognyan Kulev Subject: Re: Bug#442022: Internal network can't access internal server accessed via external ip From: Michael Hanke <[EMAIL PROTECTED]> Date: Thu, 13 Sep 2007 20:01:39 +0200 To: Ognyan Kulev <[EMAIL PROTECTED]>, [EMAIL PROTECTED] To: Ognyan Kulev <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Package: arno-iptables-firewall Version: 1.8.8.i-1 Hi, I asked upstream about this issue and he considers this a feature and not a bug. ;) Anyway, what you want to do (and are doing already) is implemented as the 'transparent DNAT' plugin that was added in version 1.8.8.i, which is in lenny already. Therefore I'm closing this bug now. Thanks for reporting this, Michael -- Arno van Amersfoort - E-mail: [EMAIL PROTECTED] ~ 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 is just a number! ~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436959: winbind hang & startup problem
Package: winbind
Version: 3.0.24-6
I have a 2 very strange problems with winbind, and I think they are
related that's why file only one bug report. The first issue is that
when my machine boots, right after boot 'wbinfo -D {mydomain}' shows:
Name : PHYSICS
Alt_Name : Physics.
SID : S-1-5-21-1818682373-3371831198-3922779086
Active Directory : No
Native: No
Primary : Yes
Sequence : -1
Although winbind works, it doesn't make sense as the machine is
connected to a Windows2003 ADS Server. But the strange thing is that
when I ie. issue '/etc/init.d/winbind restart' it shows:
Name : PHYSICS
Alt_Name : Physics.
SID : S-1-5-21-1818682373-3371831198-3922779086
Active Directory : Yes
Native: Yes
Primary : Yes
Sequence : -1
Note that both "Active Directory" and "Native" now say Yes (as expected).
Another problem I experience (and I think it's related to the above
issue) is that once in a while winbind stops responding, obviously
causing users/groups not be resolved from the Windows2003 domain.
'wbinfo -p' then shows:
Ping to winbindd failed on fd -1
could not ping winbindd!
Although winbind is still running (ps -ef |grep winbind):
root 3730 1 0 19:50 ?00:00:00 /usr/sbin/winbindd
root 3731 3730 0 19:50 ?00:00:00 /usr/sbin/winbindd
Note that I haven't found a way (yet) to reproduce this problem, so it's
quite hard to debug. The latter issue is (of course) the real show
stopper as at that point my users are no longer able to access the
machine until I issue another /etc/init.d/winbind restart.
--
Ing. A.C.J. van Amersfoort (Arno)
Department Of Electronics (ELD, k1007)
Huygens Laboratory
Leiden University
P.O. Box 9504
Niels Bohrweg 2
2333 CA Leiden
The Netherlands
Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819
E-mail: [EMAIL PROTECTED]
Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428733: keepalive socket option?
I did some additional testing here and it seems the probleem is related to the KEEPALIVE-socket option. Well, actually, the fact that one does NOT use the KEEPALIVE-socket option, but instead the seperate "keepalive = "-option. I've now removed the "keepalive =" option and add SO_KEEPALIVE to the socket options, and this seems to fix the problem (Although note that the exact same config didn't cause this problem with samba 3.0.14a (from Sarge)) -- Ing. A.C.J. van Amersfoort (Arno) Electronics & ICT Engineer Leiden Institute of Physics (LION), Electronics Department (ELD) Huygens Laboratory (Room 1007), Leiden University Postal Address: P.O. Box 9504, 2300 RA Leiden Visit Address : Niels Bohrweg 2, 2333 CA Leiden The Netherlands Phone: +31-(0)71-527.1894 Fax : +31-(0)71-527.5819 E-mail : [EMAIL PROTECTED] Homepage : http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428733: samba keeps exe-files locked?
Package: samba Version: 3.0.24-6etch4 It seems that since I've upgraded from Sarge to Etch (Samba 3.0.14a -> 3.0.24), Samba doesn't dispose of locks previously created for exe-files opened by Windows. This means that once a Windows client opens an .exe-file from a Samba-share (to execute it), and then closes it again, Samba still holds the lock on that .exe-file, as long as the Windows-client is logged on. This is what is shown by smbstatus: Locked files: Pid UidDenyMode Access R/WOplock SharePath Name Time 21470319DENY_WRITE 0x20RDONLY NONE /etc/samba/netlogon reg.exe Wed Jun 13 13:07:20 2007 . I've tried changing all related oplock & locking variables in smb.conf but the problem still persists, so I guess it's a bug of some kind. -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428097: spamd also logs to /var/log/messages
Package: spamassassin Version: 3.1.7-2 Since I've upgraded to Debian Etch, next to the normal logging to /var/log/syslog, my /var/log/messages also get filled with messages from spamassassin (spamd) like: Jun 8 23:43:31 rulhm1 check[3195]: prefork: child states: II Jun 8 23:45:15 rulhm1 check[20365]: spamd: connection from xx [127.0.0.1] at port 32818 Jun 8 23:45:15 rulhm1 check[20365]: spamd: setuid to robin succeeded Jun 8 23:45:15 rulhm1 check[20365]: spamd: processing message <[EMAIL PROTECTED]> for robin:314 Jun 8 23:45:36 rulhm1 check[23323]: spamd: connection from xx [127.0.0.1] at port 32824 Jun 8 23:45:36 rulhm1 check[23323]: spamd: setuid to egroenen succeeded I think this is a bug as spamd (by default) should only log to syslog facility "mail" and because my /etc/syslog.conf looks like this: *.=info;*.=notice;*.=warn;\ local7.none;\ auth,authpriv.none;\ cron,daemon,lpr.none;\ mark.none;\ mail,news.none /var/log/messages One expect that nothing would appear from spamd in /var/log/messages, at least that's what I understand from the man page (correct me if I'm wrong). So it seems like spamassassin is also logging to some other facility than "mail" ? -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427881: Script to handle mdadm events & generate mail reports
Package: mdadm
Version: 2.5.6-9
I wrote a script (see attachement) to automatically send out mails to a
specified user (usually root) about raid/md events. It should be called
from mdadm.conf with the PROGRAM directive.
I hope it's usefull.
--
Ing. A.C.J. van Amersfoort (Arno)
Department Of Electronics (ELD, k1007)
Huygens Laboratory
Leiden University
P.O. Box 9504
Niels Bohrweg 2
2333 CA Leiden
The Netherlands
Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819
E-mail: [EMAIL PROTECTED]
Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl
#!/bin/sh
# MDADM Event Handler - Generate mails when MD events occur
# Drop a line like "PROGRAM /root/bin/sys/mdadm-event-handler.sh" in your
mdadm.conf to use it
#
# Last update: May 19, 2007
# (C) Copyright 2006-2007 by Arno van Amersfoort
# Homepage : http://rocky.eld.leidenuniv.nl/
# Email : a r n o v a AT r o c k y DOT e l d DOT l e i d e n u
n i v DOT n l
# (note: you must remove all spaces and substitute the
@ and the . at the proper locations!)
#
--
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# version 2 as published by the Free Software Foundation.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
#
--
CONFIG="/etc/mdadm/mdadm.conf"
# Overrule mailto address from the mdadm.conf file?:
#MAILADDR="root"
parse_event()
{
echo "Host: $HOSTNAME"
if [ -z "$1" ]; then
echo "Event : Test message"
else
echo "MD Device : $2"
echo "Event : $1"
if [ -n "$3" ]; then
echo "Device Component: $3"
fi
fi
echo ""
echo "/proc/mdstat dump:"
FAIL=0
DEGRADED=0
while read LINE; do
echo -n "$LINE"
if [ -n "$(echo "$LINE" |grep 'active raid')" ]; then
if [ -n "$(echo "$LINE" |grep '\(F\)')" ]; then
FAIL=$(($FAIL + 1))
echo -n " (WARNING: FAILED DISK(S)!)"
fi
if [ -n "$(echo "$LINE" |grep '\(S\)')" ]; then
echo -n " (Hotspare(s) available)"
else
echo -n " (NOTE: No hotspare?!)"
fi
fi
if [ -n "$(echo "$LINE" |grep 'blocks')" ]; then
if [ -n "$(echo "$LINE" |grep '_')" ]; then
DEGRADED=$(($DEGRADED + 1))
echo -n " (DEGRADED!!!)"
fi
fi
echo ""
done < /proc/mdstat
if [ $FAIL -gt 0 ]; then
echo ""
echo "** WARNING: One or more RAID arrays have FAILED disk(s)! **"
fi
if [ $DEGRADED -gt 0 ]; then
echo ""
echo "** WARNING: One or more RAID arrays are running in degraded mode! **"
fi
}
# main line:
# Get MAILADDR from mdadm.conf config file, if not set already
if [ -z "$MAILADDR" ] && [ -f "$CONFIG" ]; then
MAILADDR=`grep MAILADDR "$CONFIG" |cut -d' ' -f2`
if [ -z "$MAILADDR" ]; then
MAILADDR="root"
fi
fi
# Call the parser and send it to the configured address
parse_event $* |mail -s"RAID(MD) event on $HOSTNAME" "$MAILADDR"
exit 0
Bug#427880: Script to automatically add a new harddrive with multiple RAID1 partitions
Package: mdadm
Version: 2.5.6-9
I wrote a script (see attachement) to automatically add a new harddrive
to a system which already has a harddrive with multiple RAID1
partitions. Now one has manually create a partition table on the new
drive, copy the MBR (if bootable), create SWAP (if used) and do a mdadm
--add for each partition. My script automates this process. This is
especially handy when a harddisk containing multiple RAID1 partitions
fails and is replaced by a new empty one.
Example:
When the system has 2 harddives, sda & sdb and looks like this:
- sda1/sdb1 (type fd) part of /dev/md0 (RAID1)
- sda2/sdb2 (type 82) swap
- sda5/sdb5 (type fd) part of /dev/md1 (RAID1)
When sdb fails and is replaced with a new (empty) harddrive. A single
command like: "mdadd.sh /dev/sda /dev/sdb" is sufficient. This will
completely restore the array and even the swap is recreated on the sdb.
I hope it's usefull.
--
Ing. A.C.J. van Amersfoort (Arno)
Department Of Electronics (ELD, k1007)
Huygens Laboratory
Leiden University
P.O. Box 9504
Niels Bohrweg 2
2333 CA Leiden
The Netherlands
Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819
E-mail: [EMAIL PROTECTED]
Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl
#!/bin/sh
MY_VERSION="1.33-WIP"
#
--
# Linux MD (Soft)RAID Add Script - Add a (new) harddisk to another multi
MD-array harddisk
# Last update: May 4, 2007
# (C) Copyright 2005-2007 by Arno van Amersfoort
# Homepage : http://rocky.eld.leidenuniv.nl/
# Email : a r n o v a AT r o c k y DOT e l d DOT l e i d e n u
n i v DOT n l
# (note: you must remove all spaces and substitute the
@ and the . at the proper locations!)
#
--
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# version 2 as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
#
--
show_help()
{
echo "Bad or missing parameter(s)"
echo "Usage: `basename $0` [ source_disk ] [ target_disk ] [ options ]"
echo "Options:"
echo "--force = Even proceed if target device does not appear empty"
echo "--noptupdate = Do NOT update the partition table on the target device
(EXPERT!)"
echo "--nombrupdate = Do NOT update the MBR boot-loader on the target device
(EXPERT!)"
}
echo "MDadd for SoftRAID-MDADM v$MY_VERSION"
echo "Written by Arno van Amersfoort"
echo ""
if [ "$UID" != "0" ]; then
printf "\033[40m\033[1;31mERROR: Root check FAILED (you MUST be root to use
this script)! Quitting...\n\033[0m"
exit 1
fi
if ! which mdadm 2>&1 >/dev/null; then
printf "\033[40m\033[1;31mERROR: Unable to find mdadm-binary!
Quitting...\n\033[0m"
exit 2
fi
if ! which sfdisk 2>&1 >/dev/null; then
printf "\033[40m\033[1;31mERROR: Unable to find sfdisk-binary!
Quitting...\n\033[0m"
exit 2
fi
if ! which sfdisk 2>&1 >/dev/null; then
printf "\033[40m\033[1;31mERROR: Unable to find dd-binary!
Quitting...\n\033[0m"
exit 2
fi
# Set environment variables to default
FORCE=0
NOPTUPDATE=0
NOMBRUPDATE=0
SOURCE=""
TARGET=""
# Check arguments
for arg in $*; do
ARGNAME=`echo "$arg" |cut -d= -f1`
ARGVAL=`echo "$arg" |cut -d= -f2`
if ! echo "$ARGNAME" |grep -q "^-"; then
if [ -z "$SOURCE" ]; then
SOURCE="$ARGVAL"
else
if [ -z "$TARGET" ]; then
TARGET="$ARGVAL"
else
show_help;
exit 2
fi
fi
else
case "$ARGNAME" in
--force|-force|-f) FORCE=1;;
--noptupdate|-noptupdate|--noptu|-noptu) NOPTUPDATE=1;;
--nombrupdate|-nombrupdate|--nombru|nombru) NOMBRUPDATE=1;;
--help) show_help;
exit 0;;
*) echo "ERROR: Bad argumen
Bug#427878: /usr/share/mdadm/mkconf should also keep previous CREATE, HOMEHOST & PROGRAM
Package: mdadm Version: 2.5.6-9 I think that /usr/share/mdadm/mkconf now only keeps the MAILADDR from the previous mdadm.conf . IMHO it should also do this for the options CREATE, HOMEHOST and PROGRAM . In this way one can simply use mkconf to regenerate a new mdadm.conf without worrying about settings getting lost. -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425391: Patch/bug fix for CVE-2007-2447 breaks the use of ;
Package: samba Version: 3.0.14a-3sarge After some debugging I discovered that a strange problem I experienced was caused by the patched code added in Samba 3.0.14a-3sarge for CVE-2007-2447 (Remote Command Injection Vulnerability). It is now no longer possible to use the ";" character in options like "preexec = " & "postexec =" causing the use of ie. (in my case) "root preexec = mkdir -p /home/software/Recycle; chown root:admins /home/software/.Recycle" to be executed as "root preexec = mkdir -p /home/software/Recycle chown root:admins /home/software/.Recycle" (The semicolon disappears!). As far as I can see now, it also breaks the use of (in my case) "passwd program = /usr/bin/passwd %u; /usr/local/lib/yp_make.sh" This new unexpected behaviour can possibly break a lot of setups! I think the easiest solution is to add the ";" (and possibly also & and |) to #define INCLUDE_LIST "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabdefghijklmnopqrstuvwxyz_/ \t.," -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421201: SpamAssassin: Various error messages in /var/log/mail.err
Package: spamassassin Version: 3.1.7-2 Since I've upgraded my machine to Debian Etch I'm getting these error messages in my /var/log/mail.err : Apr 24 03:28:05 rocky spamd[3835]: Can't locate Math/BigInt/FastCalc.pm in @INC (@INC contains: ../lib /usr/share/perl5 /etc/p erl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/ AND Apr 24 03:28:05 rocky spamd[3835]: Can't locate IO/Socket/INET6.pm in @INC (@INC contains: ../lib /usr/share/perl5 /etc/perl / usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_ perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4) at /usr/lib/perl5/Net/DNS/Resolver/Base.pm line 62, line 4 4. I don't know whether this is an issue I should worry about but it seems like SpamAssassin is missing some Perl modules/dependencies.(?) regards, Arno -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421200: NIS: Add support for MAXUID/MAXGID in /var/yp/Makefile
Package: nis
Version: 3.13-2
Besides having MINUID & MINGID in /var/yp/Makefile, it is quite handy to
also have MAXUID & MAXGID. For my case that is mainly to filter out
the Samba domain machines that also live in our /etc/passwd. I've added
a patch (which I've been using for quite some time now) to implement
this feature. Hopefully it is usefull for others too..
regards,
Arno
--
Ing. A.C.J. van Amersfoort (Arno)
Department Of Electronics (ELD, k1007)
Huygens Laboratory
Leiden University
P.O. Box 9504
Niels Bohrweg 2
2333 CA Leiden
The Netherlands
Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819
E-mail: [EMAIL PROTECTED]
Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl
*** /tmp/Makefile.dpkg-dist 2007-03-26 15:20:30.0 +0200
--- /var/yp/Makefile2007-02-26 11:19:29.0 +0100
***
*** 34,41
# the passwd file. If no entry is found, this shadow entry is
# ignored.
# MINGID is the lowest gid that will be included in the group maps.
! MINUID=1000
! MINGID=1000
# Don't export this uid/guid (nfsnobody).
# Set to 0 if you want to
--- 35,44
# the passwd file. If no entry is found, this shadow entry is
# ignored.
# MINGID is the lowest gid that will be included in the group maps.
! MINUID=111
! MAXUID=1999
! MINGID=120
! MAXGID=1999
# Don't export this uid/guid (nfsnobody).
# Set to 0 if you want to
***
*** 309,315
@echo "Updating [EMAIL PROTECTED]"
@$(UMASK); \
$(MERGER) -p $(PASSWD) $(SHADOW) | \
! $(AWK) -F: '!/^[-+#]/ { if ($$1 != "" && $$3 >= $(MINUID) && $$3 !=
$(NFSNOBODYUID) ) \
print $$1"\t"$$0 }' | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
--- 313,319
@echo "Updating [EMAIL PROTECTED]"
@$(UMASK); \
$(MERGER) -p $(PASSWD) $(SHADOW) | \
! $(AWK) -F: '!/^[-+#]/ { if ($$1 != "" && $$3 >= $(MINUID) && $$3 <=
$(MAXUID) && $$3 != $(NFSNOBODYUID) ) \
print $$1"\t"$$0 }' | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
***
*** 318,324
@echo "Updating [EMAIL PROTECTED]"
@$(UMASK); \
$(MERGER) -p $(PASSWD) $(SHADOW) | \
! $(AWK) -F: '!/^[-+#]/ { if ($$1 != "" && $$3 >= $(MINUID) && $$3 !=
$(NFSNOBODYUID) ) \
print $$3"\t"$$0 }' | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
--- 322,328
@echo "Updating [EMAIL PROTECTED]"
@$(UMASK); \
$(MERGER) -p $(PASSWD) $(SHADOW) | \
! $(AWK) -F: '!/^[-+#]/ { if ($$1 != "" && $$3 >= $(MINUID) && $$3 <=
$(MAXUID) && $$3 != $(NFSNOBODYUID) ) \
print $$3"\t"$$0 }' | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
***
*** 332,338
passwd.byname: $(PASSWD) $(YPDIR)/Makefile
@echo "Updating [EMAIL PROTECTED]"
@$(UMASK); \
! $(AWK) -F: '!/^[-+#]/ { if ($$1 != "" && $$3 >= $(MINUID) && $$3 !=
$(NFSNOBODYUID) ) \
print $$1"\t"$$0 }' $(PASSWD) | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
--- 336,342
passwd.byname: $(PASSWD) $(YPDIR)/Makefile
@echo "Updating [EMAIL PROTECTED]"
@$(UMASK); \
! $(AWK) -F: '!/^[-+#]/ { if ($$1 != "" && $$3 >= $(MINUID) && $$3 <=
$(MAXUID) && $$3 != $(NFSNOBODYUID) ) \
print $$1"\t"$$0 }' $(PASSWD) | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
***
*** 340,346
passwd.byuid: $(PASSWD) $(YPDIR)/Makefile
@echo "Updating [EMAIL PROTECTED]"
@$(UMASK); \
! $(AWK) -F: '!/^[-+#]/ { if ($$1 != "" && $$3 >= $(MINUID) && $$3 !=
$(NFSNOBODYUID) ) \
print $$3"\t"$$0 }' $(PASSWD) | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
--- 344,350
passwd.byuid: $(PASSWD) $(YPDIR)/Makefile
@echo "Updating [EMAIL PROTECTED]"
@$(UMASK); \
! $(AWK) -F: '!/^[-+#]/ { if ($$1 != "" && $$3 >= $(MINUID) && $$3 <=
$(MAXUID) && $$3 != $(NFSNOBODYUID) ) \
print $$3"\t"$$0 }' $(PASSWD) | $(DBLOAD) -i $(PASSWD) \
-o $(YPMAPDIR)/$@ - $@
[EMAIL PROTECTED](NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
***
*** 349,355
@echo "Updating [EMAIL PROTECTED]"
@$(UMASK); \
$(AWK) -F: '{ if (FILENAME ~ /shadow$$/) { \
! if (UID[$$1] >= $(MINUID) && U
Bug#416275: NIS: Typo in /var/yp/Makefile
Package: nis Version: 3.13-2 There is a typo in /var/yp/Makefile concerning the comment on the YPPUSHARGS variable. The -port, should be --port, else yppush treats it as a map name. I've created a patch (with some extra info that you shouldn't use quotes). Hopefully the problem can be fixed in the next update of the NIS package. regards, Arno -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl *** Makefile.dpkg-dist 2005-04-03 13:47:30.0 +0200 --- /tmp/Makefile.dpkg-dist 2007-03-26 15:20:30.0 +0200 *** *** 23,30 NOPUSH=true # Specify any additional arguments to be supplied when invoking yppush. ! # For example, the -port option may be used to allow operation with port ! # based firewalls. YPPUSHARGS= # We do not put password entries with lower UIDs (the root and system --- 23,30 NOPUSH=true # Specify any additional arguments to be supplied when invoking yppush. ! # For example, the --port option may be used to allow operation with port ! # based firewalls. NOTE: Don't use quotes to surround the arguments! YPPUSHARGS= # We do not put password entries with lower UIDs (the root and system
Bug#412191: Several bug (fixes) in arno-iptables-firewall
Package: arno-iptables-firewall Version: 1.8.8c-1 The current version has several important bugs that have been corrected in the latest upstream version (1.8.8h). These are: 1) It contains some major bugfixes in the plugin system. The plugin system in version 1.8.8c as broken causing it to be rendered completely useless if you use more than one plugin or when newer type plugins are used. 2) It contains an improvement/fix that errors and warnings get send to stderr, were version 1.8.8c sends this to stdout. 3) Some cosmetic fixes/improvements. 4) The order of some variables in the config-file was changed (the MODEM & LAN sections are swapped), causing MODEM_INTERNAL_NET="$INTERNAL_NET" not to work as INTERNAL_NET wasn't specified yet . This is a regression bug that was introduced some around version 1.8.8c. The latest upstream version (1.8.8h) has been extensively tested and currently has no pending bug (reports). I therefor strongly recommend to sync the current Etch version (1.8.8c) with the latest upstream version (1.8.8h). -- Arno van Amersfoort E-mail: [EMAIL PROTECTED] Donations are welcome through Paypal! --- Arno's (Linux IPTABLES Firewall) Homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409179: DASH: Settings IFS=$'\n' doesn't work properly
Package: dash Version: 0.5.3-6 I ran into a problem after upgrading my system to testing last week, causing one of my scripts not to work anymore. During installation I let the installer redirect sh to dash. Although it is POSIX compliant (as far as I know) it doesn't work properly. This was caused by the fact the dash doesn't understand that setting IFS=$'\n' means that the seperator is EOL. Instead dash just sees it as IFS='n' . I think it's a bug, although not sure... -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366674: Printer job names passed to CUPS are in some cases too long
Package: cups Version: 1.1.23-10sarge1 I use Samba in combination with CUPS to print (using printing = cups in Samba). The problem is that when (Windows) clients spool job, they also send the name of job, which normally is the filename of the original document (printed from). In the job history page (http page), CUPS uses the longest jobname to decide where (on the right site) the buttons should be put. If there is one job with a very longname, these buttons are put in an invisible part of the page on the right, and one has to scroll to the right (over and over again) to press the buttons. I don't know whether this is either a bug in CUPS or a bug in Samba, but my guess is that it should be fixed in CUPS because CUPS can decide when a jobname is too long and if so cut(truncate) it to a correct length. (of not please correct me). -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365569: /etc/init.d/klogd contains unused function "running"
Package: klogd Version: 1.4.1-17 While I performed some auditing in search for another bug I discovered that /etc/init.d/klogd contains an unused function called "running". I don't know whether this causes an actual bug/problem, but the maintainer may want to look into to this -- Ing. A.C.J. van Amersfoort (Arno) Department Of Electronics (ELD, k1007) Huygens Laboratory Leiden University P.O. Box 9504 Niels Bohrweg 2 2333 CA Leiden The Netherlands Phone : +31-(0)71-527.1894 Fax: +31-(0)71-527.5819 E-mail: [EMAIL PROTECTED] Arno's (Linux firewall) homepage: http://rocky.eld.leidenuniv.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293364: Bug in ZSH (zshell) using Debian-testing (Sarge)
Package: zsh
Version: 4.2.3-1
When I exit a zshell (for example when exiting from su) zshell segfaults when:
- /usr/share/zsh/functions/TRAPEXIT exists and is executable
- And the function is loaded (for example from /etc/zsh/zshrc with "autoload
${^/usr/share/zsh/functions}/*(.xN:t)" )
I am using Debian GNU/Linux 3.2 (testing/sarge)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
