Bug#717215: [pkg-dhcp-devel] Bug#717215: dhcpd: 5 bad udp checksums in 5 packets
On Tue, Mar 3, 2015 at 11:25 AM, Axel Beckert wrote: > > Hmm, not sure what we're doing differently but I'm using Xen at work > with Debian on Dom0 and DomUs for many years now (IIRC since Lenny), > my DomUs all do DHCP and I've never run into any issues of that kind > so far. > My experiment has shown that there has to be a combination of two things to trigger this bug: 1- The DHCP server needs to be running on another VM on the same host, or on Dom0. The problem is with virtual interfaces traffic flowing through software bridge not having valid checksums (since the packets aren't leaving memory, checksums are not being uselessly calculated). 2- The VM virtual interface needs to have TX offloading enabled. When enabled, ISC DHCP looks at the UDP checksum bits and find they are invalid (because of #1). The patch to ISC DHCP implements checking the TP_STATUS_CSUMNOTREADY to determine if checksum is to be verified. One workaround is to instruct iptables to recalculate the checksum for all DHCP responses. Another workaround is to use ethtool to disable TX offload on the vif interface (which I suppose causes the checksum to be forcefully calculated by the kernel). Depending of the version of Xen and/or which device model you are using, TX offload might not be supported on your virtual interface. I ran into this bug with the DHCP server running on a Jessie Dom0, Xen 4.4.1 running a Debian Wheezy PVHVM DomU. Simon
Bug#717215: [pkg-dhcp-devel] Bug#717215: dhcpd: 5 bad udp checksums in 5 packets
Hi Axel, On Tue, Mar 3, 2015 at 3:01 AM, Axel Beckert wrote: > Debian Bug Tracking System wrote: > > severity 717215 serious > > This is by no means a release-critical bug. "annoying" is no reason > for being release-critical, despite I understand that people often > wish so. > > I'd say "in not so recent versions". That was back in 2013. By the > way, the severity there is "low" because "there are workarounds". > Yes, there are workarounds. The workaround need to be applied on the host/dom0 (no matter the host distribution) for any *Debian* virtual machine to obtain configuration through DHCP. This bug prevents *Debian* instances using DHCP from working in any virtualized environments (being KVM, Xen or LXC) without the workaround. Every other major distributions (Red Hat in 2011, Ubuntu in 2013) now have fixed their DHCP client. Also LXC added the iptables workaround to 1.0.0 in 2014. This bug has been initially reported to Debian more than 3 years ago in #652739 (but BTS won't let me merge it). I didn't meant the bug to be "release-critical". Perhaps "important" would be a more suitable severity, then. But this bug definitively needs the attention of the ISC DHCP maintainers. Patch here: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/isc-dhcp/vivid/view/head:/debian/patches/udp_checksum_offloading Thanks Simon
Bug#717215:
This bug is really annoying. It has been fixed in recent version of Ubuntu: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/930962
Bug#775514: No networking running virt-builder scripts after upgrading from 1.26 to 1.28
Hi Hilko, On Sat, Jan 17, 2015 at 9:22 AM, Hilko Bengen wrote: > > Has it been fixed in 1.28.4-1? > > No, this problem affects all versions after 1.26. I tried 1:1.28.1-1, 1:1.28.4-1 and 1:1.29.14-1. Thanks Simon
Bug#775514: No networking running virt-builder scripts after upgrading from 1.26 to 1.28
Package: libguestfs-tools Version: 1:1.28.4-1 After upgrading to 1.28 (a simple apt-get upgrade in Jessie pulls 1.28 now) it seems network is no longer available inside the guest (using virt-builder). 1.26 was working fine, everything broke after upgrading to 1.28. Rolling back to 1:1.26.9-1 from snapshot.debian.org works. This no longer works in 1.28: # virt-builder debian-7 --run-command 'wget -O /dev/null https://www.debian.org/' [ 1.0] Downloading: http://libguestfs.org/download/builder/debian-7.xz [ 1.0] Planning how to build this image [ 1.0] Uncompressing [ 11.0] Opening the new disk [ 29.0] Setting a random seed [ 29.0] Running: wget -O /dev/null https://www.debian.org/ --2015-01-16 10:26:59-- https://www.debian.org/ Resolving www.debian.org (www.debian.org)... failed: Name or service not known. wget: unable to resolve host address `www.debian.org' virt-builder: wget -O /dev/null https://www.debian.org/: command exited with an error
Bug#722613: Prompt to restart Apache on unattended installation
Package: ganglia-webfrontend Version: 3.3.8-1+nmu1 When doing an unattended installation (scripted, using "sudo apt-get -y --force-yes install"), I am getting the following message: ^^^ Configuring ganglia-webfrontend --- In order to activate the new configuration, the web server needs to be restarted. If you choose not to do this automatically, you should do so manually at the first opportunity. Restart apache2? ^^^ I need to explicitly enter "y" for the installation process to continue. Thanks Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697386: RemoteSyslog Appender IP Address bug (Fixed upstream)
Package: liblog4cpp5 Version: 1.0-4 The RemoteSyslog Appender is unusable. There is a bug in the way the IP Address of the Remote syslog server is saved. Please see: http://sourceforge.net/tracker/index.php?func=detail&aid=1579890&group_id=15190&atid=115190 And: http://sourceforge.net/mailarchive/forum.php?thread_name=CAKsSo3-1BY9hA_XRTGoyPhzU%3D-ny8%3D_XHSOgjxGDLk6kq_R-1A%40mail.gmail.com&forum_name=log4cpp-devel Patch upstream, applies cleanly against Debian 1.0-4. http://log4cpp.cvs.sourceforge.net/viewvc/log4cpp/log4cpp/src/RemoteSyslogAppender.cpp?r1=1.24&r2=1.25&view=patch Also please note log4cpp 1.1 is out. However, 1.1 doesn't fix the RemoteSyslog issue, so patch above still needs to be applied against 1.1. Thanks Simon
Bug#497928: rsnapshot: The lchown Perl-module is not available in Debian-ized form
Hello, On 5-Sep-08, at 9:05 AM, Hagen Fuchs wrote: The rsnapshot downloads-page http://www.rsnapshot.org/downloads.html gives another page http://permalink.gmane.org/ gmane.comp.sysutils.backup.rsnapshot.general/1565 which allegedly provides a way to get sarge-packages. However, one of the hosts that have to be added to the 'sources.list' is not available. The only option left, which I would like to circumvent, is to run Perl to fetch it from CPAN. Unfortunately the Perl Lchown module doesn't seems to be available under Debian. I've been using Rsnapshot for years my self without using the Lchown module, and haven't had any issues. That being said, you should be able to install the Perl Lchown module under Debian by running the following command as root: perl -MCPAN -e 'install qw(Lchown)' Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501992: rsnapshot: new upstream version 1.3.1
Hello Tim, There is a new version at http://www.rsnapshot.org/downloads.html It includes taking a snapshot of an lvm snapshot, and is thus atomic. Rsnapshot 1.3.1 should be packaged and released soon, but won't make it into the next Debian release. The most recent version of Rsnapshot available with Debian is 1.3.0. Meanwhile you can still use Rsnapshot to backup your LVM volumes. You can use "cmd_preexec" in your Rsnapshot configuration file to create and mount your LVM snapshots prior to running your backups, and "cmd_postexec" to unmount and remove them. Regards, Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496908: rsnapshot: only smallest defined interval gets synced correctly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Philipp, On 28-Aug-08, at 9:48 AM, Philipp Huebner wrote: intervalhourly 60 intervaldaily 30 intervalweekly 4 intervalmonthly 6 makes only the hourly interval work correctly. With the other intervals, the old directories are moved one number forward, but no new directory is created and nothing is synced. The first interval in the configuration file is always the one that get synced from the "backup" sources specified at the bottom of your configuration file. All the other intervals simply moves the oldest copy of the interval listed immediately above in the configuration file. Your configuration below would act like this: - - The hourly interval would need to run 60 times to create directories from 0 to .59, incrementing .0 to .1, .1 to .2, and so forth each time, and then syncing the source to create a new .0 - - The daily interval will work only when hourly.59 is present. It would first increment the different daily backups ,. daily.0 to daily. 1, .1 to daily.2, etc. and then finally move hourly.59 to daily.0. - - The weekly interval would first increment the different weekly backups, weekly.0 to weekly.1, etc. and then move daily.30 to create a new weekly.0. - - etc.. In your configuration below, if you're running "rsnapshot hourly" every hour, setting "hourly 60" means your first daily.0 will hold a 60 hours old backup, daily.1 will hold a 84 hours old backup, and so forth. The same applies for your daily and weekly: your weekly.0 will hold a 30 days old backup, your weekly.1 37 days old, etc. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFIvJl71jAZg9vxR6wRAvDVAKDSpmvufs/Dwkb1OFWKHCvaGvK3QACfTbbQ hDnK7eqwH44d/SCNFpAdStc= =Z+ZG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327521: Mtop and local MySQL server
Package: mtop Version: 0.6.6-1.2 Severity: important Hi, This bug is similar to #279896. The current Mtop package is not installable here. From the README.Debian file: > You have to create a mysql user for mtop named mysqltop with the following > commands (example for localhost mysql server): > mysql> grant select on test.* to mysqltop; > mysql> grant select on test.* to [EMAIL PROTECTED]; > mysql> update user set process_priv='y' where user='mysqltop'; > mysql> flush privileges; > > This is handled automatically by debconf when the package is installed. The problem is the debconf "mysql_server", "mysql_port", "root_mysql" and "root_passwd" attributes are inexistent in debconf here, and default to "localhost" and an empty root password. I see two problems here that would fail the install of Mtop: The first is obvious, having an empty MySQL root password is bad. And not to mention the account could have been renamed for something other than "root". The second, Mtop should not complain if there are no local MySQL server. Mtop should be usable on any machines; a Web server or Mail server, with no need for a local MySQL instance. I suggest either dropping the .postinst and .postrm files, which basically tries to create that "mysqltop" user with appropriate privileges for Mtop to run, or we could prompt the user to enter it's default username, password and host for Mtop, without requiring the "mysqltop" account, and store this in some configuration file for Mtop to use. I am used to passing --user and --host manually to Mtop to choose which server I want to connect to. Regards, Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290967: steps to reproduce
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jon, This is not a problem with Rsnapshot but rather with the way permissions are treated. On 27-Jul-07, at 7:42 AM, Jon Dowland wrote: [EMAIL PROTECTED]:~/tmp/remove$ find foo -ls 334154 dr-xr-xr-x 2 jon jon 4096 Jul 27 12:33 foo 334160 -r--r--r-- 1 jon jon 0 Jul 27 12:33 foo/bar /foo needs u+w permission in order for you to be able to create or delete files in it, unless you are root of course. $ ls -ld foo dr-xr-xr-x 2 simon simon 6 2007-07-27 19:20 foo $ touch foo/bar touch: cannot touch `foo/bar': Permission denied $ chmod u+w foo $ touch foo/bar $ chmod u-w foo $ rm foo/bar rm: cannot remove `foo/bar': Permission denied By default, Rsnapshot passes -a to rsync when doing the copy to preserve permissions. If you are running Rsnapshot as root, this will not cause any problems and is most-likely the desired behavior. But in case you are running as a regular user, you will need to make sure all your folders have the right permissions before copying them. You could change rsnapshot.conf to tell Rsync NOT to preserve permissions, or, in Etch, you can use the new --chmod Rsync argument to force folders to have the u+w permission set (ex. --chmod=Du +rwx). See rsnapshot.conf rsync_short_args and rsync_long_args options. Hope this helps! Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGqoX21jAZg9vxR6wRAitPAJ4nKxhO5dYVcyCX1E7b1GJUmLcy5gCfYHIS DRrZV+ikWrPp905R9maeEMg= =/N3L -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422262: rsnapshot: Should recommend ssh-client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chris, Since ssh is a transitional package, rsnapshot should depend on ssh-client (or openssh-client?) Thank you for reporting this. This will be fixed in the coming release. Regards, Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGnVyr1jAZg9vxR6wRAlERAKChm+Zj+pLgPhsa1PBN1tuGOU5kzgCfRTgB m9105m/FP0pCfWJGfTWsM6k= =MjOW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432862: rsnapshot: interval definitions in cron.d unintuitive (particularly hour)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jon, Thank you very much for your time. I will integrate this patch in the next release. Thanks Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGnVtH1jAZg9vxR6wRAss3AKCHWyvDyc61w2cTRlz/toiJjlnsLACg2nEh bWkx7NkBJygJh52Rq24bicM= =QSHD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411317: manpage references non-existent /etc/rsnapshot.conf.default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The manpage references /etc/rsnapshot.conf.default which doesn't exist. The manpage is the unmodified version of the official Rsnapshot release, which includes an rsnapshot.conf.default file. In Debian, the rsnapshot.conf.default file can be found in /usr/share/doc/ rsnapshot/examples/rsnapshot.conf.default.gz. It will be fixed in the next release. Thank you for reporting this. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFF3Goe1jAZg9vxR6wRAhF9AJwLQoVlNx/zTb9xZp7Hb6EI/INtJwCfeaGf M2ICzCYlPSYUpN0wG4TkYG4= =o4cN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410752: Contradiction in rsnapshot.conf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chris, In the default /etc/rsnapshot.conf the comment re cmd_cp seems wrong since it claims that cmd_cp should be commented out for the default Debian system (since coreutil's version > 5.3) but it's not. Rsnapshot 1.2.9 has a fix to automatically strip trailing slashes, to accommodate users with recent coreutils. In Debian, a patch was introduced since 1.2.1-1.1 (see #339845) It is safe to leave the default cmd_cp uncommented. Thank you for bringing this to our attention. I will remove the comment about coreutils > 5.3 in the next release Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFF0dZN1jAZg9vxR6wRAuDRAJ4ggvaJEjvE3o3cCWpWTIuhCNhGxwCdGror VddUN39U3+KruHFyCP9vbEk= =6LY6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407210: Invalid argument to echo in qemu-ifup
Package: xen-utils-common Version: 3.0.3-0-2 Severity: minor Hi, In /etc/xen/scripts/qemu-ifup -c is not a valid argument to echo, did you mean -n? Thanks Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317418: Updated Sarge package available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi On 9-Sep-06, at 9:32 AM, Mario 'BitKoenig' Holbe wrote: On Fri, Sep 01, 2006 at 06:53:30PM +0200, Paul Slootman wrote: Because I couldn't reproduce it, and I didn't want to close a bug report I was able to reproduce this bug with the latest rsync and rsnapshot from stable # rsync --version rsync version 2.6.4 protocol version 29 # rsnapshot rsnapshot 1.2.1 First rsnapshot run: # rsnapshot daily # ls -lR daily.0/test/test/ daily.0/test/test/: total 0 drwxr-xr-x 3 root root 14 2006-09-09 11:09 src daily.0/test/test/src: total 0 drwxr-xr-x 2 root root 30 2006-09-09 11:15 1 daily.0/test/test/src/1: total 0 - -rw-r--r-- 1 root root 0 2006-09-09 11:15 a - -rw-r--r-- 1 root root 0 2006-09-09 11:09 b - -rw-r--r-- 1 root root 0 2006-09-09 11:09 c Remove file 'a' from the source directory: # rm /test/src/1/a Second rsnapshot run: # rsnapshot daily # ls -lR daily.0/test/test/ daily.0/test/test/: total 0 drwxr-xr-x 3 root root 14 2006-09-09 11:09 src daily.0/test/test/src: total 0 drwxr-xr-x 2 root root 30 2006-09-09 11:15 1 daily.0/test/test/src/1: total 0 - -rw-r--r-- 2 root root 0 2006-09-09 11:15 a - -rw-r--r-- 2 root root 0 2006-09-09 11:09 b - -rw-r--r-- 2 root root 0 2006-09-09 11:09 c Rsnapshot used "/usr/bin/rsync -a --delete --numeric-ids --relative -- delete-excluded /test/ /home/backup/test/daily.0/test/" I meant to say I never encountered it, and there was a pretty simple workaround (drop the trailing slash). Your report that that doesn't help Well, this is not always that simple :) A trailing slashes patch was introduced in rsnapshot 1.2.1-1.1 and later reviewed in 1.2.1-2, both went into unstable. This patch was to fix an issue with latest versions of GNU cp in testing/unstable. Now it seems you discovered a similar bug with the stable version of rsync. Please try installing the latest rsnapshot 1.2.9-1 from testing. Most of the code was reviewed in 1.2.9 and trailing slashes were completely removed. Thanks Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFAuRy1jAZg9vxR6wRAtFtAJ4oWxSDyQqvBeB0HNi1G8G3YwIF6gCggnOp 4wpuImr7kZFVqUNKvsPPi/w= =6NIA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386118: per-backup ex/include options overshadow global options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin On 5-Sep-06, at 7:30 AM, martin f krafft wrote: With the following lines in the configuration file: exclude /sys exclude /proc backup [EMAIL PROTECTED]:/ wall/ exclude=/var/spool/squid the rsync call used is /usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded --exclude=/var/spool/squid --rsh=/usr/bin/ssh [EMAIL PROTECTED]:/ /srv/backups/daily.0/wall/ you can see how the /sys and /proc excludes are being ignored. I would consider this a bug as this behaviour is not documented. I think global exclude/include options should apply to all backups. I am forwarding this to the upstream authors. You can append your --exclude directly to the end of rsync_long_args in the configuration: rsync_long_args --delete --numeric-ids --relative --delete-excluded -- exclude=/sys --exclude=/proc Or better, use --exclude-from and an exclude file: rsync_long_args --delete --numeric-ids --relative --delete-exclude -- exclude-from=/path/to/exclude/file Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE/ZRz1jAZg9vxR6wRArV4AKCHJbXK7/ArIrBGJDFuCVThnrt63QCfSeXF +xfFfYokDkFeRISL1Q5u0NA= =TUET -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352400: rsnapshot: does not start ("Can't locate Antiflux/Rename.pm in @INC")
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gregor, To my knowledge neither the official rsnapshot release nor the Debian package depends on a file called Antiflux/Rename.pm. Please make sure you are using a clean version of the latest 1.2.1-1.1 release. Regards, Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFETZqE1jAZg9vxR6wRArQNAKCbmjGFFJvh7+xH1acbItOZwj/WowCg8Mn+ ca1YQES7zGXarcx7aC14uY4= =QDbZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
