After reading the comments for bug 1810583 closer, it is also a symptom of this
bug, and keepalived >= 2.0.x would fix it (restore the VIPs).
Thanks,
- cameron
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
Bug 1815101 is a symptom of this bug.
I do not think bug 1810583 is related, I do not think a backport of
keepalived >= 2.0.x would fix bug 1810583.
Thanks,
- cameron
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.laun
Public bug reported:
Systemd-networkd clobbers VIPs placed by other daemons on any
reconfiguration triggering systemd-networkd restart (netplan apply for
example). Keepalived < version 2.0.x will not restore a VIP lost in
this fashion, breaking high availability on Ubuntu 18.04 LTS. A
backport f
Newer keepalived (> 2.0.x) addresses the systemd-networkd behavior.
>From keepalived 2.0.0 release notes: "Transition to backup state if a
VIP or eVIP is removed When we next transition to master the addresses
will be restored. If nopreempt is not set, that will be almost
immediately."
Any chance
Re #120 (adam-stokes)
The best workable solution for me would be working official packages for
Lucid and Pangolin. Working LDAP authn/z over TLS is baseline
functionality for us (servers and academic computer labs).
I've had no problems with the patch from #73 thus far on our Lucid
servers. Mos
Just a follow up to #106. We have been running with the libgcrypt11
patch from #73 with a couple thousand openldap and AD users using
Apache2/phpsuexec on Lucid 10.04.2 64 bit for months now with no
troubles.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I just tried Howard's patch from #73 this morning, using the
libgcrypt11_1.4.4-5ubuntu2_amd64.deb source files to roll a new
libgcrypt11 package. I can now su to root from accounts not in the
local password file database, before I could not. That was on a Lucid
10.04.2 LTS vm. Next week sometim
After taking a look at the debian ltsp-bindmounts script, worked around
our issue with the following in /usr/share/ltsp/ltsp-bindmounts:
#!/bin/sh
. /usr/share/ltsp/ltsp-init-common
. /etc/default/ltsp-client-setup
bind_mounts
Nothing else seems to be reading /etc/default/ltsp-client-setup file
Checked /usr/share/initramfs-tools/scripts/nfs-bottom/ltsp.
The only reference it makes to bind mounts is:
ltsp_bindmounts=/usr/share/ltsp/ltsp-bindmounts
There is no /usr/share/ltsp/ltsp-bindmounts in the ltsp-client-core package.
The bind_mounts () function exists instead
in /usr/share/ltsp
Public bug reported:
Binary package hint: ltsp-client-core
This appears to fix it in our Lucid, fat client, nfsroot, LTSP
environment:
--- ltsp-client-setup-dist-lucid 2010-08-17 16:24:20.0 -0600
+++ ltsp-client-setup 2010-08-17 14:17:35.0 -0600
@@ -38,6 +38,7 @@
e
@Tom Ellis,
Thanks! The 'noplymouth' option worked great with all plymouth upstart
scripts back in place. Definitely a more civilized approach. Boot
options of:
ro nosplash noplymouth INIT_VERBOSE=yes init=/sbin/init -v
give "nice" output on a VM server text console.
--
Graphical Ubuntu logo
Here is how we got a text only console for Lucid server, and upgrade
from Karmic on a VM:
Enable the text console:
http://staff.adams.edu/~cdmiller/posts/Ubuntu-Lucid-server-text-console/
Disable Plymouth:
http://staff.adams.edu/~cdmiller/posts/Ubuntu-Lucid-server-disable-plymouth/
Verbose
To disable Plymouth on Lucid server we removed the
/etc/init/plymouth*.conf scripts: http://staff.adams.edu/~cdmiller/posts
/Ubuntu-Lucid-server-disable-plymouth/
Hope that is a helpful kludge for some.
--
Please remove the plymouth dependency from mountall / cryptsetup
https
For Lucid Server edition we "disabled" Plymouth by removing the
/etc/init/plymouth*.conf scripts. That and some other changes resulted
in a nicer console for servers: http://staff.adams.edu/~cdmiller/posts
/Ubuntu-Lucid-server-disable-plymouth/ In the post is our list of
package
Finally got a chance to revisit this after post #29 above. For that
servers config I still had a local /etc/passwd entry for the affected
account and so was not triggering the described su and sudo symptoms.
On Karmic with:
libnss-ldap 261-2.1ubuntu4
sudo 1.7.0-1ubuntu2.1
login 1:4.1.4.1-1ubuntu
We use LDAP over TLS via PAM for auth, and use NSSWITCH as well. After
upgrade from Hardy -> Jaunty -> Karmic, su no longer functioned, however
sudo did work.
Here is what I found. When upgrading to Karmic, keeping our old
/etc/pam.d/common-auth failed for su. Putting in the default common-
aut
Public bug reported:
Binary package hint: libvirt0
On hardy with libvirt 0.4.0 and on Hardy using Intrepid libvirt 0.4.2 change
cdrom does not work for kvm/qemu guests.
Qemu version 0.9.1 changed device naming to allow for multiple cd's. A single
cd will appear as ide1-cd0 rather than cdrom.
F
** Attachment added: "sub ides-cd0 for cdrom in qemu_driver.c for libvirt"
http://launchpadlibrarian.net/15354080/qemu_driver.c-diff
--
"Fix" for cdrom change in libvirt virsh virt-manager
https://bugs.launchpad.net/bugs/240442
You received this bug notification because you are a member of Ub
I can confirm this.
This is on current Hardy and on Intrepid with libvirt 0.4.2.
Qemu 0.9.1 is where the change in cdrom device name happened.
Fedora 9 still uses Qemu 0.9.0 and are thus unaffected so far.
Short term cludge attached.
Longer term fix should check qemu info block from the monitor
I see similar behaviour constant disconnecting / reconnecting to an old
wap11 unencrypted, with Feisty on a lenovo thinkpad x60 and: 03:00.0
Network controller: Intel Corporation PRO/Wireless 3945ABG Network
Connection (rev 02).
Sometimes after several reconnects I get an oops.
--
IPW3945 using
20 matches
Mail list logo
