** Package changed: ubuntu = dhcp3 (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dhcp3 in Ubuntu.
https://bugs.launchpad.net/bugs/1403955
Title:
DHCP's Option interface-mtu 9000 is being ignored on bridge
interface br0
** Description changed:
- Using MAAS as DHCP server, the client receives the following IPv4 lease:
+ In an env with jumbo frames enabled, and using MAAS as DHCP server, the
+ client receives the following IPv4 lease:
- $ cat /var/lib/dhcp/dhclient.br0.leases
+ $ cat
Public bug reported:
Using MAAS as DHCP server, the client receives the following IPv4 lease:
$ cat /var/lib/dhcp/dhclient.br0.leases
lease {
interface br0;
fixed-address 10.230.20.26;
filename pxelinux.0;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 43200;
option
** Package changed: ubuntu = dhcp3 (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1403955
Title:
DHCP's Option interface-mtu 9000 is being ignored on bridge
interface br0
To manage
** Description changed:
- Using MAAS as DHCP server, the client receives the following IPv4 lease:
+ In an env with jumbo frames enabled, and using MAAS as DHCP server, the
+ client receives the following IPv4 lease:
- $ cat /var/lib/dhcp/dhclient.br0.leases
+ $ cat
Hi Robie,
Let me answer your questions:
Why is br0 being set up to bridge eth0? Is something doing this automatically
or is this configuration necessary for something (if so, what?)?
This configuration (br0 on a single physical interface) is automatically
generated by deploying openstack
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1585698
Title:
sssd FTBFS on Trusty following samba update
To manage notifications about this bug go to:
** Tags added: sts
** Also 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/1566508
Title:
autofs races with sssd on startup
To
As mentioned in the description, Autofs starts before SSSD's responders
are running, even though SSSD is set to start before Autofs, both in
upstart and systemd. The problem is related to the boot process of SSSD
because upstart/systemd determine the job as started right after sssd
forks, when in
** Attachment added: "sssd.conf workaround for upstart"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+attachment/4688591/+files/sssd.conf
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
>5. The issue being subject of this bug report is very likely still present,
>though I was unable to
>reproduce it exactly. Unfixed issue #2 caused auto fs to fail with a different
>error message
>("setautomntent: lookup(sss): setautomntent: No such file or directory"),
>while fixed issue #2
Bug opened upstream: https://fedorahosted.org/sssd/ticket/3080
** Bug watch added: fedorahosted.org/sssd/ #3080
https://fedorahosted.org/sssd/ticket/3080
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Yes. Systemd takes longer to set sssd as started, making the time window
smaller for the race condition to happen, but it can still appear when
the machine boots fast enough (VMs, for instance, show this issue
consistently)
--
You received this bug notification because you are a member of Ubuntu
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1604128
Title:
[2.0RC2] Unable to add a public SSH Key due to lp1604147
To manage notifications about this bug go to:
** Patch added: "yakkety_sssd_1.13.4-3ubuntu1.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+attachment/4811489/+files/yakkety_sssd_1.13.4-3ubuntu1.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "trusty_sssd_1.11.8-0ubuntu0.4.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+attachment/4811490/+files/trusty_sssd_1.11.8-0ubuntu0.4.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "xenial_sssd_1.13.4-1ubuntu1.2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+attachment/4811491/+files/xenial_sssd_1.13.4-1ubuntu1.2.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Description changed:
+ [Impact]
+
+ * SSSD is set as started before its responders are active.
+ * Depending services (e.g. autofs) start before those responders are
working, and a manual restart is required to make them work after boot
+ * This happens with upstart and, with less
** Changed in: autofs (Ubuntu)
Status: Confirmed => Invalid
** Changed in: sssd (Ubuntu)
Status: Confirmed => In Progress
** Changed in: sssd (Ubuntu)
Assignee: (unassigned) => Victor Tapia (vtapia)
--
You received this bug notification because you are a member
** Patch added: "trusty-sssd_1.11.8-0ubuntu0.4.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1641875/+attachment/4824602/+files/trusty-sssd_1.11.8-0ubuntu0.4.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "librt link fix"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1641875/+attachment/4826011/+files/trusty-sssd_1.11.8-0ubuntu0.5.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "yakkety-sssd_1.13.4-3ubuntu1.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1641875/+attachment/4824488/+files/yakkety-sssd_1.13.4-3ubuntu1.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "xenial-sssd_1.13.4-1ubuntu1.2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1641875/+attachment/4824489/+files/xenial-sssd_1.13.4-1ubuntu1.2.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1641875
Title:
Scheduled events (e.g. LDAP connection retries) are affected by clock
adjustments
To manage notifications about this bug go to:
** Description changed:
+ [Impact]
- When SSSD fails to connect to a provider (LDAP, for instance) it creates a
timed event with tevent_add_timer() in order to retry in ~1 min. Tevent relies
on CLOCK_REALTIME, using absolute epoch time, so when the time changes (e.g.
NTP sync) the scheduled
** Patch added: "zesty_sssd_1.15.0-3ubuntu3.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1641875/+attachment/4819666/+files/zesty_sssd_1.15.0-3ubuntu3.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: sssd (Ubuntu Trusty)
Importance: Undecided => Medium
** Changed in: sssd (Ubuntu Yakkety)
Importance: Undecided => Medium
** Changed in: sssd (Ubuntu Zesty)
Importance: Undecided => Medium
** Changed in: sssd (Ubuntu Xenial)
Importance: Undecided => Medium
** Tags
The patch was merged[1], so I'll start working in the SRU as soon as I
can.
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=d4063e9a21a4e203bee7e0a0144fa8cabb14cc46
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch removed: "trusty-sssd_1.11.8-0ubuntu0.5.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1641875/+attachment/4826011/+files/trusty-sssd_1.11.8-0ubuntu0.5.debdiff
** Patch added: "trusty-sssd_1.11.8-0ubuntu0.5.debdiff"
A patch has been submitted upstream for review. As soon as it lands,
I'll work on an SRU.
Regards,
Victor
--
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
Hi Maciej,
I'm attaching the suggested patch to this bug, but bear in mind it's
adapted to upstream's code.
Originally, SSSD creates the pidfile at an early stage (once it forks)
before the providers have started. This patch moves the pidfile creation
to a point where the providers are up and
Public bug reported:
When SSSD fails to connect to a provider (LDAP, for instance) it creates a
timed event with tevent_add_timer() in order to retry in ~1 min. Tevent relies
on CLOCK_REALTIME, using absolute epoch time, so when the time changes (e.g.
NTP sync) the scheduled event is
** Changed in: sssd (Ubuntu Trusty)
Assignee: (unassigned) => Victor Tapia (vtapia)
** Changed in: sssd (Ubuntu Xenial)
Assignee: (unassigned) => Victor Tapia (vtapia)
** Changed in: sssd (Ubuntu Yakkety)
Assignee: (unassigned) => Victor Tapia (vtapia)
** Changed in: sss
Hi Maciej,
After a verification run, I can confirm that it still fails for . I'll
update my fixes and upload them again.
** Tags removed: verification-needed
** Tags added: verification-failed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
# VERIFICATION FOR XENIAL
I prepared a reproducer based on the description details (LDAP + NFS)
using an entry_cache_timeout of 88000 in sssd.conf to ensure the cache
was valid during the validation run. From a remote machine, I ran this
script:
#!/bin/bash
OK=0
KO=0
while true ; do
#date
nova
# VERIFICATION FOR XENIAL
Following the instructions in the description, 'user1' is present in the
db:
root@vtapia-xenial:/var/log/sssd# sudo sss_cache -E; getent passwd 'user1'
root@vtapia-xenial:/var/log/sssd# sudo ldbsearch -H
/var/lib/sss/db/cache_openstacklocal.ldb -b
#VERIFICATION
Upgraded to proposed from 1.9.4+bzr4592-0ubuntu1~14.04.1, that was
affected by LP#1657491 (several IPs assigned to the same iface in DB).
Originally, the db contained free leases:
id | hostname | id | name |mac_address| id | ip |
alloc_type
# VERIFICATION FOR YAKKETY
Using the same script for Yakkety, I can confirm that the fix works as
expected. This is the log after 1300 succesful reboots:
Warning: Permanently added 'vtapia-yakkety,10.5.1.90' (ECDSA) to the list of
known hosts.
Mar 31 08:40:31 vtapia-yakkety systemd[1]: Started
# VERIFICATION FOR YAKKETY
Using the same verification used for Xenial:
root@vtapia-yakkety:/home/ubuntu# sss_cache -E; getent passwd 'user1'
user1:*:1:5000:user1:/home/user1:/bin/bash
root@vtapia-yakkety:/home/ubuntu# sudo ldbsearch -H
/var/lib/sss/db/cache_openstacklocal.ldb -b
** Changed in: percona-xtradb-cluster-5.6 (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1657256
Title:
Percona crashes when doing a a 'larger' update
To
** Tags removed: verification-done-xenial verification-done-yakkety
verification-needed
** Tags added: verification-failed
--
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
** Tags removed: verification-done-xenial verification-done-yakkety
verification-needed
** Tags added: verification-failed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1669712
Title:
Newline
** Tags removed: verification-failed
** Tags added: verification-failed-xenial verification-failed-yakkety
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1669712
Title:
Newline characters (\n) must
** Tags removed: verification-failed
** Tags added: verification-failed-xenial verification-failed-yakkety
--
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
** Changed in: sssd (Ubuntu Trusty)
Assignee: (unassigned) => Victor Tapia (vtapia)
** Changed in: sssd (Ubuntu Xenial)
Assignee: (unassigned) => Victor Tapia (vtapia)
** Changed in: sssd (Ubuntu Yakkety)
Assignee: (unassigned) => Victor Tapia (vtapia)
** Changed in: sss
** Patch added: "zesty-sssd_1.15.0-3ubuntu5.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1669712/+attachment/4835276/+files/zesty-sssd_1.15.0-3ubuntu5.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Description changed:
+ [Impact]
+
+ * When a username with a trailing newline or carriage return character
+ is used for authentication, the malformed LDAP query will return that
+ the username does not exist and then the username will be erased from
+ the LDB cache.
+
+ [Test Case]
+
+
** Patch added: "trusty-sssd_1.11.8-0ubuntu0.7.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1669712/+attachment/4835277/+files/trusty-sssd_1.11.8-0ubuntu0.7.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "yakkety-sssd_1.13.4-3ubuntu0.3.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1669712/+attachment/4835275/+files/yakkety-sssd_1.13.4-3ubuntu0.3.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
# VERIFICATION FOR T
Same script as for X, works as expected:
(Mon Mar 6 04:31:25 2017) [sssd[be[openstacklocal]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'LDAP'
(Mon Mar 6 04:31:25 2017) [sssd[be[openstacklocal]]] [get_server_status]
(0x1000): Status of server 'ldap'
** Patch removed: "yakkety_sssd_1.13.4-3ubuntu1.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+attachment/4811489/+files/yakkety_sssd_1.13.4-3ubuntu1.debdiff
** Patch removed: "trusty_sssd_1.11.8-0ubuntu0.4.debdiff"
** Patch added: "yakkety-sssd_1.13.4-3ubuntu0.2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+attachment/4832800/+files/yakkety-sssd_1.13.4-3ubuntu0.2.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "trusty-sssd_1.11.8-0ubuntu0.6.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/+attachment/4832799/+files/trusty-sssd_1.11.8-0ubuntu0.6.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
ete_user.
Adding '\n' to the character list in sss_filter_sanitize_ex() seems to fix this
issue.
Upstream bug: https://pagure.io/SSSD/sssd/issue/3317
** Affects: sssd (Ubuntu)
Importance: Medium
Assignee: Victor Tapia (vtapia)
Status: New
** Tags: sts
--
You received this bug noti
# VERIFICATION FOR X
After running the following script (repro.sh), the log shows the LDAP
resolution is rescheduled:
#!/bin/bash
change_time() {
sudo systemctl stop systemd-timesyncd
HOUR=$(date +%H)
MIN=$(date +%M)
NEW=$((10#$HOUR - 1))
sudo date --set
#VERIFICATION FOR XENIAL+Upstart (LP#1695870)
- Version of the package: 1.13.4-1ubuntu1.6
ubuntu@xenial-upstart:~$ dpkg -l | grep sssd
ii sssd 1.13.4-1ubuntu1.6
amd64System Security Services Daemon -- metapackage
ii sssd-ad
** Tags removed: verification-done
** Tags added: verification-done-trusty
--
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
** Tags added: verification-done-xenial
--
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:
** Description changed:
[Impact]
* Windows VMs BSOD when restoring from QEMUfile or during live migration if
the virtio balloon stats polling is enabled.
- * Affected version: 1:2.5+dfsg-5ubuntu10.14 (xenial)
+ * Affected version: 1:2.5+dfsg-5ubuntu10.14 (xenial)
[Test Case]
Thanks Thomas!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1706058
Title:
Windows VM crashes when restoring from file if balloon stats polling
is enabled
To manage notifications about this bug
To confirm the issue described in the original fix, I traced the virtio
balloon subsystem (using QEMU simpletracing) while the VM:
1.) Loaded from a QEMUFile
virtio_set_status 0.000 pid=6248 vdev=0x55dcc49cf968 val=0x0
balloon_event 31433104.748 pid=6248 opaque=0x55dcc49cf968 addr=0x1
** Patch added: "xenial-sssd_1.13.4-1ubuntu1.6.debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1695870/+attachment/4904642/+files/xenial-sssd_1.13.4-1ubuntu1.6.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
#VERIFICATION FOR XENIAL (1.13.4-3ubuntu0.4)
Using the script in comment #46, I've had the machine rebooting for
several days without hitting the issue. This is an excerpt of the logs:
Warning: Permanently added 'vtapia-xenial,10.5.1.88' (ECDSA) to the list of
known hosts.
May 3 16:00:39
#VERIFICATION FOR YAKKETY (1.13.4-3ubuntu0.4)
Script from #46, excerpt of the logs:
May 3 16:04:37 vtapia-yakkety sssd: Starting up
May 3 16:04:37 vtapia-yakkety sssd[be[openstacklocal]]: Starting up
May 3 16:04:38 vtapia-yakkety sssd[pam]: Starting up
May 3 16:04:38 vtapia-yakkety
Sorry, I meant 1.13.4-1ubuntu1.5 for Xenial:
ubuntu@vtapia-xenial:~$ dpkg -l | grep sssd-common
ii sssd-common 1.13.4-1ubuntu1.5
amd64System Security Services Daemon -- common files
--
You received this bug notification because you are a
Hi Jof, Christian:
Sure, I'll prepare an SRU to address this scenario right now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1700084
Title:
sssd wont start if autofs is not installed
To manage
LP #1695870 will address this regression
--
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:
** Changed in: sssd (Ubuntu)
Assignee: (unassigned) => Victor Tapia (vtapia)
** Tags added: sts
--
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 st
** Description changed:
+ [Impact]
+
+ * On Trusty, SSSD does not start when AutoFS is not installed because the
AutoFS "starting" signal is not emitted.
+ * This only affects the upstart service (Trusty). Systemd services work fine.
+
+ [Test Case]
+
+ * Install SSSD in a machine without
** Description changed:
[Impact]
- * On Trusty, SSSD does not start when AutoFS is not installed because the
AutoFS "starting" signal is not emitted.
- * This only affects the upstart service (Trusty). Systemd services work fine.
+ * On Trusty, SSSD does not start when AutoFS is not
# VERIFICATION FOR TRUSTY (LP#1566508)
- Version of the package: 1.11.8-0ubuntu0.7
$ ssh vtapia-trusty "dpkg -l | grep -i sssd"
Warning: Permanently added 'vtapia-trusty,10.5.1.100' (ECDSA) to the list of
known hosts.
ii libsss-idmap0 1.11.8-0ubuntu0.7
** Tags removed: verification-needed
** Tags added: verification-done
--
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
#VERIFICATION FOR YAKKETY (1.13.4-3ubuntu0.4)
Same script as in #14. This is the output:
ubuntu@vtapia-yakkety:~$ sudo ./san.sh
- SSSD version
ii sssd-common1.13.4-3ubuntu0.4
amd64System Security Services Daemon -- common
#VERIFICATION FOR XENIAL (1.13.4-1ubuntu1.5)
Using the following script to test "faulty" users (with trailing /r /n):
ubuntu@vtapia-xenial:~$ cat san.sh
#!/bin/bash
echo '- SSSD version'
dpkg -l | grep sssd-common
echo '- Query "user1"'
sss_cache -E; getent passwd 'user1'
ldbsearch -H
#VERIFICATION FOR TRUSTY (1.11.8-0ubuntu0.6)
Script from #46, excerpt of the logs:
Warning: Permanently added 'vtapia-trusty,10.5.1.100' (ECDSA) to the list of
known hosts.
May 25 15:46:01 vtapia-trusty sssd: Starting up
May 25 15:46:01 vtapia-trusty sssd[be[openstacklocal]]: Starting up
May 25
# VERIFICATION FOR TRUSTY (1.11.8-0ubuntu0.6)
Same script as in #14. This is the output:
- SSSD version
ii sssd-common 1.11.8-0ubuntu0.6amd64
System Security Services Daemon -- common files
- Query "user1"
#VERIFICATION FOR LP#1695870
- Version of the package: 1.11.8-0ubuntu0.7
ubuntu@sssd-trusty:~$ dpkg -l | grep -i sssd
ii libsss-idmap0 1.11.8-0ubuntu0.7
amd64ID mapping library for SSSD
ii sssd 1.11.8-0ubuntu0.7
The cloud image for Xenial is still affected by this bug. Deploying with
nova:
$ nova boot --flavor m1.small --image
ubuntu-xenial-daily-amd64-server-20170830.1-disk1.img xenial-iscsi1
$ nova boot --flavor m1.small --image
ubuntu-xenial-daily-amd64-server-20170830.1-disk1.img xenial-iscsi2
$
** Branch linked: lp:~vtapia/livecd-rootfs/xenial-proposed-lp1444992
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1444992
Title:
fastpath install duplicates iSCSI initiator names, blocking iSCSI
Hi Christian,
Sorry for the lack of updates, I've been trying to reproduce this
behavior using Linux guests and it seems that those VMs work perfectly.
I'm currently checking the virtio balloon driver for Windows, as it
might be the real culprit of the VM crash.
I'll update the case with my
Public bug reported:
[Description]
Corosync sigaborts if it starts before the interface it has to bind to
is ready.
On boot, if no interface in the bindnetaddr range is up/configured,
corosync binds to lo (127.0.0.1). Once an applicable interface is up,
corosync crashes with the following error
** Description changed:
[Description]
Corosync sigaborts if it starts before the interface it has to bind to
is ready.
On boot, if no interface in the bindnetaddr range is up/configured,
corosync binds to lo (127.0.0.1). Once an applicable interface is up,
corosync crashes with
** Description changed:
[Description]
Corosync sigaborts if it starts before the interface it has to bind to
is ready.
On boot, if no interface in the bindnetaddr range is up/configured,
corosync binds to lo (127.0.0.1). Once an applicable interface is up,
corosync crashes with
I just noticed that the member{} group should be inside interface{},
triggering the bug described by this commit:
https://github.com/corosync/corosync/commit/aab55a004bb12ebe78db341dc56759dfe710c1b2
** Description changed:
[Description]
Corosync sigaborts if it starts before the
** Patch added: "Xenial patch"
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1739033/+attachment/5025216/+files/fix-lp1739033-xenial.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "Trusty patch"
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1739033/+attachment/5025215/+files/fix-lp1739033-trusty.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Patch added: "Xenial debdiff"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1771805/+attachment/5141162/+files/lp1771805-xenial-sssd_1.13.4-1ubuntu1.11.debdiff
** Tags added: sts-sru-needed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Tapia (vtapia)
Status: New
** Tags: sts
** Changed in: sssd (Ubuntu)
Assignee: (unassigned) => Victor Tapia (vtapia)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1771805
Title:
** Description changed:
[Impact]
When SSSD tries to renew the machine password, a write_to_child_fd is
open but never closed, leaking a descriptor per request until it hits
the limit and SSSD stops.
[Test Case]
1. With an AD deployed, and having the machine registered,
=== VERIFICATION ===
- Using the packages in xenial-proposed:
ubuntu@sssd-xenial:~$ dpkg -l | grep sssd
ii sssd 1.13.4-1ubuntu1.11
amd64System Security Services Daemon -- metapackage
ii sssd-ad
** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1771805
Title:
AD keytab
I was wrong regarding iii) "when corosync is stopped, do not stop
pacemaker": Pacemaker can use other applications[1] (e.g. heartbeat)
instead of corosync, so this is a property we want to keep.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Forgot the link to Pacemaker's FAQ
[1] https://wiki.clusterlabs.org/wiki/FAQ
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1740892
Title:
corosync upgrade on 2018-01-02 caused pacemaker to fail
In my opinion, from the list of desired properties, only the second one is true:
i) Corosync can be used on its own, regardless of having pacemaker installed or
not. Starting both of them would force to mask pacemaker's unit file under
particular scenarios.
iii) IIRC, pacemaker requires
On Trusty + corosync=2.3.3-1ubuntu1:
- Stopping corosync while pacemaker is still running:
Jan 9 09:26:55 trusty-corosync corosync[5492]: [MAIN ] Node was shut down
by a signal
Jan 9 09:26:55 trusty-corosync corosync[5492]: [SERV ] Unloading all
Corosync service engines.
Jan 9
As mentioned by Mario @ #10, stopping corosync while pacemaker runs
throws the same error as the upgrade. Syslog from Xenial +
corosync=2.3.5-3ubuntu1:
Jan 8 16:24:37 xenial-corosync systemd[1]: Stopping Pacemaker High
Availability Cluster Manager...
Jan 8 16:24:37 xenial-corosync
1. Xenial+:
- Overriding dh_installinit[1] would still fail the first time it's
upgraded because of the old corosync.prerm file [2], that contains:
# Automatically added by dh_installinit
if [ -x "/etc/init.d/corosync" ] || [ -e "/etc/init/corosync.conf" ]; then
invoke-rc.d corosync stop
** Tags removed: verification-needed verification-needed-trusty
** Tags added: verification-done verification-done-trusty
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1732703
Title:
MAAS does not
** Changed in: linux (Ubuntu Zesty)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1724614
Title:
[KVM] Lower the default for halt_poll_ns to 20 ns
To manage
#VERIFICATION FOR XENIAL
- Packages
ii corosync 2.3.5-3ubuntu2
amd64cluster engine daemon and utilities
ii libcorosync-common4:amd642.3.5-3ubuntu2
amd64cluster engine common library
-
1 - 100 of 232 matches
Mail list logo
