Bug#488600: gitosis: FHS violation in /var/cache
Package: gitosis Version: 0.2+20080419-2 Severity: serious Hello, gitosis’s postinst script creates the gitosis user, with $HOME located in /var/cache/gitosis ; the Git repositories hosted by gitosis will then be stored in this directory, along with the gitosis configuration. According to the FHS[1], « /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. » IMHO, neither the hosted repositories nor the gitosis config match this definition. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA Bye, -- intrigeri [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456996: Please send some info
notfound 456996 0.30.215-2 found 456996 0.30.214-6 thanks Hello, Micah Anderson wrote (11 Apr 2008 23:39:48 GMT) : * intrigeri [EMAIL PROTECTED] [2008-04-08 03:09-0400]: When I upgraded a lenny system from 0.30.214-6 to 0.30.215-2, all my VServers were restarted without any warning. Yes, this is because of the postrm in 0.30.214-6 stopping the vservers. This actually has been fixed, but if you had 0.30.214-6 installed, any upgrade to a newer version would cause this behavior. That package's postrm is broken and when you upgrade to a new package, that broken postrm is executed. Sadly, I could not fix the package that you actually have installed, but instead must provide you with a new package that has the fix, but you will experience the problem when you transition to the fixed package. Your reasoning seems to make sense, I’m thus changing my « found » tag from 0.30.215-2 to 0.30.214-6. Thanks for your thorough explanation. Bye, -- intrigeri [EMAIL PROTECTED]
Bug#456996: Please send some info
Hello, Micah Anderson wrote (17 Mar 2008 16:41:38 GMT) : I'm trying to track down how this happened for you, can you please provide the following: 1. the contents of your /etc/default/util-vserver 2. the debconf value for util-vserver/prerm_stop_running_vservers 3. the debconf vaue for util-vserver/start_on_boot When I upgraded a lenny system from 0.30.214-6 to 0.30.215-2, all my VServers were restarted without any warning. Here are the relevant lines from /etc/default/util-vserver : MARK=default ALWAYS_STOP=true AUTO=true And in /var/cache/debconf/config.dat, the only util-vserver-related sections are : Name: util-vserver/postrm_remove_vserver_configs Template: util-vserver/postrm_remove_vserver_configs Owners: util-vserver Name: util-vserver/prerm_stop_running_vservers Template: util-vserver/prerm_stop_running_vservers Owners: util-vserver They are not flagged as seen, nor have any set value, which seems weird to me. Running dpkg-reconfigure -plow util-vserver does not ask any question. Bye, -- intrigeri [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473115: martian-modem-source: Does not compile against Linux 2.6.24
Release: lenny/sid APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages martian-modem-source depends on: ii bzip2 1.0.5-0.1 high-quality block-sorting file co ii debhelper 6.0.5 helper programs for debian/rules ii make 3.81-3.1 The GNU version of the make util ii module-assistant 0.10.11.0 tool to make module package creati Versions of packages martian-modem-source recommends: ii martian-modem 20061203-1 ltmodem alternative driver providi -- no debconf information Bye, -- intrigeri [EMAIL PROTECTED]
Bug#411118: clamav: CVE-2007-0897 - CAB File Denial of Service Vulnerability
Package: clamav Version: 0.84-2.sarge.13 Severity: serious All versions prior to 0.90 are suspected to be vulnerable to a resource consumption vulnerability in Clam AntiVirus' ClamAV allows remote attackers to degrade the service of the clamd scanner. E.g., legitimate email can be refused because of this bug. v0.90RC1.1 is confirmed to be vulnerable. Upstream 0.90 fixes this. A sarge security fix backport will probably be needed. Ciao, -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages clamav depends on: ii clamav-freshclam [cla 0.84-2.sarge.13downloads clamav virus databases f ii libbz2-1.01.0.2-7high-quality block-sorting file co ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an ii libclamav10.84-2.sarge.13virus scanner library ii libcurl3 7.13.2-2sarge5 Multi-protocol file transfer libra ii libgmp3 4.1.4-6Multiprecision arithmetic library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libssl0.9.7 0.9.7e-3sarge4 SSL shared libraries ii zlib1g1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411117: clamav: CVE-2007-0898 - MIME Header Directory Traversal
Package: clamav Version: 0.84-2.sarge.13 Severity: serious Hello, All versions prior to the 0.90 stable release are suspected to be vulnerable to a directory traversal vulnerability that allows remote attackers to overwrite files owned by the clamd scanner, such as the virus database file. This has been assigned the name CVE-2007-0898, and has been fixed in upstream 0.90. A sarge security fix backport will probably be needed. Ciao, -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages clamav depends on: ii clamav-freshclam [cla 0.84-2.sarge.13downloads clamav virus databases f ii libbz2-1.01.0.2-7high-quality block-sorting file co ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an ii libclamav10.84-2.sarge.13virus scanner library ii libcurl3 7.13.2-2sarge5 Multi-protocol file transfer libra ii libgmp3 4.1.4-6Multiprecision arithmetic library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libssl0.9.7 0.9.7e-3sarge4 SSL shared libraries ii zlib1g1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410843: fixed in spamassassin 3.1.7-2
Hello, Duncan Findlay wrote (15 Feb 2007 05:47:03 GMT) : Source: spamassassin Source-Version: 3.1.7-2 We believe that the bug you reported is fixed in the latest version of spamassassin, which is due to be installed in the Debian FTP archive: Are there plans to prepare sarge packages backporting the security fix ? Ciao, -- intrigeri [EMAIL PROTECTED] | gnupg key @ http://intrigeri.boum.org/intrigeri.asc | The impossible just takes a bit longer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396578: backupninja: PostgreSQL handler broken on VServers
Package: backupninja
Version: 0.9.4-3
Severity: grave
Info: starting action 15.pgsql (because of --now)
Debug: yes
Info: Using vserver 'db'.
Debug: Examining vserver 'db'.
Debug: chown 0
1
2
3
4
5
6
7
8
9
10
11
12
14
25
27
32
33
42
90
99
1000 /vservers/db/backup/postgresql
chown: cannot access `1': No such file or directory
chown: cannot access `2': No such file or directory
chown: cannot access `3': No such file or directory
chown: cannot access `4': No such file or directory
chown: cannot access `5': No such file or directory
chown: cannot access `6': No such file or directory
chown: cannot access `7': No such file or directory
chown: cannot access `8': No such file or directory
chown: cannot access `9': No such file or directory
chown: cannot access `10': No such file or directory
chown: cannot access `11': No such file or directory
chown: cannot access `12': No such file or directory
chown: cannot access `14': No such file or directory
chown: cannot access `25': No such file or directory
chown: cannot access `27': No such file or directory
chown: cannot access `32': No such file or directory
chown: cannot access `33': No such file or directory
chown: cannot access `42': No such file or directory
chown: cannot access `90': No such file or directory
chown: cannot access `99': No such file or directory
chown: cannot access `1000': No such file or directory
Debug: chmod 700 /vservers/db/backup/postgresql
Debug: /usr/sbin/vserver db exec su - postgres -c /usr/bin/pg_dumpall |
/bin/gzip /backup/postgresql/db.sql.gz
Warning: /bin/sh: /backup/postgresql/db.sql.gz: Permission denied
Looking at the code, I found what was giving that behaviour:
if [ $usevserver = yes ]; then
pguid=`$VSERVER $vsname exec getent passwd $PGSQLUSER | awk -F: '{print
$3}'`
else
pguid=`getent passwd postgres | awk -F: '{print $3}'`
fi
So it looks like PGSQLUSER wasnt set in my config and then getent
matched all passwd entries, resulting in a wrong chown $pguid
$vroot$backupdir.
Then I grep'ed backupninja source and didnt found any mention to
PGSQLUSER other than this line at pgsql handler and the Changelog
entry for 0.9.4 introducing this new variable.
I'm wondering where to set this variable and if theres still a
lot of hardcoded postgres user in this handler.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-1-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to fr_FR.UTF-8)
Versions of packages backupninja depends on:
ii bash 3.1-5 The GNU Bourne Again SHell
ii dialog1.0-20060221-1 Displays user-friendly dialog boxe
ii gawk 1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr
ii mawk 1.3.3-11 a pattern scanning and text proces
backupninja recommends no packages.
-- no debconf information
--
intrigeri [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396632: backupninja: sys handler fails to backup partition table and does not warn about it
Package: backupninja Version: 0.9.4-3 Severity: grave My sys handler cron mail reports always contain the following lines : mail *warning* -- /etc/backup.d/10.sys == warnings from /etc/backup.d/10.sys == Warning: The partition table looks like it was made Warning: The partition table looks like it was made /mail Running backupninja in debug mode gives the following output : debug Warning: The partition table looks like it was made for C/H/S=*/255/63 (instead of 19590/16/63). For this listing I'll assume that geometry. Warning: The partition table looks like it was made for C/H/S=*/255/63 (instead of 19386/16/63). For this listing I'll assume that geometry. /debug And moreover, no /var/backups/partition* file is created. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages backupninja depends on: ii bash 3.1-5 The GNU Bourne Again SHell ii dialog1.0-20060221-1 Displays user-friendly dialog boxe ii gawk 1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii mawk 1.3.3-11 a pattern scanning and text proces backupninja recommends no packages. -- no debconf information -- intrigeri [EMAIL PROTECTED] | gnupg key @ http://intrigeri.boum.org/intrigeri.asc | Every now and then I get a little bit restless | and I dream of something wild. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391519: backupninja
package backupninja found 391519 0.9.3-6 found 388543 0.9.3-6 found 371858 0.9.3-6 notfound 391519 0.9.4-1 notfound 388543 0.9.4-1 notfound 371858 0.9.4-1 thanks Forgot to close them in debian/changelog, then closed them forgetting the Version pseudoheader... Should be ok now. -- intrigeri [EMAIL PROTECTED] | gnupg key @ http://intrigeri.boum.org/intrigeri.asc | We're dreaming of something else. | Something more clandestine, something happier. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391519: backupninja: unclear symlinks/globbing support in dup and rdiff handlers can lead to data loss
Package: backupninja Version: 0.9.3-6 Severity: grave Tags: fixed-upstream As thoroughly discussed [1] on backupninja's mailing-list, incompatibilities between various readlink and backupninja versions cause hardly predictable behaviour when using symlinks and/or globbing in include/exclude/vsinclude statements for the dup and rdiff handlers' configuration. This has already lead users to think some directories were backup'd when they were actually not; this can cause data loss, that's why I'm setting severity grave to this bug. This issue was fixed upstream in SVN r437. [1] Thread with subject that * and readlink issue..., starting on http://lists.riseup.net/www/arc/backupninja/2006-06/thrd1.html, going on on http://lists.riseup.net/www/arc/backupninja/2006-07/. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Versions of packages backupninja depends on: ii bash 3.1-5 The GNU Bourne Again SHell ii dialog1.0-20060221-1 Displays user-friendly dialog boxe ii mawk 1.3.3-11 a pattern scanning and text proces backupninja recommends no packages. -- no debconf information -- intrigeri [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360371: metche: Uses all aviable disk in /var/lib
tags 369371 + moreinfo thanks Bill Thorsteinson wrote (01 Apr 2006 17:07:27 GMT) : I installed metche a couple of days ago. Today I noticed email was not being sent to the server. Do you mean : - sent to the server, i.e. the mail system was broken because of a full /var partition or - sent by metche ? Investigation showed that metche had created archives every 5 minutes since installation and retained them all. Other than configuring chagelogs no changes had occurred since instalation. I have since uninstalled. I don't understand why this is a bug : the README and metche(8) manpage clearly state that a number of system states are saved to disk ; this is necessary for metche to be able to provide reports (diffs), and to be able to rollback to a previous working state when something gets broken... which is the actual purpose of metche. Our documentation does not makes clear, though, that these backups are not done incrementally. Also, I've just found a few bugs about the way metche is supposed to remove old unneeded saved states... and actually does not, in some cases. It would be really useful to send us the output of metche list, after letting metche work for a few days, carefully monitoring it so that it does not break your system... is it possible ? -- System Information: [...] Versions of packages metche depends on: [...] pn mutt Not found. Might it be possible mutt was missing when you were trying metche ? Ciao, -- intrigeri [EMAIL PROTECTED] | gnupg key @ http://intrigeri.boum.org/intrigeri.asc pgpOBGdEFndLb.pgp Description: PGP signature
Bug#348681: /usr/sbin/localepurge: line 158: 2688K: value too great for base (error token is 2688K)
tags 348681 + moreinfo thanks Christoph Berg wrote (18 Jan 2006 13:04:11 +0100) : [0] [EMAIL PROTECTED] sudo localepurge /usr/sbin/localepurge: line 158: 2688K: value too great for base (error token is 2688K) For my first BSP, I'm having had a look to the code, and it seems that one of the calls to get_used_space echoes a human readable result instead of plain bytes count. Looking at this function's (conditional) definition, this can only happen, depending on QUICKNDIRTYCALC presence: - either in line 58's `df' call: set - $(df -P $1); shift $(($# - 6)); echo $3 - or in line 64's `du' call: set - $(du -s $1) Since your localepurge/quickndirtycalc debconf variable is set to true, we are in the first case... but `df -P' is not supposed to output any human readable values, ever. My naive guess would be that, for any obscure reason I'm not able to find out, a shell alias for df, defined on your system, is used by localepurge. A simple fix would be to replace this `df' call by a `/bin/df' one, and to do the same for the `du' call bellow. Christoph, could you please try this suggested fix on your system and tell us if it works? Ciao, -- intrigeri [EMAIL PROTECTED] | gnupg key @ http://intrigeri.boum.org/intrigeri.asc pgpF7yXcQzBWv.pgp Description: PGP signature
