This is arguably a kvm bug, in that kvm should check /usr/share/kvm
instead of or as well as /usr/share/qemu , so I've added kvm to the
affects list.
I can confirm this issue in Lucid as of five minutes ago:
$ apt-cache policy kvm kvm-pxe
kvm:
Installed: 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubunt
This issue is closely related to issue 356256.
--
update-manager doesn't prevent restart of slapd on system using ldap auth,
resulting in hung update
https://bugs.launchpad.net/bugs/572105
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to l
... which is
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/356256, since LP
didn't feel like auto-linking it.
--
update-manager doesn't prevent restart of slapd on system using ldap auth,
resulting in hung update
https://bugs.launchpad.net/bugs/572105
You received this bug notification
Public bug reported:
I use an Ubuntu 10.04 (lucid) server for, among other things, LDAP
authentication.
slapd:
Installed: 2.4.21-0ubuntu5
Candidate: 2.4.21-0ubuntu5
Version table:
*** 2.4.21-0ubuntu5 0
500 http://ftp.iinet.net.au/pub/ubuntu/ lucid/main Packages
500 http://a
The attachment contains /proc/$pid/{environ,maps,pagemap,smaps,status}
from a failed slapd instance.
I couldn't read /proc/$pid/mem; it reported "no such process".
** Attachment added: "Select files from /proc of failed slapd instance"
http://launchpadlibrarian.net/49050824/slapd_procfiles.zip
Did you consider giving me more than a few hours to respond? Or collect
more debug info?
Did either of you even bother looking at the attached details? Did you
notice the "several weeks" part, where it's not particularly easy to
reproduce this issue on demand?
This bug should not be closed.
--
Sorry, that was unnecessarily grumpy. It's been a long day of fighting
bugs in innumerable different things, etc.
--
slapd becomes non-responsive after several weeks runtime
https://bugs.launchpad.net/bugs/585208
You received this bug notification because you are a member of Ubuntu
Server Team, w
Public bug reported:
Distributor ID: Ubuntu
Description:Ubuntu 9.10
Release:9.10
Codename: karmic
# libvirtd --version
libvirtd (libvirt) 0.7.0
ii libvirt0
0.7.0-1ubuntu13.1
if listen_tls = 1 is set in libvirtd.conf, but the certs required aren't
present in /etc/pki, libvir
Also, Ubuntu's libvirt packages should probably provide a skeleton
/etc/pki which has symlinks to the default certs generated by snakeoil .
--
no useful errors if tls certs missing or unreadable
https://bugs.launchpad.net/bugs/546723
You received this bug notification because you are a member of
Public bug reported:
Description:Ubuntu 9.10
Release:9.10
Codename: karmic
libvirtd (libvirt) 0.7.0
/etc/libvirt/libvirtd.conf contains the comment:
# - sasl: use SASL infrastructure. The actual auth scheme is then
# controlled from /etc/sasl2/libvirt.conf. For the T
That patch applies to openssl as shipped in Hardy, but doesn't appear to
have any effect. After patching openssl, rebuilding the packages and
installing them, `openssl engine padlock' reports:
(padlock) VIA PadLock (no-RNG, ACE)
on my C3 thin clients. That should get me at least accelerated aes-1
Confirmed: openssl is using x86 crypto even with "-engine padlock", both
in latest upstream and in the current hardy packages.
If I interrupt a debug build of openssl while running "openssl speed
aes-128-cbc -engnie padlock" on a C3 gdb generally reports that it's
been interrupted in:
_x86_AES_en
** These bugs are fixed upstream in OpenSSH 4.9 and OpenSSL 0.9.8h **
You can apply the fix to OpenSSH 4.7 from Ubuntu just fine:
https://bugzilla.mindrot.org/attachment.cgi?id=1458 . It applies cleanly
except for two rejects at points where the changes have already been
applied, so the rejects ca
Quick instructions on rebuilding openssh and openssl to include the fix,
for those not used to patching Debian packages:
mkdir wrk
cd wrk
sudo apt-get install build-essential fakeroot wget
sudo apt-get build-dep openssl openssh
apt-get source openssl openssh
cd openssl-0.9.8g
wget --quiet -O - ht
** Description changed:
VIA PadLock is a hardware cryptography engine for AES and SHA1/256.
- OpenSSH should support PadLock. Initial work on PadLock support has already
been done:
+ OpenSSH should support PadLock. Upstream OpenSSH versions do support
+ padlock, and a working patch exists in
Upstream bug:
http://rt.openssl.org/Ticket/Display.html?id=1668&user=guest&pass=guest
Though the bug hasn't been closed, the patch has been applied to 0.9.8h
as is trivially verifiable by examination of the source.
** Also affects: openssh (Ubuntu)
Importance: Undecided
Status: New
--
16 matches
Mail list logo
