Bug#805026: Unpackaged plugins in package strongswan
Dear maintainers, I'm indebted to you for a beer. Found my missing plugins in "libcharon-extra-plugins". Thanks and sorry for the report. Thomas
Bug#805026: strongswan: Unpackaged plugins in package strongswan
Package: strongswan Version: 5.2.1-6+deb8u1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I was trying to set up an XAUTH based tunnel between a Cisco Client and a Strongswan gateway. I discovered that the libstrongswan-xauth.so plugin is missing as well as the libstrongswan-unity.so as well as their respective *.conf files in /usr/share/strongswan/templates/config/plugins * What exactly did you do (or not do) that was effective (or ineffective)? I've "apt-get source"ed the strongswan package and built it. * What was the outcome of this action? The missing plugins are built and available in the strongswan-5.2.1/debian/tmp/usr/lib/ipsec/plugins directory of the dpkg-buildpackage but are not packaged into the binary package. This disables quite some functionality of strongswan as about 20 other plugins are not packaged too. * What outcome did you expect instead? I expected all enabled plugins of strongswan to be in the binary package. *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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 strongswan depends on: ii strongswan-charon 5.2.1-6+deb8u1 ii strongswan-starter 5.2.1-6+deb8u1 strongswan recommends no packages. strongswan suggests no packages. -- no debconf information
Bug#567520: Patch for the defaultPasswordMaxAge
Hi there,
here I've been also been biten by that issue and patched my
smbldap-passwd as shown in the patch attached.
This issue is also known by the following bug-ID
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505914
and should have been patched by now, isn't it?
Best regards
t++
--- smbldap-passwd.orig 2010-04-09 06:13:13.0 +0200
+++ smbldap-passwd 2010-04-09 06:16:52.0 +0200
@@ -274,13 +274,22 @@
]
);
} else {
- $modify = $ldap_master->modify ( "$dn",
- changes => [
- replace => [userPassword => "$hash_password"],
- replace => [shadowLastChange => "$shadowLastChange"],
- replace => [shadowMax => "$config{defaultMaxPasswordAge}"]
- ]
- );
+if (defined($config{defaultMaxPasswordAge})) {
+$modify = $ldap_master->modify ( "$dn",
+changes => [
+replace => [userPassword => "$hash_password"],
+replace => [shadowLastChange => "$shadowLastChange"],
+replace => [shadowMax => "$config{defaultMaxPasswordAge}"]
+]
+);
+} else {
+$modify = $ldap_master->modify ( "$dn",
+changes => [
+replace => [userPassword => "$hash_password"],
+replace => [shadowLastChange => "$shadowLastChange"],
+]
+);
+}
}
$modify->code && warn "Failed to modify UNIX password: ", $modify->error ;
}
Bug#494547: RRDTool4 and munin - still issues - downgrade of librrds-perl solves them
Just got the following packages into testing/lenny: Wähle vormals abgewähltes Paket librrd4. Entpacke librrd4 (aus .../librrd4_1.3.1-3_amd64.deb) ... Vorbereiten zum Ersetzen von librrds-perl 1.2.28-1 (durch .../librrds-perl_1.3.1-3_amd64.deb) ... Vorbereiten zum Ersetzen von rrdtool 1.2.28-1 (durch .../rrdtool_1.3.1-3_amd64.deb) ... After the upgrade munin starts to complain with a message all five minutes stating: (process:18433): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() After rolling back the upgrade by issuing: dpkg -i librrd2_1.2.28-1_amd64.deb \ rrdtool_1.2.28-1_amd64.deb from /var/cache/archives the error is still there. But when I rolled back librrds-perl_1.3.1-3_amd64.deb to librrds-perl_1.2.28-1_amd64.deb the error is gone. This would mean that the librrds-perl_1.3.1-3_amd64.deb is the culprit. t++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496136: Gnome-Panel issues since the update of the libxml2
It seems like the crash of gnome-panel here and the hang of your menus are related. Ever since the upgrade as of August 22nd the gnome-panel crashes reproducably leaving a message in the syslog even when selecting the properties menu of the gnome-panel: Aug 23 03:00:58 sofa kernel: gnome-panel[26736]: segfault at 18 ip 7f93249ce5c8 sp 7fff30a0e6c0 error 4 in libc-2.7.so[7f9324959000+14a000] A backtrace reveals that the crash in libc.so.6 is right after a call issued by libxml2: ... Attaching to process 27391 Reading symbols from /usr/bin/gnome-panel...(no debugging symbols found)...done. ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ff78865e770 (LWP 27391)] 0x7ff7847675c8 in ?? () from /lib/libc.so.6 (gdb) bt full #0 0x7ff7847675c8 in ?? () from /lib/libc.so.6 No symbol table info available. #1 0x7ff784767a76 in free () from /lib/libc.so.6 No symbol table info available. #2 0x7ff7843e2065 in xmlParseEntityDecl () from /usr/lib/libxml2.so.2 No symbol table info available. #3 0x7ff7843e27e6 in xmlParseMarkupDecl () from /usr/lib/libxml2.so.2 No symbol table info available. #4 0x7ff7843e287e in ?? () from /usr/lib/libxml2.so.2 No symbol table info available. #5 0x7ff7843e3626 in xmlParseChunk () from /usr/lib/libxml2.so.2 No symbol table info available. #6 0x7ff77cfd1cd0 in ?? () from /usr/lib/librsvg-2.so.2 No symbol table info available. #7 0x7ff77d203d7c in ?? () from /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so No symbol table info available. #8 0x7ff78642fc99 in gdk_pixbuf_loader_write () from /usr/lib/libgdk_pixbuf-2.0.so.0 No symbol table info available. #9 0x7ff786c18530 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. When I rolled back my libxml2 by doing dpkg -i libxml2_2.6.32.dfsg-2_amd64.deb \ libxml2-utils_2.6.32.dfsg-2_amd64.deb the gnome-panel is working again so that I'm not sure about whether this is a bug in gnome-panel or libxml2. Nautilus is showing the same behavior like gnome-panel and is working again after the downgrade of libxml2. Best regards t++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463915: libnss-ldapd: Segfaulting on AMD64
Package: libnss-ldapd Version: 0.5+b1 Severity: important On my AMD64 box the nslcd demon crashes quite frequently. After the crash no mappings are resolved any more as far as they are fetched from the LDAP server in the LAN. Local mappings still work. Those crashes occur about ten to twenty times a day without any visible action, although I was not able to find a way to reproduce the crash reliably: [EMAIL PROTECTED]:/var/log# grep nslcd.*segfault syslog.0 Feb 3 08:19:10 sofa kernel: nslcd[5358]: segfault at ac0008c0 rip 00408eb0 rsp 41000f70 error 4 Feb 4 05:44:37 sofa kernel: nslcd[18186]: segfault at ac00af90 rip 0040b6ee rsp 41801b60 error 4 Feb 4 05:44:44 sofa kernel: nslcd[18234]: segfault at ac00af90 rip 0040b6ee rsp 407ffb60 error 4 Feb 4 05:50:02 sofa kernel: nslcd[18745]: segfault at ac000a50 rip 00408eb0 rsp 41000f70 error 4 Feb 4 06:09:23 sofa kernel: nslcd[21479]: segfault at ac00b350 rip 004041f6 rsp 41000630 error 4 Feb 4 06:10:01 sofa kernel: nslcd[21563]: segfault at ac00b150 rip 00408eb0 rsp 41801f70 error 4 Feb 4 06:25:02 sofa kernel: nslcd[22085]: segfault at ac000a20 rip 00408eb0 rsp 42002f70 error 4 Feb 4 06:35:02 sofa kernel: nslcd[24194]: segfault at ac003d00 rip 00408eb0 rsp 407fff70 error 4 Feb 4 07:25:02 sofa kernel: nslcd[28654]: segfault at ac0009c0 rip 00408eb0 rsp 42803f70 error 4 Feb 4 07:35:01 sofa kernel: nslcd[32760]: segfault at ac001c20 rip 00408eb0 rsp 41000f70 error 4 Feb 4 07:39:01 sofa kernel: nslcd[1077]: segfault at ac00b150 rip 00408eb0 rsp 41000f70 error 4 The backtrace of the coredump is as follows: #0 0x00408eb0 in ?? () No symbol table info available. #1 0x00409069 in ?? () No symbol table info available. #2 0x00403565 in ?? () No symbol table info available. #3 0x2b84742dc3f7 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x2b84745c897d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x in ?? () No symbol table info available. (gdb) The syslog shows regarding this segfault nothing more than: Feb 4 07:39:01 sofa kernel: nslcd[1077]: segfault at ac00b150 rip 00408eb0 rsp 41000f70 error 4 Another crashed session which was done via "nslcd -d" on the commandline revealed this log: nslcd: DEBUG: connection from pid=4932 uid=0 gid=0 nslcd: DEBUG: nslcd_group_all() nslcd: DEBUG: myldap_search(base="dc=antepoth,dc=de", filter="(objectClass=posixGroup)") nslcd: DEBUG: connection from pid=4932 uid=0 gid=0 nslcd: DEBUG: nslcd_passwd_byuid(15325) nslcd: DEBUG: myldap_search(base="dc=antepoth,dc=de", filter="(&(objectClass=posixAccount)(uidNumber=15325))") nslcd: DEBUG: connection from pid=4932 uid=0 gid=0 nslcd: DEBUG: nslcd_group_all() nslcd: DEBUG: myldap_search(base="dc=antepoth,dc=de", filter="(objectClass=posixGroup)") Speicherzugriffsfehler The user having this UID 15325 is existing and resolvable by LDAP when issuing an "getent passwd 15325" after a restart of nslcd. A third session using "gdb" is yet to come and appended to this bugreport later. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.9 (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/bash Versions of packages libnss-ldapd depends on: ii debconf [debconf-2.0] 1.5.18 Debian configuration management sy ii libc6 2.7-6 GNU C Library: Shared libraries ii libkrb53 1.6.dfsg.3~beta1-2 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.7-3+b1 OpenLDAP libraries Versions of packages libnss-ldapd recommends: ii libpam-ldap 184-2+b1 Pluggable Authentication Module al ii nscd 2.7-6 GNU C Library: Name Service Cache -- debconf information: libnss-ldapd/ldap-bindpw: (password omitted) * libnss-ldapd/ldap-rootbindpw: (password omitted) * libnss-ldapd/ldap-base: dc=antepoth,dc=de * libnss-ldapd/nsswitch: passwd, group, shadow * libnss-ldapd/ldap-binddn: * libnss-ldapd/ldap-rootbinddn: * libnss-ldapd/ldap-uris: ldap://192.168.186.254/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430065: Problem patched ...
According to the findings in the post above I patched the socket.c this
morning as follows:
--- bind9-9.3.4.orig/lib/isc/unix/socket.c 2006-05-19
04:53:36.0 +0200
+++ bind9-9.3.4/lib/isc/unix/socket.c 2007-09-10 07:45:01.0 +0200
@@ -2190,7 +2190,10 @@
if (sock->connecting)
dispatch_connect(sock);
else
- dispatch_send(sock);
+ /* Prevent reuse of a still
pending socket. */
+ if (!sock->pending_send) {
+ dispatch_send(sock);
+ }
}
FD_CLR(i, &manager->write_fds);
}
added an entry
bind9 (1:9.3.4-3) unstable; urgency=high
* Fix assertion failure in socket.c:1663
-- Thomas Antepoth <[EMAIL PROTECTED]> Mon, 10 Jan 2007 06:09:03 -0700
to the debian/changelog file and rolled my own local package of
bind9-9.3.4-3 and related libraries by issuing dpkg-buildpackage in the
bind9 source directory.
Right now the server runs since about 08:00 am in the morning without
any coredumps or other issues. No problem up to now. I know that this is
more a dirty hack^W^Wpragmatic workaround but it seems to do the trick -
at least for me and my configuration.
t++
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430065: Further investigations ...
The assertion takes place in socket.c at line 1663:
static void
dispatch_send(isc_socket_t *sock) {
intev_t *iev;
isc_socketevent_t *ev;
INSIST(!sock->pending_send); // <<-- here
The backtrace posted above shows that there were three threads active at
the time of the crash. This means that a packet was to be sent although
the previous packet had not been transferred.
"pending_send" is only cleared in socket.c and nowhere else:
internal_send:2096
"dispatch_send" is indirectly called by the eventqueuehandler and this
only in "process_fds:2193".
The sourcecode shows that a dispatch_send() is called without checking
the state of pending_send of the socket.
if (!SOCK_DEAD(sock)) {
if (sock->connecting)
dispatch_connect(sock);
else
dispatch_send(sock);
}
Now if a wakeup event occurres the socket would be dispatched for
processing regardless which kind of event (timer?) triggered the wakeup.
At least I did not find any sanity checks in process_fds() except
SOCK_DEAD(sock).
This leads to the following situation: The sock is not dead yet but it
is still pending when it is dispatched again.
I would now check sock->pending_send before calling dispatch_send().This
would at least prevent the assertion failure - well knowing that the
situation described above ( not dead but still pending and alerting ) is
not a very pleasant one - until someone comes up with a better solution.
Can anybody confirm this?
t++
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430065: named[20212]: socket.c:1663: INSIST(!sock->pending_send) failed
Hello everybody, after upgrading my system from sarge to etch this weekend, "named" crashes frequently enough to be annoying leading to a reproducible bug. On my system processes are allowed to create coredumps. -rw--- 1 bind bind 26505216 2007-09-09 08:27 core.14257 -rw--- 1 bind bind 26505216 2007-09-09 08:31 core.15809 -rw--- 1 bind bind 26501120 2007-09-09 08:33 core.16422 -rw--- 1 bind bind 26378240 2007-09-09 08:35 core.16557 -rw--- 1 bind bind 26378240 2007-09-09 08:40 core.17151 -rw--- 1 bind bind 26378240 2007-09-09 08:55 core.18819 -rw--- 1 bind bind 26443776 2007-09-09 09:21 core.20212 -rw--- 1 bind bind 26517504 2007-09-08 17:00 core.24074 -rw--- 1 bind bind 26521600 2007-09-08 17:05 core.24840 -rw--- 1 bind bind 26521600 2007-09-08 17:12 core.25418 -rw--- 1 bind bind 26947584 2007-09-08 16:16 core.3466 -rw--- 1 bind bind 26521600 2007-09-08 16:20 core.6878 -rw--- 1 bind bind 26734592 2007-09-08 19:57 core.7026 -rw--- 1 bind bind 26742784 2007-09-09 07:51 core.7033 -rw--- 1 bind bind 26517504 2007-09-08 16:58 core.8949 A gdb session on the 20212 coredump reveals this backtrace: (gdb) bt full #0 0xb7f49410 in ?? () No symbol table info available. #1 0xb6a7509c in ?? () No symbol table info available. #2 0x0006 in ?? () No symbol table info available. #3 0x4ef7 in ?? () No symbol table info available. #4 0xb7b24811 in raise () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #5 0xb7b25fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #6 0x08064a88 in ns_main_earlyfatal () No symbol table info available. #7 0xb7c858fb in isc_socket_detach () from /usr/lib/libisc.so.11 No symbol table info available. #8 0xb7c8706c in isc_socket_detach () from /usr/lib/libisc.so.11 No symbol table info available. #9 0xb7c873f9 in isc_socket_detach () from /usr/lib/libisc.so.11 No symbol table info available. #10 0xb7c32240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 No symbol table info available. #11 0xb7bc74ae in clone () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. Right now the only workaround on this bug is to restart the died process using "monit" but I'll dig further into it. It seems to have something to do with the forward zones declared in my named.conf.local. They are all forwarded to systems reachable via VPN. On some occasions when the VPN goes down for a short period of time, named pulls 100% CPU and crashes with the error message shown in the subject after about 30 seconds. t++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402880: kdm: please bring back theme with logo area and user list
It seems to me that this issue is a bug and not a wishlist. And it's not a bug of kdm either. The file which is responsible to suppress the userlist in kdm_greeter is /etc/default/kdm.d/10_desktop-base which is provided by the package "desktop-base" This file contains a reference to a theme which does not supply a userlist. If you set the variable USETHEME="false" then the userlist appears like before. Don't forget to "/etc/init.d/kdm restart" after this change as there are some files written to /var/run/kdm/ HTH. t++
Bug#362724: ddclient: Timeout is not set when creating a socket
Package: ddclient
Version: 3.6.2-3.1
Severity: important
In line 1413 there is a socket created without specifying
a timeout parameter.
This might lead to a stalled read() when the connection drops
during the network operation and to a hanging ddclient
process which does not update the ip addresses any more.
On 4 Sites we observed about 1 hang per month.
Suggestion:
Change this line 1413:
} elsif (! defined($sd = IO::Socket::INET->new(PeerAddr => $peer, PeerPort =>
$port, Proto => 'tcp'))) {
to:
} elsif (! defined($sd = IO::Socket::INET->new(PeerAddr => $peer, PeerPort =>
$port, Proto => 'tcp', Timeout => opt('timeout') ))) {
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.15
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages ddclient depends on:
ii debconf1.4.30.13 Debian configuration management sy
ii perl [perl5] 5.8.4-8sarge3 Larry Wall's Practical Extraction
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
