[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] 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 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 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, b
[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 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
** 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 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] 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 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
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
[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
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
[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
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
[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] 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 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 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.1069
[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 "sync"s 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= -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
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: [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 "sync"s 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
[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 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
