Bug#819747: KMail accepts the certificates rejected by icedove
Just for your information: I set up KMail to access the server and it works fine. So following OpenSSL s_client this is another MUA, which works nicely with my certificates.
Bug#819747: icedove: STARTTLS fails silently for no apparent reason
Package: icedove Version: 38.7.0-1~deb8u1 Severity: normal Tags: upstream Dear Maintainer, I'm running icedove for years as MUA via IMAP for my Cyrus2 mail server. Access has been encrypted using TLS on port 143 for many years. Recently, it suddenly ceased working. In the relevant time frame I updated icedove and had to renew the server certificate. I can contact the mail server using openssl s_client. And of course by falling back to plain text access. Wireshark shows that an apparently normal STARTTLS sequence is answered by icedove with "Bad Certificate", immediately. However, from UI perspective icedove seems to hang infinitely. There is no message about problems with certificates shown to the user. This at least should be considered a bug. Beyond that I cannot find any actual problems with the certificates in the chain. I am able to import both, server and CA, into icedoves certificate store. Inspecting the details of the server certificate correctly lists the CA certificate in the tree view. But still connection fails the same way. I'd expect icedove to complain about the certificates also when importing them into the store, if there is actually an issue with them. Some more information can be found at http://serverfault.com/questions/766389/thunderbird-starttls-fails-connecting-to-cyrus-imap-2-2-13 The example log using NSPR_LOG_MODULES=all:5 published there neither revealed anything useful. Kind regards, - lars. -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages icedove depends on: ii debianutils 4.4+b1 ii fontconfig2.11.0-6.3 ii libasound21.0.28-1 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-18+deb8u3 ii libcairo2 1.14.0-2.1 ii libdbus-1-3 1.8.20-0+deb8u1 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-2 ii libffi6 3.1-2+b2 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-02.31.1-2+deb8u4 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-3 ii libhunspell-1.3-0 1.3.3-3 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpixman-1-0 0.32.6-3 ii libsqlite3-0 3.8.7.1-1+deb8u1 ii libstartup-notification0 0.12-4 ii libstdc++64.9.2-10 ii libx11-6 2:1.6.2-3 ii libxcomposite11:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.1-2+b2 ii libxrender1 1:0.9.8-1+b1 ii libxt61:1.1.4-1+b1 ii psmisc22.21-2 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages icedove recommends: ii iceowl-extension38.7.0-1~deb8u1 ii myspell-de-at [myspell-dictionary] 20131206-5 ii myspell-de-ch [myspell-dictionary] 20131206-5 ii myspell-de-de [myspell-dictionary] 20131206-5 ii myspell-en-us [myspell-dictionary] 1:3.3.0-4 Versions of packages icedove suggests: ii fonts-lyx 2.1.2-2 ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u2 -- no debconf information
Bug#500778: Similar issue
I have a similar issue, but in my case the invalid mapping does not go away. I'm running Jessie with nscld to authenticate against samba4 AD and have a NAS configured as member server. To Linux clients it serves NFS4 sec=krb5p. Actually I have 2 machines, which I think are configured identically concerning nslcd, kerberos, and NFS. On one machine (fresh Jessie install) everything works perfectly. On the other machine (upgrade from wheezy) everything worked perfectly on wheezy and indeed I noticed the issue only after several days, when I first did ls -la on one of the imported drives. It looks extremely strange: drwxrwxrwx 48 nobody 42949672944096 Sep 16 21:09 . drwxr-xr-x 9 root root 4096 Nov 23 2014 .. drwxr-xr-x 38 nobody 42949672944096 Okt 23 07:16 adm drwxr-xr-x 4 nobody ad_users 4096 Okt 14 2013 admin -rw-r-xr-- 1 nobody ad_users 1219 Okt 10 2001 adsl_suse71 [...] The same directory on the other system: drwxrwxrwx 48 mgr lars4096 Sep 16 21:09 . drwxr-xr-x 9 root root4096 Nov 23 2014 .. drwxr-xr-x 38 mgr lars4096 Okt 23 07:16 adm drwxr-xr-x 4 mgr ad_users4096 Okt 14 2013 admin -rw-r-xr-- 1 mgr ad_users1219 Okt 10 2001 adsl_suse71 [...] which is the same, as I see it on the NAS. However, I can read everything, but if I create new files they're created as guest:users on the NAS, which maps to nobody:users on the machine, where everything is alright. I have a similar situation as described in this bug report during start-up. Due to trouble with k5start, nslcd is not available, when NFS is started on boot. I use to start nslcd manually from a root prompt. As said, it does not go away. Changing the expiration does not change a thing. The group number 4294967294 seems to pop out of thin air. It's not the number of the 'lars' group on any system involved. Checking syslog (Verbosity=9) it turns out that idmapd doesn't ever look up the names. This is a log following a nfs-common restart, several 'ls' and a 'touch': Nov 8 21:02:09 midgard rpc.idmapd[11283]: libnfsidmap: using domain: ad.microsult.de Nov 8 21:02:09 midgard rpc.idmapd[11283]: libnfsidmap: Realms list: 'AD.MICROSULT.DE' Nov 8 21:02:09 midgard rpc.idmapd[11283]: libnfsidmap: loaded plugin /lib/x86_64-linux-gnu/libnfsidmap/nsswitch.so for method nsswitch Nov 8 21:02:09 midgard rpc.idmapd[11284]: Expiration time is 10 seconds. Nov 8 21:02:09 midgard rpc.idmapd[11284]: Opened /proc/net/rpc/nfs4.nametoid/channel Nov 8 21:02:09 midgard rpc.idmapd[11284]: Opened /proc/net/rpc/nfs4.idtoname/channel Nov 8 21:02:09 midgard rpc.idmapd[11284]: New client: 13 Nov 8 21:02:09 midgard rpc.idmapd[11284]: New client: 14 Nov 8 21:02:09 midgard rpc.idmapd[11284]: Opened /run/rpc_pipefs/nfs/clnt14/idmap Nov 8 21:02:09 midgard rpc.idmapd[11284]: New client: 15 Nov 8 21:02:09 midgard nfs-common[11269]: Starting NFS common utilities: statd idmapdrpc.idmapd: libnfsidmap: using domain: ad.microsult.de Nov 8 21:02:09 midgard nfs-common[11269]: rpc.idmapd: libnfsidmap: Realms list: 'AD.MICROSULT.DE' Nov 8 21:02:09 midgard nfs-common[11269]: rpc.idmapd: libnfsidmap: loaded plugin /lib/x86_64-linux-gnu/libnfsidmap/nsswitch.so for method nsswitch Nov 8 21:15:29 midgard nfsidmap[11442]: key: 0x154df42a type: uid value: gu...@ad.microsult.de timeout 600 Nov 8 21:15:29 midgard nfsidmap[11442]: nfs4_name_to_uid: calling nsswitch->name_to_uid Nov 8 21:15:29 midgard nfsidmap[11442]: nss_getpwnam: name 'gu...@ad.microsult.de' domain 'ad.microsult.de': resulting localname 'guest' Nov 8 21:15:29 midgard nfsidmap[11442]: nss_getpwnam: name 'guest' not found in domain 'ad.microsult.de' Nov 8 21:15:29 midgard nfsidmap[11442]: nfs4_name_to_uid: nsswitch->name_to_uid returned -2 Nov 8 21:15:29 midgard nfsidmap[11442]: nfs4_name_to_uid: final return value is -2 Nov 8 21:15:29 midgard nfsidmap[11442]: nfs4_name_to_uid: calling nsswitch->name_to_uid Nov 8 21:15:29 midgard nfsidmap[11442]: nss_getpwnam: name 'nob...@ad.microsult.de' domain 'ad.microsult.de': resulting localname 'nobody' Nov 8 21:15:29 midgard nfsidmap[11442]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Nov 8 21:15:29 midgard nfsidmap[11442]: nfs4_name_to_uid: final return value is 0 So it obviously tries to resolve guest (during touch or the following ls), but it never looked up any other name in 13 minutes with any expiry time of 10 seconds. So it seems to be similarly related to chaching of negative results. Please let me know, if I can help with additional input.
Bug#725175: Any news?
I ran into this issue recently and filed this bug to nslcd: #787020 and #766606. So it persists for more than 2 years and made it across Debian release. I use k5start / nslcd to authenticate to samba4 AD. I'm surprised that it should be such a rare scenario. The situation actually looks quite wiered. Retrying after login always succeeds. Retrying in /etc/rc.local or by cron @reboot in general never works. On a i686 system running Wheezy it always succeeds. So if timing is the root of all evil, the required delay seems to be quite long. Could you please try to co-operate with Arthur to hunt down and eventually fix the issue? Kind regards, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787020: More info
With the script shown it regularly happens that 2 instances of nslcd are running, but of course no k5start. Shouldn't restart terminate the prior instance? I now use a stop, killall nslcd, start sequence. Again it works fine when started by root immediately after boot, but it fails if run from systemd. It also fails if run from cron with @reboot. Last time I got a different error message: Jun 03 00:08:54 frengel nslcd[762]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available) Still poking at the mist, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787020: More information
I tried to mitigate the bug by adding the following to /etc/rc.local: if [ ! -f /var/run/nslcd/nslcd.tkt ]; then systemctl restart nslcd systemctl restart kdm fi When I run this script as root after log in everything runs fine. I get a valid ticket nslcd:nslcd 600 /var/run/nslcd/nslcd.tkt. The boot up sequence however produces a total of two files called /var/run/nslcd/nslcd.tkt_##, with the hashes representing some random characters. These files are empty, root:root 600. If I omit the rc. local entry I just get one of these. Of course none without the random extension. I suspected a permission issue. But changing /etc/krb5.keytab to 644 didn't change the situation. /etc/krb5.conf ist 644 anyway. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787020: nslcd: k5start still fails during boot
Package: nslcd Version: 0.9.4-3 Severity: important Dear Maintainer, the behaviour reported for Wheezy in #766606 still persists with Jessie. I see it now on a fresh install: k5start doesn't come up on boot. Issuing /etc/init.d/nslcd restart after boot works perfectly. Situation after boot: root@frengel:~# systemctl status nslcd -l ● nslcd.service - LSB: LDAP connection daemon Loaded: loaded (/etc/init.d/nslcd) Active: active (running) since Mi 2015-05-27 21:51:15 CEST; 1min 16s ago Process: 630 ExecStart=/etc/init.d/nslcd start (code=exited, status=0/SUCCESS) CGroup: /system.slice/nslcd.service └─674 /usr/sbin/nslcd Mai 27 21:51:39 frengel nslcd[674]: [b71efb] no available LDAP server found: Local error Mai 27 21:51:39 frengel nslcd[674]: [b71efb] no available LDAP server found: Server is unavailable Mai 27 21:51:42 frengel nslcd[674]: [e2a9e3] no available LDAP server found: Server is unavailable Mai 27 21:51:42 frengel nslcd[674]: [e2a9e3] no available LDAP server found: Server is unavailable Mai 27 21:51:42 frengel nslcd[674]: [45e146] no available LDAP server found: Server is unavailable: Resource temporarily unavailable Mai 27 21:51:42 frengel nslcd[674]: [45e146] no available LDAP server found: Server is unavailable: Resource temporarily unavailable Mai 27 21:51:47 frengel nslcd[674]: [5f007c] no available LDAP server found: Server is unavailable Mai 27 21:51:47 frengel nslcd[674]: [5f007c] no available LDAP server found: Server is unavailable Mai 27 21:51:47 frengel nslcd[674]: [d062c2] no available LDAP server found: Server is unavailable Mai 27 21:51:47 frengel nslcd[674]: [d062c2] no available LDAP server found: Server is unavailable Fortunately both users are local. Situation after restart of nslcd: ● nslcd.service - LSB: LDAP connection daemon Loaded: loaded (/etc/init.d/nslcd) Active: active (running) since Mi 2015-05-27 21:53:40 CEST; 8s ago Process: 1118 ExecStop=/etc/init.d/nslcd stop (code=exited, status=0/SUCCESS) Process: 1132 ExecStart=/etc/init.d/nslcd start (code=exited, status=0/SUCCESS) CGroup: /system.slice/nslcd.service ├─1140 /usr/bin/k5start -b -p /var/run/nslcd/k5start_nslcd.pid -o nslcd -g nslcd -m 600 -f /etc/krb5.keytab -K 60 -u FRENGEL$@AD.MICROSULT.DE -k /var/run/nslcd/nslcd.tkt └─1143 /usr/sbin/nslcd Mai 27 21:53:40 frengel nslcd[1132]: Starting Keep alive Kerberos ticket: k5start. Mai 27 21:53:40 frengel nslcd[1143]: version 0.9.4 starting Mai 27 21:53:40 frengel nslcd[1143]: accepting connections Mai 27 21:53:40 frengel nslcd[1132]: Starting LDAP connection daemon: nslcd. This is in the logs about k5start: root@frengel:~# grep k5start /var/log/syslog May 27 21:51:15 frengel nslcd[630]: Starting Keep alive Kerberos ticket: k5startk5start: error getting credentials: Cannot contact any KDC for realm 'AD.MICROSULT.DE' May 27 21:53:40 frengel nslcd[1118]: Stopping Keep alive Kerberos ticket: k5startNo process in pidfile '/var/run/nslcd/k5start_nslcd.pid' found running; none killed. May 27 21:53:40 frengel nslcd[1132]: Starting Keep alive Kerberos ticket: k5start. It smells like the resolver is not up when k5start tries to figure out the KDC. The system is configured by DHCP. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nslcd depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-18 ii libgssapi-krb5-2 1.12.1+dfsg-19 ii libldap-2.4-2 2.4.40+dfsg-1 Versions of packages nslcd recommends: ii bind9-host [host] 1:9.9.5.dfsg-9 ii host1:9.9.5.dfsg-9 ii ldap-utils 2.4.40+dfsg-1 ii libnss-ldapd [libnss-ldap] 0.9.4-3 ii libpam-krb5 4.6-3+b1 ii libpam-ldapd [libpam-ldap] 0.9.4-3 pn nscd ii nslcd-utils 0.9.4-3 Versions of packages nslcd suggests: ii kstart 4.1-3 -- Configuration Files: /etc/default/nslcd changed: K5START_PRINCIPAL="FRENGEL\$@AD.MICROSULT.DE" -- debconf information: nslcd/ldap-bindpw: (password omitted) nslcd/ldap-cacertfile: /etc/ssl/certs/ca-certificates.crt nslcd/ldap-sasl-authzid: nslcd/ldap-reqcert: libraries/restart-without-asking: false nslcd/ldap-sasl-authcid: nslcd/ldap-binddn: nslcd/ldap-sasl-secprops: nslcd/restart-services: nslcd/ldap-auth-type: none * nslcd/ldap-uris: ldap://ad.microsult.de nslcd/ldap-sasl-realm: nslcd/xdm-needs-restart: nslcd/ldap-starttls: false nslcd/disable-screensaver: nslcd/ldap-sasl-mech: nslcd/restart-failed: * nslcd/ldap-base: DC=ad,DC=microsult,DC=de nslcd/ldap-sasl-krb5-ccname: /var/run/nslcd/ns
Bug#782719: lvm2: Strange state of lvmetad
Package: lvm2 Version: 2.02.111-2.1 Severity: normal Dear Maintainer, following the latest upgrade, which included a systemd and kernel upgrade, I get warnings in vgdisplay like: WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it! Also troubling: # systemctl status lvm2-lvmetad ● lvm2-lvmetad.service - LVM2 metadata daemon Loaded: loaded (/lib/systemd/system/lvm2-lvmetad.service; static) Active: inactive (dead) Docs: man:lvmetad(8) These warnings appeared during the upgrade and persisted even after reboot. As yet, I cannot see any real issues concerning the LVM data. However, since I never manually interfered with any lvm2 settings and it appears the same way on two Jessie systems, I assume that something is incorrect with the lvm2 to systemd integration. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lvm2 depends on: ii dmeventd 2:1.02.90-2.1 ii dmsetup 2:1.02.90-2.1 ii init-system-helpers 1.22 ii initscripts 2.88dsf-59 ii libc6 2.19-17 ii libdevmapper-event1.02.1 2:1.02.90-2.1 ii libdevmapper1.02.12:1.02.90-2.1 ii libreadline5 5.2+dfsg-2 ii libudev1 215-14 ii lsb-base 4.1+Debian13+nmu1 lvm2 recommends no packages. Versions of packages lvm2 suggests: pn thin-provisioning-tools -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775415: korganizer: Calendar loses data
Package: korganizer Version: 4:4.4.11.1+l10n-3+b1 Severity: normal Dear Maintainer, we observed that KOrganizer loses data and gets out of sync with what is stored on the hard disk. We run KOrganizer with many different calendars, which meanwhile are all stored on the local hard disk. We use BackInTime to produce hourly backups. As long as KOrganizer stays open everything looks smooth. After rebooting the machine, we frequently see loss of data - left alone what we probably don't see immediately. Tracing the situation with a lost event in the backups revealed that for some unknown reason the event was lost on hdd on Jan 7th in betwen 1 pm and 2 pm. It was still available on screen this morning, i.e. more than a week later! After re-boot it is gone, since it is not on disc. No uncommon behaviour of KOrganizer was observed on the 7th. The program was used during that day, but the lunch break may have fallen into the time in question. There was much more data lost. Not only the complete loss of files, but also updates of existing events vanished. It is not yet clear, whether the data loss hapened at the same time. I did not yet have had the time to analyze the contents of the files. Finding files which suddenly vanish was much easier. ;) -- System Information: Debian Release: 7.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages korganizer depends on: ii kde-runtime 4:4.8.4-2 ii kdepim-runtime4:4.4.11.1-6 ii libakonadi-contact4 4:4.8.4-2 ii libc6 2.13-38+deb7u6 ii libkabc4 4:4.8.4-2 ii libkcal4 4:4.8.4-2 ii libkcmutils4 4:4.8.4-4+deb7u1 ii libkde3support4 4:4.8.4-4+deb7u1 ii libkdecore5 4:4.8.4-4+deb7u1 ii libkdepim44:4.4.11.1+l10n-3+b1 ii libkdeui5 4:4.8.4-4+deb7u1 ii libkholidays4 4:4.8.4-2 ii libkio5 4:4.8.4-4+deb7u1 ii libkmime4 4:4.8.4-2 ii libknewstuff2-4 4:4.8.4-4+deb7u1 ii libkontactinterface4 4:4.8.4-2 ii libkparts44:4.8.4-4+deb7u1 ii libkpimidentities44:4.8.4-2 ii libkpimutils4 4:4.8.4-2 ii libkprintutils4 4:4.8.4-4+deb7u1 ii libkresources44:4.8.4-2 ii libphonon44:4.6.0.0-3 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-qt3support 4:4.8.2+dfsg-11 ii libqt4-xml4:4.8.2+dfsg-11 ii libqtcore44:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libstdc++64.7.2-5 ii perl 5.14.2-21+deb7u2 ii phonon4:4.6.0.0-3 ii zlib1g1:1.2.7.dfsg-13 korganizer recommends no packages. Versions of packages korganizer suggests: ii kdepim-groupware 4:4.4.11.1+l10n-3+b1 ii kdepim-kresources 4:4.4.11.1+l10n-3+b1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774178: Acknowledgement (bind9: No SOA nor NS in samba_dlz zones)
The bug persists with 1:9.9.5.dfsg-8. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774178: bind9: No SOA nor NS in samba_dlz zones
Package: bind9
Version: 1:9.9.5.dfsg-7
Severity: normal
Dear Maintainer,
following the upgrade to 1:9.9.5.dfsg-7 on Dec. 22nd named fails to load the
DLZ
zones from Samba:
Dec 29 10:43:07 verdandi named[2763]: Loading 'AD Zones' using driver dlopen
Dec 29 10:43:07 verdandi named[2763]: samba_dlz: started for DN
DC=ad,DC=microsult,DC=de
Dec 29 10:43:07 verdandi named[2763]: samba_dlz: starting configure
Dec 29 10:43:07 verdandi named[2763]: zone 10.16.172.in-addr.arpa/NONE: has 0
SOA records
Dec 29 10:43:07 verdandi named[2763]: zone 10.16.172.in-addr.arpa/NONE: has no
NS records
Dec 29 10:43:07 verdandi named[2763]: samba_dlz: Failed to configure zone
'10.16.172.in-addr.arpa.'
Dec 29 10:43:07 verdandi named[2763]: loading configuration: bad zone
Dec 29 10:43:07 verdandi named[2763]: exiting (due to fatal error)
Dec 29 10:43:07 verdandi named[2763]: samba_dlz: shutting down
This is strange, since samba reports the zones okay:
root@verdandi:~# samba-tool dns query localhost 10.16.172.in-addr.arpa. @ ALL
-U Administrator
Password for [AD\Administrator]:
Name=, Records=2, Children=0
SOA: serial=1, refresh=900, retry=600, expire=86400, minttl=3600,
ns=samba.ad.microsult.de., email=hostmaster.ad.microsult.de. (flags=60f0,
serial=1, ttl=3600)
NS: samba.ad.microsult.de. (flags=60f0, serial=1, ttl=3600)
A Wheezy Bind9 1:9.8.4.dfsg.P1-6+nmu2+deb7u3 runs perfectly on a replica server
in the same configuration (but with other samba_dlz plugin lib of course).
Syslog
on the Jessie machine has Bind9 exiting gracefully due to bind restart after
upgrading, but failing to come up with the described issue immediately
afterwards.
Inquiries to the samba mailing list (see: samba_dlz Failed to configure
reverse zone) did not yield any results. Although BIND_DLZ configuration of
a Samba AD DC is quite common, the issue seems to be unknown. This hints
at something broken in this particular Bind9 package.
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages bind9 depends on:
ii adduser3.113+nmu3
ii bind9utils 1:9.9.5.dfsg-7
ii debconf [debconf-2.0] 1.5.55
ii init-system-helpers1.22
ii libbind9-901:9.9.5.dfsg-7
ii libc6 2.19-13
ii libcap21:2.24-6
ii libcomerr2 1.42.12-1
ii libdns100 1:9.9.5.dfsg-7
ii libgssapi-krb5-2 1.12.1+dfsg-16
ii libisc95 1:9.9.5.dfsg-7
ii libisccc90 1:9.9.5.dfsg-7
ii libisccfg901:9.9.5.dfsg-7
ii libk5crypto3 1.12.1+dfsg-16
ii libkrb5-3 1.12.1+dfsg-16
ii liblwres90 1:9.9.5.dfsg-7
ii libssl1.0.01.0.1j-1
ii libxml22.9.1+dfsg1-4
ii lsb-base 4.1+Debian13+nmu1
ii net-tools 1.60-26+b1
ii netbase5.3
bind9 recommends no packages.
Versions of packages bind9 suggests:
pn bind9-doc
ii dnsutils1:9.9.5.dfsg-7
pn resolvconf
pn ufw
-- Configuration Files:
/etc/bind/named.conf.local changed:
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
include "/etc/bind/zones.private";
include "/var/lib/samba/private/named.conf";
zones.private is zones.rfc1918 w/o 172.16.0.0, since I use this net.
/var/lib/samba/private/named.conf is as created by Samba:
dlz "AD Zones" {
# For BIND 9.9.0
database "dlopen /usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_9.so";
};
-- debconf information:
bind9/different-configuration-file:
bind9/start-as-user: bind
bind9/run-resolvconf: false
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#773074: browser-plugin-gnash: gnash ignores proxy settings
Package: browser-plugin-gnash Version: 0.8.11~git20140319+dfsg-1~bpo70+1 Severity: normal Dear Maintainer, trying to watch any youtube video I saw my firewall logging connections to external systems on port 443. The port is blocked, since all traffic is expected to pass through a proxy. Iceweasel is configured accordingly. I tried to add https_proxy=proxy.fqdn:8080 to the "command to open addresses" in the "Player" tab of the gnash configuration, but I guess it's the wrong place anyway - it did not help. I could not find any other place to configure a proxy for gnash. If I allow access to external systems on 443 the video is played. The behaviour was identical with 0.8.11~git20120629-1+deb7u1, i.e. the standard wheezy packet. -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages browser-plugin-gnash depends on: ii gnash 0.8.11~git20140319+dfsg-1~bpo70+1 ii libboost-iostreams1.49.0 1.49.0-3.2 ii libc6 2.13-38+deb7u6 ii libgcc1 1:4.7.2-5 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libstdc++64.7.2-5 browser-plugin-gnash recommends no packages. Versions of packages browser-plugin-gnash suggests: pn browser-plugin-lightspark -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767774: dpkg: File descriptor 20 (/dev/pts/2) leaked on vgs invocation
I'm not sure I understood the state of this bug report. I'm seeing the same issue and can reproduce the behaviour shown by Niechta. This is a plain Jessie install, so apt is 1.0.9.3; not the experimental one. Do you consider the bug fixed in 1.1 and we wait until it trickles down into Jessie, or shall we set up a VM with mixed distributions to verify something? Regards, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766606: Mitigate the bug - on a way to a patch
The problem is that obviously network configuration takes time and the
init script starts too early. I mitigated this by adding the following
to /etc/defaults/nslcd:
# wait for DNS
wait_for_dns(){
log_action_begin_msg "Check for KDC"
local HOST=/usr/bin/host
local RETRY=5
while [ $RETRY -gt 0 ]; do
local DC=$($HOST -t SRV _kerberos._udp | sed '/^;;/d;s/^.* //')
if [ -n "$DC" ]; then
DC=$($HOST "$DC" | sed '/^;;/d;s/^.* //')
if [ -n "$DC" ]; then
log_action_end_msg 0 success
return 0
else
log_action_cont_msg "KDC: $RETRY"
fi
else
log_action_cont_msg "DNS: $RETRY"
fi
RETRY=$(($RETRY-1))
done
log_action_end_msg 20 fail
return 20
}
if [ "$K5START_START" = "yes" ]; then
wait_for_dns
fi
Okay, my KDC is an AD DC, so "_kerberos._udp" may not be valid in other
environments. But unless the boot sequence in itself will be changed,
some code like this in the k5start startup may do the trick. I fear that
the situation won't exactly improve with systemd.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766606: nslcd: k5start fails during boot
Package: nslcd Version: 0.8.10-4 Severity: important Dear Maintainer, I just switched from libnss-ldap / OpenLDAP with TLS auth to libnssd-ldap / Samba4 AD DC with Kerberos auth. So the issue might have existed for some time. During boot k5start fails: Fri Oct 24 12:34:55 2014: [FAIL] Starting Keep alive Kerberos ticket: k5startk5start: error getting credentials: Cannot contact any KDC for realm 'AD.MICROSULT.DE' Fri Oct 24 12:34:55 2014: [ ok ] Starting LDAP connection daemon: nslcd which means that nslcd cannot read from the AD DC and all AD users are unknown. Logging in as root following start-up and restarting nslcd by /etc/init.d/nslcd restart works fine and also starts k5start. Could it be that it is run too early in the start-up? However, NFS is started before nslcd and I use kerberized NFS4! Regards, - lars -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nslcd depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38+deb7u6 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u2 ii libldap-2.4-2 2.4.31-1+nmu2 Versions of packages nslcd recommends: ii bind9-host [host] 1:9.8.4.dfsg.P1-6+nmu2+deb7u2 ii host1:9.8.4.dfsg.P1-6+nmu2+deb7u2 ii ldap-utils 2.4.31-1+nmu2 ii libnss-ldapd [libnss-ldap] 0.8.10-4 ii libpam-krb5 4.6-1 pn nscd Versions of packages nslcd suggests: ii kstart 4.1-2 -- Configuration Files: /etc/default/nslcd changed: K5START_PRINCIPAL="MIDGARD\$@AD.MICROSULT.DE" -- debconf information: nslcd/ldap-sasl-realm: nslcd/ldap-starttls: false nslcd/ldap-sasl-krb5-ccname: /var/run/nslcd/nslcd.tkt nslcd/ldap-auth-type: none nslcd/ldap-reqcert: * nslcd/ldap-uris: ldap://samba.ad.microsult.de/ nslcd/ldap-sasl-secprops: nslcd/ldap-binddn: nslcd/ldap-sasl-authcid: nslcd/ldap-sasl-mech: * nslcd/ldap-base: DC=ad,DC=microsult,DC=de nslcd/ldap-sasl-authzid: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733252: gcr: libgcr-3-1:i386 is not installable
Package: gcr Version: 3.4.1-3 Severity: normal Dear Maintainer, on an amd64 system installing gcr:i386 - apparently used by acroread - fails. The reason is that libgcr-3-1:i386 requires libgcr-3-common:i386, which is not available: $ apt-cache policy libgcr-3-common:i386 libgcr-3-common:i386: Installiert: (keine) Installationskandidat: (keine) Versionstabelle: Which of course is nonsense, since the package is architechture independent and in fact installed already. I'm not too familiar with the multi-arch stuff, so I do not know whether this is an issue of the apt system or the gcr control files. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gcr depends on: ii dbus-x11 1.6.8-1+deb7u1 ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii libc62.13-38 ii libgcr-3-1 3.4.1-3 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgtk-3-0 3.4.2-7 gcr recommends no packages. gcr suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708086: Probable solution
I worked a little more on the issue and it seems to be a user error, respectively a cryptic error message. The new Kontact does not automatically import the old calendars since it apparently uses a new storage model. It however starts wit some default calendar, which is marked read only by default. So any attempt to import calendars or create new events must fail. What might stay as a bug is that it also fails to import the .ics files as new calendars, but you can create your own and import the .ics into it. Regards, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708086: Same situation after update Squeeze to Wheezy
I see the same situation here. Just updated from Squeeze to Wheezy. Any progress on this since May? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701805: add_uevent_var: buffer size too small
Package: linux-2.6 Version: 2.6.32-48squeeze1 Severity: normal I'm not sure what actually caused the issue. I did disconnect my WD-Book (sdd) from the USB. I re-attached it after the error using eSATA. This is what you see in the kernel log. However, the kernel source points to a buffer overflow, which already happened, when this message is generated. So it might be a critical security issue. -- Package-specific info: ** Version: Linux version 2.6.32-5-openvz-amd64 (Debian 2.6.32-48squeeze1) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Feb 25 01:16:25 UTC 2013 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-openvz-amd64 root=UUID=ace017c1-b7df-4523-906e-c1e718faec10 ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 1522.525743] scsi 10:0:0:1: Enclosure WD My Book Device 1010 PQ: 0 ANSI: 4 [ 1522.526267] sd 10:0:0:0: Attached scsi generic sg4 type 0 [ 1522.526345] ses 10:0:0:1: Attached Enclosure device [ 1522.526393] ses 10:0:0:1: Attached scsi generic sg5 type 13 [ 1522.527981] sd 10:0:0:0: [sdd] 1953508784 512-byte logical blocks: (1.00 TB/931 GiB) [ 1522.528997] sd 10:0:0:0: [sdd] Write Protect is off [ 1522.529001] sd 10:0:0:0: [sdd] Mode Sense: 10 00 00 00 [ 1522.529004] sd 10:0:0:0: [sdd] Assuming drive cache: write through [ 1522.531618] sd 10:0:0:0: [sdd] Assuming drive cache: write through [ 1522.531651] sdd: sdd1 [ 1522.543110] sd 10:0:0:0: [sdd] Assuming drive cache: write through [ 1522.543143] sd 10:0:0:0: [sdd] Attached SCSI disk [ 1827.046486] FWD: IN=eth0 OUT=ppp0 SRC=172.16.17.18 DST=62.157.140.77 LEN=44 TOS=0x00 PREC=0x00 TTL=127 ID=60691 DF PROTO=TCP SPT=60314 DPT=80 WINDOW=1608 RES=0x00 SYN URGP=0 [ 1830.052607] FWD: IN=eth0 OUT=ppp0 SRC=172.16.17.18 DST=62.157.140.77 LEN=44 TOS=0x00 PREC=0x00 TTL=127 ID=60692 DF PROTO=TCP SPT=60314 DPT=80 WINDOW=1608 RES=0x00 SYN URGP=0 [ 1834.068263] FWD: IN=eth0 OUT=ppp0 SRC=172.16.17.18 DST=62.157.140.77 LEN=44 TOS=0x00 PREC=0x00 TTL=127 ID=60693 DF PROTO=TCP SPT=60314 DPT=80 WINDOW=1608 RES=0x00 SYN URGP=0 [ 1874.242782] IN: IN=br1 OUT= PHYSIN=veth1007.0 MAC=00:18:51:5d:6c:ac:00:18:51:66:74:50:08:00 SRC=172.16.2.131 DST=172.16.8.1 LEN=331 TOS=0x00 PREC=0x00 TTL=127 ID=627 PROTO=UDP SPT=68 DPT=67 LEN=311 [ 1999.656073] usb 3-7: USB disconnect, address 5 [ 1999.681146] [ cut here ] [ 1999.681153] WARNING: at /build/buildd-linux-2.6_2.6.32-48squeeze1-amd64-qu4MIV/linux-2.6-2.6.32/debian/build/source_amd64_openvz/lib/kobject_uevent.c:313 add_uevent_var+0xaf/0xf0() [ 1999.681158] Hardware name: MS-7395 [ 1999.681160] add_uevent_var: buffer size too small [ 1999.681171] Modules linked in: ses enclosure usbhid usb_storage hid ebtable_nat ebtables vzethdev vznetdev simfs vzrst vzcpt vzdquota vzmon vzdev ip6t_REJECT ip6table_mangle ip6table_filter ip6_tables xt_length xt_hl xt_limit xt_dscp ipt_REJECT acpi_cpufreq cpufreq_conservative cpufreq_stats cpufreq_powersave cpufreq_userspace capi capifs vzevent kvm_intel kvm fuse pppoe pppox ppp_generic slhc ipt_MASQUERADE iptable_nat nf_nat ipt_LOG nf_conntrack_ipv4 nf_defrag_ipv4 xt_state xt_multiport iptable_filter xt_TCPMSS xt_tcpmss xt_tcpudp iptable_mangle ip_tables x_tables bridge stp xfs exportfs ext2 dm_crypt coretemp f71882fg nf_conntrack_ftp nf_conntrack loop snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq b1pci b1dma b1 snd_timer kernelcapi snd_seq_device snd shpchp radeon ttm drm_kms_helper i2c_i801 pci_hotplug drm soundcore i2c_algo_bit parport_pc snd_page_alloc pcspkr usblp psmouse i2c_core parport evdev serio_raw processor button ext3 jbd mbcache dm_mod raid456 md_mod async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx sg sr_mod cdrom sd_mod crc_t10dif ata_generic ahci pata_jmicron r8169 ata_piix aic7xxx uhci_hcd thermal sundance libata mii ehci_hcd scsi_transport_spi scsi_mod thermal_sys usbcore nls_base [last unloaded: scsi_wait_scan] [ 1999.681281] Pid: 264, comm: khubd Tainted: GW 2.6.32-5-openvz-amd64 #1 [ 1999.681283] Call Trace: [ 1999.681288] [] ? add_uevent_var+0xaf/0xf0 [ 1999.681292] [] ? add_uevent_var+0xaf/0xf0 [ 1999.681296] [] ? warn_slowpath_common+0x77/0xa3 [ 1999.681300] [] ? warn_slowpath_fmt+0x51/0x59 [ 1999.681304] [] ? vsnprintf+0x40a/0x449 [ 1999.681308] [] ? add_uevent_var+0xaf/0xf0 [ 1999.681313] [] ? input_dev_uevent+0x267/0x29f [ 1999.681318] [] ? dev_uevent+0x13f/0x146 [ 1999.681322] [] ? kobject_uevent_env+0x22a/0x3e6 [ 1999.681326] [] ? release_nodes+0x152/0x18b [ 1999.681330] [] ? device_del+0x15a/0x198 [ 1999.681334] [] ? device_unregister+0x9/0x12 [ 1999.681340] [] ? hidinput_disconnect+0x49/0x62 [hid] [ 1999.681344] [] ? hid_disconnect+0x12/0x38 [hid] [ 1999.681349] [] ? hid_device_remove+0x2c/0x48 [hid] [ 1999.681353] [] ? __device_release_driver+0x96/0xeb [ 1999.681357] [] ? device_release_driver+0x1e/0x2a [ 1999.681361] [] ? bus_remove_device
Bug#698170: libpam-krb5: Default configuration does not work
Package: libpam-krb5 Version: 4.3-1 Severity: normal Tags: patch Using the configuration files as produced by this package fails to login to the system using kerberos. A typical auth.log for a kerberos login looks like this: Jan 14 21:12:56 nfs4 login[5265]: pam_krb5(login:auth): user xxx authenticated as xxx@XXX Jan 14 21:12:56 nfs4 login[5265]: Authentication failure Changing /etc/pam.d/common-account to reflect: account sufficient pam_krb5.so minimum_uid=1000 account requiredpam_unix.so account requiredpam_permit.so makes logins based on /etc/shadow and Kerberos successful. I couldn't get both scenarios running in parallel with any minor change to the config, but I'm neither a PAM wizard. -- 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/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpam-krb5 depends on: ii krb5-config 2.2 Configuration files for Kerberos V ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libkrb5-3 1.8.3+dfsg-4squeeze6 MIT Kerberos runtime libraries ii libpam-runtime 1.1.1-6.1+squeeze1 Runtime support for the PAM librar ii libpam0g1.1.1-6.1+squeeze1 Pluggable Authentication Modules l libpam-krb5 recommends no packages. libpam-krb5 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#638040: krb5-user: kpasswd connects on 454 instead of 464
Package: krb5-user Version: 1.8.3+dfsg-4squeeze1 Severity: normal Tags: patch kpasswd without setting of the kpasswd_server property in the [realms] section connects to the KDC on UDP port 454. Specifying the port 464 explicitly for the kpasswd_server property fixes the problem, but this behaviour does not reflect the man page and moreover is annoying. Obviously the issue existed on Lenny already - and obviously I change passwords too rarely, i.e. my Lenny machine hits the firewall on 454 as well. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages krb5-user depends on: ii krb5-config 2.2 Configuration files for Kerberos V ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-4stable1 common error description library ii libgssapi-krb5-21.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries - k ii libgssrpc4 1.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries - G ii libk5crypto31.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries - C ii libkadm5clnt-mit7 1.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries - A ii libkeyutils11.4-1Linux Key Management Utilities (li ii libkrb5-3 1.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries ii libkrb5support0 1.8.3+dfsg-4squeeze1 MIT Kerberos runtime libraries - S ii libss2 1.41.12-4stable1 command-line interface parsing lib krb5-user recommends no packages. krb5-user suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#500743: Similar issue -- quite reproducible
My bind9 simply stopped working all of a sudden. It worked perfectly and
then following a reboot of the VZ container it would segfault on start.
The first event coincided with the latetst security update. I installed
the update and it did start again. However, now using still the same
code, it segfaults on every start. I tried to reinstall the package
without any change. I also rebooted the VZ container to get around
resource leakage, but the issue persists. I'd think that it is quite
unlikely that bind9 uses the same physical memory page after rebooting
the container.
To get around it, I installed a new bind9 into a new VZ container,
copied my zone files and it runs like a charm. So configuration
problems in the zone files are probably not the major cause.
Kernel: 2.6.26-2-openvz-amd64 #1 SMP Thu Nov 5 03:06:00 UTC 2009 x86_64
GNU/Linux
Version: bind9 1:9.5.1.dfsg.P3-1+lenny1
I straced named once before reboot and once after: strace -f -o
bind2.trc named -u bind -fg -d . Apart from PID and memory
addresses these two traces apparently are identical and contain 437
lines. The following is the tail of both logs:
432 setuid(102) = 0
432 prctl(0x4, 0x1, 0, 0, 0) = 0
432 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
432 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
432 capget(0x20080522, 0, {0,
CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
0}) = 0
432 getuid() = 102
432 capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE,
CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE, 0}) = 0
432 mmap(NULL, 266240, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f04ff1f
432 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
432 +++ killed by SIGSEGV +++
The other log has address 0x7fc1309f8000 as the mmap() result.
Apparently, the segfault happens quite immediately following the
privilege dropping.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#500743: Similar issue -- quite reproducible
My bind9 simply stopped working all of a sudden. It worked perfectly and
then following a reboot of the VZ container it would segfault on start.
The first event coincided with the latetst security update. I installed
the update and it did start again. However, now using still the same
code, it segfaults on every start. I tried to reinstall the package
without any change. I also rebooted the VZ container to get around
resource leakage, but the issue persists. I'd think that it is quite
unlikely that bind9 uses the same physical memory page after rebooting
the container.
To get around it, I installed a new bind9 into a new VZ container,
copied my zone files and it runs like a charm. So configuration
problems in the zone files are probably not the major cause.
Kernel: 2.6.26-2-openvz-amd64 #1 SMP Thu Nov 5 03:06:00 UTC 2009 x86_64
GNU/Linux
Version: bind9 1:9.5.1.dfsg.P3-1+lenny1
I straced named once before reboot and once after: strace -f -o
bind2.trc named -u bind -fg -d . Apart from PID and memory
addresses these two traces apparently are identical and contain 437
lines. The following is the tail of both logs:
432 setuid(102) = 0
432 prctl(0x4, 0x1, 0, 0, 0) = 0
432 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
432 capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address)
432 capget(0x20080522, 0, {0,
CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
0}) = 0
432 getuid() = 102
432 capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE,
CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE, 0}) = 0
432 mmap(NULL, 266240, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f04ff1f
432 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
432 +++ killed by SIGSEGV +++
The other log has address 0x7fc1309f8000 as the mmap() result.
Apparently, the segfault happens quite immediately following the
privilege dropping.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532386: XFS Crash
I have a similar issue with a "NAS" RAID attached via eSATA, which I use for backup. It has XFS on LUKS. While it worked well in the beginning, the last 3 backups messed it all up and required xfs repairs. Two times it kicked the server into kernel crashes. This was in /var/log/messages for the latest event: [3786325.118537] sd 4:0:0:0: [sdd] Attached SCSI disk [3786325.118537] sd 4:0:0:0: Attached scsi generic sg4 type 0 [3786395.573640] Filesystem "dm-10": Disabling barriers, not supported by the underlying device [3786395.573640] XFS mounting filesystem dm-10 [3786396.244611] Ending clean XFS mount for filesystem: dm-10 # backup runs w/o dm-10 related messages here [3789609.893908] Filesystem "dm-10": xfs_iflush: Bad inode 26673648, ptr 0x81016cc72780, magic number 0x494c [3789609.893908] xfs_force_shutdown(dm-10,0x8) called from line 3276 of file fs/xfs/xfs_inode.c. Return address = 0xa03587a5 [3789609.900184] Filesystem "dm-10": Corruption of in-memory data detected. Shutting down filesystem: dm-10 [3789609.900217] Please umount the filesystem, and rectify the problem(s) [3789613.568623] Filesystem "dm-10": xfs_log_force: error 5 returned. [3789613.568632] Filesystem "dm-10": xfs_log_force: error 5 returned. [3789613.568639] xfs_force_shutdown(dm-10,0x1) called from line 420 of file fs/xfs/xfs_rw.c. Return address = 0xa036fe1a [3789613.568643] Filesystem "dm-10": xfs_log_force: error 5 returned. [3789613.568646] Filesystem "dm-10": xfs_log_force: error 5 returned. [3789613.568649] xfs_force_shutdown(dm-10,0x1) called from line 420 of file fs/xfs/xfs_rw.c. Return address = 0xa036fe1a [3789615.925371] Filesystem "dm-10": xfs_log_force: error 5 returned. [3789615.925371] Filesystem "dm-10": xfs_log_force: error 5 returned. [3789615.925371] Filesystem "dm-10": xfs_log_force: error 5 returned. [3789615.925371] Filesystem "dm-10": xfs_log_force: error 5 returned. [3789616.245362] Filesystem "dm-10": xfs_log_force: error 5 returned. Software is Lenny untainted current as for today: 2.6.26-2-openvz-amd64 #1 SMP Thu Nov 5 03:06:00 UTC 2009 x86_64 GNU/Linux running on an Intel Quad-Core. The error also occured with the previous Lenny kernel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525021: Version in Testing looks promising
I encountered the same issue today, when my backup script attempted to rsync -aHAXx --stats --numeric-ids --inplace --delete '/' '/media/backup/repository/sda5' which produced rsync: writefd_unbuffered failed to write 4092 bytes [sender]: Broken pipe (32) rsync: connection unexpectedly closed (4387 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(635) [sender=3.0.3] during file list transfer. Interestingly, --dry-run was not affected; and shouldn't it run just the same file list transfer? Setting '-v' did not affect the behavior but clearly showed that the error occurs during file-list transfer. Anyhow, I retrieved the current testing sources, compiled them on Lenny amd64 and installed the package. Afterwards my backup script ran perfectly, and it has a lot of rsync commands like the above. So it seems like the current testing closes the issue. Thanks, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532218: Sorry for impatience
Sorry, as the patch comments say, the bug has already been filed as #405495, I myself have sent the patch then, and it circles somewhere in unstable. As we say in German: Reading educates! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532218: libsasl2-2: Bug #499770 still exists
Package: libsasl2-2
Version: 2.1.22.dfsg1-23+lenny1
Severity: important
Tags: patch
Using the ldapdb auxprop with cyrus-imap fails because the authentication
process crashes due to a double init of a mutex (cause briefly explained by
Eric Leblond in Bug #499770). This makes any kind of login into the IMAP server
entirely impossible. The error messages produced are not very helpful so it's
more than annoying to hunt the problem down to begin with. It took more than a
week when I first faced that issue some time beginning this year.
Today due to the security upgrade SASL was replaced and my IMAP was down again
with the same symptoms (I love my internal wiki). Re-installing my hand-fixed
sasl2 packages from cyrus-sasl2-2.1.22.dfsg1 sources got it working instantly.
I'll prepare a new build based on the security patched sources shortly and
report whether this still fixes the issue. Actually, the patch is a single if
statement.
--8<-
ad...@valhalla:~/packages/cyrus-sasl2$ cat 0021_fix_sasl_mutex.dpatch
#! /bin/sh /usr/share/dpatch/dpatch-run
## 0021_fix_sasl_mutex.dpatch by
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fix SEGFAULT on sasl_mutex. Debian Bug #405495
@DPATCH@
--- trunk~/lib/common.c 2009-01-05 12:20:53.0 +0100
+++ trunk/lib/common.c 2009-01-05 12:24:19.0 +0100
@@ -150,9 +150,17 @@
&sasl_mutex_free
};
-void sasl_set_mutex(sasl_mutex_alloc_t *n, sasl_mutex_lock_t *l,
- sasl_mutex_unlock_t *u, sasl_mutex_free_t *d)
-{
+void sasl_set_mutex(sasl_mutex_alloc_t *n,
+ sasl_mutex_lock_t *l,
+ sasl_mutex_unlock_t *u,
+ sasl_mutex_free_t *d)
+{
+ /* Disallow mutex function changes once sasl_client_init
+ and/or sasl_server_init is called */
+ if(_sasl_server_cleanup_hook || _sasl_client_cleanup_hook){
+return;
+ }
+
_sasl_mutex_utils.alloc=n;
_sasl_mutex_utils.lock=l;
_sasl_mutex_utils.unlock=u;
--8<-
-- System Information:
Debian Release: 5.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-openvz-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages libsasl2-2 depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libdb4.6 4.6.21-11 Berkeley v4.6 Database Libraries [
Versions of packages libsasl2-2 recommends:
ii libsasl2-modules 2.1.22.dfsg1-23+lenny1 Cyrus SASL - pluggable authenticat
libsasl2-2 suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509613: Resolved
I recompiled the kernel from the current official security update sources. These sources contain the patch and work flawlessly, although I did not see any mention of this fix in changelog. So this bug can be closed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509613: Progress
Hi there, is there a reason, why this fix did not make it into the last Release. After reading the changelog I set my Kernel on hold before the update, which locks me out of security updates, which is a least desirable situation. Regards, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#487494: Some more info
At first - the bug persists with current Lenny. I have not checked, whether this bug is related to HTML context, but I'll keep an eye on it in future. Icedove does retrieve the contents from the IMAP server. It is there for replies or when displaying the message source. It's just not displayed in any mode (Plain text, HTML, simplified HTML). The bug is also filed with Ubuntu as Bug#515569. The Ubuntu bug also refers to IMAP sources. I can't say whether it appears with POP accounts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511165: SOLVED
Vitaliy Gusev wrote:
It seem like bug #1091 (http://bugzilla.openvz.org/show_bug.cgi?id=1091)
Pavel, please apply fix patch to 2.6.26
Yes, this does it. For the Debian openvz-amd64 sources the above patch
translated to quilt results in what's attached.
Regards,
- lars.
Index: build_amd64_openvz_amd64/include/net/netfilter/nf_conntrack_l4proto.h
===
--- build_amd64_openvz_amd64.orig/include/net/netfilter/nf_conntrack_l4proto.h 2009-01-29 12:42:16.0 +0100
+++ build_amd64_openvz_amd64/include/net/netfilter/nf_conntrack_l4proto.h 2009-01-29 12:46:07.0 +0100
@@ -126,6 +126,9 @@
#ifdef CONFIG_VE_IPTABLES
#include
#define ve_nf_ct4 (get_exec_env()->_nf_conntrack)
+#define ve_nf_ct_initialized() (get_exec_env()->_nf_conntrack != NULL)
+#else
+#define ve_nf_ct_initialized() 1
#endif
#if defined(CONFIG_VE_IPTABLES) && defined(CONFIG_SYSCTL)
Index: build_amd64_openvz_amd64/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
===
--- build_amd64_openvz_amd64.orig/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c 2009-01-29 12:42:25.0 +0100
+++ build_amd64_openvz_amd64/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c 2009-01-29 12:48:43.0 +0100
@@ -306,6 +306,9 @@
const struct nf_conntrack_tuple_hash *h;
struct nf_conntrack_tuple tuple;
+ if (!ve_nf_ct_initialized())
+ return -ENOPROTOOPT;
+
memset(&tuple, 0, sizeof(tuple));
tuple.src.u3.ip = inet->rcv_saddr;
tuple.src.u.tcp.port = inet->sport;
Index: build_amd64_openvz_amd64/net/netfilter/nf_conntrack_netlink.c
===
--- build_amd64_openvz_amd64.orig/net/netfilter/nf_conntrack_netlink.c 2009-01-29 12:42:36.0 +0100
+++ build_amd64_openvz_amd64/net/netfilter/nf_conntrack_netlink.c 2009-01-29 12:53:28.0 +0100
@@ -790,6 +790,9 @@
u_int8_t u3 = nfmsg->nfgen_family;
int err = 0;
+ if (!ve_nf_ct_initialized())
+ return -ENOPROTOOPT;
+
if (cda[CTA_TUPLE_ORIG])
err = ctnetlink_parse_tuple(cda, &tuple, CTA_TUPLE_ORIG, u3);
else if (cda[CTA_TUPLE_REPLY])
@@ -836,6 +839,9 @@
u_int8_t u3 = nfmsg->nfgen_family;
int err = 0;
+ if (!ve_nf_ct_initialized())
+ return -ENOPROTOOPT;
+
if (nlh->nlmsg_flags & NLM_F_DUMP) {
#ifndef CONFIG_NF_CT_ACCT
if (NFNL_MSG_TYPE(nlh->nlmsg_type) == IPCTNL_MSG_CT_GET_CTRZERO)
@@ -1203,6 +1209,9 @@
u_int8_t u3 = nfmsg->nfgen_family;
int err = 0;
+ if (!ve_nf_ct_initialized())
+ return -ENOPROTOOPT;
+
if (cda[CTA_TUPLE_ORIG]) {
err = ctnetlink_parse_tuple(cda, &otuple, CTA_TUPLE_ORIG, u3);
if (err < 0)
@@ -1527,6 +1536,9 @@
u_int8_t u3 = nfmsg->nfgen_family;
int err = 0;
+ if (!ve_nf_ct_initialized())
+ return -ENOPROTOOPT;
+
if (nlh->nlmsg_flags & NLM_F_DUMP) {
return netlink_dump_start(ctnl, skb, nlh,
ctnetlink_exp_dump_table,
@@ -1588,6 +1600,9 @@
unsigned int i;
int err;
+ if (!ve_nf_ct_initialized())
+ return -ENOPROTOOPT;
+
if (cda[CTA_EXPECT_TUPLE]) {
/* delete a single expect by tuple */
err = ctnetlink_parse_tuple(cda, &tuple, CTA_EXPECT_TUPLE, u3);
@@ -1726,6 +1741,9 @@
u_int8_t u3 = nfmsg->nfgen_family;
int err = 0;
+ if (!ve_nf_ct_initialized())
+ return -ENOPROTOOPT;
+
if (!cda[CTA_EXPECT_TUPLE]
|| !cda[CTA_EXPECT_MASK]
|| !cda[CTA_EXPECT_MASTER])
Bug#509613: SOLVED
First, for all users trying to apply the patch, the recipe for building the kernel given in the last post does not work. The following succeeded: * rm -Rf linux-2.6-2.6.26; apt-get source -t testing linux-2.6 * cd linux-2.6-2.6.26/; fakeroot debian/rules debian/build debian/stamps * fakeroot make -f debian/rules.gen setup_amd64_openvz * I have my own patches at the top of the directory tree pushd debian/build/build_amd64_openvz_amd64/ ln -s ../../../../patches/ . quilt push -a popd * fakeroot make -f debian/rules.gen binary-arch_amd64_openvz And this is the patch in dpatch format, which solves the bug (essentially OpenVZ patch for Bug 1044) ---8< Index: linux-2.6-2.6.26/net/core/dev.c === --- linux-2.6-2.6.26.orig/net/core/dev.c2009-01-21 22:45:25.0 +0100 +++ linux-2.6-2.6.26/net/core/dev.c 2009-01-21 22:47:29.0 +0100 @@ -4239,8 +4239,11 @@ } /* Fixup kobjects */ + set_exec_env(src_ve); netdev_unregister_kobject(dev); + set_exec_env(dst_ve); err = netdev_register_kobject(dev); + set_exec_env(cur_ve); WARN_ON(err); /* Add the device back in the hashes */ ---8< -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509613: Kernel Compile
Hi there, I'm now ready set to compile a kernel and patch it with the upstream patches. However, last time I compiled a kernel myself, was before the days of make-kpkg - and it's not to compile any kernel, but the official one. This is the best guess I tried after stress-testing google for some hours and suffering lots of unsuccessful attempts: rm -Rf linux-2.6-2.6.26; apt-get source -t testing linux-2.6 cd linux-2.6-2.6.26; make-kpkg --added_patches=openvz clean # get the config from the node into the container ... scp r...@asgard:/boot/config-2.6.26-1-openvz-amd64 .config make-kpkg --append_to_version=-1-openvz --revision=1 --initrd --rootcmd fakeroot -uc -ua buildpackage [answer all of the remaining configure questions by ] This finally generates kernel packages. But I'm still not sure, whether these are the correct ones. Can you confirm that this is the right way to build the kernel packages? Otherwise, what am I doing wrong? Regards, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#460338: Some additional info
I'm using apt-proxy since Sarge and problems like these had always been there. I actually had a cron job restarting apt-proxy every two hours. However, with the current Lenny it happens quite often. I observed the following: 1) It does only happen during apt-get update; never during the upgrade. 2) There is always at least one large (several MB) package file involved, e.g. lenny/main. 3) Another variant is that this large source file dies at 99%. 4) When the update died, an upgrade running on another machine continues to work perfectly. 5) Killing the update by ctrl-c on the client, and restarting apt-get update runs into the same tarpit. 6) Starting an update on another machine will also die. 7) Restarting apt-proxy always helps. Probably, someone familiar with the apt-proxy architecture can use that to close on the bug. Regards, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511348: Patch - SOLVED
Hi Russ,
I think that Kerberos library functions must all return krb5_error_code,
which should be 0 if there is no error. So:
Probably this is something to discuss with the upstream. My personal
conviction is that functions with boolean semantic, shall be boolean
valued. The function has boolean semantic, which is stressed by naming
it as past participle. This idea had its share in confusing the original
authors of the code.
Of course the boolean expression can be moved to the caller as (0 ==
krb5_db_inited(...)) or !krb5_db_inited(...) as done in keytab.c and
using an error valued function. This would beautify the API, but wreck
the semantics.
If I'm right, reverting your patch and instead changing krb5_db_inited to
the following code should also fix the problem:
It does, but it does require a code change in adb_policy_init(), which
considers krb5_db_inited() as boolean valued - and KADM5_OK=0 is false!
Could you try that and see if I'm right?
See patch attached. It does work as well -- and modifies fewer files.
KADM5_OK is from a different set than the KRB5_KDB_ errors (and defined
in a different include), so I did not use that value.
BTW: Do you know, why kadm5_flush() is implemented by closing and
re-opening the database. This creates lots of entirely useless overhead,
if a real db is at the backend. And even for plain files POSIX flush()
should as reliable.
Regards,
- lars.
Index: krb5-1.6.dfsg.4~beta1/src/lib/kadm5/srv/server_misc.c
===
--- krb5-1.6.dfsg.4~beta1.orig/src/lib/kadm5/srv/server_misc.c 2009-01-11
02:00:25.0 +0100
+++ krb5-1.6.dfsg.4~beta1/src/lib/kadm5/srv/server_misc.c 2009-01-11
02:21:20.0 +0100
@@ -22,7 +22,7 @@
adb_policy_init(kadm5_server_handle_t handle)
{
/* now policy is initialized as part of database. No seperate call needed
*/
-if( krb5_db_inited( handle->context ) )
+if( 0 == krb5_db_inited( handle->context ) )
return KADM5_OK;
return krb5_db_open( handle->context, NULL,
Index: krb5-1.6.dfsg.4~beta1/src/lib/kdb/kdb5.c
===
--- krb5-1.6.dfsg.4~beta1.orig/src/lib/kdb/kdb5.c 2009-01-11
02:09:34.0 +0100
+++ krb5-1.6.dfsg.4~beta1/src/lib/kdb/kdb5.c2009-01-11 02:19:30.0
+0100
@@ -642,8 +642,16 @@
krb5_error_code
krb5_db_inited(krb5_context kcontext)
{
-return !(kcontext && kcontext->db_context &&
-((kdb5_dal_handle *) kcontext->db_context)->db_context);
+if (kcontext && kcontext->db_context &&
+ ((kdb5_dal_handle *) kcontext->db_context)->db_context)
+ /* there is no symbol KRB5_KDB_OK, so we return 0,
+i.e. krb5_db_inited() is false - has no errors -, if
+the db is initialized correctly
+ */
+ return(0);
+
+/* Error not initialized otherwise */
+return KRB5_KDB_DBNOTINITED;
}
krb5_error_code
Bug#511348: Patch - SOLVED
Hi Russ,
this solves the LDAP problem. Since it changes some core code, it should
be tested in other set-ups.
ad...@valhalla:~/packages/krb5-kdc/krb5-1.6.dfsg.4~beta1$ cat
patches/krb5_db_inited-fix
Index: krb5-1.6.dfsg.4~beta1/src/include/kdb.h
===
--- krb5-1.6.dfsg.4~beta1.orig/src/include/kdb.h 2009-01-10
15:54:38.0 +0100
+++ krb5-1.6.dfsg.4~beta1/src/include/kdb.h 2009-01-10
15:55:03.0 +0100
@@ -232,7 +232,7 @@
krb5_error_code krb5_db_open( krb5_context kcontext, char **db_args, int
mode );
krb5_error_code krb5_db_init ( krb5_context kcontext );
krb5_error_code krb5_db_create ( krb5_context kcontext, char **db_args );
-krb5_error_code krb5_db_inited ( krb5_context kcontext );
+char krb5_db_inited ( krb5_context kcontext );
krb5_error_code kdb5_db_create ( krb5_context kcontext, char **db_args );
krb5_error_code krb5_db_fini ( krb5_context kcontext );
const char * krb5_db_errcode2string ( krb5_context kcontext, long
err_code );
Index: krb5-1.6.dfsg.4~beta1/src/lib/kdb/kdb5.c
===
--- krb5-1.6.dfsg.4~beta1.orig/src/lib/kdb/kdb5.c 2009-01-10
15:53:14.0 +0100
+++ krb5-1.6.dfsg.4~beta1/src/lib/kdb/kdb5.c 2009-01-10
15:53:34.0 +0100
@@ -639,10 +639,10 @@
return status;
}
-krb5_error_code
+char
krb5_db_inited(krb5_context kcontext)
{
- return !(kcontext && kcontext->db_context &&
+ return (kcontext && kcontext->db_context &&
((kdb5_dal_handle *) kcontext->db_context)->db_context);
}
Index: krb5-1.6.dfsg.4~beta1/src/lib/kdb/keytab.c
===
--- krb5-1.6.dfsg.4~beta1.orig/src/lib/kdb/keytab.c 2009-01-10
15:56:40.0 +0100
+++ krb5-1.6.dfsg.4~beta1/src/lib/kdb/keytab.c 2009-01-10
15:57:09.0 +0100
@@ -141,8 +141,8 @@
xrealm_tgt = is_xrealm_tgt(context, principal);
/* Check whether database is inited. Open is commented */
- if ((kerror = krb5_db_inited(context)))
- return(kerror);
+ if (! krb5_db_inited(context) )
+ return(KRB5_KDB_DBNOTINITED);
/* get_principal */
kerror = krb5_db_get_principal(context, principal, &
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511348: Logs
> (I personally have no idea on the krb524d problems, unfortunately.) I just produced a strace. I do not post it here, it's got 3111 syscalls for a single call to kadm_flush() according to ltrace. But from small portions it's clear that something wicked is happening: hel:/# grep shutdown /tmp/krb.trc shutdown(52, 2 /* send and receive */) = -1 ENOTCONN (Transport endpoint is not connected) shutdown(4294967295, 2 /* send and receive */) = -1 EBADF (Bad file descriptor) shutdown(51, 2 /* send and receive */) = -1 ENOTCONN (Transport endpoint is not connected) shutdown(4294967295, 2 /* send and receive */) = -1 EBADF (Bad file descriptor) shutdown(50, 2 /* send and receive */) = -1 ENOTCONN (Transport endpoint is not connected) shutdown(4294967295, 2 /* send and receive */) = -1 EBADF (Bad file descriptor) shutdown(49, 2 /* send and receive */) = -1 ENOTCONN (Transport endpoint is not connected) shutdown(4294967295, 2 /* send and receive */) = -1 EBADF (Bad file descriptor) shutdown(48, 2 /* send and receive */) = -1 ENOTCONN (Transport endpoint is not connected) shutdown(4294967295, 2 /* send and receive */) = -1 EBADF (Bad file descriptor) Interestingly 48,50,51,52 are successfully written to. All of these fds are read successfully. The strace has 10 connect(), ... Whatever is happening there, it is definitely not an optimal way of doing an idle loop. I suspect that the return codes proliferated from the ldap backend are wrong when evaluated in kadm5_flush in server_init.c at line 405. Regards, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511348: Logs
The problem is that this is a catch-22. KDC first. There's no good ordering that works for all cases. Well, probably not for all cases, but we might do better as we do now: Kerberos is unlikely to retrieve any authentication info from any other database. It may require DNS - e.g. to resolve the LDAP host. Bind will have a hard time using LDAP as backend while using Kerberos for the bind, since it would not have the KDC text entries, before it is up. LDAP is unlikely to authenticate to anything (except for replication cases). Hostnames required at start-up refer to itself and can therefore be considered to exist in /etc/hosts. So LDAP, BIND, Kerberos should catch most setups. But of course the world is larger than that. :) What probably should happen is that krb5kdc should keep retrying the LDAP server for a while rather than giving up and exiting. Yes, that would be a fix ... (I personally have no idea on the krb524d problems, unfortunately.) I made a little progress. The connections are created in kadm5_flush(handle) at line 253 in krb524d.c. For some reason gdb does not follow that call (built with export DEB_BUILD_OPTIONS=debug,noopt,nostrip) - hmm, according to readelf the library has no debugging symbols. Seems like debian/rules does not heed debug,nostrip for the libs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511348: Logs
Ah, forgot to add some logs: /var/log/syslog | grep krb5 (for the time writing the bug report): Jan 9 20:34:56 hel krb5kdc[354]: Unable to access Kerberos database - while initializing database for realm MGR Jan 9 20:34:56 hel krb5kdc[354]: Unable to access Kerberos database - while initializing database for realm MGR Jan 9 20:36:03 hel krb5kdc[682]: setting up network... Jan 9 20:36:03 hel krb5kdc[682]: setting up network... Jan 9 20:36:03 hel krb5kdc[682]: listening on fd 11: udp 127.0.0.1.88 Jan 9 20:36:03 hel krb5kdc[682]: listening on fd 11: udp 127.0.0.1.88 Jan 9 20:36:03 hel krb5kdc[682]: listening on fd 12: udp 127.0.0.1.750 Jan 9 20:36:03 hel krb5kdc[682]: listening on fd 12: udp 127.0.0.1.750 Jan 9 20:36:03 hel krb5kdc[682]: listening on fd 13: udp 172.16.6.3.88 Jan 9 20:36:03 hel krb5kdc[682]: listening on fd 13: udp 172.16.6.3.88 Jan 9 20:36:03 hel krb5kdc[682]: listening on fd 14: udp 172.16.6.3.750 Jan 9 20:36:03 hel krb5kdc[682]: listening on fd 14: udp 172.16.6.3.750 Jan 9 20:36:03 hel krb5kdc[682]: set up 4 sockets Jan 9 20:36:03 hel krb5kdc[682]: set up 4 sockets Jan 9 20:36:03 hel krb5kdc[683]: commencing operation Jan 9 20:36:03 hel krb5kdc[683]: commencing operation Jan 9 21:13:09 hel krb5kdc[683]: Interrupted system call - while selecting for network input(1) Jan 9 21:13:09 hel krb5kdc[683]: Interrupted system call - while selecting for network input(1) Jan 9 21:13:09 hel krb5kdc[683]: shutting down Jan 9 21:13:09 hel krb5kdc[683]: shutting down I guess the first two entries are the reason, why the autostart fails. After a short look to /etc/rc3.d this is clear: S18krb5-kdc, S19slapd (same problems would arise with bind9 and LDAP backend). Is this something to report to the LDAP maintainers? Interestingly none of the entries relate to the offending process 687. I checked the situation now, after restarting the KDC. This suggests that 683 had been /usr/sbin/krb5kdc, and 682 was not running. Now I have the following situation: Jan 9 21:13:09 hel krb5kdc[843]: set up 4 sockets Jan 9 21:13:09 hel krb5kdc[843]: set up 4 sockets Jan 9 21:13:09 hel krb5kdc[844]: commencing operation Jan 9 21:13:09 hel krb5kdc[844]: commencing operation 844 ?Ss 0:00 /usr/sbin/krb5kdc -4none 858 ?Ss 0:00 /usr/sbin/krb524d -m krb524d 858 root 130u IPv4 163255 TCP hel.mgr:35084->hel.mgr:ldaps (ESTABLISHED) (105 sockets at 21:33: 5 sockets per minute!) /var/log/messages: nothing in the relevant interval /var/log/auth.log: Jan 9 20:36:03 hel krb524d[685]: No dictionary file specified, continuing without one. Jan 9 20:36:03 hel krb524d[685]: service entry `krb524' not found, using Regards, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511348: krb5-kdc-ldap: krb524d establishes lots of connections to LDAP over time
Package: krb5-kdc-ldap Version: 1.6.dfsg.4~beta1-5 Severity: important After restarting krb524d opens 5 connections to ldap on my system. Some minutes later, i.e. now, it has already 56 connections - all from the same PID. Since the KDC is not productive yet, I'm not aware of any requests handled in the meantime. Once it reaches the limit of its OpenVZ container it uses 100% CPU. From the outside the KDC remains responsive (now it's 70 connections!). I only noticed the issue, because of the high CPU load and then because of user_bean hits. Increment is in lots of 5 connections. Apart from a single UDP connection to it does not entertain any other connections according to lsof -i. ... now it's 115 connections ... lsof -i reports: krb524d 687 root4u IPv4 155440 TCP hel.mgr:47962->hel.mgr:ldaps (ESTABLISHED) krb524d 687 root7u IPv4 155445 TCP hel.mgr:47963->hel.mgr:ldaps (ESTABLISHED) krb524d 687 root8u IPv4 155450 TCP hel.mgr:47964->hel.mgr:ldaps (ESTABLISHED) krb524d 687 root9u IPv4 155455 TCP hel.mgr:47965->hel.mgr:ldaps (ESTABLISHED) ... krb524d 687 root 139u IPv4 158877 TCP hel.mgr:40286->hel.mgr:ldaps (ESTABLISHED) krb524d 687 root 140u IPv4 158882 TCP hel.mgr:40287->hel.mgr:ldaps (ESTABLISHED) krb524d 687 root 141u IPv4 158887 TCP hel.mgr:40288->hel.mgr:ldaps (ESTABLISHED) krb524d 687 root 142u IPv4 158892 TCP hel.mgr:40289->hel.mgr:ldaps (ESTABLISHED) Another observation is that the KDC does not start automatically on boot. It could be a simple misconfiguration (setting enable somewhere), but maybe it's another evidence. Starting manually using /etc/init.d/krb5-kdc start works flawlessly. Doing a restart kills all the bogous connections and starts the game from the beginning. All my test Tickets are obtained correctly. From the outside the KDC appears completely sane. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-openvz-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages krb5-kdc-ldap depends on: ii krb5-kdc 1.6.dfsg.4~beta1-5 MIT Kerberos key server (KDC) ii libc6 2.7-16 GNU C Library: Shared libraries ii libcomerr21.41.3-1 common error description library ii libkadm55 1.6.dfsg.4~beta1-5 MIT Kerberos administration runtim ii libkeyutils1 1.2-9 Linux Key Management Utilities (li ii libkrb53 1.6.dfsg.4~beta1-5 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries krb5-kdc-ldap recommends no packages. krb5-kdc-ldap suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511272: squid3: remove --enable-poll config option
Package: squid3 Version: 3.0.STABLE8-1 Severity: minor The config option --enable-poll is listed as deprecated, since squid3 is said to do some fancy things to determine the best I/O method. I did a test compile w/o the option, and according to powertop it wakes up the CPU 10-20 times less per second, which relates to about 15% CPU power saving on that machine. I could not notice any performance issue removing the option. However, heavy load tests should be done to verify this. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-openvz-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages squid3 depends on: ii adduser 3.110 add and remove users and groups ii libc62.7-16 GNU C Library: Shared libraries ii libdb4.6 4.6.21-11 Berkeley v4.6 Database Libraries [ ii libgcc1 1:4.3.2-1.1 GCC support library ii libldap-2.4-22.4.11-1OpenLDAP libraries ii libpam0g 1.0.1-4+b1 Pluggable Authentication Modules l ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL - authentication abstra ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3 ii logrotate3.7.1-5 Log rotation utility ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii netbase 4.34Basic TCP/IP networking system ii squid3-common3.0.STABLE8-1 A full featured Web Proxy cache (H squid3 recommends no packages. Versions of packages squid3 suggests: pn resolvconf (no description available) pn smbclient (no description available) pn squid3-cgi (no description available) pn squidclient(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511165: Does not show up with standard clients
I tried to further locate when the bug appears. As it turned out the command line ftp client does not cause the kernel panic, neither in passive nor in standard mode. I also ran the ftpsync Perl script without problems. In order to allow the systems to access ftp, I added the following rule to the applicable chain: iptables -A _chain_ -p tcp -o ppp0 -s _client-system_ --syn -m state --state NEW -j ACCEPT (yes, there is a state established, related rule somewhere at the top of the stack.) However, even after having performed the ftpsync, using gFTP through frox panicked the firewall. However, during further searching for the point of no return, I found that my proxy did not even have permission to open a connection to port 21. After allowing this, I can browse ftp:// URLs through the same squid3 as used by frox without problems. The kernel panic using gFTP still persists. If nf_nat_ftp and nf_conntrack_ftp are not loaded during browser access, the data connection is just dropped by the firewall. Nothing evil happens. This is the frox configuration file. So far untested, but a very similar one ran for a couple of years on my Etch server. /# grep -v '^#' /etc/frox.conf | grep -v '^ *$' Listen proxy.mgr Port 2121 ResolvLoadHack wontresolve.doesntexist.abc User frox Group frox WorkingDir /srv/proxy/frox LogLevel 25 LogFile /var/log/frox.log PidFile /var/run/frox.pid BounceDefend yes CacheModule http HTTPProxy 127.0.0.1:8080 MinCacheSize 5000 DoNTP yes MaxForks 10 MaxForksPerHost 4 ACL Allow sleipnir - * gFTP on sleipnir is configured to use: Proxy: proxy.mgr:2121 Typ: u...@host NOAUTH USER %...@%hh PASS %hp ... and yes proxy.mgr resolves to the OpenVZ container homing the frox. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#405495: ldapdb auxprop configuration -- RESOLVED
So thanks to all of you,
adding the following dpatch as indicated by Eric resolves the SEGFAULT
and I can resume troubleshooting my configuration issues :(
ad...@valhalla:~/packages/cyrus-sasl2$ cat 0021_fix_sasl_mutex.dpatch
8<-
#! /bin/sh /usr/share/dpatch/dpatch-run
## 0021_fix_sasl_mutex.dpatch by
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fix SEGFAULT on sasl_mutex. Debian Bug #405495
@DPATCH@
--- trunk~/lib/common.c 2009-01-05 12:20:53.0 +0100
+++ trunk/lib/common.c 2009-01-05 12:24:19.0 +0100
@@ -150,9 +150,17 @@
&sasl_mutex_free
};
-void sasl_set_mutex(sasl_mutex_alloc_t *n, sasl_mutex_lock_t *l,
- sasl_mutex_unlock_t *u, sasl_mutex_free_t *d)
-{
+void sasl_set_mutex(sasl_mutex_alloc_t *n,
+ sasl_mutex_lock_t *l,
+ sasl_mutex_unlock_t *u,
+ sasl_mutex_free_t *d)
+{
+ /* Disallow mutex function changes once sasl_client_init
+ and/or sasl_server_init is called */
+ if(_sasl_server_cleanup_hook || _sasl_client_cleanup_hook){
+return;
+ }
+
_sasl_mutex_utils.alloc=n;
_sasl_mutex_utils.lock=l;
_sasl_mutex_utils.unlock=u;
8<-
Regards,
- lars.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#405495: Patch available
During writing my last reply, the following reached me from Howard Chu: Based on your backtrace, pretty sure you're running into the bug that was discussed here http://asg.andrew.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=8954 I reported this to the Ubuntu folks https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/280982 but looking at the Debian Changelog, I don't think the Debian guys have patched it yet. http://packages.debian.org/changelogs/pool/main/c/cyrus-sasl2/cyrus-sasl2_2.1.22.dfsg1-23/changelog So, it looks like this bug can be fixed! Regards, - lars. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#405495: Still not resolved
Hi there, the bug persists in current Lenny. I'm currently discussing it on the SASL list (thread: ldapdb auxprop configuration) I'm running cyrus-imap to authenticate users using the ldapdb auxprop against a remote ldaps: host. During the DIGEST-MD5 or CRAM-MD5 authentication of the user using imtest imapd SEGFAULTs. The ltrace suggests that it happens somewhere in the SASL layer. The setup is Debian Lenny kept current daily on an Intel Core2-Quad, i.e. amd64 build. So what I did was to use CYRUS_VERBOSE=100 in /etc/default/cyrus2.2 and used the 15 second delay to attach a gdb. The following happened and produced the backtrace of the SEGFAULT: hermod:/# imtest -u cyrus -a cyrus -v -p imap -m DIGEST-MD5 hermod.mgr S: * OK hermod.mgr Cyrus IMAP4 v2.2.13-Debian-2.2.13-14 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=NTLM AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR S: C01 OK Completed C: A01 AUTHENTICATE DIGEST-MD5 S: + bm9uY2U9IjNFZzIrY2xsci84dmREdXprTkd3a1VmL25XYTRBVnRXQmMxSGpndFBiVEk9IixyZWFsbT0iaGVybW9kLm1nciIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M= Please enter your password: C: dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0iaGVybW9kLm1nciIsbm9uY2U9IjNFZzIrY2xsci84dmREdXprTkd3a1VmL25XYTRBVnRXQmMxSGpndFBiVEk9Iixjbm9uY2U9IjluczF0dmwwMUhWU095dzlNZXRXK0ltRnVyWHRINDd4TFhyUjEvcXpNZHM9IixuYz0wMDAwMDAwMSxxb3A9YXV0aC1jb25mLGNpcGhlcj1yYzQsbWF4YnVmPTEwMjQsZGlnZXN0LXVyaT0iaW1hcC9oZXJtb2QubWdyIixyZXNwb25zZT1lZmYxZjk2MjUyNzlmY2UyMDY3MmIxOTg1NjIzZmIwYw== failure: prot layer failure Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fa6ca1e3700 (LWP 5409)] 0x7fa6c72ed4aa in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0x7fa6c72ed4aa in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x7fa6c32b75a9 in ldap_pvt_thread_mutex_lock (mutex=0x1) at /home/admin/packages/openldap/openldap-2.4.11/libraries/libldap_r/thr_posix.c:296 #2 0x7fa6c32c112b in ldap_pvt_sasl_mutex_lock (mutex=0x1) at cyrus.c:1294 #3 0x7fa6c4b69828 in digestmd5_client_mech_step (conn_context=0x2094440, params=0x20960b0, serverin=0x0, serverinlen=0, prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c, oparams=0x209a510) at digestmd5.c:3955 #4 0x7fa6c9dc25e6 in sasl_client_step (conn=0x2099ca0, serverin=0x0, serverinlen=0, prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c) at client.c:658 #5 0x7fa6c9dc2445 in sasl_client_start (conn=0x2099ca0, mechlist=0x2041d40 "DIGEST-MD5", prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c, mech=0x7fffd21e8778) at client.c:606 #6 0x7fa6c32bfc79 in ldap_int_sasl_bind (ld=0x2053880, dn=0x0, mechs=0x2041d40 "DIGEST-MD5", sctrls=0x0, cctrls=0x0, flags=2, interact=0x7fa6c34fd704 , defaults=0x204dce0) at cyrus.c:689 #7 0x7fa6c32c3b7f in ldap_sasl_interactive_bind_s (ld=0x2053880, dn=0x0, mechs=0x2041d40 "DIGEST-MD5", serverControls=0x0, clientControls=0x0, flags=2, interact=0x7fa6c34fd704 , defaults=0x204dce0) at sasl.c:464 #8 0x7fa6c34fd96c in ldapdb_connect (ctx=0x204dce0, sparams=0x20516c0, user=0x2052f71 "cyrus", ulen=5, cp=0x7fffd21e8910) at ldapdb.c:106 #9 0x7fa6c34fdd45 in ldapdb_auxprop_lookup (glob_context=0x204dce0, sparams=0x20516c0, flags=0, user=0x2052f71 "cyrus", ulen=5) at ldapdb.c:178 #10 0x7fa6c9dbe881 in _sasl_auxprop_lookup (sparams=0x20516c0, flags=0, user=0x2052f71 "cyrus", ulen=5) at auxprop.c:898 #11 0x7fa6c9dbf309 in _sasl_canon_user (conn=0x20521d0, user=0x2052f71 "cyrus", ulen=5, flags=1, oparams=0x2052a40) at canonusr.c:190 #12 0x7fa6c4b6556b in digestmd5_server_mech_step2 (stext=0x2054080, sparams=0x20516c0, clientin=0x7fffd21e8e10 "username=\"cyrus\",realm=\"hermod.mgr\",nonce=\"3Eg2+cllr/8vdDuzkNGwkUf/nWa4AVtWBc1HjgtPbTI=\",cnonce=\"9ns1tvl01HVSOyw9MetW+ImFurXtH47xLXrR1/qzMds=\",nc=0001,qop=auth-conf,cipher=rc4,maxbuf=1024,digest-u"..., clientinlen=262, serverout=0x7fffd21e8e00, serveroutlen=0x7fffd21e8dfc, oparams=0x2052a40) at digestmd5.c:2301 #13 0x7fa6c4b666cc in digestmd5_server_mech_step (conn_context=0x2054080, sparams=0x20516c0, clientin=0x7fffd21e8e10 "username=\"cyrus\",realm=\"hermod.mgr\",nonce=\"3Eg2+cllr/8vdDuzkNGwkUf/nWa4AVtWBc1HjgtPbTI=\",cnonce=\"9ns1tvl01HVSOyw9MetW+ImFurXtH47xLXrR1/qzMds=\",nc=0001,qop=auth-conf,cipher=rc4,maxbuf=1024,digest-u"..., clientinlen=262, serverout=0x7fffd21e8e00, serveroutlen=0x7fffd21e8dfc, oparams=0x2052a40) at digestmd5.c:2689 #14 0x7fa6c9dcd696 in sasl_server_step (conn=0x20521d0, clientin=0x7fffd21e8e10 "username=\"cyrus\",realm=\"hermod.mgr\",nonce=
Bug#509613: [Bug 1129] Kernel OOPS with netdev type devices
Hi Vitaliy, Hi Debian Team, the issue is more severe than it seemed. Actually, the kernel crashes every time the container is restarted. The first start after initial boot is flawless and the container works nicely. I'm setting up intermediate start scripts and a container with a compiler to forge a kernel including the patches. If my family doesn't kill me within the next days. Some recent logs: /var/log/messages: Dec 23 22:01:30 asgard kernel: [ 123.131912] CT: 1007: stopped Dec 23 22:01:38 asgard kernel: [ 131.238524] CT: 1007: started Dec 23 22:01:38 asgard kernel: [ 131.254520] PGD 223dd0067 PUD 223077067 PMD 0 Dec 23 22:01:38 asgard kernel: [ 131.254520] CPU: 1 Dec 23 22:01:38 asgard kernel: [ 131.254520] Modules linked in: pppoe pppox vzethdev vznetdev simfs vzrst vzcpt tun vzdquota vzmon vzdev xt_length ipt_ttl xt_tcpmss xt_TCPMSS xt_limit xt_dscp ipt_REJECT kvm_intel kvm ipv6 ppp_generic slhc iptable_mangle ipt_LOG xt_tcpudp xt_state xt_multiport iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables xfs ext2 loop parport_pc serio_raw shpchp snd_hda_intel parport pci_hotplug snd_pcm snd_timer snd soundcore snd_page_alloc pcspkr psmouse i2c_i801 iTCO_wdt i2c_core intel_agp button evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod raid456 md_mod async_xor async_memcpy async_tx xor sg sr_mod cdrom sd_mod ata_piix ata_generic sundance mii ide_pci_generic ahci jmicron r8169 libata scsi_mod dock ide_core ehci_hcd uhci_hcd thermal processor fan thermal_sys Dec 23 22:01:38 asgard kernel: [ 131.257558] Pid: 6481, comm: vzctl Not tainted 2.6.26-1-openvz-amd64 #1 036test001 Dec 23 22:01:38 asgard kernel: [ 131.257558] RIP: 0010:[] [] make_class_name+0x2a/0x7c Dec 23 22:01:38 asgard kernel: [ 131.257558] RSP: 0018:810222907d58 EFLAGS: 00010246 Dec 23 22:01:38 asgard kernel: [ 131.257558] RAX: 81022445ee00 RBX: RCX: Dec 23 22:01:38 asgard kernel: [ 131.257558] RDX: RSI: fffa RDI: 00f00020 Dec 23 22:01:38 asgard kernel: [ 131.257558] RBP: 00f00020 R08: R09: 81022f060150 Dec 23 22:01:38 asgard kernel: [ 131.257558] R10: 81022bc10be0 R11: 803772ad R12: 81022bdd7578 Dec 23 22:01:38 asgard kernel: [ 131.257558] R13: 810222c5eb80 R14: 804fb980 R15: 804fb980 Dec 23 22:01:38 asgard kernel: [ 131.257558] FS: 7fcefd7bd6e0() GS:81022e4c78c0() knlGS: Dec 23 22:01:38 asgard kernel: [ 131.257558] CS: 0010 DS: ES: CR0: 8005003b Dec 23 22:01:38 asgard kernel: [ 131.257558] CR2: 00f00020 CR3: 0002230a8000 CR4: 26e0 Dec 23 22:01:38 asgard kernel: [ 131.257558] DR0: DR1: DR2: Dec 23 22:01:38 asgard kernel: [ 131.257558] DR3: DR6: 0ff0 DR7: 0400 Dec 23 22:01:38 asgard kernel: [ 131.257558] Process vzctl (pid: 6481, veid=0, threadinfo 810222906000, task 81022c5c5090) Dec 23 22:01:38 asgard kernel: [ 131.257558] Stack: 81022bdd74c8 8030fdf7 81022bdd7488 81022bdd7488 Dec 23 22:01:38 asgard kernel: [ 131.257558] 81022bdd7578 80376d20 81022bdd7488 81022bdd7000 Dec 23 22:01:38 asgard kernel: [ 131.257558] 81022e033070 803776e9 81022c5c5090 81022bdd7000 Dec 23 22:01:38 asgard kernel: [ 131.257558] Call Trace: Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? kref_put+0x41/0x4c Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? device_remove_class_symlinks+0x40/0xbe Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? device_del+0x51/0x15d Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? __dev_change_net_namespace+0x212/0x2e4 Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? :vzmon:real_ve_dev_map+0xb2/0x1c7 Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? :vzmon:vzcalls_ioctl+0x1b3/0x47a Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? ub_slab_uncharge+0x36/0x41 Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? :vzdev:vzctl_ioctl+0x34/0x50 Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? vfs_ioctl+0x21/0x6b Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? do_vfs_ioctl+0x248/0x261 Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? sys_rt_sigaction+0x55/0x8c Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? sys_ioctl+0x3c/0x5c Dec 23 22:01:38 asgard kernel: [ 131.257558] [] ? system_call_after_swapgs+0x8a/0x8f Dec 23 22:01:38 asgard kernel: [ 131.257558] Dec 23 22:01:38 asgard kernel: [ 131.257558] Dec 23 22:01:38 asgard kernel: [ 131.258520] RSP Dec 23 22:01:38 asgard kernel: [ 131.259307] ---[ end trace ea88d2e8e559901d ]--- /var/log/syslog: Dec 23 22:01:30 asgard kernel: [ 123.131912] CT: 1007: stopped Dec 23 22:01:38 asgard kernel: [ 131.238524] CT: 1007: started Dec 23 22:01:38 asgard kerne
Bug#509613: linux-image-2.6-openvz-amd64: kernel oops on net device reconfiguration
Package: linux-image-2.6-openvz-amd64 Severity: normal Tags: patch I had Kernel oops every (3) time, when reconfiguring properties of eth3, mapped to a container by vzctl --netdev_add. The kernel oops leads to blocking the entire machine from inputs. In two cases I managed to issue "sync && halt", which finally failed when init tries to bring down the containers. It reiterates a whole night trying - before I pushed the reset button. See the following links for more details: http://bugzilla.openvz.org/show_bug.cgi?id=1129 http://forum.openvz.org/index.php?t=tree&&th=7031&goto=34209#msg_34209 I had brief communication with the openvz developers and he came to the following conclusion: I looked into debian 2.6.26-11 and 2.6.26-12 and found that both these kernels don't have fix commits: 9baf6095c98f930e02769b09addbd4b5f18772d5 35f41f111afc1a9f024153ac43d8d829a894fb2b The openvz changelogs report major changes to the functions listed in the logs which have caused the oops. So whether or not the bug is actually related to that changes, it might be a good idea to include these fixes to either fix the bug or at least stay aligned with the openvz team concerning a buggy code. Due to a hardware failure I only have a critical production server for testing. If that server fails, you won't hear, since it'd put me offline entirely. ;) I'll not be able to do any testing with reasonable effort before the systems boots without manually starting the services, which will be when all services are in place - hopefully sometime within my new years holidays. (Reportbug just failed, since I had no SMTP rule in iptables so far). Provoking the error (what's been common to all 3 incidents): - create a lenny openvz container - add a physical interface using --netdev_add - run the container - re-configure any settings of the physical interface from inside the container - restart the container The system crashes when bringing down the container and the entire accessibilty creeps away after the oops. Issuing sync on the console immediately after the oops worked and a shutdown sequence proceeded up to the point where the containers are brought down. To complete the information - this is the dump sent to the openvz crew, which is not on the net: Dec 14 19:48:19 asgard kernel: [ 4541.586522] CT: 1007: started Dec 14 19:48:19 asgard kernel: [ 4541.47] PGD 20c5c9067 PUD 0 Dec 14 19:48:19 asgard kernel: [ 4541.47] CPU: 1 Dec 14 19:48:19 asgard kernel: [ 4541.47] Modules linked in: ipt_LOG xt_state ipt_MASQUERADE iptable_ nat nf_nat nf_conntrack_ipv4 nf_conntrack vzethdev vznetdev simfs vzrst vzcpt tun vzdquota vzmon vzdev xt _length ipt_ttl iptable_filter xt_multiport xt_limit xt_dscp ipt_REJECT kvm_intel kvm xt_TCPMSS xt_tcpmss xt_tcpudp iptable_mangle ip_tables x_tables pppoe pppox ipv6 ppp_generic slhc xfs ext2 loop iTCO_wdt shp chp parport_pc intel_agp snd_hda_intel pci_hotplug serio_raw i2c_i801 parport pcspkr psmouse i2c_core snd _pcm snd_timer snd soundcore snd_page_alloc button evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm _mod raid456 md_mod async_xor async_memcpy async_tx xor sg sr_mod cdrom sd_mod ata_piix ata_generic sunda nce mii ide_pci_generic jmicron r8169 ide_core ehci_hcd ahci libata scsi_mod dock uhci_hcd thermal proces sor fan thermal_sys Dec 14 19:48:19 asgard kernel: [ 4541.47] Pid: 7312, comm: vzctl Not tainted 2.6.26-1-openvz-amd64 #1 036test001 Dec 14 19:48:19 asgard kernel: [ 4541.47] RIP: 0010:[] [] make_c lass_name+0x2a/0x7c Dec 14 19:48:19 asgard kernel: [ 4541.47] RSP: 0018:81020c54bd58 EFLAGS: 00010246 Dec 14 19:48:19 asgard kernel: [ 4541.47] RAX: 810223967000 RBX: RCX: ff ff Dec 14 19:48:19 asgard kernel: [ 4541.47] RDX: RSI: fffa RDI: 000500 01 Dec 14 19:48:19 asgard kernel: [ 4541.47] RBP: 00050001 R08: R09: 81022f 060150 Dec 14 19:48:19 asgard kernel: [ 4541.47] R10: 81022b4d15f0 R11: 8037713d R12: 81022b ced578 Dec 14 19:48:19 asgard kernel: [ 4541.47] R13: 810225930080 R14: 804fb980 R15: 80 4fb980 Dec 14 19:48:19 asgard kernel: [ 4541.47] FS: 7fa9aa3b96e0() GS:81022e4c78c0() knlGS: Dec 14 19:48:19 asgard kernel: [ 4541.47] CS: 0010 DS: ES: CR0: 8005003b Dec 14 19:48:19 asgard kernel: [ 4541.47] CR2: 00050001 CR3: 00022585c000 CR4: 26e0 Dec 14 19:48:19 asgard kernel: [ 4541.47] DR0: DR1: DR2: Dec 14 19:48:19 asgard kernel: [ 4541.47] DR3: DR6: 0ff0 DR7: 0400 Dec 14 19:48:19 asgard kernel: [ 4541.47] Process vzctl (pid: 7312, veid=0, threadinfo 81020c54a000, task 810225194810) Dec 14 19:48:19 asgard kernel: [ 4541.47] Stack: 81022bced4c8 fff
Bug#505914: smbldap-tools: smdldap-useradd strangely parses options
Package: smbldap-tools Version: 0.9.4-1 Severity: important smbldap-useradd does strange things. The following line: smbldap-useradd -a -c "Dr. Lars Hanke" -u 1001 -A -G 100 -N "Hanke" -P -S "Lars" -M mgr mgr added uid=100 (instead of mgr) and reported that -N is non-numeric. The latter is right, but ;) It did not ask for a password. smbldap-useradd -a -c "Dr. Lars Hanke" -u 1001 -A -P -M mgr mgr added mgr finally, complained that -P in non-numeric and neither asked for a password. The exact errors unfortunately are lost due to nano taking over the terminal. The users are created overly correct, however incomplete, in the LDAP. smbldap-usershow reports them as they are created in the LDAP. Even if this issue should be due to misconfiguration, which I currently are not aware of, at least the error messages are strictly misleading then. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-openvz-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages smbldap-tools depends on: ii libcrypt-smbhash-perl 0.12-2 generate LM/NT hash of a password ii libdigest-sha1-perl 2.11-2+b1 NIST SHA-1 message digest algorith ii libio-socket-ssl-perl 1.16-1 Perl module implementing object or ii libnet-ldap-perl 1:0.36-1 A Client interface to LDAP servers ii libunicode-maputf8-perl 1.11-2 Perl module for conversing between ii perl 5.10.0-17 Larry Wall's Practical Extraction smbldap-tools recommends no packages. smbldap-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462317: libqt4-sql: Conversion of TEXT columns to QString has trailing garbage
Package: libqt4-sql Version: 4.2.1-2+etch1 Severity: normal Reading from MySQL columns of type TEXT to QString, e.g. query.value(col).toString(), produces trailing garbage characters to be included in the string. The same compiled code works flawless, if the column type is changed to VARCHAR, e.g. by alter table profile change val val VARCHAR(255); in mysql. I bypassed the issue backporting Qt 4.3.3 from lenny as can be seen from the configuration below (libqt4-core). This also resolves the issue from #409937. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libqt4-sql depends on: ii libc6 2.3.6.ds1-13etch4 GNU C Library: Shared libraries ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libgcc11:4.1.1-21GCC support library ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libmysqlclient15off5.0.32-7etch4 mysql database client library ii libpq4 8.1.11-0etch1 PostgreSQL C client library ii libqt4-core4.3.3-2 Qt 4 core non-GUI functionality ru ii libsqlite0 2.8.17-2 SQLite shared library ii libsqlite3-0 3.3.8-1.1 SQLite 3 shared library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3-13compression library - runtime libqt4-sql recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409937: libqt4-sql: The method QSqlDatabase::removeDatabase() never returns
I struggled with the same kind of bug, but it was not the call to removeDatabase(), but the return from main(), which died on a futex, when a second database connection was opened. I solved the issue by backporting Qt 4.3.3 from the lenny sources. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293886: slapd: Deadlocks on SASL Auth using TLS
Severity: important
Package: slapd
Version: 2.1.30-3
Applies to: Debian/Sarge
Since the bug may be related to libraries against which slapd is linked, here
the whole story of probably relevant packages:
ii slapd 2.1.30-3 OpenLDAP server (slapd)
ii libsasl2 2.1.19-1.5 Authentication abstraction library
ii libgnutls101.0.4-8GNU TLS library - runtime library
ii libgnutls111.0.16-9 GNU TLS library - runtime library
ii libgnutls7 0.8.12-6 GNU TLS library - runtime library
ii libio-socket-s 0.96-1 Class implementing an object oriented interf
ii libnet-ssleay- 1.25-1 Perl module for Secure Sockets Layer (SSL)
ii libssl0.9.70.9.7e-2 SSL shared libraries
ii openssl0.9.7e-2 Secure Socket Layer (SSL) binary and related
Problem occurs with commands like:
ldapsearch -U mailadmin -W -b 'ou=mailbox,dc=uac,dc=mgr' -Y DIGEST-MD5 -H
'ldaps://adept.mgr'
or
ldapsearch -U mailadmin -W -b 'ou=mailbox,dc=uac,dc=mgr' -Y DIGEST-MD5 -ZZ -H
'ldap://adept.mgr'
No problems occur with:
ldapsearch -U mgr -W -b 'ou=mailbox,dc=uac,dc=mgr' -Y GSSAPI -H
'ldaps://adept.mgr'
or
ldapsearch -D 'cn=admin,dc=mgr' -x -W -b 'ou=mailbox,dc=uac,dc=mgr' -H
'ldaps://adept.mgr'
Thus the issue seems to be tied to standard SASL mechanisms over TLS. GSSAPI
for some reason did never fail. DIGEST-MD5 fails almost every time.
This is what happens (slapd -d 1):
connection_get(12): got connid=3
connection_read(12): checking for input on id=3
ber_get_next
ber_get_next: tag 0x30 len 29 contents:
ber_get_next
ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable)
do_extended
ber_scanf fmt ({m) ber:
send_ldap_extended: err=0 oid= len=0
send_ldap_response: msgid=1 tag=120 err=0
ber_flush: 14 bytes to sd 12
connection_get(12): got connid=3
connection_read(12): checking for input on id=3
connection_get(12): got connid=3
connection_read(12): checking for input on id=3
TLS certificate verification: depth: 0, err: -49, subject: -unknown-, issuer:
-unknown-
TLS certificate verification: Error, Unknown error
connection_read(12): unable to get TLS client DN error=49 id=3
connection_get(12): got connid=3
connection_read(12): checking for input on id=3
ber_get_next
ber_get_next: tag 0x30 len 24 contents:
do_bind
ber_get_next
ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable)
ber_scanf fmt ({imt) ber:
ber_scanf fmt ({m) ber:
ber_scanf fmt (}}) ber:
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_sasl_bind: dn () mech DIGEST-MD5
SASL [conn=3] Debug: DIGEST-MD5 server step 1
connection_get(12): got connid=3
connection_write(12): waking output for id=3
[... endless loop of the last two lines ...]
In very rare cases, slapd recovers continuing as follows after hundreds of the
loop pairs:
[ ... loop ...]
connection_get(12): got connid=3
connection_write(12): waking output for id=3
send_ldap_sasl: err=14 len=176
send_ldap_response: msgid=2 tag=97 err=14
ber_flush: 195 bytes to sd 12
<== slap_sasl_bind: rc=14
connection_get(12): got connid=3
connection_write(12): waking output for id=3
connection_get(12): got connid=3
connection_read(12): checking for input on id=3
ber_get_next
ber_get_next: tag 0x30 len 311 contents:
do_bind
ber_get_next
ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable)
ber_scanf fmt ({imt) ber:
ber_scanf fmt ({m) ber:
ber_scanf fmt (m) ber:
ber_scanf fmt (}}) ber:
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_sasl_bind: dn () mech DIGEST-MD5
SASL [conn=3] Debug: DIGEST-MD5 server step 2
slap_sasl_getdn: u:id converted to uid=mailadmin,cn=MGR,cn=DIGEST-MD5,cn=auth
>>> dnNormalize:
=> ldap_bv2dn(uid=mailadmin,cn=MGR,cn=DIGEST-MD5,cn=auth,0)
<= ldap_bv2dn(uid=mailadmin,cn=MGR,cn=DIGEST-MD5,cn=auth,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=mailadmin,cn=mgr,cn=digest-md5,cn=auth,272)=0
<<< dnNormalize:
==>slap_sasl2dn: converting SASL name
uid=mailadmin,cn=mgr,cn=digest-md5,cn=auth to a DN
[ .. and so on for the standard slapd processing of the request ]
Quitting slapd (^C interactively, kill -TERM, or /etc/init.d/slapd stop) can
take arbitrary long time to complete, then. Interactively slapd reports that
it's waiting for a thread.
If you need more info, do not hesitate to ask, the issue is quite
reproducible.
Best regards,
- lars.
--
Dr. Lars Hanke
µAC - Microsystem Accessory Consult
Ingenieurbüro für Technologietransfer
Nordstraße 60
53859 Niederkassel
>> Realize the possible <<
