[Bug 1930393] Re: any local user can shut clamd down via control socket
> Hello Stephane, maybe joining the amavisd-new user's to the clamav group would be a simpler way around the stricter socket permissions you are proposing? Hi Simon, No, as I said in comment #4, that doesn't work as amavisd-new doesn't set supplementary IDs, just does a setuid() and setgid() with the configured user and group. Also we don't want to give it access to all of clamav's restricted resources (mailbox, logs...), only the socket (which we'd only restrict here to mitigate this vulnerability). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1930393 Title: any local user can shut clamd down via control socket To manage notifications about this bug go to: https://bugs.launchpad.net/clamav/+bug/1930393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1930393] Re: any local user can shut clamd down via control socket
> I suggest proposing your patch in a Debian bug to get the maintainer's feedback on it. I've now raised https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989549 Should we carry on discussion over there? ** Bug watch added: Debian Bug tracker #989549 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989549 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1930393 Title: any local user can shut clamd down via control socket To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1930393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1930393] Re: any local user can shut clamd down via control socket
>From systemd.service(5): > Type= > Configures the process start-up type for this service unit. > One of simple, exec, forking, oneshot, dbus, notify or > idle: > > • If set to simple (the default if ExecStart= is > specified but neither Type= nor BusName= are), the > service manager will consider the unit started > immediately after the main service process has been > forked off. [...] > • If set to forking, it is expected that the process > configured with ExecStart= will call fork() as part of > its start-up. The parent process is expected to exit > when start-up is complete and all communication > channels are set up. The child continues to run as the > main service process, and the service manager will > consider the unit started when the parent process > exits. This is the behavior of traditional UNIX > services. If this setting is used, it is recommended to > also use the PIDFile= option, so that systemd can > reliably identify the main process of the service. > systemd will proceed with starting follow-up units as > soon as the parent process exits. So as long as the parent doesn't exit before the service is ready to accept connections, it should be reliable. It seems to be the case here. Note that clamd can take quite a long time to start (hence the 7 minute timeout which btw I don't think makes sense with type=simple and --foreground), which might be why type=forking was abandoned? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1930393 Title: any local user can shut clamd down via control socket To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1930393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
Thanks. I notice your first write() is on fd 3 while the 2nd is on stdout (while for me the first 2 are on fd 3, which in my case is the LDAPS socket). For the issue to be reproduced, we need the client to be paused after having send the TLS "client hello". The first time the breakpoint is hit, you should be seeing something like: ``` #0 __GI___libc_write (fd=3, buf=0x55ace4ab, nbytes=75) at ../sysdeps/unix/sysv/linux/write.c:27 #1 0x7797b408 in sb_debug_write (sbiod=0x55ab4810, buf=0x55ace4ab, len=75) at ../../../../libraries/liblber/sockbuf.c:854 #2 0x76bd5a0a in _gnutls_writev_emu (fd=fd@entry=0x5578f240, giovec=giovec@entry=0x7fff9b90, giovec_cnt=giovec_cnt@entry=3, vec=0, session=, session=) at buffers.c:447 #3 0x76bd608c in _gnutls_writev (total=126, giovec_cnt=3, giovec=0x7fff9b90, session=0x5578d3d0) at buffers.c:504 #4 _gnutls_io_write_flush (session=session@entry=0x5578d3d0) at buffers.c:698 #5 0x76bd7200 in _gnutls_handshake_io_write_flush (session=session@entry=0x5578d3d0) at buffers.c:820 #6 0x76bd9348 in _gnutls_send_handshake (session=session@entry=0x5578d3d0, bufel=bufel@entry=0x55acd620, type=type@entry=GNUTLS_HANDSHAKE_FINISHED) at handshake.c:1335 #7 0x76bda4ed in _gnutls_send_finished (again=, session=0x5578d3d0) at handshake.c:763 #8 send_handshake_final (session=session@entry=0x5578d3d0, init=init@entry=1) at handshake.c:3098 #9 0x76bdcd29 in handshake_client (session=0x5578d3d0) at handshake.c:2946 #10 gnutls_handshake (session=0x5578d3d0) at handshake.c:2626 #11 0x77bbb183 in tlsg_session_accept (session=0x55abb070) at tls_g.c:361 #12 0x77bb8751 in ldap_int_tls_connect (ld=ld@entry=0x557890d0, conn=) at tls2.c:362 #13 0x77bb9466 in ldap_int_tls_start (ld=ld@entry=0x557890d0, conn=conn@entry=0x55789500, srv=srv@entry=0x55789440) at tls2.c:860 #14 0x77b912b6 in ldap_int_open_connection (ld=ld@entry=0x557890d0, conn=conn@entry=0x55789500, srv=0x55789440, async=async@entry=0) at open.c:448 #15 0x77ba634d in ldap_new_connection (ld=ld@entry=0x557890d0, srvlist=srvlist@entry=0x55789198, use_ldsb=use_ldsb@entry=1, connect=connect@entry=1, bind=bind@entry=0x0, m_req=m_req@entry=0, m_res=0) at request.c:487 #16 0x77b9074a in ldap_open_defconn (ld=ld@entry=0x557890d0) at open.c:41 #17 0x77ba7908 in ldap_send_initial_request (ld=ld@entry=0x557890d0, msgtype=msgtype@entry=96, dn=dn@entry=0x0, ber=0x557894a0, msgid=1) at request.c:130 #18 0x77b9ab8f in ldap_sasl_bind (ld=0x557890d0, dn=0x0, mechanism=, cred=0x557692e0 , sctrls=0x0, cctrls=0x0, msgidp=0x7fffa2dc) at sasl.c:164 #19 0xd33b in ?? () #20 0x844f in ?? () #21 0x77388bf7 in __libc_start_main (main=0x81b0, argc=4, argv=0x7fffe638, init=, fini=, rtld_fini=, stack_end=0x7fffe628) at ../csu/libc-start.c:310 #22 0x966a in ?? () ``` And we need to make sure the server or client doesn't reject that connection outright. It would worth running "tshark -i any -f 'port 636'" in the mean time to verify the "client hello" is sent and that the server is willing to carry on the connection. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
lincvz: > Thank you for the patch and your investigations. In the next few days, I > cannot install the patched package on my production machines. I'll let you > know when I can. Thanks. Can you reproduce a similar issue with the modus operandi (using gdb) I describe above? (Note that while it renders slapd unresponsive, service is restored as soon as you quit or detach gdb on the client). If you do, it would be worth getting a backtrace on the slapd threads again, so see if you get the same ones as before or some similar to mine. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
> This is a valid issue, but are we certain it's the same one? The > reporter talked about sched_yield and their backtraces included several > threads of back_monitor waiting on some kind of lock. You're right. It may be a different issue (though possibly linked to the same root cause). In my case, all other threads are stuck on: #0 0x7f2a010fdad3 in futex_wait_cancelable (private=, expected=0, futex_word=0x55d92cadaa78) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x55d92cadaa28, cond=0x55d92cadaa50) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=cond@entry=0x55d92cadaa50, mutex=mutex@entry=0x55d92cadaa28) at pthread_cond_wait.c:655 #3 0x7f2a01fc7475 in ldap_pvt_thread_cond_wait (cond=cond@entry=0x55d92cadaa50, mutex=mutex@entry=0x55d92cadaa28) at ../../../../libraries/libldap_r/thr_posix.c:277 #4 0x7f2a01fc6d1b in ldap_int_thread_pool_wrapper (xpool=0x55d92cadaa20) at ../../../../libraries/libldap_r/tpool.c:683 #5 0x7f2a010f76db in start_thread (arg=0x7f29f99b6700) at pthread_create.c:463 #6 0x7f2a00e1971f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
> It can be reproduced by running on a client: > > gdb --args ldapsearch -H ldaps://ldap.example.com -x > > Then in gdb: > > break write > run > continue I can no longer reproduce it after I rebuild and install the libldap package with https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e applied. Note that since the above is enough to render slapd unresponsive for 15 minutes, it could be considered as a serious DoS vulnerability. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
Yes, https://github.com/openldap/openldap/commit/735e1ab14bb055344b4e767a216aa410aa7d1503 can't be directly applied there. There have been other changes in between in that section including changes in API, so it would take more effort to backport that fix. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
cherry picking https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e should fix this particular issue but reintroduce https://bugs.openldap.org/show_bug.cgi?id=8650. It may be necessary to pick https://github.com/openldap/openldap/commit/735e1ab14bb055344b4e767a216aa410aa7d1503 as well but as that's much more recent, I can't tell if it's valid on top of the package used in bionic. I'm going to do some tests. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
The important backtrace in there is the one from thread 11: #0 0x7fb288428474 in read () from /lib/x86_64-linux-gnu/libpthread.so.0 No symbol table info available. #1 0x7fb2890c4518 in ?? () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 No symbol table info available. #2 0x7fb287895848 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #3 0x7fb28788f96a in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #4 0x7fb287896d03 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #5 0x7fb28789991c in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #6 0x7fb2878a10cb in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #7 0x7fb28789d572 in gnutls_handshake () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30 No symbol table info available. #8 0x7fb289304199 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 No symbol table info available. #9 0x7fb289301abb in ldap_pvt_tls_accept () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 No symbol table info available. #10 0x556b843e6f69 in connection_read (cri=, s=430) at ../../../../servers/slapd/connection.c:1375 debug symbols are missing there, but I have the exact same problem and get: #0 0x7f2a01101474 in __libc_read (fd=40, buf=0x7f29dc142ecb, nbytes=5) at ../sysdeps/unix/sysv/linux/read.c:27 #1 0x7f2a01db0518 in sb_debug_read (sbiod=0x7f29dc10e940, buf=0x7f29dc142ecb, len=5) at ../../../../libraries/liblber/sockbuf.c:829 #2 0x7f2a00558848 in _gnutls_stream_read (ms=0x7f29e8ffb41c, pull_func=0x7f2a01ff1da0 , size=5, bufel=, session=0x7f29dc008060) at buffers.c:344 #3 _gnutls_read (ms=0x7f29e8ffb41c, pull_func=0x7f2a01ff1da0 , size=5, bufel=, session=0x7f29dc008060) at buffers.c:424 #4 _gnutls_io_read_buffered (session=session@entry=0x7f29dc008060, total=5, recv_type=recv_type@entry=4294967295, ms=0x7f29e8ffb41c) at buffers.c:579 #5 0x7f2a0055296a in recv_headers (ms=, record=0x7f29e8ffb470, htype=GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE, type=GNUTLS_HANDSHAKE, record_params=0x7f29dc1279f0, session=0x7f29dc008060) at record.c:1045 #6 _gnutls_recv_in_buffers (session=session@entry=0x7f29dc008060, type=type@entry=GNUTLS_HANDSHAKE, htype=htype@entry=GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE, ms=, ms@entry=0) at record.c:1173 #7 0x7f2a00559d03 in _gnutls_handshake_io_recv_int (session=session@entry=0x7f29dc008060, htype=htype@entry=GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE, hsk=hsk@entry=0x7f29e8ffb580, optional=optional@entry=0) at buffers.c:1412 #8 0x7f2a0055c91c in _gnutls_recv_handshake (session=session@entry=0x7f29dc008060, type=type@entry=GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE, optional=optional@entry=0, buf=buf@entry=0x7f29e8ffb830) at handshake.c:1465 #9 0x7f2a005640cb in _gnutls_recv_client_kx_message (session=session@entry=0x7f29dc008060) at kx.c:563 #10 0x7f2a00560572 in handshake_server (session=0x7f29dc008060) at handshake.c:3327 #11 gnutls_handshake (session=0x7f29dc008060) at handshake.c:2629 #12 0x7f2a01ff2199 in tlsg_session_accept (session=0x7f29dc1133f0) at tls_g.c:363 #13 0x7f2a01fefabb in ldap_pvt_tls_accept (sb=0x7f299c0051a0, ctx_arg=0x55d92cbca560) at tls2.c:425 and I've tracked it down to: https://bugs.openldap.org/show_bug.cgi?id=8650#c12 Basically, what we see is one thread stuck in a busy loop doing read()s on the TCP socket which all return immediately with EAGAIN as the fd is in non-blocking mode. In my cases, the client go offline just after sending the TLS client hello. That lasts for 15 minutes or about, probably until some timeout after which the TCP connection is eventually considered dead. It can be reproduced by running on a client: gdb --args ldapsearch -H ldaps://ldap.example.com -x Then in gdb: break write run continue Then the client is paused after sending the TLS "client hello". https://bugs.openldap.org/show_bug.cgi?id=8650#c12 explains that it's https://github.com/openldap/openldap/commit/7b5181da8cdd47a13041f9ee36fa9590a0fa6e48 that is responsible for the issue. https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e reverted that commit, but that one did not make it into bionic. So cherry picking https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e should fix it. ** Bug watch added: bugs.openldap.org/ #8650 https://bugs.openldap.org/show_bug.cgi?id=8650 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1926265 Title: slapd enter in infinite loop on sched_yield syscall To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com
[Bug 243578]
I can reproduce with Thunderbird 78.8.0 on Debian. IMAP, IMAPS, SMTPS connections go via the configured SOCKS5 proxy, but LDAPS connections are not proxied. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/243578 Title: Thunderbird address book won't use socks to access ldap server To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/243578/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 827151] Re: Annoying log message "DIGEST-MD5 common mech free"
See with just running ldapsearch after upgrade to 16.04: ``` # repeat 10 ldapsearch -x > /dev/null # tail /var/log/auth.log Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free ``` -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/827151 Title: Annoying log message "DIGEST-MD5 common mech free" To manage notifications about this bug go to: https://bugs.launchpad.net/cyrus-sasl2/+bug/827151/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1807043] Re: when rewriting sources.list ubuntu-release-upgrader doesn't check to see if new release is available
That fix breaks the upgrade (in my case from xenial to bionic) for users that use a local mirror over HTTPS as the _sourcesListEntryDownloadable->url_downloadable doesn't support HTTPS. It comments out the entries and adds: 2019-02-19 15:13:51,808 DEBUG entry '# deb https://localmirror.example.com/example/security.ubuntu.com/ubuntu xenial-security multiverse' was disabled (no Release file) The "Release file" is there but "url_downloadable" failed to download it because of the "https" scheme (note: the apt-transport-https package is installed). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1807043 Title: when rewriting sources.list ubuntu-release-upgrader doesn't check to see if new release is available To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1807043/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815021] Re: Can't read and write simultaneously from serial port
Probably same as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813873 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815021 Title: Can't read and write simultaneously from serial port To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe/+bug/1815021/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815021] Re: Can't read and write simultaneously from serial port
``` $ bash -c 'sleep 1 && : < /dev/tty & read var' < /dev/tty bash: line 0: read: read error: 0: Resource temporarily unavailable ``` seems to be related and is possibly the same bug. See https://unix.stackexchange.com/questions/499422/bash-how-can-i-run- sudo-n-true-in-the-background-without-interfering- with-r/499433?noredirect=1#comment919635_499433 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815021 Title: Can't read and write simultaneously from serial port To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe/+bug/1815021/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1695870] Re: [regression] sssd won't start if autofs is not installed
** Tags added: regression-update -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1695870 Title: [regression] sssd won't start if autofs is not installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1695870/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1695870] [NEW] [regression] sssd won't start if autofs is not installed
Public bug reported: The fix for LP# 1566508 (in Ubuntu 14.04 at least) introduces a regression that prevents sssd from starting if the autofs package is not installed. The /etc/init/sssd.conf script now has: ``` start on (filesystem and net-device-up and starting autofs) ``` The "starting autofs" will never happen if autofs is not installed. That's critical in that that prevents authentication after the next boot after "sssd" has been upgraded. The work around for now is to remove that "and starting autofs" or install the autofs package. ``` $ apt-cache policy sssd sssd: Installed: 1.11.8-0ubuntu0.6 Candidate: 1.11.8-0ubuntu0.6 Version table: *** 1.11.8-0ubuntu0.6 0 500 http://gb.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 100 /var/lib/dpkg/status 1.11.5-1ubuntu3 0 500 http://gb.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages ``` ** Affects: sssd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1695870 Title: [regression] sssd won't start if autofs is not installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1695870/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566508] Re: autofs races with sssd on startup
The fix in 14.04 causes sssd to not start on boot when "autofs" is not installed! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566508 Title: autofs races with sssd on startup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1342083] Re: Failed to create chardev due to apparmor DENIED execute of /usr/lib/pt_chown
Serge, I think the real question is how it can work for some people, without the /usr/lib/pt_chown ix, how can it work at all (for VMs with a serial port backed by a pty device, which should be the default with a typical libvirt deployment). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1342083 Title: Failed to create chardev due to apparmor DENIED execute of /usr/lib/pt_chown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1342083/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1342083] Re: Failed to create chardev due to apparmor DENIED execute of /usr/lib/pt_chown
Hi Serge, sorry, I wasn't receiving email notifications (I thought it happened automatically when one ticked this affects me). I can't test on that system as it's in production now. I may be able to test on another system later, but probably not in July. It shouldn't be difficult to reproduce though. What worries me more here is that it sometimes work, as in it sometimes manages to run pt_chown even though apparmor should have prohibited it. It may be an indication that there's some security weakness here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1342083 Title: Failed to create chardev due to apparmor DENIED execute of /usr/lib/pt_chown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1342083/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1342083] Re: Failed to create chardev due to apparmor DENIED execute of /usr/lib/pt_chown
Adding:
/usr/lib/pt_chown ix,
owner @{PROC}/[0-9]*/fd/* r,
To /etc/apparmor.d/abstractions/libvirt-qemu fixes the problem for me.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1342083
Title:
Failed to create chardev due to apparmor DENIED execute of
/usr/lib/pt_chown
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1342083/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1342083] Re: Failed to create chardev due to apparmor DENIED execute of /usr/lib/pt_chown
pt_chown is executed when adding a serial console backed by a pts chardev: It is the same problem as https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/632696 serial type='pty' target port='0'/ /serial I get the same error on the second start of the VM after a reboot of the host, not on the first one (I don't know why). Jun 9 04:06:24 host kernel: [ 2588.975014] audit: type=1400 audit(1433847984.691:97): apparmor=DENIED operation=open profile=libvirt-ee2d78ea-af2f-4e82-9b0e-ef75470ff81e name=/proc/7809/fd/ pid=7809 comm=qemu-system-x86 requested_mask=r denied_mask=r fsuid=108 ouid=108 Jun 9 04:06:24 host kernel: [ 2588.975073] audit: type=1400 audit(1433847984.691:98): apparmor=DENIED operation=exec profile=libvirt-ee2d78ea-af2f-4e82-9b0e-ef75470ff81e name=/usr/lib/pt_chown pid=7809 comm=qemu-system-x86 requested_mask=x denied_mask=x fsuid=108 ouid=0 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1342083 Title: Failed to create chardev due to apparmor DENIED execute of /usr/lib/pt_chown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1342083/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1215660] Re: dash does not drop privileges when euid != uid, this can cause local root exploits when setuid programs use system() or popen()
correction on my previous comment: My point 1 is only true on Debian and derivatives. bash does drop its privilege when setuid and called as sh without -p just like when not called as sh, but Debian's bash package has a patch that disables that dropping of privileges when called as sh. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=52586 ** Bug watch added: Debian Bug tracker #52586 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=52586 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1215660 Title: dash does not drop privileges when euid != uid, this can cause local root exploits when setuid programs use system() or popen() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dash/+bug/1215660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] Re: problem with paths with spaces with 12.04 client with 14.04 server
The bug is in apache2. It has been fixed upstreams in 2.4.10 and a patch is available at https://bz.apache.org/bugzilla/attachment.cgi?id=31705 ** Package changed: subversion (Ubuntu) = apache2 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1284641/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] Re: problem with paths with spaces with 12.04 client with 14.04 server
The bug is in apache2. It has been fixed upstreams in 2.4.10 and a patch is available at https://bz.apache.org/bugzilla/attachment.cgi?id=31705 ** Package changed: subversion (Ubuntu) = apache2 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to apache2 in Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1284641/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1376245] Re: remove_proc_entry+0x139/0x1b0() -- name 'fs/nfsfs'
Note that I can reproduce the WARNING consistently with: ip netns add test; ip netns delete test -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1376245 Title: remove_proc_entry+0x139/0x1b0() -- name 'fs/nfsfs' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1376245/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1215660] Re: dash does not drop privileges when euid != uid, this can cause local root exploits when setuid programs use system() or popen()
There are several incorrect statements in the initial report and the linked CVE. 1. bash doesn't drop its privilege when setuid when called as sh. It only does so when called as bash and without the -p option. It does however go into a mode where it does not trust its environment as much as when it's not setuid. It still trusts $PATH though. 2. pdksh like ATT ksh or bash when called as sh, does not drop privileges on startup. It enters the privileged mode in which it is more careful in what it does with the environment (for instance, ignores ENV as mandated by POSIX). Only recent versions of mksh (and possibly OpenBSD sh/ksh) based on pdksh drop the privileges. 3. Non-Linux sh are generally not pdksh. From the major ones, only OpenBSD and MirBSD have shells *based* on pdksh. Other BSDs generally have a shell based on the Almquist shell (dash itself is mostly based on NetBSD sh) or bash (like OS/X) and commercial unices generally on ATT ksh88 4. So it's not most shells dropping privileges. bash (as sh), dash, pdksh, ATT ksh, yash don't. Only some pdksh derivatives and bash when called as sh do. 5. calling popen(/usr/bin/lsb-release) as root is not the right solution as lsb-release doesn't need super-user privileges and is not guaranteed to be found in /usr/bin and is at least on Debian a python script (python's behaviour can also be affected by env vars) that relies on PATH to find other utilities, so PATH would still need to be sanitized). So dash is not any more vulnerable that any other shell in that regard and is certainly a much better choice in terms of security for /bin/sh than any other bigger shell like bash, zsh or ATT ksh. Changing dash so it drops privileges is likely to break some usages (rare as it's widely known that calling shells in setuid contexts is very risky). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1215660 Title: dash does not drop privileges when euid != uid, this can cause local root exploits when setuid programs use system() or popen() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dash/+bug/1215660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 322827] Re: libpam-gnome-keyring: keyring password should be updated or cleared when a new system password is used
Related redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=975469 ** Bug watch added: Red Hat Bugzilla #975469 https://bugzilla.redhat.com/show_bug.cgi?id=975469 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/322827 Title: libpam-gnome-keyring: keyring password should be updated or cleared when a new system password is used To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/322827/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] Re: problem with paths with spaces with 12.04 client with 14.04 server
There's a problem with any DAV client, it's not only old svn client. So I'll raise the issue upstreams. I had raised it here because in the past, similar reports to upstreams were answered with then upgrade your client to fix the problem, while here it's a real concern for ubuntu. But it is really a violation of the WebDAV protocol so I expect upstreams will want to fix it. Exceirpt of traffic between cadaver and mod_dav_svn 1.8.8, see how some space and and % characters are not escaped (but are in other contexts). I suppose it's not impossible that there be security implications as someone may be able to craft a harmful PROPFIND response (since , are not encoded) by adding crafted file names to the repository. PROPFIND /svn/ HTTP/1.1 User-Agent: cadaver/0.23.3 neon/0.29.1 Connection: TE TE: trailers Host: vm189-eth0.vmnet60 Depth: 1 Content-Length: 288 Content-Type: application/xml ?xml version=1.0 encoding=utf-8? propfind xmlns=DAV:prop getcontentlength xmlns=DAV:/ getlastmodified xmlns=DAV:/ executable xmlns=http://apache.org/dav/props// resourcetype xmlns=DAV:/ checked-in xmlns=DAV:/ checked-out xmlns=DAV:/ /prop/propfind HTTP/1.1 207 Multi-Status Date: Wed, 26 Feb 2014 08:40:23 GMT Server: Apache/2.4.7 (Ubuntu) Content-Length: 2549 Content-Type: text/xml; charset=utf-8 ?xml version=1.0 encoding=utf-8? D:multistatus xmlns:D=DAV: xmlns:ns1=http://apache.org/dav/props/; xmlns:ns0=DAV: D:response xmlns:lp1=DAV: xmlns:lp3=http://subversion.tigris.org/xmlns/dav/; xmlns:g0=DAV: xmlns:g1=http://apache.org/dav/props/; D:href/svn//D:href D:propstat D:prop lp1:getlastmodifiedTue, 25 Feb 2014 14:43:59 GMT/lp1:getlastmodified lp1:resourcetypeD:collection//lp1:resourcetype lp1:checked-inD:href/svn/!svn/ver/5//D:href/lp1:checked-in /D:prop D:statusHTTP/1.1 200 OK/D:status /D:propstat D:propstat D:prop g0:getcontentlength/ g1:executable/ g0:checked-out/ /D:prop D:statusHTTP/1.1 404 Not Found/D:status /D:propstat /D:response D:response xmlns:lp1=DAV: xmlns:lp3=http://subversion.tigris.org/xmlns/dav/; xmlns:g0=http://apache.org/dav/props/; xmlns:g1=DAV: ⇨ D:href/svn/ab/D:href D:propstat D:prop lp1:getcontentlength10/lp1:getcontentlength lp1:getlastmodifiedTue, 25 Feb 2014 13:09:01 GMT/lp1:getlastmodified lp1:resourcetype/ lp1:checked-inD:href/svn/!svn/ver/3/a%3Eb/D:href/lp1:checked-in /D:prop D:statusHTTP/1.1 200 OK/D:status /D:propstat D:propstat D:prop g0:executable/ g1:checked-out/ /D:prop D:statusHTTP/1.1 404 Not Found/D:status /D:propstat /D:response D:response xmlns:lp1=DAV: xmlns:lp3=http://subversion.tigris.org/xmlns/dav/; xmlns:g0=DAV: xmlns:g1=http://apache.org/dav/props/; ⇨ D:href/svn/A B//D:href D:propstat D:prop lp1:getlastmodifiedTue, 25 Feb 2014 12:46:53 GMT/lp1:getlastmodified lp1:resourcetypeD:collection//lp1:resourcetype lp1:checked-inD:href/svn/!svn/ver/1/A%20B/D:href/lp1:checked-in /D:prop D:statusHTTP/1.1 200 OK/D:status /D:propstat D:propstat D:prop g0:getcontentlength/ g1:executable/ g0:checked-out/ /D:prop D:statusHTTP/1.1 404 Not Found/D:status /D:propstat /D:response D:response xmlns:lp1=DAV: xmlns:lp3=http://subversion.tigris.org/xmlns/dav/; xmlns:g0=http://apache.org/dav/props/; xmlns:g1=DAV: ⇨ D:href/svn/%2F/D:href D:propstat D:prop lp1:getcontentlength9/lp1:getcontentlength lp1:getlastmodifiedTue, 25 Feb 2014 14:43:59 GMT/lp1:getlastmodified lp1:resourcetype/ lp1:checked-inD:href/svn/!svn/ver/5/%252F/D:href/lp1:checked-in /D:prop D:statusHTTP/1.1 200 OK/D:status /D:propstat D:propstat D:prop g0:executable/ g1:checked-out/ /D:prop D:statusHTTP/1.1 404 Not Found/D:status /D:propstat /D:response /D:multistatus -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] Re: problem with paths with spaces with 12.04 client with 14.04 server
Possibly related: https://issues.apache.org/bugzilla/show_bug.cgi?id=55397 ** Bug watch added: Apache Software Foundation Bugzilla #55397 http://issues.apache.org/bugzilla/show_bug.cgi?id=55397 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] Re: problem with paths with spaces with 12.04 client with 14.04 server
Yes, that was a change in API in apache at some point, dav_fs had to be modified for that https://svn.apache.org/viewvc?view=revisionrevision=1531505 dav_svn wasn't modified, so the change in the apache API broke dav_svn basically. dav_fs ships with apache2 so it's easy for it to align with the new API, but dav_svn doesn't. That means that dav_svn will work properly with older apache, and it may be up to ubuntu to adapt to the new apache API since ubuntu ships now ships with a newer apache. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] Re: problem with paths with spaces with 12.04 client with 14.04 server
Sorry, replying to myself again and thinking aloud. It looks like that change above https://svn.apache.org/viewvc?view=revisionrevision=1531505 is what broke it, as we've got apache 2.4.7 on 14.04 now. It sounds like the problem with double URI encoding has been fixed in both dav_svn and dav which means it now overshoots (no encoding instead of just one encoding). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1285204] [NEW] problem with paths with spaces with ubuntu12.04 client with ubuntu13.10 server
Public bug reported: Note that it is related but not the same bug as https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641 Bug found in: libapache2-mod-svn 1.7.9-1+nmu6ubuntu3 with 2.4.6-2ubuntu2.1 on ubuntu 13.10 amd64. Committing a change on a file that has space characters (or other characters that need encoded in a URI) in its path with a subversion client prior to 1.7 (so typically ubuntu 12.04's 1.6.17) fails with this type of error: File not found: transaction '91472-225x', path '/a%20b' That hit me when upgrading a subversion repository from ubuntu 10.04 to ubuntu 13.10 after which no ubuntu 12.04 user could commit anything with a space in a file path. It is possible that this bug also affects 14.04 (svn 1.8.8 with apache 2.4.7), but one can't tell as bug 1284641 causes the commit to fail before we reach that point. To reproduce: On a ubuntu 13.10 server, run (as root): apt-get install apache2 subversion libapache2-mod-svn a2enmod dav_svn svnadmin create /srv/svn chown -R www-data: /srv/svn cat /etc/apache2/mods-available/dav_svn.conf EOF Location /svn DAV svn SVNPath /srv/svn /Location EOF service apache2 restart On a 12.04 client: svn co http://server/svn test cd test mkdir -p 'A B/C' echo test 'A B/C/x' svn add 'A B' svn ci -m m1 echo test 'A B/C/x' svn ci -m m2 That second commit will fail with something like: File not found: transaction '2-225x', path '/A%20B/C/x' Looking at the network traffic between client and server, we see a few HTTP requests and then: REQUEST: CHECKOUT /!svn/ver/19/A%20B/test HTTP/1.1\r RESPONSE: HTTP/1.1 201 Created\r [...] Location: http://server/!svn/wrk/52a9ffc7-ace1-41be-83f1-5814bd19d0ab/A%2520B/test\r (see how the %20 became %2520 (encoded again)) Followed by: REQUEST: PUT /!svn/wrk/52a9ffc7-ace1-41be-83f1-5814bd19d0ab/A%2520B/test HTTP/1.1\r RESPONSE: HTTP/1.1 404 Not Found\r Newer subversion clients are not affected because they use a different protocol, unless you add SVNAdvertiseV2Protocol Off to the dav_svn configuration. That bug was introduced by a change in apache, by the fix to https://issues.apache.org/bugzilla/show_bug.cgi?id=54611 that encodes the location provided by dav_svn (while svn was already encoding it). Please find a patch attached. That patch against 1.7.9 removes the encoding done by dav_svn. Though I've done a fair amount of testing with it, I don't know enough about the apache/dav/svn architecture to guarantee that it won't break anything. ** Affects: subversion (Ubuntu) Importance: Undecided Status: New ** Patch added: potential fix for the issue https://bugs.launchpad.net/bugs/1285204/+attachment/3997883/+files/patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1285204 Title: problem with paths with spaces with ubuntu12.04 client with ubuntu13.10 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1285204/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] Re: problem with paths with spaces with 12.04 client with 14.04 server
Here's the related bug affecting 13.10 I mentioned earlier: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1285204 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] [NEW] problem with paths with spaces with 12.04 client with 14.04 server
Public bug reported: source package: subversion bin package: libapache2-mod-svn The problem shows up with libapache2-mod-svn 1.8.8-1ubuntu3 on the current 14.04 (amd64 though that doesn't matter). It showed up in 1.7.14 already. The problem is an interoperability problem with subversion clients prior to 1.7.x. Typically, ubuntu 12.04 clients (1.6.17) are affected by that bug. That means that anybody upgrading their server from 12.04 to 14.04 are potentially going to be affected (unless they upgrade their clients beforehand).. There's a related bug with the subversion server coming with 13.10 which I'll raise shortly. Newer clients (1.7 and above) are not affected even with SVNAdvertiseV2Protocol Off on the server (contrary to the 13.10 bug). How to reproduce: On a 14.04 server (as root), apt-get install apache2 subversion libapache2-mod-svn a2enmod dav_svn svnadmin create /srv/svn chown -R www-data: /srv/svn cat /etc/apache2/mods-available/dav_svn.conf EOF Location /svn DAV svn SVNPath /srv/svn /Location EOF service apache2 restart On a 12.04 client: svn co http://server/svn test cd test mkdir -p 'A B/C' echo test 'A B/C/x' svn add 'A B' svn ci -m m1 svn log 'A B/C/x' That svn log command will fail with: svn: Unable to parse URL '/svn/A B/C/x' A commit of a change on that x file will fail as well: echo test 'A B/C/x' svn ci -m m2 When using svn log --config-option servers:global:neon-debug-mask=130 'A B/C/x' we see: Sending request headers: PROPFIND /svn/A%20B/C/x HTTP/1.1 User-Agent: SVN/1.6.17 (r1128011) neon/0.29.6 (OK) [status-line] HTTP/1.1 207 Multi-Status [?xml version=1.0 encoding=utf-8? D:multistatus xmlns:D=DAV: xmlns:ns1=http://subversion.tigris.org/xmlns/dav/; xmlns:ns0=DAV: D:response xmlns:lp1=DAV: xmlns:lp2=http://subversion.tigris.org/xmlns/dav/; D:href/svn/A B/C/x/D:href D:propstat D:prop lp1:version-controlled-configurationD:href/svn/!svn/vcc/default/D:href/lp1:version-controlled-configuration lp1:resourcetype/ lp2:baseline-relative-pathA B/C/x/lp2:baseline-relative-path lp2:repository-uuid1e784bc0-1833-41df-a2eb-683d1610caa8/lp2:repository-uuid /D:prop D:statusHTTP/1.1 200 OK/D:status /D:propstat /D:response /D:multistatus While the problem with 13.10 (1.7.9) was too much URI encoding (space turned to %20 itself turned into %2520), it looks like in this case there's not enough encoding (href being /svn/A B/C/x instead of /svn/A%20B/C/x above). It is really a bug because even and are not encoded. The reason why newer clients work is because they send different HTTP requests (OPTIONS, REPORT and no PROPFIND even with V2 disabled). On 12.04, one can work around the problem by upgrading svn from the svn ppa (svn 1.7.9), but note that it breaks rapidsvn (segfault) and possibly other tools linking to libsvn. As show above, space is not the only character causing problem. ** Affects: subversion (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] Re: problem with paths with spaces with 12.04 client with 14.04 server
*** This bug is a duplicate of bug 1003168 *** https://bugs.launchpad.net/bugs/1003168 No, it's not a duplicate. There's no proxy here, my bug affects the simplest deployment of subversion as long as 12.04 is used on the client and 14.04 on the server and spaces are used in file names in the repository It is a bug on the server, so in the newest version of subversion (1.8.8 released a few days ago) And the symptoms are different. The double-encoding of space into %2520 is also found in the bug that I'm going to raise against 13.10, but not in this bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284641] Re: problem with paths with spaces with 12.04 client with 14.04 server
** This bug is no longer a duplicate of bug 1003168 write through proxy doesn't work with a filename that has a space -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284641 Title: problem with paths with spaces with 12.04 client with 14.04 server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/1284641/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 900393] Re: Won't boot if grub on partition holding the LVM root fs
Also affects 12.04 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/900393 Title: Won't boot if grub on partition holding the LVM root fs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/900393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 844159] Re: -virtual kernel does not have aufs filesystem
AFAICT, this bug is also in precise 12.04 (amd64 at least). $ grep CONFIG_AUFS_FS /boot/config-3.2.0-34-virtual CONFIG_AUFS_FS=m $ dpkg -L linux-image-3.2.0-34-virtual | grep -i aufs $ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/844159 Title: -virtual kernel does not have aufs filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/844159/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 900393] [NEW] Won't boot if grub on partition holding the LVM root fs
Public bug reported: $ apt-cache policy libblkid1 libblkid1: Installed: 2.19.1-2ubuntu3 Candidate: 2.19.1-2ubuntu3 Version table: *** 2.19.1-2ubuntu3 0 500 http://gb.archive.ubuntu.com/ubuntu/ oneiric/main amd64 Packages 100 /var/lib/dpkg/status blkid will fail to report a partition as a LVM2 Member if it contains a grub boot sector. On Ubuntu 11.10 where VGs are activated by udev upon finding LVM physical volumes (as opposed to lvm vgchange -ay being run unconditionally in earlier versions), that means that it won't boot as it won't find the root FS: pre Gave up waiting for root device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mapper/VG_linux-ubuntu64 does not exist. Dropping to a shell! BusyBox v1.18.4 (Ubuntu 1:1.18.4-2ubuntu2) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) blkid -o udev -p /dev/vda4 ID_PART_TABLE_TYPE=dos ID_PART_ENTRY_SCHEME=dos ID_PART_ENTRY_TYPE=0x8e ID_PART_ENTRY_FLAGS=0x80 ID_PART_ENTRY_NUMBER=4 (initramfs) lvm vgchange -ay 5 logical volume(s) in volume group VG_linux now active (initramfs) lvm pvs PV VG Fmt Attr PSize PFree /dev/vda4 VG_linux lvm2 a- 771.30g 503.30g /pre It can be reproduced with the PV on a partition or on a full disk such as with this script: pre #! /bin/sh - set -ex truncate -s 1T test qemu-nbd -c /dev/nbd0 test sleep 1 pvcreate /dev/nbd0 vgcreate V /dev/nbd0 : Before grub: blkid -o udev -p /dev/nbd0 xxd -r \EOF 1 /dev/nbd0 000: eb63 9000 .c.. 010: 020: 030: 040: 050: 0080 7eb0 0300 ~... 060: fffa 9090 f6c2 8074 05f6 c270 ...t...p 070: 7402 b280 ea79 7c00 0031 c08e d88e d0bc ty|..1.. 080: 0020 fba0 647c 3cff 7402 88c2 52be 807d . ..d|.t...R..} 090: e817 01be 057c b441 bbaa 55cd 135a 5272 .|.A..U..ZRr 0a0: 3d81 fb55 aa75 3783 e101 7432 31c0 8944 =..U.u7...t21..D 0b0: 0440 8844 ff89 4402 c704 1000 668b 1e5c .@.D..D.f..\ 0c0: 7c66 895c 0866 8b1e 607c 6689 5c0c c744 |f.\.f..`|f.\..D 0d0: 0600 70b4 42cd 1372 05bb 0070 eb76 b408 ..p.B..r...p.v.. 0e0: cd13 730d f6c2 800f 84d8 00be 8b7d e982 ..s..}.. 0f0: 0066 0fb6 c688 64ff 4066 8944 040f b6d1 .fd.@f.D 100: c1e2 0288 e888 f440 8944 080f b6c2 c0e8 ...@.D.. 110: 0266 8904 66a1 607c 6609 c075 4e66 a15c .f..f.`|f..uNf.\ 120: 7c66 31d2 66f7 3488 d131 d266 f774 043b |f1.f.4..1.f.t.; 130: 4408 7d37 fec1 88c5 30c0 c1e8 0208 c188 D.}70... 140: d05a 88c6 bb00 708e c331 dbb8 0102 cd13 .Zp..1.. 150: 721e 8cc3 601e b900 018e db31 f6bf 0080 r...`..1 160: 8ec6 fcf3 a51f 61ff 265a 7cbe 867d eb03 ..a.Z|..}.. 170: be95 7de8 3400 be9a 7de8 2e00 cd18 ebfe ..}.4...}... 180: 4752 5542 2000 4765 6f6d 0048 6172 6420 GRUB .Geom.Hard 190: 4469 736b 0052 6561 6400 2045 7272 6f72 Disk.Read. Error 1a0: 0d0a 00bb 0100 b40e cd10 ac3c 0075 f4c3 u.. 1b0: 1c0: 1d0: 1e0: 1f0: 55aa ..U. EOF : After grub: blkid -o udev -p /dev/nbd0 : clean-up vgchange -an V qemu-nbd -d /dev/nbd0 rm -f test /pre Which gives: pre $ sudo sh ./reproduce + truncate -s 1T test + qemu-nbd -c /dev/nbd0 test + sleep 1 + pvcreate /dev/nbd0 Writing physical volume data to disk /dev/nbd0 Physical volume /dev/nbd0 successfully created + vgcreate V /dev/nbd0 Volume group V successfully created + : Before grub: + blkid -o udev -p /dev/nbd0 ID_FS_UUID=1iWyMS-ZzMm-l7nv-kLTc-V2Rq-CqRo-q4RTnz ID_FS_UUID_ENC=1iWyMS-ZzMm-l7nv-kLTc-V2Rq-CqRo-q4RTnz ID_FS_VERSION=LVM2\x20001 ID_FS_TYPE=LVM2_member ID_FS_USAGE=raid + xxd -r + : After grub: + blkid -o udev -p /dev/nbd0 ID_PART_TABLE_TYPE=dos + : clean-up + vgchange -an V 0 logical volume(s) in volume group V now active + qemu-nbd -d /dev/nbd0 /dev/nbd0 disconnected + rm -f test /pre ** Affects: util-linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/900393 Title: Won't boot if grub on partition holding the LVM root fs To manage notifications about this bug go to:
[Bug 900393] Re: Won't boot if grub on partition holding the LVM root fs
Actually, 1f0: 55aa ..U. It's the MBR signature (the 55aa above) that causes problem. If I replace it with , blkid sees it as a LVM member again but the system doesn't boot as its not recognised as a boot sector. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/900393 Title: Won't boot if grub on partition holding the LVM root fs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/900393/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 595117] Re: qemu-nbd slow and missing writeback cache option
For the record, there's more on that bug at http://thread.gmane.org/gmane.linux.ubuntu.bugs.server/36923 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in ubuntu. https://bugs.launchpad.net/bugs/595117 Title: qemu-nbd slow and missing writeback cache option -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 595117] Re: qemu-nbd slow and missing writeback cache option
For the record, there's more on that bug at http://thread.gmane.org/gmane.linux.ubuntu.bugs.server/36923 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/595117 Title: qemu-nbd slow and missing writeback cache option -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 648202] Re: vsftpd started even if not in standalone mode
Also, I suspect the last line of the pre-start script should be: check_standalone_mode || stop instead of: check_standalone_mode || exit 0 which is a no-op except for the message that check_standalone_mode might display. -- vsftpd started even if not in standalone mode https://bugs.launchpad.net/bugs/648202 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to vsftpd in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 648202] Re: vsftpd started even if not in standalone mode
Also, I suspect the last line of the pre-start script should be: check_standalone_mode || stop instead of: check_standalone_mode || exit 0 which is a no-op except for the message that check_standalone_mode might display. -- vsftpd started even if not in standalone mode https://bugs.launchpad.net/bugs/648202 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 648202] [NEW] vsftpd started even if not in standalone mode
Public bug reported:
Binary package hint: vsftpd
(lucid vsftpd 2.2.2-3ubuntu6)
because of a syntax error in /etc/init/vsftpd.con, vsftd is started (and
respawns a lot as it fails to start) if there's no listen=yes in
/etc/vsftpd.conf
/etc/init/vsftpd.conf has:
if [ -e ${CONFFILE} ] !egrep -iq ^
*listen(_ipv6)? *= *yes ${CONFFILE}
without space between ! and egrep. As a result !egrep returns with an
error (!egrep command not found) and as a result, the script assumes
the listen = yes line is in the file.
Moreover, if the /etc/vsftpd.conf file is not there, vsftpd is also
started which I suspect was not intended.
Moreover egrep is not a POSIX command.
Would be better written as:
if ! grep -qEis --
'^[[:blank:]]*listen(_ipv6)?[[:blank:]]*=[[:blank:]]*yes' $CONFFILE;
then...
** Affects: vsftpd (Ubuntu)
Importance: Undecided
Status: New
--
vsftpd started even if not in standalone mode
https://bugs.launchpad.net/bugs/648202
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vsftpd in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 648202] [NEW] vsftpd started even if not in standalone mode
Public bug reported:
Binary package hint: vsftpd
(lucid vsftpd 2.2.2-3ubuntu6)
because of a syntax error in /etc/init/vsftpd.con, vsftd is started (and
respawns a lot as it fails to start) if there's no listen=yes in
/etc/vsftpd.conf
/etc/init/vsftpd.conf has:
if [ -e ${CONFFILE} ] !egrep -iq ^
*listen(_ipv6)? *= *yes ${CONFFILE}
without space between ! and egrep. As a result !egrep returns with an
error (!egrep command not found) and as a result, the script assumes
the listen = yes line is in the file.
Moreover, if the /etc/vsftpd.conf file is not there, vsftpd is also
started which I suspect was not intended.
Moreover egrep is not a POSIX command.
Would be better written as:
if ! grep -qEis --
'^[[:blank:]]*listen(_ipv6)?[[:blank:]]*=[[:blank:]]*yes' $CONFFILE;
then...
** Affects: vsftpd (Ubuntu)
Importance: Undecided
Status: New
--
vsftpd started even if not in standalone mode
https://bugs.launchpad.net/bugs/648202
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 27520] Re: cron no longer respects nsswitch.conf
This appears to be a variant of Debian bug #512757 against cron. Can somebody confirm this for me? [...] Pretty much, though for me reordering the init scripts wasn't enough as there was some delay between the time nslcd (the LDAP cache daemon) was started and it being operational. In any case we need a mechanism for cron to refresh its idea of which users are valid at a given time. It already checks upon executing a cron job whether the user is still there, it would also need to check regularly (or upon notification of the NSS system) when new users come into life. Or because it checks before executing the jobs anyway, cron could skip the check for orphan crontabs at startup altogether (or maybe just issue a warning that some crontabs could be cleaned up). -- cron no longer respects nsswitch.conf https://bugs.launchpad.net/bugs/27520 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 625955] [NEW] vsftpd installation fails if there's a user name starting with ftp
Public bug reported:
Binary package hint: vsftpd
2.2.2-3ubuntu6
debian/vsftpd.postinst has
if ! getent passwd | grep -q ^${_USERNAME}
($_USERNAME being ftp by default).
It should be:
if ! getent -- passwd $_USERNAME
same for groups.
** Affects: vsftpd (Ubuntu)
Importance: Undecided
Status: New
--
vsftpd installation fails if there's a user name starting with ftp
https://bugs.launchpad.net/bugs/625955
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vsftpd in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 625955] [NEW] vsftpd installation fails if there's a user name starting with ftp
Public bug reported:
Binary package hint: vsftpd
2.2.2-3ubuntu6
debian/vsftpd.postinst has
if ! getent passwd | grep -q ^${_USERNAME}
($_USERNAME being ftp by default).
It should be:
if ! getent -- passwd $_USERNAME
same for groups.
** Affects: vsftpd (Ubuntu)
Importance: Undecided
Status: New
--
vsftpd installation fails if there's a user name starting with ftp
https://bugs.launchpad.net/bugs/625955
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 560210] Re: Can't enable jumbo frames on Intel 82573V (e1000e)
According to Intel (http://ark.intel.com/Product.aspx?id=26551), that NIC doesn't support Jumbo frames. In Ubuntu 8.04, ifconfig eth0 1501 also reports SIOCSIFMTU: Invalid argument in there. -- Can't enable jumbo frames on Intel 82573V (e1000e) https://bugs.launchpad.net/bugs/560210 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 587858] Re: update-motd executed even in non-interactive sessions
2010-07-22 17:28:48 -, Dustin Kirkland: Patch to pam developed, tested, and pushed to lp:~kirkland/+junk/587858. Awaiting a quick review by Steve before uploading to Maverick. [...] Note that though this fix would be an improvement, in my opinion, it's a fix to another bug like the result of update-motd is not cached. This bug is about motd being computed in non-interactive non-login ssh sessions where motd is not even displayed. Maybe a fix/wa could be implemented by doing a pam_putenv(PAM_NONLOGINSESSION=) in sshd upon non-login sessions or hushedlogin ones and have pam_motd skip the update-motd in that case. Or split into two services sshd-login and sshd with /etc/pam.d/sshd-login including sshd and adding the pam_motd... Cheers, Stephane -- update-motd executed even in non-interactive sessions https://bugs.launchpad.net/bugs/587858 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 27520] Re: cron no longer respects nsswitch.conf
Also affects Ubuntu lucid 10.04. crontabs for LDAP users are ignored on boot. You need to edit the user's crontab or cron reload for the LDAP users crontabs to be loaded. A work around could be to do a reload cron every time a network interface goes up or down. I suppose the fix would be to load all the crontabs but to check for the presence of the user only upon running the jobs. -- cron no longer respects nsswitch.conf https://bugs.launchpad.net/bugs/27520 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Qemu-devel] [Bug 595117] Re: qemu-nbd slow and missing writeback cache option
2010-06-24 00:16:03 -, Jamie Lokier: Serge Hallyn wrote: The default of qemu-img (of using O_SYNC) is not very sensible because anyway, the client (the kernel) uses caches (write-back), (and qemu-nbd -d doesn't flush those by the way). So if for instance qemu-nbd is killed, regardless of whether qemu-nbd uses O_SYNC, O_DIRECT or not, the data in the image will not be consistent anyway, unless syncs are done by the client (like fsync on the nbd device or sync mount option), and with qemu-nbd's O_SYNC mode, those syncs will be extremely slow. Do the client syncs cause the nbd server to fsync or fdatasync the file? The clients syncs cause the data to be sent to the server. The server then writes it to disk and each write blocks until the data is written physically on disk with O_SYNC. It appears it is because by default the disk image it serves is open with O_SYNC. The --nocache option, unintuitively, makes matters a bit better because it causes the image to be open with O_DIRECT instead of O_SYNC. [...] --cache=off is the same as --nocache (that is use O_DIRECT), writethrough is using O_SYNC and is still the default so this patch doesn't change the functionality. writeback is none of those flags, so is the addition of this patch. The patch also does an fsync upon qemu-nbd -d to make sure data is flushed to the image before removing the nbd. I really wish qemu's options didn't give the false impression nocache does less caching than writethrough. O_DIRECT does caching in the disk controller/hardware, while O_SYNC hopefully does not, nowadays. [...] Note that I use the same none, writethrough, writeback as another utility shipped with qemu for consistency (see vl.c in the source), I don't mind about the words as long as the writeback functionality is available. Cheers, Stephane -- qemu-nbd slow and missing writeback cache option https://bugs.launchpad.net/bugs/595117 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Qemu-devel] [Bug 595117] Re: qemu-nbd slow and missing writeback cache option
2010-06-24 00:16:03 -, Jamie Lokier: Serge Hallyn wrote: The default of qemu-img (of using O_SYNC) is not very sensible because anyway, the client (the kernel) uses caches (write-back), (and qemu-nbd -d doesn't flush those by the way). So if for instance qemu-nbd is killed, regardless of whether qemu-nbd uses O_SYNC, O_DIRECT or not, the data in the image will not be consistent anyway, unless syncs are done by the client (like fsync on the nbd device or sync mount option), and with qemu-nbd's O_SYNC mode, those syncs will be extremely slow. Do the client syncs cause the nbd server to fsync or fdatasync the file? The clients syncs cause the data to be sent to the server. The server then writes it to disk and each write blocks until the data is written physically on disk with O_SYNC. It appears it is because by default the disk image it serves is open with O_SYNC. The --nocache option, unintuitively, makes matters a bit better because it causes the image to be open with O_DIRECT instead of O_SYNC. [...] --cache=off is the same as --nocache (that is use O_DIRECT), writethrough is using O_SYNC and is still the default so this patch doesn't change the functionality. writeback is none of those flags, so is the addition of this patch. The patch also does an fsync upon qemu-nbd -d to make sure data is flushed to the image before removing the nbd. I really wish qemu's options didn't give the false impression nocache does less caching than writethrough. O_DIRECT does caching in the disk controller/hardware, while O_SYNC hopefully does not, nowadays. [...] Note that I use the same none, writethrough, writeback as another utility shipped with qemu for consistency (see vl.c in the source), I don't mind about the words as long as the writeback functionality is available. Cheers, Stephane -- qemu-nbd slow and missing writeback cache option https://bugs.launchpad.net/bugs/595117 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 595117] Re: qemu-nbd slow and missing writeback cache option
2010-06-16 20:36:00 -, Dustin Kirkland: [...] Could you please send that patch to the qemu-devel@ mailing list? Thanks! [...] Hi Dustin, it looks like qemu-devel is subscribed to bugs in there, so the bug report is on the list already. Note that I still consider it as a bug because: - slow performance for no good reason - --nocache option is misleading - no fsync on -d which to my mind is a bug. Cheers, Stephane -- qemu-nbd slow and missing writeback cache option https://bugs.launchpad.net/bugs/595117 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 595117] Re: qemu-nbd slow and missing writeback cache option
2010-06-16 20:36:00 -, Dustin Kirkland: [...] Could you please send that patch to the qemu-devel@ mailing list? Thanks! [...] Hi Dustin, it looks like qemu-devel is subscribed to bugs in there, so the bug report is on the list already. Note that I still consider it as a bug because: - slow performance for no good reason - --nocache option is misleading - no fsync on -d which to my mind is a bug. Cheers, Stephane -- qemu-nbd slow and missing writeback cache option https://bugs.launchpad.net/bugs/595117 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 595117] [NEW] qemu-nbd slow and missing writeback cache option
Public bug reported:
Binary package hint: qemu-kvm
dpkg -l | grep qemu
ii kvm
1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9dummy transitional
pacakge from kvm to qemu-
ii qemu 0.12.3+noroms-0ubuntu9
dummy transitional pacakge from qemu to qemu
ii qemu-common 0.12.3+noroms-0ubuntu9
qemu common functionality (bios, documentati
ii qemu-kvm 0.12.3+noroms-0ubuntu9
Full virtualization on i386 and amd64 hardwa
ii qemu-kvm-extras 0.12.3+noroms-0ubuntu9
fast processor emulator binaries for non-x86
ii qemu-launcher1.7.4-1ubuntu2
GTK+ front-end to QEMU computer emulator
ii qemuctl 0.2-2
controlling GUI for qemu
lucid amd64.
qemu-nbd is a lot slower when writing to disk than say nbd-server.
It appears it is because by default the disk image it serves is open
with O_SYNC. The --nocache option, unintuitively, makes matters a bit
better because it causes the image to be open with O_DIRECT instead of
O_SYNC.
The qemu code allows an image to be open without any of those flags, but
unfortunately qemu-nbd doesn't have the option to do that (qemu doesn't
allow the image to be open with both O_SYNC and O_DIRECT though).
The default of qemu-img (of using O_SYNC) is not very sensible because
anyway, the client (the kernel) uses caches (write-back), (and qemu-nbd
-d doesn't flush those by the way). So if for instance qemu-nbd is
killed, regardless of whether qemu-nbd uses O_SYNC, O_DIRECT or not, the
data in the image will not be consistent anyway, unless syncs are done
by the client (like fsync on the nbd device or sync mount option), and
with qemu-nbd's O_SYNC mode, those syncs will be extremely slow.
Attached is a patch that adds a
--cache={off,none,writethrough,writeback} option to qemu-nbd.
--cache=off is the same as --nocache (that is use O_DIRECT),
writethrough is using O_SYNC and is still the default so this patch
doesn't change the functionality. writeback is none of those flags, so
is the addition of this patch. The patch also does an fsync upon qemu-
nbd -d to make sure data is flushed to the image before removing the
nbd.
Consider this test scenario:
dd bs=1M count=100 of=a /dev/null
qemu-nbd --cache=x -c /dev/nbd0 a
cp /dev/zero /dev/nbd0
time perl -MIO::Handle -e 'STDOUT-sync or die$!' 1 /dev/nbd0
With cache=writethrough (the default), it takes over 10 minutes to write
those 100MB worth of zeroes. Running a strace, we see the recvfrom and
sentos delayed by each 1kb write(2)s to disk (10 to 30 ms per write).
With cache=off, it takes about 30 seconds.
With cache=writeback, it takes about 3 seconds, which is similar to the
performance you get with nbd-server
Note that the cp command runs instantly as the data is buffered by the
client (the kernel), and not sent to qemu-nbd until the fsync(2) is
called.
** Affects: qemu-kvm (Ubuntu)
Importance: Undecided
Status: New
--
qemu-nbd slow and missing writeback cache option
https://bugs.launchpad.net/bugs/595117
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 595117] Re: qemu-nbd slow and missing writeback cache option
** Patch added: qemu-nbd.diff http://launchpadlibrarian.net/50435882/qemu-nbd.diff -- qemu-nbd slow and missing writeback cache option https://bugs.launchpad.net/bugs/595117 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 595117] [NEW] qemu-nbd slow and missing writeback cache option
Public bug reported:
Binary package hint: qemu-kvm
dpkg -l | grep qemu
ii kvm
1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9dummy transitional
pacakge from kvm to qemu-
ii qemu 0.12.3+noroms-0ubuntu9
dummy transitional pacakge from qemu to qemu
ii qemu-common 0.12.3+noroms-0ubuntu9
qemu common functionality (bios, documentati
ii qemu-kvm 0.12.3+noroms-0ubuntu9
Full virtualization on i386 and amd64 hardwa
ii qemu-kvm-extras 0.12.3+noroms-0ubuntu9
fast processor emulator binaries for non-x86
ii qemu-launcher1.7.4-1ubuntu2
GTK+ front-end to QEMU computer emulator
ii qemuctl 0.2-2
controlling GUI for qemu
lucid amd64.
qemu-nbd is a lot slower when writing to disk than say nbd-server.
It appears it is because by default the disk image it serves is open
with O_SYNC. The --nocache option, unintuitively, makes matters a bit
better because it causes the image to be open with O_DIRECT instead of
O_SYNC.
The qemu code allows an image to be open without any of those flags, but
unfortunately qemu-nbd doesn't have the option to do that (qemu doesn't
allow the image to be open with both O_SYNC and O_DIRECT though).
The default of qemu-img (of using O_SYNC) is not very sensible because
anyway, the client (the kernel) uses caches (write-back), (and qemu-nbd
-d doesn't flush those by the way). So if for instance qemu-nbd is
killed, regardless of whether qemu-nbd uses O_SYNC, O_DIRECT or not, the
data in the image will not be consistent anyway, unless syncs are done
by the client (like fsync on the nbd device or sync mount option), and
with qemu-nbd's O_SYNC mode, those syncs will be extremely slow.
Attached is a patch that adds a
--cache={off,none,writethrough,writeback} option to qemu-nbd.
--cache=off is the same as --nocache (that is use O_DIRECT),
writethrough is using O_SYNC and is still the default so this patch
doesn't change the functionality. writeback is none of those flags, so
is the addition of this patch. The patch also does an fsync upon qemu-
nbd -d to make sure data is flushed to the image before removing the
nbd.
Consider this test scenario:
dd bs=1M count=100 of=a /dev/null
qemu-nbd --cache=x -c /dev/nbd0 a
cp /dev/zero /dev/nbd0
time perl -MIO::Handle -e 'STDOUT-sync or die$!' 1 /dev/nbd0
With cache=writethrough (the default), it takes over 10 minutes to write
those 100MB worth of zeroes. Running a strace, we see the recvfrom and
sentos delayed by each 1kb write(2)s to disk (10 to 30 ms per write).
With cache=off, it takes about 30 seconds.
With cache=writeback, it takes about 3 seconds, which is similar to the
performance you get with nbd-server
Note that the cp command runs instantly as the data is buffered by the
client (the kernel), and not sent to qemu-nbd until the fsync(2) is
called.
** Affects: qemu-kvm (Ubuntu)
Importance: Undecided
Status: New
--
qemu-nbd slow and missing writeback cache option
https://bugs.launchpad.net/bugs/595117
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 595117] Re: qemu-nbd slow and missing writeback cache option
** Patch added: qemu-nbd.diff http://launchpadlibrarian.net/50435882/qemu-nbd.diff -- qemu-nbd slow and missing writeback cache option https://bugs.launchpad.net/bugs/595117 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 587858] [NEW] update-motd executed even in non-interactive sessions
Public bug reported: ssh localhost exit takes edges on lucid (ii libpam-modules1.1.1-2ubuntu2 Pluggable Authentication Modules for PAM ii openssh-server1:5.3p1-3ubuntu3 secure shell (SSH) server, for secure access from remote machines ) Because /etc/motd is updated even though it is not displayed as we're running a command non-interactively. Example timing for running ssh localhost 'exit 3' (using strace -tt -fe execve): 11089 10:50:23.149350 execve(/usr/sbin/sshd, [/usr/sbin/sshd, -R], [/* 4 vars */]) = 0 11091 10:50:23.525659 execve(/bin/sh, [sh, -c, run-parts --lsbsysinit /etc/upda...], [/* 4 vars */]) = 0 11092 10:50:23.548468 execve(/bin/run-parts, [run-parts, --lsbsysinit, /etc/update-motd.d], [/* 5 vars */]) = 0 11093 10:50:23.564947 execve(/etc/update-motd.d/00-header, [/etc/update-motd.d/00-header], [/* 5 vars */]) = 0 11094 10:50:23.571854 execve(/bin/uname, [uname, -a], [/* 5 vars */]) = 0 11095 10:50:23.589084 execve(/usr/bin/lsb_release, [lsb_release, -s, -d], [/* 5 vars */]) = 0 11097 10:50:24.077419 execve(/etc/update-motd.d/10-help-text, [/etc/update-motd.d/10-help-text], [/* 5 vars */]) = 0 11098 10:50:24.097081 execve(/bin/uname, [uname, -r], [/* 5 vars */]) = 0 11100 10:50:24.108702 execve(/bin/grep, [grep, -qs, \\-server], [/* 5 vars */]) = 0 11101 10:50:24.124869 execve(/etc/update-motd.d/20-cpu-checker, [/etc/update-motd.d/20-cpu-checke...], [/* 5 vars */]) = 0 11101 10:50:24.137645 execve(/usr/lib/update-notifier/update-motd-cpu-checker, [/usr/lib/update-notifier/update-...], [/* 5 vars */]) = 0 11102 10:50:24.158758 execve(/usr/bin/check-bios-nx, [/usr/bin/check-bios-nx], [/* 5 vars */]) = 0 11103 10:50:24.180763 execve(/usr/bin/getopt, [getopt, -o, h, --long, verbose,help, -n, check-bios-nx, --], [/* 6 vars */]) = 0 11104 10:50:24.204348 execve(/usr/bin/awk, [awk, -f, -, /proc/cpuinfo], [/* 7 vars */]) = 0 11106 10:50:24.231468 execve(/bin/sh, [sh, -c, uname -m], [/* 7 vars */]) = 0 11107 10:50:24.238869 execve(/bin/uname, [uname, -m], [/* 7 vars */]) = 0 11108 10:50:24.254079 execve(/etc/update-motd.d/50-landscape-sysinfo, [/etc/update-motd.d/50-landscape-...], [/* 5 vars */]) = 0 11109 10:50:24.262037 execve(/bin/date, [/bin/date], [/* 5 vars */]) = 0 0 10:50:24.285766 execve(/usr/bin/landscape-sysinfo, [/usr/bin/landscape-sysinfo], [/* 5 vars */]) = 0 8 10:50:26.755870 execve(/usr/local/sbin/who, [who, -q], [/* 5 vars */]) = -1 ENOENT (No such file or directory) 8 10:50:26.756061 execve(/usr/local/bin/who, [who, -q], [/* 5 vars */]) = -1 ENOENT (No such file or directory) 8 10:50:26.756227 execve(/usr/bin/who, [who, -q], [/* 5 vars */]) = 0 11120 10:50:26.847832 execve(/etc/update-motd.d/90-updates-available, [/etc/update-motd.d/90-updates-av...], [/* 5 vars */]) = 0 11120 10:50:26.853820 execve(/usr/lib/update-notifier/update-motd-updates-available, [/usr/lib/update-notifier/update-...], [/* 5 vars */]) = 0 11121 10:50:26.872259 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/update-notifier/updates...], [/* 5 vars */]) = 0 11122 10:50:26.904240 execve(/usr/bin/apt-config, [apt-config, shell, StateDir, Dir::State], [/* 5 vars */]) = 0 11123 10:50:26.961484 execve(/usr/bin/apt-config, [apt-config, shell, ListDir, Dir::State::Lists], [/* 5 vars */]) = 0 11124 10:50:26.987301 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//_var_cache_...], [/* 5 vars */]) = 0 11125 10:50:26.997297 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//...], [/* 5 vars */]) = 0 11126 10:50:27.007091 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11127 10:50:27.017322 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11128 10:50:27.027804 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11129 10:50:27.046944 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11130 10:50:27.056748 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11131 10:50:27.066563 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11132 10:50:27.076351 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11133 10:50:27.086191 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11134 10:50:27.096436 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11135 10:50:27.106932 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11136 10:50:27.117383 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11137 10:50:27.127606 execve(/usr/bin/stat, [stat, -c, %Y,
[Bug 587858] [NEW] update-motd executed even in non-interactive sessions
Public bug reported: ssh localhost exit takes edges on lucid (ii libpam-modules1.1.1-2ubuntu2 Pluggable Authentication Modules for PAM ii openssh-server1:5.3p1-3ubuntu3 secure shell (SSH) server, for secure access from remote machines ) Because /etc/motd is updated even though it is not displayed as we're running a command non-interactively. Example timing for running ssh localhost 'exit 3' (using strace -tt -fe execve): 11089 10:50:23.149350 execve(/usr/sbin/sshd, [/usr/sbin/sshd, -R], [/* 4 vars */]) = 0 11091 10:50:23.525659 execve(/bin/sh, [sh, -c, run-parts --lsbsysinit /etc/upda...], [/* 4 vars */]) = 0 11092 10:50:23.548468 execve(/bin/run-parts, [run-parts, --lsbsysinit, /etc/update-motd.d], [/* 5 vars */]) = 0 11093 10:50:23.564947 execve(/etc/update-motd.d/00-header, [/etc/update-motd.d/00-header], [/* 5 vars */]) = 0 11094 10:50:23.571854 execve(/bin/uname, [uname, -a], [/* 5 vars */]) = 0 11095 10:50:23.589084 execve(/usr/bin/lsb_release, [lsb_release, -s, -d], [/* 5 vars */]) = 0 11097 10:50:24.077419 execve(/etc/update-motd.d/10-help-text, [/etc/update-motd.d/10-help-text], [/* 5 vars */]) = 0 11098 10:50:24.097081 execve(/bin/uname, [uname, -r], [/* 5 vars */]) = 0 11100 10:50:24.108702 execve(/bin/grep, [grep, -qs, \\-server], [/* 5 vars */]) = 0 11101 10:50:24.124869 execve(/etc/update-motd.d/20-cpu-checker, [/etc/update-motd.d/20-cpu-checke...], [/* 5 vars */]) = 0 11101 10:50:24.137645 execve(/usr/lib/update-notifier/update-motd-cpu-checker, [/usr/lib/update-notifier/update-...], [/* 5 vars */]) = 0 11102 10:50:24.158758 execve(/usr/bin/check-bios-nx, [/usr/bin/check-bios-nx], [/* 5 vars */]) = 0 11103 10:50:24.180763 execve(/usr/bin/getopt, [getopt, -o, h, --long, verbose,help, -n, check-bios-nx, --], [/* 6 vars */]) = 0 11104 10:50:24.204348 execve(/usr/bin/awk, [awk, -f, -, /proc/cpuinfo], [/* 7 vars */]) = 0 11106 10:50:24.231468 execve(/bin/sh, [sh, -c, uname -m], [/* 7 vars */]) = 0 11107 10:50:24.238869 execve(/bin/uname, [uname, -m], [/* 7 vars */]) = 0 11108 10:50:24.254079 execve(/etc/update-motd.d/50-landscape-sysinfo, [/etc/update-motd.d/50-landscape-...], [/* 5 vars */]) = 0 11109 10:50:24.262037 execve(/bin/date, [/bin/date], [/* 5 vars */]) = 0 0 10:50:24.285766 execve(/usr/bin/landscape-sysinfo, [/usr/bin/landscape-sysinfo], [/* 5 vars */]) = 0 8 10:50:26.755870 execve(/usr/local/sbin/who, [who, -q], [/* 5 vars */]) = -1 ENOENT (No such file or directory) 8 10:50:26.756061 execve(/usr/local/bin/who, [who, -q], [/* 5 vars */]) = -1 ENOENT (No such file or directory) 8 10:50:26.756227 execve(/usr/bin/who, [who, -q], [/* 5 vars */]) = 0 11120 10:50:26.847832 execve(/etc/update-motd.d/90-updates-available, [/etc/update-motd.d/90-updates-av...], [/* 5 vars */]) = 0 11120 10:50:26.853820 execve(/usr/lib/update-notifier/update-motd-updates-available, [/usr/lib/update-notifier/update-...], [/* 5 vars */]) = 0 11121 10:50:26.872259 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/update-notifier/updates...], [/* 5 vars */]) = 0 11122 10:50:26.904240 execve(/usr/bin/apt-config, [apt-config, shell, StateDir, Dir::State], [/* 5 vars */]) = 0 11123 10:50:26.961484 execve(/usr/bin/apt-config, [apt-config, shell, ListDir, Dir::State::Lists], [/* 5 vars */]) = 0 11124 10:50:26.987301 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//_var_cache_...], [/* 5 vars */]) = 0 11125 10:50:26.997297 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//...], [/* 5 vars */]) = 0 11126 10:50:27.007091 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11127 10:50:27.017322 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11128 10:50:27.027804 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11129 10:50:27.046944 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11130 10:50:27.056748 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11131 10:50:27.066563 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11132 10:50:27.076351 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11133 10:50:27.086191 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11134 10:50:27.096436 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11135 10:50:27.106932 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11136 10:50:27.117383 execve(/usr/bin/stat, [stat, -c, %Y, /var/lib/apt//lists//gb.archive], [/* 5 vars */]) = 0 11137 10:50:27.127606 execve(/usr/bin/stat, [stat, -c, %Y,
Re: [Bug 587858] Re: update-motd executed even in non-interactive sessions
[...] Bug description: ssh localhost exit takes edges on lucid [...] Ouch, sorry. I meant ages above. -- Stephane -- update-motd executed even in non-interactive sessions https://bugs.launchpad.net/bugs/587858 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 572393] Re: err:module:attach_process _dlls “odbc32.dll” failed to initializ e, aborting
same problem when running Sparx Systems Enterprise Architect. Same work around. -- err:module:attach_process_dlls “odbc32.dll” failed to initialize, aborting https://bugs.launchpad.net/bugs/572393 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 572393] Re: err:module:attach_process _dlls “odbc32.dll” failed to initializ e, aborting
and I should add that it worked OK in karmic. Also, same problem with wine1.0 on Lucid. -- err:module:attach_process_dlls “odbc32.dll” failed to initialize, aborting https://bugs.launchpad.net/bugs/572393 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 559047] [NEW] parted print crash in en_GB.utf8 locale
Public bug reported: Binary package hint: parted $ uname -a Linux dagobah 2.6.24-27-server #1 SMP Fri Mar 12 01:23:09 UTC 2010 x86_64 GNU/Linux $ dpkg -l | grep parted ii libparted1.7-1 1.7.1-5.1ubuntu9.2 The GNU Parted disk partitioning shared libr ii libparted1.7-dbg1.7.1-5.1ubuntu9.2 The GNU Parted disk partitioning library deb ii libparted1.7-dev1.7.1-5.1ubuntu9.2 The GNU Parted disk partitioning library dev ii parted 1.7.1-5.1ubuntu9.2 The GNU Parted disk partition resizing progr ii parted-doc 1.7.1-5.1ubuntu9.2 The GNU Parted disk partition resizing progr (on hardy amd64) $ sudo env LC_ALL=en_US.utf8 parted /dev/sda print Disk /dev/sda: 2000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End SizeFile system Name Flags 1 17.4kB 1000MB 1000MB linux-swap 2 1000MB 8000MB 7000MB ext3 raid 3 8000MB 2000GB 1992GB lvm Information: Don't forget to update /etc/fstab, if necessary. $ sudo env LC_ALL=en_GB.utf8 parted /dev/sda print Disk /dev/sda: 2000GB Sector size (logical/physical): 512B/512B Partition Table: gpt *** glibc detected *** parted: realloc(): invalid next size: 0x0063bab0 *** === Backtrace: = /lib/libc.so.6[0x7fb17e2afe02] /lib/libc.so.6(realloc+0x130)[0x7fb17e2b1ea0] parted[0x40b2b9] parted[0x405773] parted[0x40a18c] parted[0x4083e7] /lib/libc.so.6(__libc_start_main+0xf4)[0x7fb17e2581c4] parted[0x403ba9] === Memory map: 0040-0041 r-xp 09:00 153388 /sbin/parted 0060f000-0061 rw-p f000 09:00 153388 /sbin/parted 0061-006e rw-p 0061 00:00 0 [heap] 7fb17800-7fb178021000 rw-p 7fb17800 00:00 0 7fb178021000-7fb17c00 ---p 7fb178021000 00:00 0 7fb17de28000-7fb17de35000 r-xp 09:00 258064 /lib/libgcc_s.so.1 7fb17de35000-7fb17e035000 ---p d000 09:00 258064 /lib/libgcc_s.so.1 7fb17e035000-7fb17e036000 rw-p d000 09:00 258064 /lib/libgcc_s.so.1 7fb17e036000-7fb17e039000 r-xp 09:00 258062 /lib/libuuid.so.1.2 7fb17e039000-7fb17e239000 ---p 3000 09:00 258062 /lib/libuuid.so.1.2 7fb17e239000-7fb17e23a000 rw-p 3000 09:00 258062 /lib/libuuid.so.1.2 7fb17e23a000-7fb17e392000 r-xp 09:00 258071 /lib/libc-2.7.so 7fb17e392000-7fb17e592000 ---p 00158000 09:00 258071 /lib/libc-2.7.so 7fb17e592000-7fb17e595000 r--p 00158000 09:00 258071 /lib/libc-2.7.so 7fb17e595000-7fb17e597000 rw-p 0015b000 09:00 258071 /lib/libc-2.7.so 7fb17e597000-7fb17e59c000 rw-p 7fb17e597000 00:00 0 7fb17e59c000-7fb17e5d3000 r-xp 09:00 258113 /lib/libncurses.so.5.6 7fb17e5d3000-7fb17e7d2000 ---p 00037000 09:00 258113 /lib/libncurses.so.5.6 7fb17e7d2000-7fb17e7d7000 rw-p 00036000 09:00 258113 /lib/libncurses.so.5.6 7fb17e7d7000-7fb17e7d9000 r-xp 09:00 258074 /lib/libdl-2.7.so 7fb17e7d9000-7fb17e9d9000 ---p 2000 09:00 258074 /lib/libdl-2.7.so 7fb17e9d9000-7fb17e9db000 rw-p 2000 09:00 258074 /lib/libdl-2.7.so 7fb17e9db000-7fb17ea12000 r-xp 09:00 258218 /lib/libreadline.so.5.2 7fb17ea12000-7fb17ec12000 ---p 00037000 09:00 258218 /lib/libreadline.so.5.2 7fb17ec12000-7fb17ec1a000 rw-p 00037000 09:00 258218 /lib/libreadline.so.5.2 7fb17ec1a000-7fb17ec1b000 rw-p 7fb17ec1a000 00:00 0 7fb17ec1b000-7fb17ec75000 r-xp 09:00 260438 /lib/libparted-1.7.so.1.0.0 7fb17ec75000-7fb17ee74000 ---p 0005a000 09:00 260438 /lib/libparted-1.7.so.1.0.0 7fb17ee74000-7fb17ee77000 rw-p 00059000 09:00 260438 /lib/libparted-1.7.so.1.0.0 7fb17ee77000-7fb17ee78000 rw-p 7fb17ee77000 00:00 0 7fb17ee78000-7fb17ee95000 r-xp 09:00 258065 /lib/ld-2.7.so 7fb17ef53000-7fb17ef54000 rw-p 7fb17ef53000 00:00 0 7fb17ef54000-7fb17ef55000 r--p 09:00 64708 /usr/share/locale-langpack/en_GB/LC_MESSAGES/parted.mo 7fb17ef55000-7fb17ef94000 r--p 09:00 64517 /usr/lib/locale/en_GB.utf8/LC_CTYPE 7fb17ef94000-7fb17ef95000 r--p 09:00 64518 /usr/lib/locale/en_GB.utf8/LC_NUMERIC 7fb17ef95000-7fb17ef96000 r--p 09:00 64519 /usr/lib/locale/en_GB.utf8/LC_TIME
[Bug 559047] Re: parted print crash in en_GB.utf8 locale
Was fixed upstreams at: http://git.debian.org/?p=parted/parted.git;a=blobdiff;f=parted/parted.c;h=203358b0496fe81f5b1c70cc86a47dce4f2ace6e;hp=37ed053512e0ca9c3c6bbed2b92474c0b97f3a84;hb=0757137981e4ae47ed5e91413e526478c7ab1770;hpb=75f5b27a41f59441c7bcaf14d8015a247bb44d66 Patch attached. ** Patch added: fix http://launchpadlibrarian.net/43564207/parted.patch -- parted print crash in en_GB.utf8 locale https://bugs.launchpad.net/bugs/559047 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 536620] [NEW] SEGV when using pasv_address
Public bug reported:
Binary package hint: vsftpd
vsftpd2.2.0-1ubuntu1
Any attempt to set the pasv_address configuration parameter causes
vsftpd to SEGV upon a client issuing a PASV FTP command.
The bug was already fixed upstreams in 2.2.1, the fix is:
--- vsftpd-2.2.0/postlogin.c2009-08-08 02:49:15.0 +0100
+++ vsftpd-2.2.0.fixed/postlogin.c 2010-03-10 12:28:30.0 +
@@ -584,6 +584,7 @@ handle_pasv(struct vsf_session* p_sess,
if (tunable_pasv_address != 0)
{
/* Report passive address as specified in configuration */
+vsf_sysutil_sockaddr_alloc_ipv4(s_p_sockaddr);
if (vsf_sysutil_inet_aton(tunable_pasv_address, s_p_sockaddr) == 0)
{
die(invalid pasv_address);
Any way that this fix be applied to the karmic package?
** Affects: vsftpd (Ubuntu)
Importance: Undecided
Status: New
--
SEGV when using pasv_address
https://bugs.launchpad.net/bugs/536620
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vsftpd in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 536620] [NEW] SEGV when using pasv_address
Public bug reported:
Binary package hint: vsftpd
vsftpd2.2.0-1ubuntu1
Any attempt to set the pasv_address configuration parameter causes
vsftpd to SEGV upon a client issuing a PASV FTP command.
The bug was already fixed upstreams in 2.2.1, the fix is:
--- vsftpd-2.2.0/postlogin.c2009-08-08 02:49:15.0 +0100
+++ vsftpd-2.2.0.fixed/postlogin.c 2010-03-10 12:28:30.0 +
@@ -584,6 +584,7 @@ handle_pasv(struct vsf_session* p_sess,
if (tunable_pasv_address != 0)
{
/* Report passive address as specified in configuration */
+vsf_sysutil_sockaddr_alloc_ipv4(s_p_sockaddr);
if (vsf_sysutil_inet_aton(tunable_pasv_address, s_p_sockaddr) == 0)
{
die(invalid pasv_address);
Any way that this fix be applied to the karmic package?
** Affects: vsftpd (Ubuntu)
Importance: Undecided
Status: New
--
SEGV when using pasv_address
https://bugs.launchpad.net/bugs/536620
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 536620] Re: SEGV when using pasv_address
** Patch added: fix http://launchpadlibrarian.net/40689544/vsftpd.patch -- SEGV when using pasv_address https://bugs.launchpad.net/bugs/536620 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 412152] Re: gnome-disk-utility nags me too much that my disk is failing
** Changed in: gnome-disk-utility (Ubuntu) Status: Fix Released = Fix Committed ** Changed in: gnome-disk-utility (Ubuntu) Status: Fix Committed = Fix Released -- gnome-disk-utility nags me too much that my disk is failing https://bugs.launchpad.net/bugs/412152 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 519380] Re: remounts don't work with mountall
2010-02-09 20:37:34 -, Stephane Chazelas: [...] I've now found not too bad a work around: have a /sbin/mount.bind like: #! /bin/sh -x [ $# -ge 2 ] || exit dev=$1 mount_point=$2; shift 2 /bin/mount -i --bind -- $dev $mount_point || exit [ $1 != -o ] exit exec /bin/mount -i -o remount $@ $mount_point and then: /here /there bind noexec 0 0 in fstab Of, course /sbin/mount.bind being a shell script, you don't want to add the user option to the script, but that script could be written in a safer language, you get the idea. [...] Please ignore that last part, that script is run as the real user (I had assumed it was run as root because of mount's setuid). And user mounts wouldn't work anyway here. I can see mount.smbfs is a shell script as well. regards, Stephane -- remounts don't work with mountall https://bugs.launchpad.net/bugs/519380 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 519380] [NEW] remounts don't work with mountall
Public bug reported: Binary package hint: mountall Hi, the context: to have the noexec or nosuid applied on a --bind mount, you need to do it in two steps (one may argue that mount(8) is broken in that way): mount --bind /here /there mount -o remount,noexec /there (mount --bind -o noexec /here /there won't work). So, in /etc/fstab, you've got to write it: /here /there none bind 0 0 remount-there /there none remount,noexec 0 0 However the above doesn't work with mountall. It does work with mount -a so it seems it's a regression from pre- mountall ubuntu releases. The problem occurs both on karmic and lucid (2.4): ** Affects: mountall (Ubuntu) Importance: Undecided Status: New -- remounts don't work with mountall https://bugs.launchpad.net/bugs/519380 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 519380] Re: remounts don't work with mountall
2010-02-09 18:02:32 -, Johan Kiviniemi: It seems to me the correct fstab entry would look like /here /there none bind,noexec mount needs to be modified to handle that, though. Yes, agreed, see: http://article.gmane.org/gmane.linux.utilities.util-linux-ng/2979 raised today. There’s also a race condition in mounting something without noexec and then adding the flag with remount. Yes, though you'd had the same condition (though shorter) if mount(8) were modified as you need 2 mount(2) system calls anywat. A mount that needs to be noexec for whatever reason isn’t for a short period. Yes, but here we're talking of /etc/fstab which (unless noauto is also passed, which is not really our concern here as we're discussing mountall), this is gonna happen before anybody can log in and exploit the race condition. In my case, I'm actually doing a mount --bind /here /here and I'm concerned with suid files. /here contains file systems trees meant to be mounted as root file systems by other hosts over NFS, I want local users to be able to access the images for reading, but I don't want suid files as they could potentially be exploited . Not that it’s likely to cause a problem, but that’s an indicator something’s not right with the method. I agree, but at the moment, I didn't have any way around that (other than adding an init script that mounts those separately), and it used to work, so it's a regression. I've now found not too bad a work around: have a /sbin/mount.bind like: #! /bin/sh -x [ $# -ge 2 ] || exit dev=$1 mount_point=$2; shift 2 /bin/mount -i --bind -- $dev $mount_point || exit [ $1 != -o ] exit exec /bin/mount -i -o remount $@ $mount_point and then: /here /there bind noexec 0 0 in fstab Of, course /sbin/mount.bind being a shell script, you don't want to add the user option to the script, but that script could be written in a safer language, you get the idea. -- Stephane -- remounts don't work with mountall https://bugs.launchpad.net/bugs/519380 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 510086] Re: localhost connection timeouts after start of eucalyptus
2010-01-30 02:37:08 -, Daniel Nurmi: [...] I'm unable to reproduce this problem with (pre) Eucalyptus 1.6.2; with a running active CC in MANAGED mode (which has the masq rule in place), I can telnet to localhost port 22 (for example) without a problem, and sshing to localhost shows that I'm logged in from 'localhost' (implying that there is no nat going on). [...] Hi Daniel, the thing is, it's for ports where there's no listener that there's problem. Obviously, you've got a listener here as you managed to ssh. Try: telnet localhost 2 for instance (assuming you've got no service on port 2), you'll see telnet hanging instead of returning with a connection refused error message (that is, if you can reproduce the bug, but I'm quite confident that it's easily reproducible as it happened after a fresh install of Ubuntu Cloud with default parameters) Best regards, Stephane -- localhost connection timeouts after start of eucalyptus https://bugs.launchpad.net/bugs/510086 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 510086] Re: localhost connection timeouts after start of eucalyptus
2010-01-30 02:37:08 -, Daniel Nurmi: [...] I'm unable to reproduce this problem with (pre) Eucalyptus 1.6.2; with a running active CC in MANAGED mode (which has the masq rule in place), I can telnet to localhost port 22 (for example) without a problem, and sshing to localhost shows that I'm logged in from 'localhost' (implying that there is no nat going on). [...] Hi Daniel, the thing is, it's for ports where there's no listener that there's problem. Obviously, you've got a listener here as you managed to ssh. Try: telnet localhost 2 for instance (assuming you've got no service on port 2), you'll see telnet hanging instead of returning with a connection refused error message (that is, if you can reproduce the bug, but I'm quite confident that it's easily reproducible as it happened after a fresh install of Ubuntu Cloud with default parameters) Best regards, Stephane -- localhost connection timeouts after start of eucalyptus https://bugs.launchpad.net/bugs/510086 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 510086] [NEW] localhost connection timeouts after start of eucalyptus
Public bug reported: This is on ubuntu karmic server. After the starting of eucalyptus (sudo start eucalyptus), any TCP connection attempt on the loopback interface (the connect(2) system call) to a port that has no listener hangs instead of returning immediately with ECONNREFUSED. The problem seems due to a rule added upon startup in the nat iptable: Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 801 48085 MASQUERADE all -- anyany anywhere !172.19.0.0/16 That masquerades every connection even those locally generated. It could have other side effects. But the one that causes connection hangs is quite noticeable and affects many services. It could also be a kernel bug, because looking at the pcap traces upon a telnet localhost: 2997.869330 10.10.10.38 - 127.0.0.1TCP 35140 telnet [SYN] Seq=0 Win=32792 Len=0 MSS=16396 TSV=6901389 TSER=0 WS=7 12:43 2997.869351127.0.0.1 - 127.0.0.1TCP telnet 35140 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 and we see retransmissions of that until the connect(2) timesout. While if there's someone listening: 3432.999156 10.10.10.38 - 127.0.0.1TCP 57717 telnet [SYN] Seq=0 Win=32792 Len=0 MSS=16396 TSV=6944902 TSER=0 WS=7 12:55 3432.999183127.0.0.1 - 127.0.0.1TCP telnet 57717 [SYN, ACK] Seq=0 Ack=0 Win=32768 Len=0 MSS=16396 TSV=6944902 TSER=6944902 WS=7 3432.999203 10.10.10.38 - 127.0.0.1TCP 57717 telnet [ACK] Seq=1 Ack=1 Win=32896 Len=0 TSV=6944902 TSER=6944902 3432.999366 10.10.10.38 - 127.0.0.1TELNET Telnet Data ... 3432.999384127.0.0.1 - 127.0.0.1TCP telnet 57717 [ACK] Seq=1 Ack=24 Win=256 Len=0 TSV=6944902 TSER=6944902 It's still masqueraded, but the connection goes through. Also, I don't like the fact that the whole iptables conf is wiped out as soon as eucalyptus is started. (note that the UEC default installation installs ufw whose configuration is wiped that way). Those tables are installed via a call to iptables-restore on a file generated on the fly: root 1374 1 0 17:33 ?00:00:00 apache2 -f /var/run/eucalyptus/httpd-cc.conf -D FOREGROUND 107 1420 1374 0 17:33 ?00:00:00 apache2 -f /var/run/eucalyptus/httpd-cc.conf -D FOREGROUND 107 3497 1420 0 17:34 ?00:00:00 sh -c ///usr/lib/eucalyptus/euca_rootwrap iptables-restore /tmp/euca-ipt-WF6Jg9 root 3498 3497 0 17:34 ?00:00:00 /bin/sh - /sbin/iptables-restore (it's called several times), upon some POST http://10.10.10.38:8774/axis2/services/EucalyptusCC HTTP/1.1 request issues by I don't what. $ uname -srvm Linux 2.6.31-17-server #54-Ubuntu SMP Thu Dec 10 18:06:56 UTC 2009 x86_64 $ dpkg -l | grep euca ii euca2ools1.0+bzr20091007-0ubuntu1.1 managing cloud instances for Eucalyptus ii eucalyptus-cc1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Clu ii eucalyptus-cloud 1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Clo ii eucalyptus-common1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Com ii eucalyptus-gl1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Log ii eucalyptus-java-common 1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Com ii eucalyptus-sc1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Sto ii eucalyptus-walrus1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Wal ii libeucalyptus-commons-ext-java 0.4.2-0ubuntu1 Eucalyptus commons external Java library ** Affects: eucalyptus (Ubuntu) Importance: Undecided Status: New -- localhost connection timeouts after start of eucalyptus https://bugs.launchpad.net/bugs/510086 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to eucalyptus in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 510086] [NEW] localhost connection timeouts after start of eucalyptus
Public bug reported: This is on ubuntu karmic server. After the starting of eucalyptus (sudo start eucalyptus), any TCP connection attempt on the loopback interface (the connect(2) system call) to a port that has no listener hangs instead of returning immediately with ECONNREFUSED. The problem seems due to a rule added upon startup in the nat iptable: Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 801 48085 MASQUERADE all -- anyany anywhere !172.19.0.0/16 That masquerades every connection even those locally generated. It could have other side effects. But the one that causes connection hangs is quite noticeable and affects many services. It could also be a kernel bug, because looking at the pcap traces upon a telnet localhost: 2997.869330 10.10.10.38 - 127.0.0.1TCP 35140 telnet [SYN] Seq=0 Win=32792 Len=0 MSS=16396 TSV=6901389 TSER=0 WS=7 12:43 2997.869351127.0.0.1 - 127.0.0.1TCP telnet 35140 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 and we see retransmissions of that until the connect(2) timesout. While if there's someone listening: 3432.999156 10.10.10.38 - 127.0.0.1TCP 57717 telnet [SYN] Seq=0 Win=32792 Len=0 MSS=16396 TSV=6944902 TSER=0 WS=7 12:55 3432.999183127.0.0.1 - 127.0.0.1TCP telnet 57717 [SYN, ACK] Seq=0 Ack=0 Win=32768 Len=0 MSS=16396 TSV=6944902 TSER=6944902 WS=7 3432.999203 10.10.10.38 - 127.0.0.1TCP 57717 telnet [ACK] Seq=1 Ack=1 Win=32896 Len=0 TSV=6944902 TSER=6944902 3432.999366 10.10.10.38 - 127.0.0.1TELNET Telnet Data ... 3432.999384127.0.0.1 - 127.0.0.1TCP telnet 57717 [ACK] Seq=1 Ack=24 Win=256 Len=0 TSV=6944902 TSER=6944902 It's still masqueraded, but the connection goes through. Also, I don't like the fact that the whole iptables conf is wiped out as soon as eucalyptus is started. (note that the UEC default installation installs ufw whose configuration is wiped that way). Those tables are installed via a call to iptables-restore on a file generated on the fly: root 1374 1 0 17:33 ?00:00:00 apache2 -f /var/run/eucalyptus/httpd-cc.conf -D FOREGROUND 107 1420 1374 0 17:33 ?00:00:00 apache2 -f /var/run/eucalyptus/httpd-cc.conf -D FOREGROUND 107 3497 1420 0 17:34 ?00:00:00 sh -c ///usr/lib/eucalyptus/euca_rootwrap iptables-restore /tmp/euca-ipt-WF6Jg9 root 3498 3497 0 17:34 ?00:00:00 /bin/sh - /sbin/iptables-restore (it's called several times), upon some POST http://10.10.10.38:8774/axis2/services/EucalyptusCC HTTP/1.1 request issues by I don't what. $ uname -srvm Linux 2.6.31-17-server #54-Ubuntu SMP Thu Dec 10 18:06:56 UTC 2009 x86_64 $ dpkg -l | grep euca ii euca2ools1.0+bzr20091007-0ubuntu1.1 managing cloud instances for Eucalyptus ii eucalyptus-cc1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Clu ii eucalyptus-cloud 1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Clo ii eucalyptus-common1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Com ii eucalyptus-gl1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Log ii eucalyptus-java-common 1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Com ii eucalyptus-sc1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Sto ii eucalyptus-walrus1.6~bzr931-0ubuntu7.4 Elastic Utility Computing Architecture - Wal ii libeucalyptus-commons-ext-java 0.4.2-0ubuntu1 Eucalyptus commons external Java library ** Affects: eucalyptus (Ubuntu) Importance: Undecided Status: New -- localhost connection timeouts after start of eucalyptus https://bugs.launchpad.net/bugs/510086 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 364581] Re: Crash when logging in
2009-10-13 20:05:29 -, Chuck Short: [...] You have provided the information that I have needed. Regards chuck ** Changed in: mod-auth-mysql (Ubuntu) Importance: Undecided = Low [...] Hi Chunk, Why low? It crashes on 64bit machines, it's not really benign, is it? And the fix is the adding of a missing #include, which can't do much harm. regards, Stephane -- Crash when logging in https://bugs.launchpad.net/bugs/364581 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mod-auth-mysql in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 364581] Re: Crash when logging in
2009-10-13 20:05:29 -, Chuck Short: [...] You have provided the information that I have needed. Regards chuck ** Changed in: mod-auth-mysql (Ubuntu) Importance: Undecided = Low [...] Hi Chunk, Why low? It crashes on 64bit machines, it's not really benign, is it? And the fix is the adding of a missing #include, which can't do much harm. regards, Stephane -- Crash when logging in https://bugs.launchpad.net/bugs/364581 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 368044] Re: slapd crash when using SQL backend
What do you mean by where does it come from?. I comes from me some time ago. Why classify as low? Is it because the sql backend isn't supported? Cheers, Stephane -- slapd crash when using SQL backend https://bugs.launchpad.net/bugs/368044 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 368044] Re: slapd crash when using SQL backend
What do you mean by where does it come from?. I comes from me some time ago. Why classify as low? Is it because the sql backend isn't supported? Cheers, Stephane -- slapd crash when using SQL backend https://bugs.launchpad.net/bugs/368044 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 364581] Re: Crash when logging in
2009-10-05 14:02:29 -, Chuck Short: Which version of apache are you using (output of dpkg -l | grep apache will do)? [...] Any version of apache will do, the bug is not with apache. ii apache2-doc 2.2.11-2ubuntu2.3 Apache HTTP Server documentation ii apache2-mpm-itk 2.2.6-02-1build4.3 multiuser MPM for Apache 2.2 ii apache2-src 2.2.11-2ubuntu2.3 Apache source code ii apache2-utils 2.2.11-2ubuntu2.3 utility programs for webservers ii apache2.2-common 2.2.11-2ubuntu2.3 Apache HTTP Server common files ii libapache-htpasswd-perl 1.8-0.1 Manage Unix crypt-style password file ii libapache2-mod-auth-mysql 4.3.9-11 Apache 2 module for MySQL authentication ii libapache2-mod-auth-pam 1.1.1-6.1ubuntu1 module for Apache2 which authenticate using ii libapache2-mod-auth-sys-group 1.1.1-6.1ubuntu1 Module for Apache2 which checks user against ii libapache2-mod-perl2 2.0.4-5ubuntu1 Integration of perl with the Apache2 web ser ii libapache2-mod-php5 5.2.6.dfsg.1-3ubuntu4.2 server-side, HTML-embedded scripting languag ii libapache2-mod-proxy-html 3.0.1-1 Apache2 filter module for HTML links rewriti ii libapache2-reload-perl0.10-2 Reload Perl modules when changed on disk ii libapache2-svn1.5.4dfsg1-1ubuntu2.1 Subversion server modules for Apache ii libapache2-webauth3.6.0-1 Apache 2 modules for WebAuth authentication ii libapache2-webkdc 3.6.0-1 Apache 2 modules for a WebAuth authenticatio Attached is an updated version of the diff that fixes the other compiler warnings. IIRC, I've provided with an explanation of the actual bug, it is a bug that occurs on 64bit systems. Please let me know if it's not clear enough. Cheers, Stephane ** Attachment added: mod-auth-mysql.diff http://launchpadlibrarian.net/33110793/mod-auth-mysql.diff -- Crash when logging in https://bugs.launchpad.net/bugs/364581 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mod-auth-mysql in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
Re: [Bug 364581] Re: Crash when logging in
2009-10-05 14:02:29 -, Chuck Short: Which version of apache are you using (output of dpkg -l | grep apache will do)? [...] Any version of apache will do, the bug is not with apache. ii apache2-doc 2.2.11-2ubuntu2.3 Apache HTTP Server documentation ii apache2-mpm-itk 2.2.6-02-1build4.3 multiuser MPM for Apache 2.2 ii apache2-src 2.2.11-2ubuntu2.3 Apache source code ii apache2-utils 2.2.11-2ubuntu2.3 utility programs for webservers ii apache2.2-common 2.2.11-2ubuntu2.3 Apache HTTP Server common files ii libapache-htpasswd-perl 1.8-0.1 Manage Unix crypt-style password file ii libapache2-mod-auth-mysql 4.3.9-11 Apache 2 module for MySQL authentication ii libapache2-mod-auth-pam 1.1.1-6.1ubuntu1 module for Apache2 which authenticate using ii libapache2-mod-auth-sys-group 1.1.1-6.1ubuntu1 Module for Apache2 which checks user against ii libapache2-mod-perl2 2.0.4-5ubuntu1 Integration of perl with the Apache2 web ser ii libapache2-mod-php5 5.2.6.dfsg.1-3ubuntu4.2 server-side, HTML-embedded scripting languag ii libapache2-mod-proxy-html 3.0.1-1 Apache2 filter module for HTML links rewriti ii libapache2-reload-perl0.10-2 Reload Perl modules when changed on disk ii libapache2-svn1.5.4dfsg1-1ubuntu2.1 Subversion server modules for Apache ii libapache2-webauth3.6.0-1 Apache 2 modules for WebAuth authentication ii libapache2-webkdc 3.6.0-1 Apache 2 modules for a WebAuth authenticatio Attached is an updated version of the diff that fixes the other compiler warnings. IIRC, I've provided with an explanation of the actual bug, it is a bug that occurs on 64bit systems. Please let me know if it's not clear enough. Cheers, Stephane ** Attachment added: mod-auth-mysql.diff http://launchpadlibrarian.net/33110793/mod-auth-mysql.diff -- Crash when logging in https://bugs.launchpad.net/bugs/364581 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 326768] Re: mysqld_safe thinks mysqld has crashed when it hasn't
that patch is still wrong. The first time a HUP is received, we run the code in the trap and call wait which will wait for both the refresh command and the mysqld one. But we won't return from that trap until mysqld dies, and in the trap the HUP signal is blocked, which means any subsequent HUP will not be handled. A better way could be to implement some proper event handling as in: trap : HUP INT QUIT TERM while :; do action= mysqld ... while :; do signal=NONE wait || signal=$(kill -l $?) case $signal in (INT|TERM|QUIT) mysqladmin ... shutdown; exit;; (HUP) mysqladmin ... refresh;; (NONE) break;; # mysqld died (*) unexpected ... die;; esac esac done ** Changed in: mysql-dfsg-5.0 (Ubuntu Jaunty) Status: Fix Released = Incomplete -- mysqld_safe thinks mysqld has crashed when it hasn't https://bugs.launchpad.net/bugs/326768 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mysql-dfsg-5.0 in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 326768] Re: mysqld_safe thinks mysqld has crashed when it hasn't
that patch is still wrong. The first time a HUP is received, we run the code in the trap and call wait which will wait for both the refresh command and the mysqld one. But we won't return from that trap until mysqld dies, and in the trap the HUP signal is blocked, which means any subsequent HUP will not be handled. A better way could be to implement some proper event handling as in: trap : HUP INT QUIT TERM while :; do action= mysqld ... while :; do signal=NONE wait || signal=$(kill -l $?) case $signal in (INT|TERM|QUIT) mysqladmin ... shutdown; exit;; (HUP) mysqladmin ... refresh;; (NONE) break;; # mysqld died (*) unexpected ... die;; esac esac done ** Changed in: mysql-dfsg-5.0 (Ubuntu Jaunty) Status: Fix Released = Incomplete -- mysqld_safe thinks mysqld has crashed when it hasn't https://bugs.launchpad.net/bugs/326768 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 382677] Re: crash with SQL backend on search with empty attributes
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/27403420/Dependencies.txt -- crash with SQL backend on search with empty attributes https://bugs.launchpad.net/bugs/382677 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 382677] [NEW] crash with SQL backend on search with empty attributes
Public bug reported:
When using the SQL backend, a search like:
ldapsearch ... '(cn=)'
causes slapd to crash with this error:
slapd: /tmp/openldap-2.4.15/servers/slapd/back-sql/search.c:1366:
backsql_process_filter_attr: Assertion `0' failed.
Looking at the code there, it does a
switch(f-f_choice) {
default:
assert(0);
}
As it happens, in that instance f_choice is something like 0x80a3, that
is SLAPD_FILTER_UNDEFINED|LDAP_FILTER_EQUALITY.
And the back-sql backend doesn't support that SLAPD_FILTER_UNDEFINED
flag like the other backends, hence the abort() on that assert.
A work around for that (change in indentation no shown):
--- search.c~ 2009-06-01 15:55:16.0 +0100
+++ servers/slapd/back-sql/search.c 2009-06-01 17:00:51.0 +0100
@@ -717,6 +717,9 @@
goto done;
}
+ if (f-f_choice SLAPD_FILTER_UNDEFINED) {
+ rc = -1;
+ } else {
switch( f-f_choice ) {
case LDAP_FILTER_OR:
rc = backsql_process_filter_list( bsi, f-f_or,
@@ -772,6 +775,7 @@
ad = f-f_av_desc;
break;
}
+ }
if ( rc == -1 ) {
goto done;
That's only a work around. The fix would be to implement the support for
such searches.
Best regards,
Stephane
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: slapd 2.4.15-1ubuntu3
ProcEnviron:
SHELL=/bin/zsh
PATH=(custom, user)
LANG=en_GB.UTF-8
SourcePackage: openldap
Uname: Linux 2.6.30-rc6-custom i686
** Affects: openldap (Ubuntu)
Importance: Undecided
Status: New
** Tags: apport-bug i386
--
crash with SQL backend on search with empty attributes
https://bugs.launchpad.net/bugs/382677
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 382677] [NEW] crash with SQL backend on search with empty attributes
Public bug reported:
When using the SQL backend, a search like:
ldapsearch ... '(cn=)'
causes slapd to crash with this error:
slapd: /tmp/openldap-2.4.15/servers/slapd/back-sql/search.c:1366:
backsql_process_filter_attr: Assertion `0' failed.
Looking at the code there, it does a
switch(f-f_choice) {
default:
assert(0);
}
As it happens, in that instance f_choice is something like 0x80a3, that
is SLAPD_FILTER_UNDEFINED|LDAP_FILTER_EQUALITY.
And the back-sql backend doesn't support that SLAPD_FILTER_UNDEFINED
flag like the other backends, hence the abort() on that assert.
A work around for that (change in indentation no shown):
--- search.c~ 2009-06-01 15:55:16.0 +0100
+++ servers/slapd/back-sql/search.c 2009-06-01 17:00:51.0 +0100
@@ -717,6 +717,9 @@
goto done;
}
+ if (f-f_choice SLAPD_FILTER_UNDEFINED) {
+ rc = -1;
+ } else {
switch( f-f_choice ) {
case LDAP_FILTER_OR:
rc = backsql_process_filter_list( bsi, f-f_or,
@@ -772,6 +775,7 @@
ad = f-f_av_desc;
break;
}
+ }
if ( rc == -1 ) {
goto done;
That's only a work around. The fix would be to implement the support for
such searches.
Best regards,
Stephane
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: slapd 2.4.15-1ubuntu3
ProcEnviron:
SHELL=/bin/zsh
PATH=(custom, user)
LANG=en_GB.UTF-8
SourcePackage: openldap
Uname: Linux 2.6.30-rc6-custom i686
** Affects: openldap (Ubuntu)
Importance: Undecided
Status: New
** Tags: apport-bug i386
--
crash with SQL backend on search with empty attributes
https://bugs.launchpad.net/bugs/382677
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 382677] Re: crash with SQL backend on search with empty attributes
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/27403420/Dependencies.txt -- crash with SQL backend on search with empty attributes https://bugs.launchpad.net/bugs/382677 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 364581] Re: Crash when logging in
Or http://groups.google.com/group/ubuntu-users-archive/browse_thread/thread/9e03284b53639844/f00fa4582ef139da I didn't have time to raise a bug using launchpad at the time, but I can do it now if that's a different issue from this one. Colin, do you mean that you applied the patch there and it fixed your problem? Here is the patch attached. Could anybody please do something about it? At the moment, I have to reapply the patch after every update. ** Attachment added: fix for a bug that might be related. http://launchpadlibrarian.net/26316509/mod-auth-mysql.diff -- Crash when logging in https://bugs.launchpad.net/bugs/364581 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 368044] [NEW] slapd crash when using SQL backend
Public bug reported:
I've not narrowed down the minimum scenario that causes it. But the bug
is quite obvious from reading the code. There's a free() that should
definitely not be called as it is made on an address that is not the
result of an allocation.
Please find diff attached (it may not be *the* best/correct solution as
I've not deeply analysed why the code was written that way but it seems
to fix it for me).
hardy is also affected.
Below is valgrind and gdb information.
The crash occurs when a client connects and does a search. I suppose
just setting up openldap with a SQL backend would be enough.
Valgrind:
==backsql_search(): base=*, filter=(objectClass=*),
scope=2, deref=0, attrsonly=0, attributes to load: all
==backsql_get_db_conn()
==backsql_open_db_handle()
do_bind: v3 anonymous bind
==backsql_open_db_handle()
==backsql_get_db_conn()
==backsql_dn2id(MASKED) matched expected
==backsql_id2entry()
==32193==
==32193== Thread 4:
==32193== Invalid free() / delete / delete[]
==32193==at 0x4824B4A: free (vg_replace_malloc.c:323)
==32193==by 0x489AE28: ber_memfree_x (memory.c:152)
==32193==by 0x6058F: ch_free (ch_malloc.c:139)
==32193==by 0x53F86BF: backsql_id2entry (entry-id.c:945)
==32193==by 0x53ED183: backsql_init_search (search.c:315)
==32193==by 0x53F1B04: backsql_search (search.c:2034)
==32193==by 0x3F8C8: fe_op_search (search.c:366)
==32193==by 0x3F21B: do_search (search.c:217)
==32193==by 0x3B8F9: connection_operation (connection.c:1084)
==32193==by 0x3BE54: connection_read_thread (connection.c:1211)
==32193==by 0x485219A: ldap_int_thread_pool_wrapper (tpool.c:663)
==32193==by 0x49E750E: start_thread (in
/lib/tls/i686/cmov/libpthread-2.8.90.so)
==32193== Address 0x4e31c24 is 444 bytes inside a block of size 40,004 alloc'd
==32193==at 0x4823DE2: calloc (vg_replace_malloc.c:397)
==32193==by 0x489B034: ber_memcalloc_x (memory.c:277)
==32193==by 0x6039A: ch_calloc (ch_malloc.c:104)
==32193==by 0x4A15E: entry_prealloc (entry.c:548)
==32193==by 0x4A22D: entry_alloc (entry.c:575)
==32193==by 0x53EBCDD: read_baseObject (config.c:677)
==32193==by 0x53EAC96: backsql_db_config (config.c:448)
==32193==by 0x2F1BB: read_config_file (config.c:786)
==32193==by 0x23A21: read_config (bconfig.c:3463)
==32193==by 0x18DF7: main (main.c:754)
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6dddb90 (LWP 426)]
0xb7ee0430 in __kernel_vsyscall ()
(gdb) bt full
#0 0xb7ee0430 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb79f38a0 in raise () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2 0xb79f5268 in abort () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#3 0xb7a3116d in ?? () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#4 0xb7a37454 in ?? () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#5 0xb7a394b6 in free () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#6 0xb7e54e29 in ber_memfree_x (p=0xb830b13c, ctx=0x0) at
/home/stephane/install/DEB/openldap-2.4.11/libraries/liblber/memory.c:152
__PRETTY_FUNCTION__ = ber_memfree_x
#7 0xb7f43590 in ch_free (ptr=0xb830b13c) at
/home/stephane/install/DEB/openldap-2.4.11/servers/slapd/ch_malloc.c:139
ctx = (void *) 0x0
#8 0xb76ef6c0 in backsql_id2entry (bsi=0xb6ddbdb8, eid=0xb6ddbdcc) at
/home/stephane/install/DEB/openldap-2.4.11/servers/slapd/back-sql/entry-id.c:945
e = (Entry *) 0xb830b13c
op = (Operation *) 0xb836ac40
bi = (backsql_info *) 0xb82f5358
i = 1203274741
rc = -1209131020
__PRETTY_FUNCTION__ = backsql_id2entry
#9 0xb76e4184 in backsql_init_search (bsi=0xb6ddbdb8, nbase=0xb836ac5c,
scope=2, stoptime=1240841287, filter=0xb68dc12c, dbh=0xb8385b90, op=0xb836ac40,
rs=0xb6ddd12c, attrs=0x0, flags=11)
at
/home/stephane/install/DEB/openldap-2.4.11/servers/slapd/back-sql/search.c:315
matched = 1
getentry = 1
gotit = 1
bi = (backsql_info *) 0xb82f5358
rc = 0
__PRETTY_FUNCTION__ = backsql_init_search
#10 0xb76e8b05 in backsql_search (op=0xb836ac40, rs=0xb6ddd12c) at
/home/stephane/install/DEB/openldap-2.4.11/servers/slapd/back-sql/search.c:2034
bi = (backsql_info *) 0xb82f5358
dbh = (SQLHDBC) 0xb8385b90
sres = 0
user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname =
{bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0,
bv_val = 0x0}, e_private = 0x0}
base_entry = {e_id = 0, e_name = {bv_len = 17, bv_val = 0xb8359908
MASKED}, e_nname = {bv_len = 17, bv_val = 0xb8359340
MASKED}, e_attrs = 0xb83169cc,
e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0}
manageDSAit = 0
stoptime = 1240841287
bsi = {bsi_op = 0xb836ac40, bsi_rs = 0xb6ddd12c, bsi_flags = 1,
[Bug 368044] Re: slapd crash when using SQL backend
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/26034841/Dependencies.txt -- slapd crash when using SQL backend https://bugs.launchpad.net/bugs/368044 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 368044] Re: slapd crash when using SQL backend
I'm not seeing the patch, so I attach it again. Sorry if that causes a duplicate. ** Attachment added: possible fix http://launchpadlibrarian.net/26034890/slapd.diff -- slapd crash when using SQL backend https://bugs.launchpad.net/bugs/368044 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
