Thanks for everyone's work on this - much appreciated.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1366174
Title:
apache2 SEGV with multiple SSL sites
To manage notifications
http://people.canonical.com/~ubuntu-archive/pending-sru.html indicates
there is allegedly a regression in svn. Last build is here:
https://jenkins.qa.ubuntu.com/job/trusty-adt-
subversion/lastBuild/ARCH=amd64,label=adt/ and indeed the build log
shows a failure here:
Thanks. Verified that this works with the original test cases, and
marked verification-done.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
Thanks Robie.
If it helps, we have been running this patch on many tens of machines of
machines since early Nov 2014 (so approximately 4 months) without any
ill effects, with and without SSL (though we don't use stapling).
--
You received this bug notification because you are a member of Ubuntu
Any update on this one?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1366174
Title:
apache2 SEGV with multiple SSL sites
To manage notifications about this bug go to:
Robie: can I ping you once more re the backport to trusty?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1366174
Title:
apache2 SEGV with multiple SSL sites
To manage notifications
Robie: I've verified that the Vivid version works fine. Can I ping you
re getting the SRU done for Trusty?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1366174
Title:
apache2 SEGV
Made this public as the links to which it refers are public.
** Information type changed from Private Security to Public Security
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1400775
Robie: this is me poking you after a couple of weeks, as requested.
--
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/1366174
Title:
apache2 SEGV with multiple SSL sites
To manage
Robie: no apology needed, and yes I would be happy to check Vivid.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1366174
Title:
apache2 SEGV with multiple SSL sites
To manage
I have added [Impact] and [Regression potential] sections.
Do the SRU requirements mean we need a patch for U too? I'm not sure
what current development release means right now given that U is out.
I believe the upstream 2.4.10 patch should apply straight to U. It's
upstream, so V will
I have attached a backport to 2.4.7 to this comment. This is a backport
of the backport to 2.4.x in upstream svn. More details in the commit
message.
This is a straight patch to the source (produced from git) rather than a
proper packaged up patch, if you see what I mean.
I've put this up on
This has now been merged into 2.4. See
https://issues.apache.org/bugzilla/show_bug.cgi?id=54357
Any chance this can now be backported to Trusty? The impact is pretty
severe.
** Bug watch added: Apache Software Foundation Bugzilla #54357
http://issues.apache.org/bugzilla/show_bug.cgi?id=54357
The fix for this is now committed in trunk. A 2.4 backport is
available. See:
https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?r1=1631030r2=1631029
Patch (per the above) at:
https://people.apache.org/~kbrand/mod_ssl-2.4.x-PR54357.diff
--
You received this bug notification
Yes, we did talk on IRC :-)
As far as I can tell, utopic 2.4.10-1ubuntu1 does not build modident
(still). I suspect what might have been fixed in the debian bug my
report got merged into (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=711925) is the constant removal of any module
called
Yep, though I think that was what https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=752922 asked for.
--
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/188
Title:
mod_ident no
Robie: removing the reference to certinfo_free where
X509_get_ex_new_index is called within ssl_stapling_ex_init works around
the 2.4.10 bug at the expense of a memory leak. I haven't (yet) verified
this entirely fixes 2.4.7 though I suspect it will. I'll test that in a
bit.
Obviously this
I can confirm that the above workaround fixes 2.4.7, both my testcase
and our real world version. I attach a patch. This is probably 'better
than nothing'.
** Patch added: Patch to avoid calling certinfo_free (ugly workaround)
Robie: that attitude is quite understandable. I'm willing to do some work
bisecting it, but I fear the root problem is going to be that addressed this
commit:
http://svn.apache.org/viewvc?view=revisionrevision=1573360
The ssl_pphrase_Handle routine is misleadingly named, and in fact is pretty
Turns out 2.4.10 also has the bug after all (it's just more difficult to
trigger). I think I have found the root cause. I've put details
upstream.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to apache2 in Ubuntu.
I think I've got about the minimal case for replication. Attached is a
tiny perl script which generates a number of SSL sites of the form:
VirtualHost 127.0.0.1:$port
ServerName 127.0.0.1:$port
SSLEngine on
SSLCertificateFile/etc/ssl/certs/ssl-cert-snakeoil.pem
Actually DBDriver pgsql causes the issue, but not DBDriver mysql,
and it can be outside the virtual host block. So I think this might be a
pgsql driver issue.
Reported upstream at:
https://issues.apache.org/bugzilla/show_bug.cgi?id=56919
** Bug watch added: Apache Software Foundation Bugzilla
The number of sites required appears to vary. Also it appears to be
necessary to have mod php5 enabled.
--
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/1366174
Title:
apache2 SEGV
Public bug reported:
Apache2 crashes with multiple SSL sites.
When starting apache2 with multiple SSL sites I get a SEGV like this:
(gdb) bt
#0 0x705faaf3 in ?? () from /usr/lib/apache2/modules/mod_ssl.so
#1 0x729647a6 in int_free_ex_data (class_index=optimized out,
Public bug reported:
libxen-4.4 has no corresponding debug package with debugging symbols in.
** Affects: xen (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
This gets worse.
You can't even use your own mod_ident, because whenever apache2 is
upgraded, it runs this:
OBSOLETE_CONFFILES=...
/etc/apache2/mods-available/ident.load
...
...
if [ -n $2 ] || obsolete_conffile_exists ; then
prepare_rm_conffile
This is pretty annoying. In a situation where you have many customer VMs
running on 12.04, and want to migrate them to a host running 14.04 (so
you can do a rolling OS upgrade), I'm afraid shut down all your
customer VMs and restart isn't really an option for obvious reasons.
Equally, installing
Looks like there is a patch here:
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
but it's either take it (and break inbound migrates from quantal etc.)
or don't (and break inbound migrates from precise). Another possibility
(unhelpful for libvirt
Public bug reported:
kmod should permit use of compressed modules. This enables images that
boot from RAM to be much smaller. In essence this requires only changing
a build option. Uncompressed modules are still supported.
A patch is here:
gah this got filed under apache2 even though I said affects kmod. -
apologies all
** Package changed: apache2 (Ubuntu) = kmod (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to apache2 in Ubuntu.
Reported to Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752922
** Bug watch added: Debian Bug tracker #752922
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752922
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
Arguably the real fix to this is to configure apache with --reallyall
(compile everything), then perhaps put the more esoteric modules in a
secondary package (libapache2-mod-extra or something).
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Public bug reported:
Precise included mod_ident in apache2.2. Trusty does not include
mod_ident in apache2.4. There appears to be no other package containing
mod_ident.so. Therefore an upgrade between Precise (LTS) and Trusty
(LTS) will unfixably break anything using mod_ident.
This affects me
The attached patch appear to result in it building, and being able to be
inserted as a module.
root@trustytest:/home/ubuntu/apache2/apache2-2.4.7# for i in ../*.deb ; do echo
$i ; dpkg -c $i | fgrep ident ; done
../apache2_2.4.7-1ubuntu4_amd64.deb
-rw-r--r-- root/root62 2014-06-23 20:00
If you prefer this as a separate module, this would appear to compile and load
as a module:
https://github.com/abligh/libapache-mod-ident
Direction on which you would prefer would be useful and I will get
testing.
--
You received this bug notification because you are a member of Ubuntu
That's a shame, but thanks for the info.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to open-vm-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1275656
Title:
open-vm-dkms 2011.12.20-562307-0ubuntu1: open-vm-tools kernel module
Hi,
I tried to test this and couldn't get it to work, though I may have done
something stupid.
I run precise, and upgraded to the lts-trusty kernel. I then removed
open-vm-tools ( friends), and inserted the custom built precise
package.
That all worked fine, but I still can't mount vmhgfs as I
Further playing about suggests I need (somehow) vmware-hgfsclient, but
the package seems devoid of any documentation or manual pages.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to open-vm-tools in Ubuntu.
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
IPv6 Privacy Extensions enabled on
Neil: the metadata is just one example (though that's not happening).
The firewall rule thing applies irrespective of the metadata. The cloud
environment created requires only /128 addresses it knows about to be
accessible, and firewalls everything else out. Reasons for this include
prevention of
This affects 14.04 too
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1068756
Title:
IPv6 Privacy Extensions enabled on Ubuntu Server by default
To manage notifications about
That doesn't work if (for instance) you have 2 machines on the same SDN
virtual LAN, which is a /64, and you want to prevent source spoofing
between them. For avoidance of doubt, we do use /64s.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Just as a note, the new kernels are not only needed on LTS for hardware
enablement (and I'm guessing relatively few people need hardware
enablement in a VMware guest), but also to run Docker, which I suspect
affects more people (me included).
--
You received this bug notification because you are
** Description changed:
Affects: 1:9.7.0.dfsg.P1-1ubuntu0.8, 1:9.8.1.dfsg.P1-4ubuntu0.4, 1:9.8.4
.dfsg-1ubuntu1.
bind9.postinst only sets permissions on
/var/cache/bind on a fresh install. When the bind9 package is removed
but not purged, /var/cache/bind is removed, but /etc/bind is
Note that upgrades from Lucid to Precise can trigger this bug as the
directory permissions may preclude writing to /var/cache/bind - see bug
1086775
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to bind9 in Ubuntu.
Public bug reported:
Summary: bind9 uses very high CPU after an upgrade from Lucid to
Precise. I have traced this to a directory permissions problem as
/var/cache/bind is not writeable by the bind group after an upgrade, but
is writeable after a clean install.
Ubuntu release:
** Description changed:
Summary: bind9 uses very high CPU after an upgrade from Lucid to
Precise. I have traced this to a directory permissions problem as
/var/cache/bind is not writeable by the bind group after an upgrade, but
is writeable after a clean install.
Ubuntu release:
The server concerns was automatically installed from a CD-ROM built from
Ubuntu sources and (in respect of bind) it has only had automatic
updates run on it. I am very confident it was not operator error.
It was upgraded with 'do-release-upgrade'.
I can tell you I am not the only person
Well I'm pretty sure the problem is this. I've just gone to another
(unconnected) Lucid box, and:
root@extility-developers:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 10.04.4 LTS
Release:10.04
Codename: lucid
OK so my working hypothesis is this. On Lucid /var/cache/bind is created
simply by virtue of it being a directory within the package (see the
bind9.list file). The group write permission is added by the postinst.
If the Lucid package was installed, then removed, then installed again,
the following
To follow this up, the .deb at least on Lucid does NOT have the write
permission set.
amb@nimrod-ubuntu:~/bind-test$ dpkg -c bind9_9.7.0.dfsg.P1-1ubuntu0.8_amd64.deb
| fgrep cache
drwxr-xr-x root/root 0 2012-10-09 14:13 ./var/cache/
drwxr-xr-x root/root 0 2012-10-09 14:13
Robie,
No problem - I'm just glad I wasn't imagining it.
I agree the 100% CPU problem can't be reproduced on precise.
To be honest I don't quite understand why /var/cache/bind isn't in
/var/run (given it's a cache) but I may be wrong about that.
Alex
--
You received this bug notification
Public bug reported:
cloud-init should run resize2fs in the background. In a development
environment I am looking at, the resize takes 2 minutes. Scott Moser
pointed out that as it runs on a mounted file system, there is no reason
not to complete the boot process whilst it runs.
** Affects:
** Patch added: untested patch to fix loop over devices
https://bugs.launchpad.net/bugs/961240/+attachment/2910439/+files/cc_grub_dpkg.py.patch
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
Public bug reported:
On paravirtualised Xen, cloud-init will not rerun grub. KVM may also
have issues.
The problem is at:
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/CloudConfig/cc_grub_dpkg.py
line 47.
The 'if' condition at line 36 handles the case where
The particular development platform I was trying this has an I/O speed
about the same as a floppy disk drive, so this is perhaps not as
important as one might think. However, it might still be useful as a
feature to speed up boot time.
--
You received this bug notification because you are a
We have Maverick running in Xen quite extensively. We use debootstrap
images with normal grub (not pvgrub), i.e. we are passing a full HD
image to Xen (and I know we aren't the only ones to do this). We do
however modify /etc/fstab etc., and aren't using -virtual (I think we
use -server) precisely
No, these are different bugs I think, though they relate to the same
sort of issue.
Bug 726635 says that even on conventional (non-UEC) images, MAC
addresses ranges used by Virtualbox should be ignored in the persistent
udev rules. That's fair enough, though I note Xen and KVM were treated
From the manpage of udev: Rule files are required to have a unique
name, duplicate file names are ignored. Files in /etc/udev/rules.d/ have
precedence over files with the same name in /lib/udev/rules.d/. This can
be used to ignore a default rules file if needed..
Untested, but perhaps on UEC
Further example of why this is needed: see my comment on Bug 726635.
VirtualBox appears to use a borrowed MAC range, rather than an
officiant assignment. That means it's probably not a great idea to use
that MAC address range as a basis for black/whitelisting.
--
You received this bug
Public bug reported:
Binary package hint: cloud-init
Persistent interface naming should be disabled in UEC images, as it
causes more harm that good.
Firstly, cloud systems generally expect the interfaces to be created in
the order they are created in the hypervisor. Renaming them
(particularly
I have tested this on Xen 3.3.1 in HVM mode and now correctly get
/dev/xvda etc.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
https://bugs.launchpad.net/bugs/684875
Title:
Patch to Natty 2.6.37-virtual
Further notes:
1. non-ubuntu specific: to get HVM devices to work on Xen pre
3.4.something, you need to use emulunplug=unnecessary or perhaps
emulunplug=unnecessary,all on the command line. Otherwise Xen's non-
support of PCI unplug means that failure to unplug the emulated devices
stops the HVM
xen-devel thread is here:
http://www.gossamer-threads.com/lists/xen/devel/192003
I've been asked to point out there are really two problems:
1. If the emulated devices (i.e. the real sda) is not unplugged, there
is a device name clash. The emulated devices cannot be unplugged on xen
3.3
My understanding is that the patch currently applies to all kernel variants, so
has the potential to cause problems for:
* Anyone running Xen versions pre 3.4
* Anyone running any version of Xen hoping for stable device naming between
Ubuntu kernels and any others (e.g. mainline, Debian , the
Public bug reported:
Binary package hint: cloud-init
cloud-init should fetch data specific to the image (and the platform)
prior to fetching user-data, and treat it the same way.
It should be an objective of ubuntu cloud images that they will run on
multiple cloud platforms without
EC2 specifies 'root=sda1' on the kernel command line.
EC2 should fix that then, as it's plain wrong.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
https://bugs.launchpad.net/bugs/684875
Title:
Patch to
Though a compromise solution would be to register as sda only if the
unplug of the original sda device succeeded / is going to be tried.
Otherwise it's just going to cause a kernel bug.
I think xen_unplug_emulated_devices() is called sufficiently early you
could choose the name when the driver is
This bug appears in Jaunty if a new kernel is loaded - strace below. Is
it really working as designed if loading a new kernel causes dhcp to
fail?
508 execve(/sbin/dhclient-script, [/sbin/dhclient-script], [/* 4 vars */])
= 0
2508 brk(0)= 0x215c000
2508 fcntl(0,
69 matches
Mail list logo
