Bug#697851: nslcd: idle_timelimit is only checked at a new request, which may cause undesired delays
Thanks for the quick reply! We have indeed the timelimit option set low. Just didn't check all changelog files of the lastest version. Sorry for the noise. Durk Strooisma Scrum Master, Senior Unix/Linux System Engineer Tele2 / IT Infrastructure / Unix (formerly Datacenter) Tel. +31 (0) 20 750 1471 Cel. +31 (0) 6 2128 2452 From: Arthur de Jong adej...@debian.org To: Durk Strooisma durk.strooi...@tele2.com, 697851-d...@bugs.debian.org, Date: 2013-01-10 22:28 Subject:Re: Bug#697851: nslcd: idle_timelimit is only checked at a new request, which may cause undesired delays Version: 0.8.0 On Thu, 2013-01-10 at 13:20 +0100, Durk Strooisma wrote: It seems that the idle_timelimit setting is only checked at a new request. [snip] This is correct for the 0.7 series, in the 0.8 this is fixed. In this case the process of cleaning up the connection takes longer, because it doesn't get a response from the LDAP server, as the firewall doesn't have an open session anymore. You should be able to use the timelimit option to make the delay for timeouts shorter as a workaround. For disconnecting half the timelimit value is set to ensure faster shutdown of the connection to the LDAP server. Not an easy or nice fix would be to have a thread running all the time that checks all connections for idle_timelimit and cleans them up if needed. In 0.8.0 the worker threads wake up every idle_timelimit seconds to check if an LDAP connection needs to be closed. Thanks, -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- [attachment signature.asc deleted by Durk Strooisma/NL/Tele2] IMPORTANT NOTICE This e-mail (including any attachments) may contain information that is confidential or otherwise protected from disclosure and it is intended only for the addressees. If you are not the intended recipient, please note that any copying, distribution or other use of information contained in this e-mail (and its attachments) is not allowed. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message (including any attachments) from your system. Please note that e-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be subject of unauthorized interception or other interference without the knowledge of sender or recipient. Tele2 only send and receive e-mails on the basis that Tele2 is not responsible for any such computer viruses, corruption or other interference or any consequences thereof.
Bug#697851: nslcd: idle_timelimit is only checked at a new request, which may cause undesired delays
Package: nslcd Version: 0.7.15+squeeze2 Severity: normal Tags: upstream It seems that the idle_timelimit setting is only checked at a new request. Let's say there's a firewall between the client with nslcd and the LDAP server. The session timeout on the firewallis 1800 seconds and idle_timelimit is set to 1500. The latter seems a reasonable setting; timeouting LDAP connections before the firewall will. Because the idle_timelimit setting is only checked at a new request, it can happen that the LDAP connection lives longer than 1800 seconds before killed by nslcd. In the meanwhile the firewall has removed the session. Then, if a new request enters nslcd and gets that LDAP connection assigned, it notices that it's expired and tries to properly clean up the connection. In this case the process of cleaning up the connection takes longer, because it doesn't get a response from the LDAP server, as the firewall doesn't have an open session anymore. For servers using nslcd that are not used frequently it's a bit annoying to have slow logins etc. I'm not sure what the best solution is. Not an easy or nice fix would be to have a thread running all the time that checks all connections for idle_timelimit and cleans them up if needed. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/3 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 nslcd depends on: ii adduser 3.112+nmu2 add and remove users and groups ii debconf [debconf-2. 1.5.36.1 Debian configuration management sy ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libgssapi-krb5-21.8.3+dfsg-4squeeze6 MIT Kerberos runtime libraries - k ii libldap-2.4-2 2.4.23-7.2 OpenLDAP libraries Versions of packages nslcd recommends: ii libnss-ldapd [libnss-lda 0.7.15+squeeze2 NSS module for using LDAP as a nam ii libpam-krb5 4.3-1 PAM module for MIT Kerberos ii libpam-ldapd [libpam-lda 0.7.15+squeeze2 PAM module for using LDAP as an au ii unscd [nscd] 0.47-2 Micro Name Service Caching Daemon Versions of packages nslcd suggests: ii kstart3.16-3 Kerberos kinit supporting AFS and -- Configuration Files: /etc/default/nslcd changed [not included] -- 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#621122: viewvc: as text links in log displayed for binaries instead of text files
Package: viewvc Version: 1.1.5-1.1 Severity: normal The as text links are displayed in the ViewVC log pages in wrong circumstances. They ARE displayed for binary files and are NOT displayed for plain text files. That is exactly the other way around as it should be. I just did a quick view in /usr/lib/viewvc/lib/viewvc.py and found out there's a negation error on line 1049: if not is_plain_text(mime_type): download_text_href = request.get_url(view_func=view_checkout, The not should not be there. -- System Information: Debian Release: 6.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (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/dash Versions of packages viewvc depends on: ii python 2.6.6-3+squeeze5 interactive high-level object-orie ii python-subversion 1.6.12dfsg-5 Python bindings for Subversion ii python-support 1.0.10 automated rebuilding support for P ii rcs 5.7-25 The GNU Revision Control System ii subversion 1.6.12dfsg-5 Advanced version control system Versions of packages viewvc recommends: ii apache2 2.2.16-6 Apache HTTP Server metapackage ii apache2-mpm-worker [httpd-cgi 2.2.16-6 Apache HTTP Server - high speed th pn python-pygments none (no description available) Versions of packages viewvc suggests: pn cvsgraph none (no description available) pn libapache2-mod-python none (no description available) ii mime-support 3.48-1 MIME files 'mime.types' 'mailcap pn python-tk none (no description available) pn viewvc-query none (no description available) -- Configuration Files: /etc/viewvc/viewvc.conf changed [not included] -- 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#612413: openssh-server: Kerberos cred cache not cleaned up after failed authorisation by PAM
Package: openssh-server Version: 1:5.5p1-6 Severity: normal Normally the Kerberos credential cache is cleaned up after a user logs out and the SSH session closes. My assumption is that this behaviour is caused by the settings in /etc/ssh/sshd_config below: KerberosTicketCleanup yes GSSAPICleanupCredentials yes However, I found a case in which the credential cache is NOT cleaned up. This happens when a user successfully authenticates with Kerberos/GSSAPI, but authorisation fails while processing PAM account settings. This is what happens on the client: $ ssh user@host user@host's password: LDAP authorisation check failed Connection closed by 10.0.10.10 On the server you'll see a credential cache file that has been created: # ls -l /tmp/*1400400* -rw--- 1 user user 507 Feb 8 10:40 krb5cc_1400400_wGxWcnG143 But it will never be removed... Conclusion: clean up of credential caches works, but not in case PAM account fails. I don't know whether this is an upstream issue. I couldn't find any configuration settings I'm missing. My guess is that sshd doesn't know about the failed authorisation by PAM and thus doesn't invoke the clean up process. Remember that the authentication that happens on SSH-level WAS successful, which might sshd letting think that it's a successful login, so no clean up needed. Thanks for looking at this issue. -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (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/dash Versions of packages openssh-server depends on: ii adduser 3.112+nmu2 add and remove users and groups ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii dpkg1.15.8.9 Debian package management system ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-2common error description library ii libgssapi-krb5-21.8.3+dfsg-4 MIT Kerberos runtime libraries - k ii libkrb5-3 1.8.3+dfsg-4 MIT Kerberos runtime libraries ii libpam-modules 1.1.1-6.1Pluggable Authentication Modules f ii libpam-runtime 1.1.1-6.1Runtime support for the PAM librar ii libpam0g1.1.1-6.1Pluggable Authentication Modules l ii libselinux1 2.0.96-1 SELinux runtime shared libraries ii libssl0.9.8 0.9.8o-4 SSL shared libraries ii libwrap07.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii openssh-blacklist 0.4.1list of default blacklisted OpenSS ii openssh-client 1:5.5p1-6secure shell (SSH) client, for sec ii procps 1:3.2.8-9/proc file system utilities ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages openssh-server recommends: pn openssh-blacklist-extra none (no description available) pn xauth none (no description available) Versions of packages openssh-server suggests: pn molly-guard none (no description available) pn rssh none (no description available) pn ssh-askpass none (no description available) pn ufw none (no description available) -- debconf information: * ssh/use_old_init_script: true ssh/vulnerable_host_keys: ssh/encrypted_host_key_but_no_keygen: ssh/disable_cr_auth: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504027: postfix: Some chroot issues in init.d script (+ patch)
Patch update concerning the creation of the chroot:
1. Made copying of files other than regular files possible, this
is useful for links and files like /dev/urandom. Directories are
still skipped.
2. Made sure that the postfix user is able to read files in the chroot
that are not group readable on their original location. As the
default group ownership is postfix, I just added chmod g+r on the
chroot file.
3. If files were world-writable on their original location, make it
also writable for the postfix group in the chroot.
Durk
--- postfix-2.5.5-orig/debian/init.d 2008-10-31 13:59:26.0 +0100
+++ postfix-2.5.5/debian/init.d 2008-12-12 11:45:58.0 +0100
@@ -25,6 +25,8 @@
# Defaults - don't touch, edit /etc/default/postfix
SYNC_CHROOT=y
+CHROOT_FILES=etc/localtime etc/services etc/resolv.conf etc/hosts \
+ etc/nsswitch.conf etc/nss_mdns.config
test -f /etc/default/postfix . /etc/default/postfix
@@ -45,6 +47,60 @@
fi
}
+update_chroot() {
+# see if anything is running chrooted.
+NEED_CHROOT=$(awk '/^[0-9a-z]/ ($5 ~ [-yY]) { print y; exit}' /etc/postfix/master.cf)
+
+if [ -n $NEED_CHROOT ] [ -n $SYNC_CHROOT ]; then
+ # Make sure that the chroot environment is set up correctly.
+ oldumask=$(umask)
+ umask 027
+ cd $(postconf -h queue_directory)
+
+ # if we're using tls, then we need to add etc/ssl/certs/ca-certificates.crt.
+ smtp_tls_security_level=$(postconf -h smtp_tls_security_level)
+ smtp_use_tls=$(postconf -h smtp_use_tls)
+ smtpd_tls_security_level=$(postconf -h smtpd_tls_security_level)
+ smtpd_use_tls=$(postconf -h smtpd_use_tls)
+ if [ X$smtp_use_tls = Xyes -o X$smtpd_use_tls = Xyes \
+ -o X$smtp_tls_security_level != X -a X$smtp_tls_security_level != Xnone \
+ -o X$smtpd_tls_security_level != X -a X$smtpd_tls_security_level != Xnone ]; then
+ if [ -f /etc/ssl/certs/ca-certificates.crt ]; then
+ mkdir -p etc/ssl/certs
+ cp /etc/ssl/certs/ca-certificates.crt etc/ssl/certs/
+ chgrp -R postfix etc
+chmod g+r etc/ssl/certs/ca-certificates.crt
+ fi
+ fi
+
+ # if we're using unix:passwd.byname, then we need to add etc/passwd.
+ local_maps=$(postconf -h local_recipient_maps)
+ if [ X$local_maps != X${local_maps#*unix:passwd.byname} ]; then
+ if [ X$local_maps = X${local_maps#*proxy:unix:passwd.byname} ]; then
+ sed 's/^\([^:]*\):[^:]*/\1:x/' /etc/passwd etc/passwd
+ chgrp postfix etc/passwd
+ fi
+ fi
+
+ for file in $CHROOT_FILES; do
+ if [ ! -d ${file%/*} ]; then mkdir -p ${file%/*} chgrp -R postfix ${file%%/*}; fi
+ if [ -e /${file} ] [ ! -d ${file} ]; then rm -f ${file} cp -r /${file} ${file}; fi
+ if [ -e ${file} ] [ ! -L ${file} ]; then
+ chgrp postfix ${file}
+ chmod g+rX ${file}
+ if ( stat -c%A /${file} | grep -q 'w.$' ) ; then chmod g+w ${file} ; fi
+ fi
+ done
+ rm -f usr/lib/zoneinfo/localtime
+ mkdir -p usr/lib/zoneinfo
+ ln -sf /etc/localtime usr/lib/zoneinfo/localtime
+ rm -f lib/libnss_*so*
+ tar cf - /lib/libnss_*so* 2/dev/null |tar xf -
+ umask $oldumask
+fi
+}
+
+
case $1 in
start)
log_daemon_msg Starting Postfix Mail Transport Agent postfix
@@ -65,48 +121,7 @@
exit 1
fi
- # see if anything is running chrooted.
- NEED_CHROOT=$(awk '/^[0-9a-z]/ ($5 ~ [-yY]) { print y; exit}' /etc/postfix/master.cf)
-
- if [ -n $NEED_CHROOT ] [ -n $SYNC_CHROOT ]; then
- # Make sure that the chroot environment is set up correctly.
- oldumask=$(umask)
- umask 022
- cd $(postconf -h queue_directory)
-
- # if we're using tls, then we need to add etc/ssl/certs/ca-certificates.crt.
- smtp_use_tls=$(postconf -h smtp_use_tls)
- smtpd_use_tls=$(postconf -h smtpd_use_tls)
- if [ X$smtp_use_tls = Xyes -o X$smtpd_use_tls = Xyes ]; then
- if [ -f /etc/ssl/certs/ca-certificates.crt ]; then
- mkdir -p etc/ssl/certs
- cp /etc/ssl/certs/ca-certificates.crt etc/ssl/certs/
- fi
- fi
-
- # if we're using unix:passwd.byname, then we need to add etc/passwd.
- local_maps=$(postconf -h local_recipient_maps)
- if [ X$local_maps != X${local_maps#*unix:passwd.byname} ]; then
- if [ X$local_maps = X${local_maps#*proxy:unix:passwd.byname} ]; then
- sed 's/^\([^:]*\):[^:]*/\1:x/' /etc/passwd etc/passwd
- chmod a+r etc/passwd
- fi
- fi
-
- FILES=etc/localtime etc/services etc/resolv.conf etc/hosts \
- etc/nsswitch.conf etc/nss_mdns.config
- for file in $FILES; do
- [ -d ${file%/*} ] || mkdir -p ${file%/*}
- if [ -f /${file} ]; then rm -f ${file} cp /${file} ${file}; fi
- if [ -f ${file} ]; then chmod a+rX ${file}; fi
- done
- rm -f usr/lib/zoneinfo/localtime
- mkdir -p usr/lib/zoneinfo
- ln -sf /etc/localtime usr/lib/zoneinfo/localtime
- rm -f lib/libnss_*so*
- tar cf - /lib/libnss_*so* 2/dev/null |tar xf -
- umask $oldumask
- fi
+ update_chroot
if start-stop-daemon --start --exec ${DAEMON} -- quiet-quick-start; then
log_end_msg 0
@@ -159,8 +174,14 @@
${DAEMON} $1
;;
Bug#363524: Additional information + testpackages
Hi, I encountered the same issue; the unnecessary question for overwriting a conffile that does not exist anymore, because it's already diverted. But in contrast to the original bug poster, removing the package in question wasn't a problem, unless the dpkg-divert removal statement in put in the right postrm target. Another observation is that if the overwriting package has the new configuration file not marked as conffile, no question is asked (as it should be). I created some test packages (all attached) to demonstrate the issue. test-pkg-c -- Installs /etc/test-pkg-c/config-file as conffile. test-pkg-d -- Diverts /etc/test-pkg-c/config-file to /etc/test-pkg-c/config-file.diverted and installs a different /etc/test-pkg-c/config-file (also) as conffile. test-pkg-e -- Diverts /etc/test-pkg-c/config-file to /etc/test-pkg-c/config-file.diverted and installs a different /etc/test-pkg-c/config-file, but not marking it as conffile. Demonstration - First we install test-pkg-c: # dpkg -i test-pkg-c_0.1_all.deb Selecting previously deselected package test-pkg-c. (Reading database ... 15719 files and directories currently installed.) Unpacking test-pkg-c (from test-pkg-c_0.1_all.deb) ... Setting up test-pkg-c (0.1) ... # ls -l /etc/test-pkg-c total 4 -rw-r--r-- 1 root root 9 2008-12-10 11:04 config-file Okay, everything seems fine. Next, test-pkg-e: # dpkg -i test-pkg-e_0.1_all.deb Selecting previously deselected package test-pkg-e. (Reading database ... 15724 files and directories currently installed.) Unpacking test-pkg-e (from test-pkg-e_0.1_all.deb) ... Adding `diversion of /etc/test-pkg-c/config-file to /etc/test-pkg-c/config-file.diverted by test-pkg-e' Setting up test-pkg-e (0.1) ... # ls -l /etc/test-pkg-c total 8 -rw-r--r-- 1 root root 19 2008-12-10 11:35 config-file -rw-r--r-- 1 root root 9 2008-12-10 11:04 config-file.diverted # dpkg-divert --list /etc/test-pkg-c/config-file diversion of /etc/test-pkg-c/config-file to /etc/test-pkg-c/config-file.diverted by test-pkg-e Okay, seems fine. As said before, if the overwriting file is not marked as conffile, no question is asked. Let's remove/purge test-pkg-e: # dpkg -P test-pkg-e (Reading database ... 15727 files and directories currently installed.) Removing test-pkg-e ... Removing `diversion of /etc/test-pkg-c/config-file to /etc/test-pkg-c/config-file.diverted by test-pkg-e' Purging configuration files for test-pkg-e ... # ls -l /etc/test-pkg-c total 4 -rw-r--r-- 1 root root 9 2008-12-10 11:04 config-file # dpkg-divert --list /etc/test-pkg-c/config-file # Okay, package was nicely removed, nothing left and original file restored. Now we're going to install test-pkg-d: # dpkg -i test-pkg-d_0.1_all.deb Selecting previously deselected package test-pkg-d. (Reading database ... 15724 files and directories currently installed.) Unpacking test-pkg-d (from test-pkg-d_0.1_all.deb) ... Adding `diversion of /etc/test-pkg-c/config-file to /etc/test-pkg-c/config-file.diverted by test-pkg-d' Setting up test-pkg-d (0.1) ... Configuration file `/etc/test-pkg-c/config-file' == Deleted (by you or by a script) since installation. == Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** config-file (Y/I/N/O/D/Z) [default=N] ? Y Installing new version of config file /etc/test-pkg-c/config-file ... # ls -l /etc/test-pkg-c total 8 -rw-r--r-- 1 root root 13 2008-12-10 11:07 config-file -rw-r--r-- 1 root root 9 2008-12-10 11:04 config-file.diverted # dpkg-divert --list /etc/test-pkg-c/config-file diversion of /etc/test-pkg-c/config-file to /etc/test-pkg-c/config-file.diverted by test-pkg-d Everything went alright, but as said before the question is pointless here. Even more strange: if chosen to do a diff (D), dpkg diffs the new file against an empty file, which doesn't make sense. Chosing N instead of Y will leave an inconsistent system, we will demonstrate this later, first we need to remove/purge test-pkg-d: # dpkg -P test-pkg-d (Reading database ... 15727 files and directories currently installed.) Removing test-pkg-d ... Purging configuration files for test-pkg-d ... Removing `diversion of /etc/test-pkg-c/config-file to /etc/test-pkg-c/config-file.diverted by test-pkg-d' # ls -l /etc/test-pkg-c total 4 -rw-r--r-- 1 root root 9 2008-12-10 11:04 config-file # dpkg-divert --list /etc/test-pkg-c/config-file # Okay, package was nicely removed, nothing left and original file restored. Now we're going to install test-pkg-d and answer N: # dpkg -i test-pkg-d_0.1_all.deb Selecting previously deselected package test-pkg-d. (Reading database ... 15724 files and directories
Bug#504027: postfix: Some chroot issues in init.d script (+ patch)
Update:
I found another issue:
5. Files copied by the init.d script will be world-readable, sometimes
in contrast to the original files.
This a problem for some files that people might want to add to the
chroot, like /etc/sasldb, which has clear-text passwords.
In my updated patch I changed the umask to 027 to prevent files from
being created as world-readable and made them in stead group-readable
by the postfix user. I think this is open enough. Please correct me
if I'm wrong.
I updated the previous patch to resolve this issue
(init.d-chroot-new.patch). All the comments in the original bug post still
apply.
--- postfix-2.5.5-orig/debian/init.d 2008-10-31 13:59:26.0 +0100
+++ postfix-2.5.5/debian/init.d 2008-10-31 14:01:08.0 +0100
@@ -25,6 +25,8 @@
# Defaults - don't touch, edit /etc/default/postfix
SYNC_CHROOT=y
+CHROOT_FILES=etc/localtime etc/services etc/resolv.conf etc/hosts \
+ etc/nsswitch.conf etc/nss_mdns.config
test -f /etc/default/postfix . /etc/default/postfix
@@ -45,6 +47,55 @@
fi
}
+update_chroot() {
+# see if anything is running chrooted.
+NEED_CHROOT=$(awk '/^[0-9a-z]/ ($5 ~ [-yY]) { print y; exit}' /etc/postfix/master.cf)
+
+if [ -n $NEED_CHROOT ] [ -n $SYNC_CHROOT ]; then
+ # Make sure that the chroot environment is set up correctly.
+ oldumask=$(umask)
+ umask 027
+ cd $(postconf -h queue_directory)
+
+ # if we're using tls, then we need to add etc/ssl/certs/ca-certificates.crt.
+ smtp_tls_security_level=$(postconf -h smtp_tls_security_level)
+ smtp_use_tls=$(postconf -h smtp_use_tls)
+ smtpd_tls_security_level=$(postconf -h smtpd_tls_security_level)
+ smtpd_use_tls=$(postconf -h smtpd_use_tls)
+ if [ X$smtp_use_tls = Xyes -o X$smtpd_use_tls = Xyes \
+ -o X$smtp_tls_security_level != X -a X$smtp_tls_security_level != Xnone \
+ -o X$smtpd_tls_security_level != X -a X$smtpd_tls_security_level != Xnone ]; then
+ if [ -f /etc/ssl/certs/ca-certificates.crt ]; then
+ mkdir -p etc/ssl/certs
+ cp /etc/ssl/certs/ca-certificates.crt etc/ssl/certs/
+ chgrp postfix etc/ssl/certs/ca-certificates.crt
+ fi
+ fi
+
+ # if we're using unix:passwd.byname, then we need to add etc/passwd.
+ local_maps=$(postconf -h local_recipient_maps)
+ if [ X$local_maps != X${local_maps#*unix:passwd.byname} ]; then
+ if [ X$local_maps = X${local_maps#*proxy:unix:passwd.byname} ]; then
+ sed 's/^\([^:]*\):[^:]*/\1:x/' /etc/passwd etc/passwd
+ chgrp postfix etc/passwd
+ fi
+ fi
+
+ for file in $CHROOT_FILES; do
+ [ -d ${file%/*} ] || mkdir -p ${file%/*}
+ if [ -f /${file} ]; then rm -f ${file} cp /${file} ${file}; fi
+ if [ -f ${file} ]; then chgrp postfix ${file}; fi
+ done
+ rm -f usr/lib/zoneinfo/localtime
+ mkdir -p usr/lib/zoneinfo
+ ln -sf /etc/localtime usr/lib/zoneinfo/localtime
+ rm -f lib/libnss_*so*
+ tar cf - /lib/libnss_*so* 2/dev/null |tar xf -
+ umask $oldumask
+fi
+}
+
+
case $1 in
start)
log_daemon_msg Starting Postfix Mail Transport Agent postfix
@@ -65,48 +116,7 @@
exit 1
fi
- # see if anything is running chrooted.
- NEED_CHROOT=$(awk '/^[0-9a-z]/ ($5 ~ [-yY]) { print y; exit}' /etc/postfix/master.cf)
-
- if [ -n $NEED_CHROOT ] [ -n $SYNC_CHROOT ]; then
- # Make sure that the chroot environment is set up correctly.
- oldumask=$(umask)
- umask 022
- cd $(postconf -h queue_directory)
-
- # if we're using tls, then we need to add etc/ssl/certs/ca-certificates.crt.
- smtp_use_tls=$(postconf -h smtp_use_tls)
- smtpd_use_tls=$(postconf -h smtpd_use_tls)
- if [ X$smtp_use_tls = Xyes -o X$smtpd_use_tls = Xyes ]; then
- if [ -f /etc/ssl/certs/ca-certificates.crt ]; then
- mkdir -p etc/ssl/certs
- cp /etc/ssl/certs/ca-certificates.crt etc/ssl/certs/
- fi
- fi
-
- # if we're using unix:passwd.byname, then we need to add etc/passwd.
- local_maps=$(postconf -h local_recipient_maps)
- if [ X$local_maps != X${local_maps#*unix:passwd.byname} ]; then
- if [ X$local_maps = X${local_maps#*proxy:unix:passwd.byname} ]; then
- sed 's/^\([^:]*\):[^:]*/\1:x/' /etc/passwd etc/passwd
- chmod a+r etc/passwd
- fi
- fi
-
- FILES=etc/localtime etc/services etc/resolv.conf etc/hosts \
- etc/nsswitch.conf etc/nss_mdns.config
- for file in $FILES; do
- [ -d ${file%/*} ] || mkdir -p ${file%/*}
- if [ -f /${file} ]; then rm -f ${file} cp /${file} ${file}; fi
- if [ -f ${file} ]; then chmod a+rX ${file}; fi
- done
- rm -f usr/lib/zoneinfo/localtime
- mkdir -p usr/lib/zoneinfo
- ln -sf /etc/localtime usr/lib/zoneinfo/localtime
- rm -f lib/libnss_*so*
- tar cf - /lib/libnss_*so* 2/dev/null |tar xf -
- umask $oldumask
- fi
+ update_chroot
if start-stop-daemon --start --exec ${DAEMON} -- quiet-quick-start; then
log_end_msg 0
@@ -159,8 +169,14 @@
${DAEMON} $1
;;
+update-chroot)
+ log_action_begin_msg Updating the Postfix chroot
+ update_chroot
+ log_action_end_msg 0
+;;
+
*)
-
Bug#504027: postfix: Some chroot issues in init.d script (+ patch)
Regarding issue 5, I forgot to take care of directories in the patch. Fixed
in the attached patch.
Sorry for the mess!
--- postfix-2.5.5-orig/debian/init.d 2008-10-31 13:59:26.0 +0100
+++ postfix-2.5.5/debian/init.d 2008-10-31 14:47:54.0 +0100
@@ -25,6 +25,8 @@
# Defaults - don't touch, edit /etc/default/postfix
SYNC_CHROOT=y
+CHROOT_FILES=etc/localtime etc/services etc/resolv.conf etc/hosts \
+ etc/nsswitch.conf etc/nss_mdns.config
test -f /etc/default/postfix . /etc/default/postfix
@@ -45,6 +47,55 @@
fi
}
+update_chroot() {
+# see if anything is running chrooted.
+NEED_CHROOT=$(awk '/^[0-9a-z]/ ($5 ~ [-yY]) { print y; exit}' /etc/postfix/master.cf)
+
+if [ -n $NEED_CHROOT ] [ -n $SYNC_CHROOT ]; then
+ # Make sure that the chroot environment is set up correctly.
+ oldumask=$(umask)
+ umask 027
+ cd $(postconf -h queue_directory)
+
+ # if we're using tls, then we need to add etc/ssl/certs/ca-certificates.crt.
+ smtp_tls_security_level=$(postconf -h smtp_tls_security_level)
+ smtp_use_tls=$(postconf -h smtp_use_tls)
+ smtpd_tls_security_level=$(postconf -h smtpd_tls_security_level)
+ smtpd_use_tls=$(postconf -h smtpd_use_tls)
+ if [ X$smtp_use_tls = Xyes -o X$smtpd_use_tls = Xyes \
+ -o X$smtp_tls_security_level != X -a X$smtp_tls_security_level != Xnone \
+ -o X$smtpd_tls_security_level != X -a X$smtpd_tls_security_level != Xnone ]; then
+ if [ -f /etc/ssl/certs/ca-certificates.crt ]; then
+ mkdir -p etc/ssl/certs
+ cp /etc/ssl/certs/ca-certificates.crt etc/ssl/certs/
+ chgrp -R postfix etc
+ fi
+ fi
+
+ # if we're using unix:passwd.byname, then we need to add etc/passwd.
+ local_maps=$(postconf -h local_recipient_maps)
+ if [ X$local_maps != X${local_maps#*unix:passwd.byname} ]; then
+ if [ X$local_maps = X${local_maps#*proxy:unix:passwd.byname} ]; then
+ sed 's/^\([^:]*\):[^:]*/\1:x/' /etc/passwd etc/passwd
+ chgrp postfix etc/passwd
+ fi
+ fi
+
+ for file in $CHROOT_FILES; do
+ if [ ! -d ${file%/*} ]; then mkdir -p ${file%/*} chgrp -R postfix ${file%%/*}; fi
+ if [ -f /${file} ]; then rm -f ${file} cp /${file} ${file}; fi
+ if [ -f ${file} ]; then chgrp postfix ${file}; fi
+ done
+ rm -f usr/lib/zoneinfo/localtime
+ mkdir -p usr/lib/zoneinfo
+ ln -sf /etc/localtime usr/lib/zoneinfo/localtime
+ rm -f lib/libnss_*so*
+ tar cf - /lib/libnss_*so* 2/dev/null |tar xf -
+ umask $oldumask
+fi
+}
+
+
case $1 in
start)
log_daemon_msg Starting Postfix Mail Transport Agent postfix
@@ -65,48 +116,7 @@
exit 1
fi
- # see if anything is running chrooted.
- NEED_CHROOT=$(awk '/^[0-9a-z]/ ($5 ~ [-yY]) { print y; exit}' /etc/postfix/master.cf)
-
- if [ -n $NEED_CHROOT ] [ -n $SYNC_CHROOT ]; then
- # Make sure that the chroot environment is set up correctly.
- oldumask=$(umask)
- umask 022
- cd $(postconf -h queue_directory)
-
- # if we're using tls, then we need to add etc/ssl/certs/ca-certificates.crt.
- smtp_use_tls=$(postconf -h smtp_use_tls)
- smtpd_use_tls=$(postconf -h smtpd_use_tls)
- if [ X$smtp_use_tls = Xyes -o X$smtpd_use_tls = Xyes ]; then
- if [ -f /etc/ssl/certs/ca-certificates.crt ]; then
- mkdir -p etc/ssl/certs
- cp /etc/ssl/certs/ca-certificates.crt etc/ssl/certs/
- fi
- fi
-
- # if we're using unix:passwd.byname, then we need to add etc/passwd.
- local_maps=$(postconf -h local_recipient_maps)
- if [ X$local_maps != X${local_maps#*unix:passwd.byname} ]; then
- if [ X$local_maps = X${local_maps#*proxy:unix:passwd.byname} ]; then
- sed 's/^\([^:]*\):[^:]*/\1:x/' /etc/passwd etc/passwd
- chmod a+r etc/passwd
- fi
- fi
-
- FILES=etc/localtime etc/services etc/resolv.conf etc/hosts \
- etc/nsswitch.conf etc/nss_mdns.config
- for file in $FILES; do
- [ -d ${file%/*} ] || mkdir -p ${file%/*}
- if [ -f /${file} ]; then rm -f ${file} cp /${file} ${file}; fi
- if [ -f ${file} ]; then chmod a+rX ${file}; fi
- done
- rm -f usr/lib/zoneinfo/localtime
- mkdir -p usr/lib/zoneinfo
- ln -sf /etc/localtime usr/lib/zoneinfo/localtime
- rm -f lib/libnss_*so*
- tar cf - /lib/libnss_*so* 2/dev/null |tar xf -
- umask $oldumask
- fi
+ update_chroot
if start-stop-daemon --start --exec ${DAEMON} -- quiet-quick-start; then
log_end_msg 0
@@ -159,8 +169,14 @@
${DAEMON} $1
;;
+update-chroot)
+ log_action_begin_msg Updating the Postfix chroot
+ update_chroot
+ log_action_end_msg 0
+;;
+
*)
- log_action_msg Usage: /etc/init.d/postfix {start|stop|restart|reload|flush|check|abort|force-reload}
+ log_action_msg Usage: /etc/init.d/postfix {start|stop|restart|reload|flush|check|abort|force-reload|update-chroot}
exit 1
;;
esac
Bug#504027: postfix: Some chroot issues in init.d script (+ patch)
Package: postfix
Version: 2.5.5-1.1
Severity: normal
Tags: patch
I found some issues in the postfix init.d script regarding the chroot
setup.
1. There are more options in Postfix besides smtp_use_tls and
smtpd_use_tls to enable TLS. In the other cases
/etc/ssl/certs/ca-certificates.crt should be copied as well.
In my patch I added checks for:
* smtp_tls_security_level
* smtpd_tls_security_level
This is probably still not perfect, because there is also
smtp_tls_per_site and smtp_tls_policy_maps. But these seem much more
difficult to check (and are probably much less used).
2. The FILES variable can't be overridden by /etc/default/postfix.
This could be a very neat way to expand the files that need to be
copied to the chroot.
In my patch I renamed the FILES variable to CHROOT_FILES and moved
it before sourcing of /etc/default/postfix.
3. There is no way to update the chroot without restarting the postfix
daemon.
I can imagine people want to avoid restarting postfix in production
environments and prefer reloading it in stead after configuration
changes. However, if a configuration change needs an extra file in
the chroot, reloading is not enough. Now, people have the choice
between manually copying the file the chroot (before reloading) or
restarting postfix (after modifying the FILES variable).
In my patch I added a third option, a new argument (update-chroot)
can be called to update the chroot. To realise this I've put all
chroot logic in a function (update_chroot()).
4. Another issue seems that files that don't have to be put in the
chroot anymore, due to configuration changes, will never get removed
from the chroot. People have to remove them manually.
This might be intentionally and I didn't try to fix it in the patch,
'cause it seems a bit complicated as not all the files in the chroot
were created by the init.d script. So you can't simply remove all
files before copying the files again.
Please review the attached patch (init.d-chroot.patch) and consider
applying it.
I saw that a patch to the init.d script in bug #433660 is still waiting
to be included. Obviously, my patch won't work if it the other one get
applied.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
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
--- postfix-2.5.5-orig/debian/init.d2008-10-30 15:51:43.0 +0100
+++ postfix-2.5.5/debian/init.d 2008-10-30 17:44:39.0 +0100
@@ -25,6 +25,8 @@
# Defaults - don't touch, edit /etc/default/postfix
SYNC_CHROOT=y
+CHROOT_FILES=etc/localtime etc/services etc/resolv.conf etc/hosts \
+ etc/nsswitch.conf etc/nss_mdns.config
test -f /etc/default/postfix . /etc/default/postfix
@@ -45,6 +47,54 @@
fi
}
+update_chroot() {
+# see if anything is running chrooted.
+NEED_CHROOT=$(awk '/^[0-9a-z]/ ($5 ~ [-yY]) { print y; exit}'
/etc/postfix/master.cf)
+
+if [ -n $NEED_CHROOT ] [ -n $SYNC_CHROOT ]; then
+ # Make sure that the chroot environment is set up correctly.
+ oldumask=$(umask)
+ umask 022
+ cd $(postconf -h queue_directory)
+
+ # if we're using tls, then we need to add
etc/ssl/certs/ca-certificates.crt.
+ smtp_tls_security_level=$(postconf -h smtp_tls_security_level)
+ smtp_use_tls=$(postconf -h smtp_use_tls)
+ smtpd_tls_security_level=$(postconf -h smtpd_tls_security_level)
+ smtpd_use_tls=$(postconf -h smtpd_use_tls)
+ if [ X$smtp_use_tls = Xyes -o X$smtpd_use_tls = Xyes \
+ -o X$smtp_tls_security_level != X -a
X$smtp_tls_security_level != Xnone \
+ -o X$smtpd_tls_security_level != X -a
X$smtpd_tls_security_level != Xnone ]; then
+ if [ -f /etc/ssl/certs/ca-certificates.crt ]; then
+ mkdir -p etc/ssl/certs
+ cp /etc/ssl/certs/ca-certificates.crt etc/ssl/certs/
+ fi
+ fi
+
+ # if we're using unix:passwd.byname, then we need to add etc/passwd.
+ local_maps=$(postconf -h local_recipient_maps)
+ if [ X$local_maps != X${local_maps#*unix:passwd.byname} ]; then
+ if [ X$local_maps = X${local_maps#*proxy:unix:passwd.byname} ];
then
+ sed 's/^\([^:]*\):[^:]*/\1:x/' /etc/passwd etc/passwd
+ chmod a+r etc/passwd
+ fi
+ fi
+
+ for file in $CHROOT_FILES; do
+ [ -d ${file%/*} ] || mkdir -p ${file%/*}
+ if [ -f /${file} ]; then rm -f ${file} cp /${file} ${file}; fi
+ if [ -f ${file} ]; then chmod a+rX ${file}; fi
+ done
+ rm -f usr/lib/zoneinfo/localtime
+ mkdir -p usr/lib/zoneinfo
+ ln -sf /etc/localtime usr/lib/zoneinfo/localtime
+ rm -f lib/libnss_*so*
+ tar cf - /lib/libnss_*so* 2/dev/null |tar xf -
+
Bug#503189: tzsetup: Preseeding timezone doesn't work as described
Package: tzsetup Version: 1:0.23 Severity: normal Hi all, I noticed that somewhere between lenny beta 2 and the latest daily builds there's a difference in how you effectivily preseed the timezone. In lenny beta 2, these lines were sufficient to set the timezone to Europe/Amsterdam while having the locale set to en_US: d-i debian-installer/locale string en_US d-i time/zone string Europe/Amsterdam Unlike the latest D-I manual states, this doesn't work in the latest daily builds anymore. The timezone will be forced to US/Eastern. To figure this out, I ran a manual (expert) installation and noticed that the timezone choices are based on the locale settings. I tried to add: d-i localechooser/shortlist select other d-i localechooser/continentlist select Europe d-i localechooser/countrylist/Europe select NL but it didn't work. During a manual (expert) install it's perfectly possible to choose English with country Netherlands, so that it is possible to choose Europe/Amsterdam as timezone. In a discussion on the debian-boot mailinglist, Christian Perrier proposed[1] to try changing the locale from en_US to en_NL. This actually works! Unlike you would expect, but desired however, the locale on the target system will be en_US.UTF-8. So, if this is the way we should preseed the timezone from now on, the D-I manual must be changed to reflect this. Durk [1] http://lists.debian.org/debian-boot/2008/10/msg00617.html -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503189: tzsetup: Preseeding timezone doesn't work as described
d-i debian-installer/locale string en_US d-i time/zone string Europe/Amsterdam What you are doing here is essentially invalid for interactive installations, and thus also for preseeded installations: you are selecting English as language and US as country, and then trying to set the time zone for NL, which is of course an invalid time zone for the US. Makes sense. That will not work as it does not match what is documented for language and country preseeding [1]. You need d-i/locale=en_NL as Christian already explained. That will automatically give you the Dutch time zone (and you don't even need to preseed it at all!). This is nice. But as Christian mentioned, there is no such locale as en_NL, which will probably keep users from specifying it. Maybe a note in the D-I manual will help, that specifying non-existing locales doesn't matter, as long as the two-letter codes are valid. In a discussion on the debian-boot mailinglist, Christian Perrier proposed[1] to try changing the locale from en_US to en_NL. This actually works! Unlike you would expect, but desired however, the locale on the target system will be en_US.UTF-8. No, that's *exactly* what you'd expect. I mean, if you specify en_NL as locale, an uninformed user would probably be surprised to see LANG set to en_US.UTF-8. Just to check if I understand correctly; so en_US is the default locale for an en_country setting that does not exist as real locale? So, if this is the way we should preseed the timezone from now on, the D-I manual must be changed to reflect this. No change needed as basically you should always have done it like this. See my comment above in this post about adding a note to the D-I manual. Would be nice that users get a bit more details. The fact that in the past an invalid timezone was accepted for the selected country could be seen as a bug. Yep, understood. Also, in the case of tzsetup I think it is probably OK to allow a bit more freedom for preseeding than for interactive installs and allow to select any time zone. The attached patch should restore the old behavior. The patch also adds a sanity check that a (preseeded) value should be valid before the target system is actually modified. Okay, great, seems reasonable. Durk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502850: debian-installer: D-I fails to process some correct (!) preseed files
I've tested the patches moderately and everything seems to work as intended. The goal of the patches sounds like a good idea. I've tested them as well, and they worked fine. I also doubt we have any real chance to fix this issue in busybox before lenny. I hope it will be fixed at least at some point of time. Busybox weirdness may have effect on other D-I parts in some situations as well. Thanks for your quick response to this issue! Durk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502850: debian-installer: D-I fails to process some correct (!) preseed files
Note that $line at that point is the three lines concatenated, minus the line continuation character. What we're now going to need is a simplified, reproducible testcase; probably just a simple script that sets a variable to a bad value and then executes the test above. Hmm I didn't exactly understand how this script should work. Is there anything I can do? Durk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502850: debian-installer: D-I fails to process some correct (!) preseed files
Package: debian-installer Version: D-I daily build October 19, 2008 Severity: normal Hi all, With some (correct) preseed files, Debian Installer fails at the Download debconf preconfiguration file step, with the message: Failed to process the preconfiguration file The installer failed to process the preconfiguration file from http://x.x.x.x/d-i/preseed/xx.di. The file may be corrupt. debconf-set-selections -c xx.di does not give any output, so that seems alright. I can work around this problem by adding a couple of extra packages to pkgsel/include in the preseed file. Suddenly the preseed file doesn't break Debian Installer! That proves even more that the original preseed file was okay. The diff is, of course, not more than the extra package definitions. Tested with VMware Server, real hardware and architecture amd64. And now the most interesting observation: using the same preseed file, the one that breaks, for i386... no error message anymore! So this problem seems to be architecture-dependent. I have had this problem for a couple of months, since at least Lenny beta 2. With the latest daily build (October 19), this is still the case, so I thought to share my experiences. The problem is easily reproducible with a specially crafted preseed file. Creating such a file is not easy, so I'll provide you one (bad.di). I also added one with the above described work-around (good.di). bad.di : http://krnl.nl/bad.di good.di : http://krnl.nl/good.di The diff is: $ diff bad.di good.di 160a161 mysql-client \ If you try to install these preseed files on amd64, bad.di will break D-I at the Download debconf preconfiguration file step and good.di will probably break later when it tries to retrieve archive information, because the network configuration won't work in all environments. For i386, D-I will break on retrieving archive information for both bad.di and good.di. Posting this bug in debian-installer, because I'm not sure which specific package this should go. Feel free to move it. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502850: debian-installer: D-I fails to process some correct (!) preseed files
On Monday 20 October 2008, Durk Strooisma wrote: With some (correct) preseed files, Debian Installer fails at the Download debconf preconfiguration file step, with the message: The file is not correct as you're using line continuation _within_ the value field. That is *only* allowed for the partition scheme as partman will ignore extra whitespace, but is not supported for other types of questions. Cheers, FJP Okay.. alright. This explanation seems different from what I've read in the D-I documentation: http://d-i.alioth.debian.org/manual/en.i386/apbs03.html A line can be split into multiple lines by appending a backslash (\) as the line continuation character. A good place to split a line is after the question name; a bad place is between type and value. Splitting up a value is not mentioned here, nor as good place, nor as bad place. I guess this should be listed as bad practise as well, to prevent this usage. Anyhow, thanks for the information! This explains the strange behaviour. Durk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502850: debian-installer: D-I fails to process some correct (!) preseed files
On Monday 20 October 2008, Durk Strooisma wrote: Splitting up a value is not mentioned here, nor as good place, nor as bad place. I guess this should be listed as bad practise as well, to prevent this usage. It also says: Put only a single space or tab between type and value: any additional whitespace will be interpreted as belonging to the value. That can be expanded to any additional whitespace inside the value is interpreted as belonging to the value. Yeah, I know and I thought it wouldn't be a problem, because APT doesn't care about lots of whitespace anyway. And as it always worked, except for a few files on amd64 (like 100:1), I didn't realise it could be totally wrong, using line continuation. Another reason your preseed file is incorrect is that you're missing a tab or space after tasksel tasksel/first multiselect. An empty value is allowed, but you still need the separator between the type and the value. It may well be that that is the real cause for the error. Hmm that wasn't careful of me. I fixed it, but it didn't help. Anyhow, it wouldn't have explained why it IS working on i386. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492222: dpkg: Renaming doesn't work in a particular case when diverting a conffile in preinst
Package: dpkg Version: 1.15.0 Severity: normal This is the case: -- Package B depends on package A and package B does a diversion (in preinst with --rename) of a conffile in package A and installs a file on the orginal location. We're going to install package B. The resulting issue: -- It turns out that the original conffile of package A isn't renamed. In contrast to that, ordinary files WILL be. The cause: -- During the install process (after unpack), conffiles have temporarily a .dpkg-new suffix. If, on that particular moment, a preinst from a different package tries to divert (and rename) a conffile, it cannot rename the file, because it cannot find it on the original location (without .dpkg-new). Tested on: -- Lenny with dpkg 1.15.0 (git HEAD of 2008-07-24). Test packages: -- I've attached test packages that demonstrate the issue. test-pkg-a (package A) and test-pkg-b (package B). Test output: -- In the demonstration test-pkg-b diverts /etc/test-pkg-a/config-file and /usr/share/test-pkg-a/ordinary-file of test-pkg-a. # apt-get install test-pkg-b Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: test-pkg-a The following NEW packages will be installed: test-pkg-a test-pkg-b 0 upgraded, 2 newly installed, 0 to remove and 2 not upgraded. Need to get 3072B of archives. After this operation, 135kB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://packages.xx..xx lenny/main test-pkg-a 0.1 [1314B] Get:2 http://packages.xx..xx lenny/main test-pkg-b 0.1 [1758B] Fetched 3072B in 0s (0B/s) Selecting previously deselected package test-pkg-a. (Reading database ... 17350 files and directories currently installed.) Unpacking test-pkg-a (from .../test-pkg-a_0.1_all.deb) ... Selecting previously deselected package test-pkg-b. Unpacking test-pkg-b (from .../test-pkg-b_0.1_all.deb) ... Adding `diversion of /etc/test-pkg-a/config-file to /etc/test-pkg-a/config-file.diverted by test-pkg-b' Adding `diversion of /usr/share/test-pkg-a/ordinary-file to /usr/share/test-pkg-a/ordinary-file.diverted by test-pkg-b' Setting up test-pkg-a (0.1) ... Setting up test-pkg-b (0.1) ... # ls -l /usr/share/test-pkg-a total 12 -rw-r--r-- 1 root root 9 2008-07-24 14:25 another-file -rw-r--r-- 1 root root 9 2008-07-24 15:01 ordinary-file -rw-r--r-- 1 root root 9 2008-07-24 14:24 ordinary-file.diverted # ls -l /usr/share/test-pkg-b total 4 -rw-r--r-- 1 root root 9 2008-07-24 15:09 another-file # ls -l /etc/test-pkg-a/ total 4 -rw-r--r-- 1 root root 9 2008-07-24 15:01 config-file # As you see, ordinary-file is renamed, config-file is not. -- I know diverting of conffiles isn't a supported feature by Debian, but it would be great if this issue would be fixed though. Durk -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-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 dpkg depends on: ii coreutils 6.10-6 The GNU core utilities ii libc6 2.7-10 GNU C Library: Shared libraries dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.14+b1 Advanced front-end for dpkg pn lzma none (no description available) -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492222: More info
Forgot to mention: Work-around: -- To work-around the issue, package A has to be listed as Pre-Depends in stead of a normal Depends. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492222: Files attached
Here are the test packages. test-pkg-a_0.1_all.deb Description: application/deb test-pkg-a_0.1.dsc Description: Binary data test-pkg-a_0.1.tar.gz Description: GNU Zip compressed data test-pkg-b_0.1_all.deb Description: application/deb test-pkg-b_0.1.dsc Description: Binary data test-pkg-b_0.1.tar.gz Description: GNU Zip compressed data
Bug#486816: openafs-client: Weak detection of openafs module by init.d script
I agree that this is a problem, but unfortunately there's no good way to fix it without creating other, more serious problems. dpkg and apt don't enforce installation order without Depends, but having openafs-client Depend on the module breaks anyone who builds the module themselves rather than as a package and also makes openafs-client uninstallable until one has built the module (even to look at the documentation which points one at the right package to build the module). Also, at a Policy level, openafs-client can't Depend on the module package since it's not in Debian proper because it's not built automatically. I fully agree, the problem shouldn't be fixed with a Depends-construction. However, one thing that we can do is have the init script exit with a 0 status if run when there's no module available. Exactly, just like the current check on file system level. It does an exit 0 just like you said. There only needs to be an extra check on registration of the openafs module (I guess this info is in modules.dep). If that check fails, the OpenAFS Client shouldn't be started, but the script should exit with 0 as well. It still doesn't get OpenAFS started properly in this particular case if the kernel module is installed after openafs-client, but it at least prevents dpkg from failing and makes the end state less confusing. Yep, I agree, openafs-client can't help the module is installed later. Durk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486816: openafs-client: Weak detection of openafs module by init.d script
Package: openafs-client Version: 1.4.7.dfsg1-2 Severity: normal The OpenAFS Client is only started if the Linux openafs module exists. This check is not strong enough (see below). Besides checking for existence of the kernel module on file system level, the init.d script should check whether the module is registered. What happens if someone has built the openafs-modules-source, has put the resulting binary package in a local repository and tries to install the package together with openafs-client, is that the installation will fail (apt fails actually). The trouble is that registration of the openafs module happens after starting the OpenAFS Client. See below for an example: # apt-get install openafs-modules2 openafs-client Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting openafs-modules-2.6.24-1-686 instead of openafs-modules2 Suggested packages: openafs-doc Recommended packages: openafs-modules-source openafs-modules2 lsof The following NEW packages will be installed: openafs-client openafs-modules-2.6.24-1-686 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/3164kB of archives. After this operation, 6988kB of additional disk space will be used. Preconfiguring packages ... Selecting previously deselected package openafs-client. (Reading database ... 12583 files and directories currently installed.) Unpacking openafs-client (from .../openafs-client_1.4.7.dfsg1-2_i386.deb) ... Selecting previously deselected package openafs-modules-2.6.24-1-686. Unpacking openafs-modules-2.6.24-1-686 (from .../openafs-modules-2.6.24-1-686_1.4.7.dfsg1-2+2.6.24-7_i386.deb) ... Processing triggers for man-db ... Setting up openafs-client (1.4.7.dfsg1-2) ... Starting AFS services:FATAL: Module openafs not found. Failed to load AFS kernel module, not starting AFS invoke-rc.d: initscript openafs-client, action start failed. dpkg: error processing openafs-client (--configure): subprocess post-installation script returned error exit status 1 Setting up openafs-modules-2.6.24-1-686 (1.4.7.dfsg1-2+2.6.24-7) ... Errors were encountered while processing: openafs-client E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-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 openafs-client depends on: ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii libc6 2.7-10 GNU C Library: Shared libraries ii libncurses5 5.6+20080308-1 Shared libraries for terminal hand Versions of packages openafs-client recommends: pn lsof none (no description available) ii openafs-modules-2 1.4.7.dfsg1-2+2.6.24-7 AFS distributed filesystem kernel -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482069: adduser: If uid 999 exists, next system uid will be between 0-99
if first_avail_uid returns -1 (which is indicating that in the range FIRST_SYS_UID and LAST_SYS_UID there was no free uid), adduser will stop. I don't see any overflow which causes adduser to start at uid 0 again. Please correct me if I'm wrong, but I don't get the problem. Hi, I didn't check the code, but while trying to reproduce my described problem, I couldn't and saw that I made a terrible mistake. I invoked useradd in stead of adduser.. :-( Adduser IS working the way you would expect. Sorry for the noise. Bug can be closed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482069: adduser: If uid 999 exists, next system uid will be between 0-99
Package: adduser Version: 3.107 Severity: normal If, for whatever reason, there's a system user having uid 999, adduser will look for a uid starting from 0 when a new system user is created. In most cases it will find a free uid between 0-99, which is allocated by the Debian project and for that reason not desirable. In stead of what seems to happen in reality, I would expect that adduser would try to look for a free system uid starting from 100 in stead of 0. It seems to ignore the value of FIRST_SYSTEM_UID in this process. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-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 adduser depends on: ii debconf [debconf-2.0] 1.5.21 Debian configuration management sy ii passwd1:4.1.1-1 change and administer password and ii perl-base 5.10.0-10 The Pathologically Eclectic Rubbis adduser recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476524: debian-installer: DI Manual Bug: the use of killall.sh as described kills itself
Hmm but killall.sh doesn't use pidof... Well I'm not sure if my problem is clear, but correct me if I'm wrong. Anyway, to clarify: killall.sh works perfectly, but people should not use it with an argument; specially not with dhclient as argument. Using an argument with killall.sh is stated in the DI Manual and definately wrong usage. So it's a bug in the manual, not in killall.sh. I guess it's even expected behaviour of killall.sh. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476524: debian-installer: DI Manual Bug: the use of killall.sh as described kills itself
Package: debian-installer Severity: normal From the latest version of the Debian Installer Manual, B.4.2.: --- killall.sh dhclient netcfg --- If this code is used, killall.sh will return exit code 143 because it kills itself. killall.sh looks for DHCP client processes like dhclient. In this case it will find its own process as well, because dhclient is part of the killall.sh command. And so it kills itself in additions to the running DHCP clients. Although it might work in a script triggered by preseed/run anyhow, it is not desired behaviour. In addition to that using killall.sh dhclient ; netcfg as preseed/early_command makes the early_command fail by the exit code. Because the dhclient argument used with killall.sh is totally unnecessary - unused by the script - I would suggest replacing the line killall.sh dhclient in the manual by just killall.sh. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-4-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#448760: openafs-client: vos dump segfaults if output file name is longer than 104 characters
Package: openafs-client Version: 1.3.81-3sarge2 Severity: important vos dump segfaults on dumping a backup volume if the output file name is longer than 104 characters. The command was run locally on an OpenAFS server using Debian 3.1 sarge. I know sarge is no longer a current release, but upgrading to or setting up a test server using etch, lenny or sid isn't that easy. If in etch, lenny or sid the segfault is gone, this report will probably remain as merely an informational report. 104 characters-long file name works: filesrv:~# vos dump -id svn.backup -localauth -time 0 -file abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz01234 Dumped volume svn.backup in file abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz01234 filesrv:~# 105 characters-long file name segfaults: filesrv:~# vos dump -id svn.backup -localauth -time 0 -file abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz012345 Dumped volume svn.backup in file abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz012345 Segmentation fault filesrv:~# Even though vos dump segfaults, the file is written and is even bit-for-bit identical to the 104 characters test. So it seems workable, but not really reliable. Durk -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages openafs-client depends on: ii debconf1.4.30.13 Debian configuration management sy ii libc6 2.3.2.ds1-22sarge6GNU C Library: Shared libraries an ii libncurses 5.4-4 Shared libraries for terminal hand ii openafs-mo 1.3.81-3sarge1+2.6.8-16sarge1 The AFS distributed filesystem- Ke ii openafs-mo 1.3.81-3sarge2+2.6.8-16sarge7 The AFS distributed filesystem- Ke ii openafs-mo 1.3.81-3sarge2The AFS distributed filesystem- Mo -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445265: w3c-markup-validator: https checking is not allowed because of missing dependency (libcrypt-ssleay-perl)
Package: w3c-markup-validator Version: 0.7.4-4 Severity: normal Hi, The W3C Markup Validator installed by this package doesn't accept HTTPS URLs out-of-the-box (invalid scheme), even though the default configuration file (/etc/w3c/validator.conf) contains: Protocols Allow = data,http,https /Protocols The package libcrypt-ssleay-perl has to be installed to make the validator accept HTTPS URLs. I think there are two options for a solution: 1. Add libcrypt-ssleay-perl as dependency of w3c-markup-validator or 2. remove https as allowed protocol in the default configuration file (/etc/w3c/validator.conf) and add libcrypt-ssleay-perl as recommended package. Regards, Durk -- 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-5-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages w3c-markup-validator depends on: ii apache22.2.3-4+etch1 Next generation, scalable, extenda ii apache2-mpm-worker [httpd] 2.2.3-4+etch1 High speed threaded model for Apac ii debconf [debconf-2.0] 1.5.11Debian configuration management sy ii libconfig-general-perl 2.31-3Generic Configuration Module ii libhtml-parser-perl3.55-1A collection of modules that parse ii libhtml-template-perl 2.8-1 HTML::Template : A module for usin ii libnet-ip-perl 1.25-2Perl extension for manipulating IP ii libset-intspan-perl1.07-3.1 Manages sets of integers ii libtext-iconv-perl 1.4-3 converts between character sets in ii liburi-perl1.35-2Manipulates and accesses URI strin ii libwww-perl5.805-1 WWW client/server library for Perl ii opensp 1.5.2-3 OpenJade group's SGML parsing tool ii perl 5.8.8-7 Larry Wall's Practical Extraction ii sgml-data 2.0.3 common SGML and XML data ii w3c-dtd-xhtml 1.1-5 W3C eXtensible HyperText Markup La ii w3c-linkchecker4.3-1 W3C Link Checker ii wwwconfig-common 0.0.48Debian web auto configuration Versions of packages w3c-markup-validator recommends: pn w3-dtd-mathml none (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368175: Seems like the problem's still there
Hi, Yesterday I upgraded my etch install. The vim packages got upgraded from version 7.0-122+1 to 1:7.0-122+1etch2. Unfortunately I lost my manual settings. Before the upgrade the editor alternative was forced to /usr/bin/vim.basic, but after the upgrade the alternative was set to auto (which implies nano). To prove: Preparing to replace vim 1:7.0-122+1 (using .../vim_1%3a7.0-122+1etch2_i386.deb) ... Removing manually selected alternative - switching to auto mode Unpacking replacement vim ... So it seems that this bug is not fully resolved yet. Durk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413505: debian-installer: Preseeding only one partition results in a logical partition
Package: debian-installer
Version: etch-20070228
Severity: normal
If you preseed only one partition on a disk for the whole
installation it's always getting logical, whatever you do.
The following preseed data will exhibit this behaviour:
d-i partman-auto/disk string/dev/discs/disc0/disc
d-i partman-auto/method stringregular
d-i partman-auto/purge_lvm_from_deviceboolean true
d-i partman-lvm/confirm boolean true
d-i partman-auto/expert_recipestring \
boot-root ::\
800 10 10 ext3 \
$primary{ } \
method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 }\
mountpoint{ / } \
.
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition selectFinish partitioning and
write changes to disk
d-i partman/confirm boolean true
As you see, it's marked as primary, but it will end up
being logical...
I did some other tests using more partitions and it seemed
that the last defined partition in a set always becomes
logical. In my single partition setup the first partition
is also the last partition, so I think that makes it
logical.
In my opinion, partitions should only be forced being
logical when there are more than four primary partitions
defined. In that case, every primary partition that preceeds
three other primary partitions should be made logical.
If the above was reality, my single partition would be kept
primary. Although the system is working with a single logical
partition, it's not what you're expecting and therefor I
consider it as a bug.
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413505: Preseeding only one partition results in a logical partition
I did a check in the partman bug reports - what I should have done before - and it seems like it's the same issue as bug 353257. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357054: Opening a second document often crashes kpdf
Package: kpdf Version: 4:3.3.2-2sarge3 Severity: important When opening a new document if there's already a document loaded, kpdf crashes often. Best way to reproduce the crash: - Start kpdf - Open a PDF file using the GUI controls - Scroll a couple of pages down in the main view as well as the thumbnails and click a little in the page (yes, this really helps reproducing the bug!) - Open another PDF file using the GUI controls - At this moment kpdf crashes most of the times without showing any of the contents. The crashes don't seem to be related to specific PDF files. This behaviour is reproducible on two different Debian 3.1 systems. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages kpdf depends on: ii kdelibs4 4:3.3.2-6.4KDE core libraries ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-6sarge1 client library to control the FAM ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc1 1:3.4.3-13 GCC support library ii libice6 6.9.0.dfsg.1-3bpo1 Inter-Client Exchange library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libpaper1 1.1.14-3 Library for handling paper charact ii libpng12-01.2.8rel-1 PNG library - runtime ii libqt3c102-mt 3:3.3.4-3 Qt GUI Library (Threaded runtime v ii libsm66.9.0.dfsg.1-3bpo1 X Window System Session Management ii libstdc++51:3.3.5-13 The GNU Standard C++ Library v3 ii libx11-6 6.9.0.dfsg.1-3bpo1 X Window System protocol client li ii libxext6 6.9.0.dfsg.1-3bpo1 X Window System miscellaneous exte ii libxrender1 1:0.9.0.2-0bpo1X Rendering Extension client libra ii xlibs 6.9.0.dfsg.1-3bpo1 X Window System client libraries m 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#168170: heimdal-clients: I also prefer /usr/bin
Package: heimdal-clients Version: 0.6.3-10sarge1 Followup-For: Bug #168170 I would like to see kadmin and the like in /usr/bin as well. I don't know what the definition for sbin is in linux, but most other systems has it as administration utilities (or similar). Well, let's take an excerpt from the FHS: /usr/sbin : Non-essential standard system binaries Purpose This directory contains any non-essential binaries used exclusively by the system administrator. System administration programs that are required for system repair, system recovery, mounting /usr, or other essential functions must be placed in /sbin instead. http://www.pathname.com/fhs/pub/fhs-2.3.html First of all, I'd call kadmin and the like as service administration programs rather than system administration programs. And in addition to that, I don't believe these tools are essential for fixing the local system, unless everything is consolidated to a single machine (which is very rare, I think). It would be nice if it's going to be fixed by the upstream maintainer. Durk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
