Bug#473651: [samba] Add a regular backup of .tdb files
On Sun, Aug 23, 2009 at 05:33:35PM -0700, Steve Langasek wrote: I agree that these are equally as important as *passdb.tdb* to back up. But copy to /var/backups is not an appropriate backup strategy - these files are already under /var/lib and should therefore already be part of any system backup policy. We should not be backing them up piecemeal in the samba package. Ah, OK. I was under the impression that /var/backups was meant for critical odds-and-ends that should be backed up by default even on systems managed by extremely lax sysadmins. A bit of googling for debian policy /var/backups shows similar confusion by others. One other point: many well-meaning sysadmins may be doing rsync backups of their entire systems, including /var/lib/samba, thinking that they are safe in case of any catastrophe. But they might not be aware that the modification date on the *.tdb files rarely gets changed, even if the contents do, because Samba uses mmap() to access them. Er, use of mmap() should not affect the filesystem semantics of mtime. I think you're mistaken here. You are right, mmap() *should* update mtime according to man mmap. But I do not believe it ever since I got bitten by a bug like http://his.luky.org/ML/linux-kernel.2005/msg28040.html or http://his.luky.org/ML/linux-kernel.2005/msg28040.html a number of years ago. I have been cautious of how I backup mmapped data ever since. FYI, I just did a test with smbpasswd on my Lenny system with the 2.6.26-2-vserver-686 kernel and the /var/lib/samba/passdb.tdb file changed mtime as it should. Good. -- Erik Rossen OpenPGP key: 2935D0B9 ros...@rossen.ch On fonce la tête dans http://www.rtfm-sarl.ch le guidon et on RTFM. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#473651: [samba] Add a regular backup of .tdb files
Package: samba Version: 2:3.2.5-4lenny6 Followup-For: Bug #473651 On Wed, 16 Apr 2008 23:08:20 -0700, Steve Langasek vor...@debian.org wrote: Actually yes, I do object because I don't think we should be doing piecemeal backups in individual packages. Losing winbind_idmap is bad, but not worse than losing other databases on the system, and I haven't seen that tdbs are noticeably more fragile than other database formats that they should require a separate backup policy from the rest of the system. I just spent an hour modifying and testing the pre-existing /etc/cron.daily/samba to backup the /var/lib/samba/*.tdb files to /var/backups/samba on a number of Samba servers that I manage. If /etc/samba/smbpasswd is important enough to backup, then so is secrets.tdb, winbind_idmap.tdb, and all of the others. My goal in the attached script is to provide a reasonable chance of recovery in case /var/lib/samba gets blown away. Use it if you like, ignore it if you don't. One other point: many well-meaning sysadmins may be doing rsync backups of their entire systems, including /var/lib/samba, thinking that they are safe in case of any catastrophe. But they might not be aware that the modification date on the *.tdb files rarely gets changed, even if the contents do, because Samba uses mmap() to access them. As a result, rsync might pick up the *.tdb files the first time they are seen and then never again. At least by running tdbbackup regularly, one can guarantee that rsynced *.tdb.bak files are somewhat up-to-date. Personally I do not see anything wrong in supplying a minimal backup procedure as part of a package. Perhaps it should not be installed into /etc/cron* by default, but that is another subject. #!/bin/sh # # cron script to save a backup copy of /etc/samba/smbpasswd in /var/backups. # # Written by Eloy A. Paris pe...@debian.org for the Debian project. # Augmented by Erik Rossen ros...@rossen.ch to backup *.tdb files. # BAK=/var/backups/samba umask 022 mkdir -p $BAK if cd $BAK; then # Make sure /etc/samba/smbpasswd exists if [ -f /etc/samba/smbpasswd ]; then cmp -s smbpasswd.bak /etc/samba/smbpasswd || cp -p /etc/samba/smbpasswd smbpasswd.bak fi # Make sure tdbbackup exists if [ -x /usr/bin/tdbbackup ]; then /usr/bin/tdbbackup /var/lib/samba/*.tdb for i in /var/lib/samba/*.tdb.bak ; do j=$(basename $i) cmp -s $j $i || cp -p $i $j done fi fi
Bug#514960: mutt: refusal to save cert may be due to stricter gnutls
Package: mutt Version: 1.5.18-6 Followup-For: Bug #514960 Lenny's version of mutt also refused to save the cert/fingerprint of my IMAPS server but I was able to fix the problem by regenerating my IMAPS server SSL certificate to use Signature Algorithm: sha1WithRSAEncryption rather than Signature Algorithm: md5WithRSAEncryption. Check which one you are using by doing the following on your IMAPS server: openssl x509 -in /etc/ssl/certs/imaps-server.crt -text | less If you are using openssl to generate your keys, check that the openssl.cnf parameter default_md is set to sha1 rather than md5. gnutls (used by Mutt) now refuses to accept MD5. This bug/change/feature of gnutls has bitten OpenLDAP users as well. See http://www.debian-administration.org/users/dkg/weblog/42 for a good summary of the problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475158: snmpd: confirmed bug #475158 still in Lenny
Package: snmpd Followup-For: Bug #475158 I just upgraded a vserver from etch to lenny and I wish to confirm that this bug from April 2008 still exists. snmpd in a vserver still complains like this: Feb 12 15:07:45 durian snmpd[2550]: No page line in /proc/stat Feb 12 15:07:45 durian snmpd[2550]: No swap line in /proc/stat -- Erik Rossen OpenPGP key: 2935D0B9 ros...@rossen.ch On fonce la tête dans http://www.rtfm-sarl.ch le guidon et on RTFM. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514423: libpam-modules: 'or' operator ignored in services field of /etc/security/group.conf
Package: libpam-modules Version: 1.0.1-5 Severity: normal There is another bug in pam_groups that seems similar to #326407, i.e. the 'or' operator is ignored in services field of /etc/security/group.conf. In etch, I use the following line in /etc/security/group.conf to give users access to the audio group (among other things). login|gdm|gdm-autologin|kdm|xdm|ssh; *; *; Al-2400; audio, camera, cdrom, dialout, floppy, fuse, plugdev, scanner, video The above does not work in lenny at the moment. If I remove the |gdm|gdm-autologin|kdm|xdm|ssh part and login from the console, I get the complete group list. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (90, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (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 libpam-modules depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii libc6 2.7-18 GNU C Library: Shared libraries ii libdb4.6 4.6.21-11 Berkeley v4.6 Database Libraries [ ii libpam0g 1.0.1-5Pluggable Authentication Modules l ii libselinux1 2.0.65-5 SELinux shared libraries libpam-modules recommends no packages. libpam-modules 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#499675: /etc/cron.daily/integrit reports are not in alphabetical order
There was a error in my patch - the field seperator for the sorts should have been / instead of :. Attached is the complete /etc/cron.daily/integrit that I am currently using. -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] On fonce la tête dans http://www.rtfm-sarl.ch le guidon et on RTFM. #!/bin/sh # /etc/cron.daily/integrit : integrit daily cron job # initially written by Andras Bali test -x /usr/sbin/integrit || exit 0 test -f /etc/integrit/integrit.debian.conf || exit 0 CONFIGS= . /etc/integrit/integrit.debian.conf test -n $CONFIGS || exit 0 if test -z $EMAIL_RCPT; then echo EMAIL_RCPT must be set in /etc/integrit/integrit.debian.conf 2 exit 1 fi REPORT=/var/lib/integrit/current.report.$$ cp /dev/null $REPORT trap rm -f \$REPORT\ EXIT rc=0 for i in $CONFIGS; do known=`sed -n 's/^ *known *= *\(.\+\) *$/\1/p' $i |head -1` current=`sed -n 's/^ *current *= *\(.\+\) *$/\1/p' $i |head -1` if test -z $known -o -z $current; then echo known and/or current not set in $i, skipping. 2; echo continue fi OPTS='-cu' test -e $known || OPTS='-u' echo start: integrit -C $i $OPTS RC=0 nice integrit -C $i $OPTS 21 || RC=$? echo exit: $RC; echo if test $RC -eq 0; then test -e $known || cp $current $known else rc=$RC fi test AUTO_UPDATE = no || cp $current $known done $REPORT LC_COLLATE=C ed -s $REPORT 1/dev/null EOF 1 /do update/+1 .,/^integrit:/-1 w ! sort -t/ -k2 %.changes .,/^integrit:/-1 d -1 . r ! cat %.changes ! rm -f %.changes w /integrit: checking for missing files/+1 .,/^integrit:/-1 w ! sort -t/ -k2 %.missing .,/^integrit:/-1 d -1 . r ! cat %.missing ! rm -f %.missing wq EOF if test $rc -ne 0 -o $ALWAYS_EMAIL = 'true'; then mail -s $EMAIL_SUBJ $EMAIL_RCPT $REPORT fi
Bug#499675: /etc/cron.daily/integrit reports are not in alphabetical order
Package: integrit Version: 4.0-1 Severity: wishlist Tags: patch I collect and read integrit reports from several dozen machines every morning. It would be helpful if the cronjob sent reports with affected files listed in alphabetical order. When the reports are ordered one can rapidly scan each message (in Mutt, for example) since common changes (due to a cron-apt update, for example) appear always in the same relative locations in the reports. The following ed script inserted near the end of /etc/cron.daily/integrit rewrites $REPORT just before it is sent: LC_COLLATE=c ed -s $REPORT 1/dev/null EOF 1 /do update/+1 .,/^integrit:/-1 w ! sort -t: -k2 %.changes .,/^integrit:/-1 d -1 . r ! cat %.changes ! rm -f %.changes w /integrit: checking for missing files/+1 .,/^integrit:/-1 w ! sort -t: -k2 %.missing .,/^integrit:/-1 d -1 . r ! cat %.missing ! rm -f %.missing wq EOF -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (991, 'oldstable'), (991, 'stable'), (66, 'oldstable'), (33, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-6-vserver-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) integrit depends on no packages. Versions of packages integrit recommends: ii cron 3.0pl1-100 management of regular background p ii mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
I asked the people on the mailing list of our local LUG to test if chmod changes ctime on non-GNU systems even when there is no difference beteen the mode before and after the chmod. From these few data, the trend seems to be that ctime gets changed. Here are the results thus far (identified by uname -a): systems that change ctime: -- AIX 3 4 000650834C00 SunOS 5.8 Generic_108528-29 sun4u sparc SUNW,UltraSPARC-IIi-cEngine OpenBSD 4.1 GENERIC#187 i386 systems that do not change ctime: - FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossento do, start with RTFM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
Package: coreutils Version: 5.97-5.3 Severity: wishlist It would be nice if chmod (and chown and chgrp) only made changes to inodes when necessary so as not to change the ctime of files. I like to use the integrit file integrity-checking program which scans for changes to mtime and ctime. I also occasionally set up fix-perms cronjobs that scan directories recursively and fix any mis-configured of permissions/ownerships. The problem is that chmod -R and company change the ctimes of all files, not just those that need to be fixed. This causes excessively long (and useless) file integrity reports. I could use cfengine to do the same job, but chmod is sometimes much more convenient. I have tested Busybox chmod and it suffers from the same behavior. If unconditionally resetting the ctime of inodes is normal POSIX behavior for chmod, then this function should be implemented as a option flag. If not, can the authors make change-only-if-necessary the default behavior of chmod and company? Thanks. -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (991, 'oldstable'), (991, 'stable'), (66, 'oldstable'), (33, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-6-vserver-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages coreutils depends on: ii libacl12.2.41-1 Access control list shared library ii libc6 2.3.6.ds1-13etch7 GNU C Library: Shared libraries ii libselinux11.32-3SELinux shared libraries coreutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
On Tue, Sep 02, 2008 at 08:19:38AM -0400, Michael Stone wrote: On Tue, Sep 02, 2008 at 11:30:46AM +0200, you wrote: It would be nice if chmod (and chown and chgrp) only made changes to inodes when necessary so as not to change the ctime of files. I'm fairly certain there have also been complaints about these utilities not resetting the inode even when not necessary. That is certainly possible, if that is normal POSIX behavior. I'd suggest using them in conjunction with find(1) if you only want to modify files that don't match a particular setting. Yup. But it would be so much more elegant if chmod just Did The Right Thing. Can I ask you to pass along this wishlist item to upstream and maybe ask them why ctime must be modified even when the permissions are not? I would really like to know why. -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossento do, start with RTFM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
On Tue, Sep 02, 2008 at 08:06:51PM +0200, Jim Meyering wrote: Good idea. At least for chmod, it is not only possible, but the optimization would be essentially free, since chmod already has the required stat data. Yeah, I thought it was a good idea too. AFAICS POSIX (http://www.opengroup.org/onlinepubs/007908775/xsh/chmod.html) allows the behavior you propose. That same feature was even requested a few years ago, but no one implemented it. Thanks for the lead - I had no idea where to go looking for POSIX specs. But you got the wrong URL. The URL above refers to chmod() the function. What we needed was chmod the utility. Here it is: http://www.opengroup.org/onlinepubs/007908799/xcu/chmod.html And, if one wants to be REALLY pedantic, it looks like the file node is supposed to be changed each time. For example, here is an extract: + If perm is not specified, the + operation will not change the file mode bits. If who is not specified, the file mode bits represented by perm for the owner, group and other permissions, except for those with corresponding bits in the file mode creation mask of the invoking process, will be set. Otherwise, the file mode bits represented by the specified who and perm values will be set. Here it says that the bits will be set. Unfortunately, they do not say something like set unless already set. If the feature is to added, it will be a non-standard option. A patch would be welcome. I totally agree. If you're not interested, let me know in any case and I'll add it to the TODO list. I think I will let you add it to the TODO list. :-) For chgrp (probably chown, too, at least in some cases), it's not as obvious, since the current implementation does not stat files before changing permissions. So, to do what you want would involve adding a stat call per file to get owner/group in order to avoid(maybe) the offending ownership-changing syscall. That would not be an improvement. As far as speed is concerned, you are right that an extra stat() would usually not improve matters. (Would it be an enormous penalty? I doubt it.) But users of file integrity checking systems like myself will be grateful for the change of behavior. -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossento do, start with RTFM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
On Tue, Sep 02, 2008 at 02:30:20PM -0600, Bob Proulx wrote: Erik Rossen wrote: As far as speed is concerned, you are right that an extra stat() would usually not improve matters. (Would it be an enormous penalty? I doubt it.) But users of file integrity checking systems like myself will be grateful for the change of behavior. You would be surprised how much performance can change when adding extra stat calls. Many filesystems such as networked filesystems are extremely latency bound and those kinds of changes have a strong negative impact upon them. OK. But I still wonder how expensive are the extra stat() calls that would be spent compared to the extra chown() calls that could be saved by checking first to see if a chown() was even necessary? -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossento do, start with RTFM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489546: fai-client: dryrun -n option of install_packages is broken
Package: fai-client
Version: 3.2.8
Severity: normal
Tags: patch
It looks like a line for treating the dryrun option -n
install_packages has gone missing. The fix is simple:
--- /usr/sbin/install_packages.ORIG 2008-07-05 10:57:14.0
+0200
+++ /usr/sbin/install_packages.FIXED2008-07-06 22:14:27.0
+0200
@@ -105,6 +105,7 @@
$opt_h usage();
$opt_H showcommands();
$verbose=$ENV{verbose} || $opt_v;
+$dryrun=1 if $opt_n;
$opt_d setdownloadonly();
$maxpl=$ENV{MAXPACKAGES} || $opt_m ;
$maxpl $verbose warn Maxmimum number of packages installed at a
time set to $maxpl\n;
-- System Information:
Debian Release: 4.0
APT prefers oldstable
APT policy: (991, 'oldstable'), (991, 'stable'), (66, 'oldstable'), (33,
'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-6-vserver-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages fai-client depends on:
ii file4.17-5etch3 Determines file type using magic
ii libapt-pkg-perl 0.1.20 Perl interface to libapt-pkg
ii libparse-recdescent-perl1.94.free-3 Generates recursive-descent parser
ii perl5.8.8-7etch3 Larry Wall's Practical Extraction
Versions of packages fai-client recommends:
ii debconf-utils1.5.11etch1 debconf utilities
pn liblinux-lvm-perlnone (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475036: So if kernel-package no longer works, what do we do in the meantime?
Package: kernel-package Version: 11.001-0.1 Followup-For: Bug #475036 Recently I wanted to rebuild linux-image-2.6.18-6-xen-vserver-686 with one option changed, but the only way that I have found to do this is apt-get source linux-image-2.6.18-6-xen-vserver-686 cd linux-2.6-2.6.18.dfsg.1 # use vi to change # CONFIG_XEN_BLKDEV_TAP is not set to # CONFIG_XEN_BLKDEV_TAP=y in debian/arch/_xen/config dpkg-buildpackages -b -rfakeroot and wait for a day while a whole series of .debs are built that do not interest me. Surely this is not the way that the kernel team builds and tests kernels. Or is it? Can you please tell us how they do it? Until the rewritten version of kernel-package is ready, what should we do? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486121: gosa-schema: goserver.schema lacks a structuralObjectClass goServer
Package: gosa-schema
Version: 2.5.16.1-1
Severity: important
Somewhere between version 2.4beta2-1 and 2.5.16, the definition of the
objectClass goServer underwent a regression where it got changed from
a STRUCTURAL to an AUXILLARY objectClass (line 230 of the current
version).
This causes LDAP trees exported from older systems containing GOsa
configurations to fail importation into newer (and stricter) OpenLDAP
servers since the objects lack a valid structural object class. The
failure looks like
[EMAIL PROTECTED]:~# slapadd -c -l oldldap.ldif
slapadd: dn=cn=mail,ou=servers,ou=systems,dc=example,dc=com
(line=248): (65) no structural object class provided
even though cn=mail,ou=servers,ou=systems,dc=example,dc=com is
perfectly well-defined:
dn: cn=mail,ou=servers,ou=systems,dc=example,dc=com
structuralObjectClass: goServer
entryUUID: a279e56e-bd5d-1029-8625-9ebaa3928079
creatorsName: cn=admin,dc=example,dc=com
createTimestamp: 20050919133257Z
cn: mail
goImapSievePort: 2000
goImapPassword: NONEOFYOURBUSINESS
goImapAdmin: cyrus
objectClass: top
objectClass: goImapServer
objectClass: goServer
goImapName: imap://mail.example.com
goImapSieveServer: mail.example.com
goImapConnect: {mail.example.com:143/imap/notls}
entryCSN: 20060220124346Z#01#00#00
modifiersName: cn=admin,dc=example,dc=com
modifyTimestamp: 20060220124346Z
A temporary workaround is just to change line 230 from AUXILLARY back to
STRUCTURAL.
It would also be nice if the version number at the head of the file
## Version 030403
got incremented when there were changes. ;-)
-- System Information:
Debian Release: 4.0
APT prefers oldstable
APT policy: (991, 'oldstable'), (991, 'stable'), (66, 'oldstable'), (33,
'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-6-vserver-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486121: gosa-schema: goserver.schema lacks a structuralObjectClass goServer
On Fri, Jun 13, 2008 at 04:52:52PM +0200, Cajus Pollmeier wrote: Add the GOhard objectClass to your server entries and you're fine. The GOsa package cannot modify your ldap content to do a smooth update in this case. Ah, OK. I cannot fix your issue - except writing a note inside of the README. Please do. And thanks. -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossento do, start with RTFM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484666: fcopy: file-modes do not yet work for directories
Package: fai-client Version: 3.1.8 Severity: wishlist I like using fcopy for maintaining tarballs of configuration files for a bunch of hosts. The file-modes file permits me to own/edit/maintain my repository of configuration files as a non-privileged user because fcopy, when given a list of classes and run recursively using my repository as the source, produces a target tree of files with exactly the right owners, groups, and permissions. Unfortunately, the owner of the *directories* of the resulting tree is the un-privileged user and the directory modes are all 755. This means that I cannot simply copy the resulting tree to the target machine. This could be fixed if the file-modes file applied to directories as well as files. In the meantime, I manage the situation by carefully maintaining the configuration repository as root with each directory given the right owner, group, and perms (usually root,root,0755), but I prefer not depending on root access. Somebody else already made this request back in November 2004, but not to the BTS as far as I can see. Here is the thread: https://lists.uni-koeln.de/pipermail/linux-fai/2004-November/002568.html Thanks in advance for considering this feature request. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (991, 'stable'), (33, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-6-vserver-686 Locale: LANG=en_US, LC_CTYPE=fr_CH (charmap=ISO-8859-1) Versions of packages fai-client depends on: ii cfengine2 2.1.20-1 Tool for configuring and maintaini ii file4.17-5etch3 Determines file type using magic ii libapt-pkg-perl 0.1.20 Perl interface to libapt-pkg ii perl5.8.8-7etch3 Larry Wall's Practical Extraction fai-client recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476797: chbg: propose XLIB_SKIP_ARGB_VISUALS=1
Package: chbg Version: 1.5-9 Followup-For: Bug #476797 This is a me too report. A bug very similar to this one showed up in the qiv package. The solution proposed in #326849 is to prefix the command like so: XLIB_SKIP_ARGB_VISUALS=1 chbg I just added this to my .xsession file and now I am finally able to do a XDMCP login without eating 100% CPU. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (991, 'stable'), (33, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-6-vserver-686 Locale: LANG=en_US, LC_CTYPE=fr_CH (charmap=ISO-8859-1) Versions of packages chbg depends on: ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libgdk-pixbuf2 0.22.0-11 The GdkPixBuf image library, gtk+ ii libglib1.2 1.2.10-17 The GLib library of C routines ii libgtk1.2 1.2.10-18 The GIMP Toolkit set of widgets fo ii libpng12-0 1.2.15~beta5-1PNG library - runtime ii libx11-6 2:1.0.3-7 X11 client-side library ii zlib1g 1:1.2.3-13compression library - runtime chbg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475549: libsane-extras: info for installing proprietary epkowa backend out of date
On Fri, Apr 11, 2008 at 10:10:21PM +0200, Julien BLACHE wrote: Erik Rossen [EMAIL PROTECTED] wrote: And in which RPM is it found? The -plugin one. This was the bit of information that was missing from the README.Debian. Could you please add it? Just FYI, I was looking in the main iscan RPM for the module+firmware. I found one of the directories mentioned in the README.Debian (and none of the files in it looked relevant), but not the other, so I assumed that something had changed. For that reason, I went through the procedure of installing everything they proposed, including the -plugin RPM where I should have been looking in the first place. And where precisely should it be placed? The module and firmware files will be available in the usr/lib/iscan and usr/share/iscan directories, relative to the current directory. You need to copy the module files to /usr/lib/iscan and the firmware file to /usr/share/iscan. Seems clear to me, here again? Certainly, if you do not get confused like I did. If it's not easy enough for you, direct your complaints to Epson. There's not much I can do to help, given that I have about as much information as about everybody else. epkowa is included in libsane-extras as a service to my users. It costs me time and effort to deal with this crap, given that Epson provides absolutely nothing to distro packagers. If you don't like the way it is now, complain to Epson, trash your scanner and buy another one from a more friendly, less autistic vendor. Who's complaining? Not me! I'm actually quite grateful that I found a modern scanner in stock in a local store with any Linux support at all. But of course I am used to the vendor philosophy You can attract more flies with honey than with vinegar, but if you pull off their wings, they will accept any crap you give them. Cheers, -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossento do, start with RTFM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475549: libsane-extras: info for installing proprietary epkowa backend out of date
On Sat, Apr 12, 2008 at 08:11:58AM +0200, Erik Rossen wrote: On Fri, Apr 11, 2008 at 10:10:21PM +0200, Julien BLACHE wrote: Erik Rossen [EMAIL PROTECTED] wrote: And in which RPM is it found? The -plugin one. This was the bit of information that was missing from the README.Debian. Could you please add it? Forget what I said. I just re-read README.Debian (fifth time) and saw: rpm2cpio iscan-plugin- My apologies for the noise. -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossento do, start with RTFM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475549: libsane-extras: info for installing proprietary epkowa backend out of date
Package: libsane-extras Version: 1.0.18.5 Severity: normal The information for installing the epkowa backend, found in /usr/share/doc/libsane-extras/README.Debian, needs to be updated because Avasys has changed their packaging of iscan and the proprietary firmware that they distribute. In addition, the method for installing the files proposed in README.Debian can be improved upon somewhat. http://www.avasys.jp/lx-bin2/linux_e/scan/DL1.do offers a download form covering all of the models of Epson scanners supported by the iscan software from Avasys. Even though Debian is in the dropdown list of distributions, it is not really supported - all you will get is an RPM. When you fill out the form, they propose RPMs and docs for gcc3.2/3.3 systems or for gcc3.4/later. Assuming that we want to install on etch, download the files for gcc3.4/later. As of 2008-04-11, there is: - iscan-2.3.0-1.c2.i386.rpm, containing the iscan program (a basic GUI for scanning); - iscan-2.3.0-1.c2.tar.gz, a tarball of the sources for iscan, - userg_revG_e.pdf, a manual describing how to install and use iscan. And last, but not least, there is the file containing the bits of proprietary code. This file is probably different for every model of scanner. For example, the name of the file for my Epson GT-F700 Perfection V350 PHOTO scanner is iscan-plugin-gt-f700-2.0.0-0.c2.i386.rpm Here is how I converted and installed the downloaded RPMs: As root: apt-get install fakeroot alien As normal user: fakeroot alien -d iscan-2.3.0-1.c2.i386.rpm fakeroot alien -d iscan-plugin-gt-f700-2.0.0-0.c2.i386.rpm As root: dpkg-divert --package iscan --add /usr/share/man/man5/sane-epkowa.5.gz dpkg-divert --package iscan --add /usr/lib/sane/libsane-epkowa.la dpkg-divert --package iscan --add /usr/lib/sane/libsane-epkowa.so.1 dpkg -i iscan_2.3.0-2_i386.deb dpkg -i iscan-plugin-gt-f700_2.0.0-1_i386.deb The advice about commenting-out the epson line in /etc/sane.d/dll.conf is probably still valid. I did this. After doing all of the above, scanimage -L finally worked for me. sane-find-scanner had already been giving me results, but not scanimage. As a bonus, the iscan program works too. System Information: Debian Release: 4.0 APT prefers stable APT policy: (991, 'stable'), (33, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-6-vserver-686 Locale: LANG=en_US, LC_CTYPE=fr_CH (charmap=ISO-8859-1) Versions of packages libsane-extras depends on: ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libieee1284-3 0.2.10-4 cross-platform library for paralle ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libltdl3 1.5.22-4 A system independent dlopen wrappe ii libsane1.0.18-5 API library for scanners ii libtiff4 3.8.2-7 Tag Image File Format (TIFF) libra ii libusb-0.1-4 2:0.1.12-5userspace USB programming library Versions of packages libsane-extras recommends: ii udev 0.105-4/dev/ and hotplug management daemo -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475549: libsane-extras: info for installing proprietary epkowa backend out of date
On Fri, Apr 11, 2008 at 05:45:26PM +0200, Julien BLACHE wrote: Err, I just checked, and, no, nothing changed. The interpreter libs (and not firmware or whatever) are still shipped in a dedicated RPM package. Not one, two. Or perhaps many RPMs, if you count all of the different RPMs for all of the different Epson scanners. All you need is the interpreter lib; the install instructions in the README.Debian are valid and describe the recommended way to install the interpreter libraries as far as Debian is concerned. Which file is the interpreter lib? And in which RPM is it found? And where precisely should it be placed? -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossento do, start with RTFM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470749: dnsutils: how to patch nsupdate man page
Package: dnsutils Version: 1:9.3.4-2etch1 Followup-For: Bug #470749 The nsupdate man page can be patched to remove the broken nroff formatting commands by doing the following: gunzip /usr/share/man/man8/nsupdate.8.gz ; \ perl -p -i -e 's/.HP (\d+) //gs' /usr/share/man/man8/nsupdate.8 ; \ gzip /usr/share/man/man8/nsupdate.8 Hopefully upstream will fix this one of these days. I have seen the same problem in recent SuSE distributions. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (991, 'stable'), (33, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-6-vserver-686 Locale: LANG=en_US, LC_CTYPE=fr_CH (charmap=ISO-8859-1) Versions of packages dnsutils depends on: ii bind9-host [host] 1:9.3.4-2etch1Version of 'host' bundled with BIN ii libbind9-0 1:9.3.4-2etch1BIND9 Shared Library used by BIND ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libdns22 1:9.3.4-2etch1DNS Shared Library used by BIND ii libisc11 1:9.3.4-2etch1ISC Shared Library used by BIND ii libisccfg1 1:9.3.4-2etch1Config File Handling Library used ii liblwres9 1:9.3.4-2etch1Lightweight Resolver Library used ii libssl0.9.80.9.8c-4etch1 SSL shared libraries dnsutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353364: ganglia-monitor: status of glibc copyright infringement?
Package: ganglia-monitor Followup-For: Bug #353364 Hi Stuart, Almost 2 years ago you mentioned that the reason that Ganglia version 3.x was not getting into Debian was because the developers had included some of the source of glibc directly into Ganglia without changing the licence of Ganglia from BSD to GPL. You were going to contact the developers and let them know about the problem, but you never mentioned the outcome of the discussion in the Debian bug-tracking system. Have you considered reporting this problem to the FSF? They can be very efficient about policing their copyrights when they want to be. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453050: samba: too-many-files-in-directory bug in 3.0.24-6etch6 too?
Package: samba Version: 3.0.24-6etch6 Followup-For: Bug #453050 It was reported that 3.0.24-6etch7 had a problem with too many files in a directory, but I think that I have at least one server experiencing this problem with 3.0.24-6etch6. This is seen when attempting to load older roaming profiles that have plenty of .lnk and IE bookmark files. Loading the profile fails and the user gets a temporary one. Returning to 3.0.24-6etch4 makes the problem go away. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396544: bootcd+dash fails due to bashisms
Package: bootcd
Version: 2.53
Severity: normal
There are a number of bashisms in bootcd version 2.53 (currently found
in etch) that cause it and boot CD images created with bootcd to fail
when dash is used as /bin/sh.
dash is a strictly POSIX-compliant Bourne shell that is frequently used
to speed up shell scripting on older or minimalist systems. Personally,
I have found that using dash instead of bash can speed up boot-up times
by as much as 30%.
If you want to get a quick survey of where the problems might be,
install the devscripts package and try the following:
[EMAIL PROTECTED]:~# ls /usr/bin/bootcdwrite /usr/share/bootcd/*{.lib,.sh} |
xargs checkbashisms
possible bashism in /usr/bin/bootcdwrite line 755: ' function extra_changes'
possible bashism in /usr/bin/bootcdwrite line 870: 'echo -e'
possible bashism in /usr/share/bootcd/S12bootcdram.sh line 10: 'echo -n'
script /usr/share/bootcd/bootcd-check.lib does not appear to have a #!
interpreter line; you may get strange results
possible bashism in /usr/share/bootcd/bootcd-check.lib line 14: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 544: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 546: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 548: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 552: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 555: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 561: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 571: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 579: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 582: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 585: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-check.lib line 588: 'echo -n'
script /usr/share/bootcd/bootcd-i386.lib does not appear to have a #!
interpreter line; you may get strange results
script /usr/share/bootcd/bootcd-ia64.lib does not appear to have a #!
interpreter line; you may get strange results
script /usr/share/bootcd/bootcd-run.lib does not appear to have a #!
interpreter line; you may get strange results
possible bashism in /usr/share/bootcd/bootcd-run.lib line 40: 'echo -n'
possible bashism in /usr/share/bootcd/bootcd-run.lib line 76: 'echo -n'
script /usr/share/bootcd/bootcd2disk.lib does not appear to have a #!
interpreter line; you may get strange results
possible bashism in /usr/share/bootcd/bootcd2disk.lib line 54: 'function
disk2real'
possible bashism in /usr/share/bootcd/bootcd2disk.lib line 166: ' function
do_first'
possible bashism in /usr/share/bootcd/bootcdtest.sh line 68: 'echo -n'
possible bashism in /usr/share/bootcd/bootcdtest.sh line 69: 'let '
possible bashism in /usr/share/bootcd/bootcdtest.sh line 70: 'echo -n'
possible bashism in /usr/share/bootcd/bootcdtest.sh line 77: 'echo -n'
I think that the 'echo -n' complaints can be ignored as well as the
missing hash-bangs in the .libs, but the rest should be fixed. Either
that, or specifically use #!/bin/bash as the first line of your
scripts.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383926: dosage 1.5.8 is available
Package: dosage Version: 1.5.7-2 Severity: wishlist Just a heads-up to inform you that dosage 1.5.8 is available at http://slipgate.za.net/dosage/downloads/dosage-1.5.8.tar.gz -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (991, 'testing'), (55, 'stable'), (33, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=C, LC_CTYPE=fr_CH (charmap=ISO-8859-1) Versions of packages dosage depends on: ii python2.3.5-10 An interactive high-level object-o ii python-central0.4.17 register and build utility for Pyt dosage recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367820: davfs2: MOVE method broken - davfs treats file names as directory names
Package: davfs2 Version: 0.2.8-1 Severity: important When trying the following on a mounted davfs, I get the following error: [EMAIL PROTECTED]:/mnt/test# mv luge.gif luge2.gif mv: cannot move `luge.gif' to `luge2.gif': No such file or directory Using cadaver to do the MOVE works, so I looked at the Apache logs and saw the following when I was using davfs2: W.X.Y.Z - myusername [18/May/2006:13:01:04 +0200] MOVE /download/luge.gif/ HTTP/1.1 404 300 cadaver leaves the following result: W.X.Y.Z - myusername [18/May/2006:13:08:46 +0200] MOVE /download/luge.gif HTTP/1.1 201 278 See the difference? devfs2 has tacked a / to the end of the MOVE request for luge.gif. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (991, 'testing'), (55, 'stable'), (33, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=C, LC_CTYPE=fr_CH (charmap=ISO-8859-1) Versions of packages davfs2 depends on: ii libc62.3.6-7 GNU C Library: Shared libraries ii libneon250.25.5.dfsg-5 An HTTP and WebDAV client library ii libssl0.9.8 0.9.8a-7SSL shared libraries ii libxml2 2.6.23.dfsg.2-3 GNOME XML library ii zlib1g 1:1.2.3-11 compression library - runtime davfs2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358923: unfs3: non-existant directory in /etc/exports causes silent failure
Package: unfs3 Version: 0.9.13+dfsg-1prolibre Severity: normal If one includes an entry in /etc/exports for a directory that does not exist, unfsd silently denies access to ANY exports (even valid ones) until the offending entries are removed. Although there is a warning in syslog in this case, there nothing on STDERR. In contrast, nfs-user-server simply ignores any missing directory entries. Since some users might expect unfs3 to be an almost-drop-in replacement for nfs-user-server, it would help to have unfs3 follow this behavior. Until the problem is fixed, it would be nice to put a little warning somewhere in the README files. P.S. You can ignore the version number above: I just did a backport to woody. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux hulk 2.4.27prolibre #1 SMP Thu Jan 19 09:07:57 CET 2006 i686 Locale: LANG=C, LC_CTYPE=fr_CH Versions of packages unfs3 depends on: ii libc6 2.2.5-11.8 GNU C Library: Shared libraries an ii portmap 5-2The RPC portmapper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331269: cfengine: security update of 2005-10-01 moved binaries from /usr/bin to /usr/sbin
Package: cfengine Version: 1.6.5-1sarge1 Severity: important [Please ignore the Version info above: I am writing this email from a sarge machine because reportbug is broken in woody now.] The latest cfengine update by the Security Team has moved all of the cfengine binaries from /usr/bin to /usr/sbin. Upstream did this change back in version 1.4.3, but Debian had elected to stay with binaries in /usr/bin up until and including woody. This recent change by the Security Team probably is breaking every cfengine application that relies in a hard-coded hash-bang path in the first line of cfengine scripts. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (33, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27prolibre Locale: LANG=C, LC_CTYPE=fr_CH (charmap=ISO-8859-1) Versions of packages cfengine depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libdb4.14.1.25-18Berkeley v4.1 Database Libraries [ ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra ii perl [perl5]5.8.4-8 Larry Wall's Practical Extraction -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293435: vserver-debiantools: VREBOOT_LOCATION is set to the old location
Package: vserver-debiantools
Version: 0.1.7
Severity: normal
In the scripts /usr/sbin/{newnfserver,newvserver,stripserver}, there is
the line
VREBOOT_LOCATION=/usr/lib/vserver/vreboot
which was the old locateion of the vreboot utility.
The package util-vserver now stores vreboot in
/usr/lib/util-vserver/vreboot, thus the vreboot utility is never copied
into a freshly-made vserver.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'), (133, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.27prolibre
Locale: LANG=C, LC_CTYPE=fr_CH (charmap=ISO-8859-1)
Versions of packages vserver-debiantools depends on:
ii binutils 2.15-5 The GNU assembler, linker and bina
ii debootstrap 0.2.45 Bootstrap a basic Debian system
ii rsync 2.6.3-2fast remote file copy program (lik
ii util-vserver 0.30-14tools for Virtual private servers
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
