[Touch-packages] [Bug 2034656] Re: ESM archive getting DoSed with legitimate traffic every day at 06:25 (cron.daily time)

2023-09-25 Thread Junien Fridrick
@juliank : can we not spread the load over 24h without systemd timers ?
With a random sleep for example ? Surely people were spreading tasks
over a specific period before systemd got invented.

Also you say "they shouldn't then see more load than the archive mirror"
but archive mirrors and ESM mirrors are vastly different, in terms of
traffic, in terms of hardware, but also because ESM mirrors are HTTPS-
only with an authentication backend whereas the archive mirrors are
HTTP-only without authentication.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2034656

Title:
  ESM archive getting DoSed with legitimate traffic every day at 06:25
  (cron.daily time)

Status in cloud-images:
  New
Status in apt package in Ubuntu:
  New
Status in ubuntu-advantage-tools package in Ubuntu:
  Invalid

Bug description:
  Hi,

  We're seeing frequent alerts on the Ubuntu ESM archive servers due to
  surges in requests. On two systems, I'm seeing this:

  | Sep  6 05:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 05:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 10:49:35 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 10:49:35 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 17:17:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 17:17:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 23:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 23:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  7 01:55:02 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 01:55:02 machine-2 systemd[1]: Finished Update the local ESM caches.

  On another:

  | Sep  6 02:41:02 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 02:41:03 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 09:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 09:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 15:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 15:32:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 22:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 22:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  7 04:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 04:32:42 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.

  This is all from `/usr/lib/systemd/system/esm-cache.service` which
  calls `/usr/lib/ubuntu-advantage/esm_cache.py`.

  Can we please have this run less frequent? Perhaps only once daily
  which aligns with APT and apt-daily-upgrade.service / unattended-
  upgrades?

  Perhaps check existence of a file and run if not, then age of that
  same file and only run if it's older than a day?

  I think, from what I can see, this may be triggered from
  /lib/systemd/system/ua-timer.timer and /etc/apt/apt.conf.d/20apt-esm-
  hook.conf?

  See also LP:1554848 which was for APT.

  On Trusty and Xenial clients we only seem to update daily, but the
  problem is worse as it's a cron.daily job, so all clients fire
  simultaneously - could we get this changed to a cron.d job with a
  randomised firing time instead?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2034656/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 2034656] Re: ESM archive getting DoSed with legitimate traffic every day at 06:25 (cron.daily time)

2023-09-25 Thread Junien Fridrick
@esj : Hi ! Thanks for chiming in. I think doing APT activities once a
day is fine indeed.

However, I think even if we had ESM archives in cloud mirrors, having a
large amount of clients do their updates all at the same time would lead
to said cloud mirrors being overwhelmed, unless we throw an absurd
amount of resources at the problem - resources that wouldn't be used
during the rest of the day.

I think we do need both : spread updates throughout the day (this bug),
and have ESM archives in cloud mirrors.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2034656

Title:
  ESM archive getting DoSed with legitimate traffic every day at 06:25
  (cron.daily time)

Status in cloud-images:
  New
Status in apt package in Ubuntu:
  New
Status in ubuntu-advantage-tools package in Ubuntu:
  Invalid

Bug description:
  Hi,

  We're seeing frequent alerts on the Ubuntu ESM archive servers due to
  surges in requests. On two systems, I'm seeing this:

  | Sep  6 05:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 05:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 10:49:35 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 10:49:35 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 17:17:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 17:17:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 23:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 23:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  7 01:55:02 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 01:55:02 machine-2 systemd[1]: Finished Update the local ESM caches.

  On another:

  | Sep  6 02:41:02 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 02:41:03 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 09:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 09:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 15:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 15:32:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 22:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 22:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  7 04:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 04:32:42 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.

  This is all from `/usr/lib/systemd/system/esm-cache.service` which
  calls `/usr/lib/ubuntu-advantage/esm_cache.py`.

  Can we please have this run less frequent? Perhaps only once daily
  which aligns with APT and apt-daily-upgrade.service / unattended-
  upgrades?

  Perhaps check existence of a file and run if not, then age of that
  same file and only run if it's older than a day?

  I think, from what I can see, this may be triggered from
  /lib/systemd/system/ua-timer.timer and /etc/apt/apt.conf.d/20apt-esm-
  hook.conf?

  See also LP:1554848 which was for APT.

  On Trusty and Xenial clients we only seem to update daily, but the
  problem is worse as it's a cron.daily job, so all clients fire
  simultaneously - could we get this changed to a cron.d job with a
  randomised firing time instead?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2034656/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 2034656] Re: ESM archive getting DoSed with legitimate traffic every day at 06:25 (cron.daily time)

2023-09-25 Thread Junien Fridrick
** Summary changed:

- Update Ubuntu ESM cache only once daily?
+ ESM archive getting DoSed with legitimate traffic every day at 06:25 
(cron.daily time)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2034656

Title:
  ESM archive getting DoSed with legitimate traffic every day at 06:25
  (cron.daily time)

Status in cloud-images:
  New
Status in apt package in Ubuntu:
  New
Status in ubuntu-advantage-tools package in Ubuntu:
  Invalid

Bug description:
  Hi,

  We're seeing frequent alerts on the Ubuntu ESM archive servers due to
  surges in requests. On two systems, I'm seeing this:

  | Sep  6 05:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 05:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 10:49:35 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 10:49:35 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 17:17:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 17:17:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 23:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 23:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  7 01:55:02 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 01:55:02 machine-2 systemd[1]: Finished Update the local ESM caches.

  On another:

  | Sep  6 02:41:02 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 02:41:03 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 09:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 09:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 15:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 15:32:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 22:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 22:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  7 04:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 04:32:42 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.

  This is all from `/usr/lib/systemd/system/esm-cache.service` which
  calls `/usr/lib/ubuntu-advantage/esm_cache.py`.

  Can we please have this run less frequent? Perhaps only once daily
  which aligns with APT and apt-daily-upgrade.service / unattended-
  upgrades?

  Perhaps check existence of a file and run if not, then age of that
  same file and only run if it's older than a day?

  I think, from what I can see, this may be triggered from
  /lib/systemd/system/ua-timer.timer and /etc/apt/apt.conf.d/20apt-esm-
  hook.conf?

  See also LP:1554848 which was for APT.

  On Trusty and Xenial clients we only seem to update daily, but the
  problem is worse as it's a cron.daily job, so all clients fire
  simultaneously - could we get this changed to a cron.d job with a
  randomised firing time instead?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2034656/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 2034656] Re: Update Ubuntu ESM cache only once daily?

2023-09-25 Thread Junien Fridrick
@juliank : would you know how a trusty machine does its daily apt
activities (including ESM) ? Are the downloads spread out during the
day, or is everything done in cron.daily ?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2034656

Title:
  Update Ubuntu ESM cache only once daily?

Status in cloud-images:
  New
Status in apt package in Ubuntu:
  New
Status in ubuntu-advantage-tools package in Ubuntu:
  Invalid

Bug description:
  Hi,

  We're seeing frequent alerts on the Ubuntu ESM archive servers due to
  surges in requests. On two systems, I'm seeing this:

  | Sep  6 05:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 05:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 10:49:35 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 10:49:35 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 17:17:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 17:17:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 23:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 23:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  7 01:55:02 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 01:55:02 machine-2 systemd[1]: Finished Update the local ESM caches.

  On another:

  | Sep  6 02:41:02 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 02:41:03 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 09:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 09:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 15:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 15:32:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 22:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 22:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  7 04:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 04:32:42 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.

  This is all from `/usr/lib/systemd/system/esm-cache.service` which
  calls `/usr/lib/ubuntu-advantage/esm_cache.py`.

  Can we please have this run less frequent? Perhaps only once daily
  which aligns with APT and apt-daily-upgrade.service / unattended-
  upgrades?

  Perhaps check existence of a file and run if not, then age of that
  same file and only run if it's older than a day?

  I think, from what I can see, this may be triggered from
  /lib/systemd/system/ua-timer.timer and /etc/apt/apt.conf.d/20apt-esm-
  hook.conf?

  See also LP:1554848 which was for APT.

  On Trusty and Xenial clients we only seem to update daily, but the
  problem is worse as it's a cron.daily job, so all clients fire
  simultaneously - could we get this changed to a cron.d job with a
  randomised firing time instead?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2034656/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 2034656] Re: Update Ubuntu ESM cache only once daily?

2023-09-25 Thread Junien Fridrick
Also @orndorffgrant "Do we have control over any of the offending
machines?" sadly no...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2034656

Title:
  Update Ubuntu ESM cache only once daily?

Status in cloud-images:
  New
Status in apt package in Ubuntu:
  New
Status in ubuntu-advantage-tools package in Ubuntu:
  Invalid

Bug description:
  Hi,

  We're seeing frequent alerts on the Ubuntu ESM archive servers due to
  surges in requests. On two systems, I'm seeing this:

  | Sep  6 05:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 05:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 10:49:35 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 10:49:35 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 17:17:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 17:17:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 23:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 23:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  7 01:55:02 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 01:55:02 machine-2 systemd[1]: Finished Update the local ESM caches.

  On another:

  | Sep  6 02:41:02 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 02:41:03 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 09:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 09:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 15:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 15:32:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 22:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 22:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  7 04:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 04:32:42 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.

  This is all from `/usr/lib/systemd/system/esm-cache.service` which
  calls `/usr/lib/ubuntu-advantage/esm_cache.py`.

  Can we please have this run less frequent? Perhaps only once daily
  which aligns with APT and apt-daily-upgrade.service / unattended-
  upgrades?

  Perhaps check existence of a file and run if not, then age of that
  same file and only run if it's older than a day?

  I think, from what I can see, this may be triggered from
  /lib/systemd/system/ua-timer.timer and /etc/apt/apt.conf.d/20apt-esm-
  hook.conf?

  See also LP:1554848 which was for APT.

  On Trusty and Xenial clients we only seem to update daily, but the
  problem is worse as it's a cron.daily job, so all clients fire
  simultaneously - could we get this changed to a cron.d job with a
  randomised firing time instead?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2034656/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 2034656] Re: Update Ubuntu ESM cache only once daily?

2023-09-25 Thread Junien Fridrick
Thanks both for your updates, I'll try to see if someone at Azure can
help.

** Changed in: ubuntu-advantage-tools (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2034656

Title:
  Update Ubuntu ESM cache only once daily?

Status in cloud-images:
  New
Status in apt package in Ubuntu:
  New
Status in ubuntu-advantage-tools package in Ubuntu:
  Invalid

Bug description:
  Hi,

  We're seeing frequent alerts on the Ubuntu ESM archive servers due to
  surges in requests. On two systems, I'm seeing this:

  | Sep  6 05:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 05:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 10:49:35 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 10:49:35 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 17:17:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 17:17:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  6 23:47:16 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 23:47:17 machine-2 systemd[1]: Finished Update the local ESM caches.
  | Sep  7 01:55:02 machine-2 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 01:55:02 machine-2 systemd[1]: Finished Update the local ESM caches.

  On another:

  | Sep  6 02:41:02 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 02:41:03 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 09:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 09:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 15:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 15:32:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  6 22:02:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  6 22:02:41 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.
  | Sep  7 04:32:40 is-bastion-ps5 systemd[1]: Starting Update the local ESM 
caches...
  | Sep  7 04:32:42 is-bastion-ps5 systemd[1]: Finished Update the local ESM 
caches.

  This is all from `/usr/lib/systemd/system/esm-cache.service` which
  calls `/usr/lib/ubuntu-advantage/esm_cache.py`.

  Can we please have this run less frequent? Perhaps only once daily
  which aligns with APT and apt-daily-upgrade.service / unattended-
  upgrades?

  Perhaps check existence of a file and run if not, then age of that
  same file and only run if it's older than a day?

  I think, from what I can see, this may be triggered from
  /lib/systemd/system/ua-timer.timer and /etc/apt/apt.conf.d/20apt-esm-
  hook.conf?

  See also LP:1554848 which was for APT.

  On Trusty and Xenial clients we only seem to update daily, but the
  problem is worse as it's a cron.daily job, so all clients fire
  simultaneously - could we get this changed to a cron.d job with a
  randomised firing time instead?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2034656/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 2003250] Re: networkctl reload with bond devices causes slaves to go DOWN and UP, causing couple of seconds of network loss

2023-07-28 Thread Junien Fridrick
I agree that the importance should be higher than "Low".

This bug is also triggered every time a "netplan apply" is run, since
netplan will always re-generate the systemd-networkd config files.

VLAN interfaces are also torn down and recreated.

This is highly problematic on critical networking hosts, such as
firewalls, since any networking configuration change will trigger
seconds of downtime, which can lead to VRRP failovers, etc...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2003250

Title:
  networkctl reload with bond devices causes slaves to go DOWN and UP,
  causing couple of seconds of network loss

Status in systemd package in Ubuntu:
  Triaged
Status in systemd source package in Jammy:
  Triaged
Status in systemd source package in Kinetic:
  Triaged

Bug description:
  We currently use Ubuntu 22.04.1 LTS including updates for our production 
cloud (switched from legacy Centos 7).
  Although we like the distribution we recently hit serious systemd buggy 
behavior described in [1] bugreport using packages [2].

  Unfortunatelly the clouds we are running consist of openstack on top
  of kubernetes and we need to have complex network configuration
  including linux bond devices.

  Our observation is that every time we apply our configuration via
  CI/CD infrastructure using ansible and netplan (regardless whether
  there is actual network configuration change) we see approximatelly
  8-16 seconds network interruptions and see bond interfaces going DOWN
  and then UP.

  We expect bond interfaces stay UP when there is no network
  configuration change.

  We went though couple of options how to solve the issue and the first
  one is to add such existing patch [3] into current
  systemd-249.11-0ubuntu3.6.

  Could you comment whether this kind of non-security patch is likely to land 
in 22.04.1 LTS soon.
  We are able to help to bring patch into systemd package community way if you 
suggest the steps.

  
  [1] https://github.com/systemd/systemd/issues/25067
  [2] Packages
  root@controlplane-001:/etc/apt0# apt list | grep -E '^(systemd/|netplan.io)'
  netplan.io/jammy-updates,now 0.105-0ubuntu2~22.04.1 amd64 
[installed,automatic]
  systemd/jammy-updates,now 249.11-0ubuntu3.6 amd64 [installed,automatic]
  [3] https://github.com/systemd/systemd/pull/25162
  [4] # lsb_release -rd
  Description:Ubuntu 22.04.1 LTS
  Release:22.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2003250/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 645404] Re: Support Private PPAs

2022-10-03 Thread Junien Fridrick
see also bug 1991553

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/645404

Title:
  Support Private PPAs

Status in software-properties package in Ubuntu:
  Confirmed
Status in software-properties source package in Bionic:
  Won't Fix
Status in software-properties source package in Cosmic:
  Won't Fix
Status in software-properties source package in Disco:
  Won't Fix
Status in software-properties source package in Eoan:
  Won't Fix
Status in software-properties source package in Focal:
  Won't Fix

Bug description:
  Software properties add-apt-repository currently does not support
  adding private PPAs.

  software-properties should connect to the API and observe that it gets
  permission denied trying to read the ppa. Then it can reconnect to the
  API asking for authentication, which will open a browser window where
  you can do the openid ritual. Then using that token it ought to be
  possible for it to get the password etc.

  
  ProblemType: BugDistroRelease: Ubuntu 12.04
  Package: python-software-properties 0.82.4

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/645404/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1991553] [NEW] can't add a private PPA

2022-10-03 Thread Junien Fridrick
Public bug reported:

As per today's discussion in ~is :

add-apt-repository has a bug when adding a private PPA. Quoting
~cjwatson :

===
It asks Launchpad for all your personal archive subscriptions _that have 
tokens_.  But `Person:+archivesubscriptions` also shows subscriptions without 
tokens - the token is generated when you click on Viewt here for the first time.

Instead, `add-apt-repository` should call `getArchiveSubscriptionURL` (not 
`getArchiveSubscriptionURLs`) for the archive it's interested in.  That 
generates tokens on-demand.  Either it will get an HTTP 401, or it will get a 
URL which it can parse for the username and password.
===

Thanks !

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1991553

Title:
  can't add a private PPA

Status in software-properties package in Ubuntu:
  New

Bug description:
  As per today's discussion in ~is :

  add-apt-repository has a bug when adding a private PPA. Quoting
  ~cjwatson :

  ===
  It asks Launchpad for all your personal archive subscriptions _that have 
tokens_.  But `Person:+archivesubscriptions` also shows subscriptions without 
tokens - the token is generated when you click on Viewt here for the first time.

  Instead, `add-apt-repository` should call `getArchiveSubscriptionURL` (not 
`getArchiveSubscriptionURLs`) for the archive it's interested in.  That 
generates tokens on-demand.  Either it will get an HTTP 401, or it will get a 
URL which it can parse for the username and password.
  ===

  Thanks !

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1991553/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1952264] Re: ntpd interface listing is bugged

2021-11-25 Thread Junien Fridrick
** Summary changed:

- ntp sync checks fail when server as no IPv6 connectivity
+ ntpd interface listing is bugged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1952264

Title:
  ntpd interface listing is bugged

Status in NTP Charm:
  Invalid
Status in ntp package in Ubuntu:
  New

Bug description:
  This charm sets up ntpmon and nagios checks to alert when ntp was not
  able to select a sync peer.

  On a server without a routable ipv6 configured, ntpq -p fails with:
  $ ntpq -p
  localhost: timed out, nothing received
  ***Request timed out

  $ /opt/ntpmon-ntp-charm/check_ntpmon.py --check sync
  CRITICAL: No sync peer selected | frequency= offset=nan peers=0 reach=nan 
result=2 rootdelay= rootdisp= runtime= stratum= sync=0.00 sysjitter= 
sysoffset= tracehosts= traceloops= tracetime=

  This results in a nagios alert complaining about the problem.
  Although:

  $ ntpq -p -4
   remote   refid  st t when poll reach   delay   offset  jitter
  ==
  *hostname1   xxx.xxx.xxx.x2 u  210  256  3770.8420.031   0.050
  +hostname2   xxx.xxx.xxx.x2 u   88  256  3770.3270.062   0.107
  -hostname3   xxx.xxx.xxx.x2 u  210  256  377   75.810   -1.198   1.035
  +hostname4   xxx.xxx.xxx.x2 u   68  256  3770.7510.078   0.193

  $ ntpq -p -4 | /opt/ntpmon-ntp-charm/check_ntpmon.py --check sync --test
  OK: Time is in sync with hostname1 | frequency= offset=0.57 peers=4 
reach=100.00 result=0 rootdelay= rootdisp= runtime= stratum= sync=1.00 
sysjitter= sysoffset= tracehosts= traceloops= tracetime=

  Maybe this is a bug to file against ntp itself ? Or some configuration
  could allow ntpq -p and check_ntpmon.py to succeed ? I've tested
  running ntpd with -4 (using defaults file) but with no luck.

  Let us know if you need more information.

  Thank you,
  Loïc

To manage notifications about this bug go to:
https://bugs.launchpad.net/ntp-charm/+bug/1952264/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1952264] Re: ntp sync checks fail when server as no IPv6 connectivity

2021-11-25 Thread Junien Fridrick
I investigated this quite a bit, and this appears to be an ntp bug and
not a charm bug.

This host is a trusty host, running ntp version
1:4.2.6.p5+dfsg-3ubuntu2.14.04.13. We have other hosts running the same
version that don't have the problem described above.

I spent quite some time investigating this, comparing the hosts, running
strace etc, and I noticed a subtle difference in /etc/hosts : on the
working host, the ::1 entry doesn't have "localhost", but it does on the
failing host. When I removed "localhost" from the ::1 entry on the
failing host, "ntpq -pn" started working.

Investigating things a bit more, I found out that on the working host,
ntpd was listening on ::1 but on the failing host, it wasn't (by
checking "ss -anupe" output as well as ntpd starting logs).

Comparing straces of starting ntpd, I think I was able to find what's
going on. On the working host it gives (only relevant output is posted
here) :

3973  19:41:32 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
[...]
3973  19:41:32 ioctl(5, SIOCGIFFLAGS, {ifr_name="qvobb268af4-e9", 
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_PROMISC|IFF_MULTICAST}) = 0
3973  19:41:32 ioctl(5, SIOCGIFFLAGS, {ifr_name="qbrd5588b49-e3", 
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
3973  19:41:32 ioctl(5, SIOCGIFFLAGS, {ifr_name="qvb1693c156-5f", 
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_PROMISC|IFF_MULTICAST}) = 0
[... the same for a bunch of interfaces - this is a nova compute node so this 
is expected ...]
3973  19:41:32 close(5) = 0


But on the failing host, it checks a single interface :
56717 19:37:03 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
[...]
56717 19:37:03 ioctl(5, SIOCGIFFLAGS, {ifr_name="qvbba244f00-69", 
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_PROMISC|IFF_MULTICAST}) = 0
56717 19:37:03 close(5) = 0

So I thought this interface was a bit special :
$ ip li sh dev qvbba244f00-69
67772: qvbba244f00-69@qvoba244f00-69:  
mtu 1500 qdisc noqueue master qbrba244f00-69 state UP mode DEFAULT group 
default qlen 1000
link/ether 0e:ac:86:b1:c8:24 brd ff:ff:ff:ff:ff:ff

It appears completely normal, except that it has an unusually high
ifindex (67772). Could that be the cause of the problem ? Looking at the
source code at
https://git.launchpad.net/ubuntu/+source/ntp/tree/?h=ubuntu/trusty-
updates : interfaces are parsed looking at the /proc/net/if_inet6 file
(https://git.launchpad.net/ubuntu/+source/ntp/tree/lib/isc/unix/ifiter_getifaddrs.c?h=ubuntu/trusty-
updates#n54) which strace confirms :

3973  19:41:32 open("/proc/net/if_inet6", O_RDONLY) = 6

Each line is parsed using fgets :

fgets(iter->entry, sizeof(iter->entry), iter->proc) != NULL)

https://git.launchpad.net/ubuntu/+source/ntp/tree/lib/isc/unix/interfaceiter.c?h=ubuntu/trusty-
updates#n181

What's sizeof(iter->entry) ? Well "entry" is defined like that :

charentry[ISC_IF_INET6_SZ];

https://git.launchpad.net/ubuntu/+source/ntp/tree/lib/isc/unix/ifiter_getifaddrs.c?h=ubuntu/trusty-
updates#n48

And ISC_IF_INET6_SZ is :
#define ISC_IF_INET6_SZ \
sizeof("0001 01 80 10 80 XXlo\n")

https://git.launchpad.net/ubuntu/+source/ntp/tree/lib/isc/unix/interfaceiter.c?h=ubuntu/trusty-
updates#n153

And this is where the problem is. The computation of ISC_IF_INET6_SZ
assumes that ifindex will be 2 chars (in hex), so that ifindex will be <
256. However, ifindexes higher than that are likely common, so why don't
we see this bug elsewhere ? Well because the computation of
ISC_IF_INET6_SZ also assumes that the interface name is 16 chars.

In our example, the interface name is "only" 14 chars, so we have a buffer of 2 
chars for the ifindex. But that's not enough, it's off by 1 in fact !
"0001 01 80 10 80 XXlo\n" is 62 chars 
long.
The first line of if_inet6 on our machine is :
fe800cac86fffeb1c824 108bc 40 20 80 qvbba244f00-69, and that's 62 
chars long... but without the \n !

So what might be happening here is that the first iteration of the loop
will properly read the whole line except the \n, and the next iteration
will resume at that location, and because fgets() stops at EOF or
newline, it will just return a newline, which will make the whole
iteration stop.

The fix here is pretty simple : the computation of ISC_IF_INET6_SZ
should assume an ifindex of UINT_MAX, ie  (or any 8-chars
number). If I can trust
https://git.launchpad.net/ubuntu/+source/ntp/tree/lib/isc/unix/interfaceiter.c?h=applied/ubuntu/jammy
this is still present in Jammy.

Redirecting the bug to the "ntp" package.

** Also affects: ntp (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: ntp-charm
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1952264

Title:
  ntp sync che

[Touch-packages] [Bug 1860926] Re: Ubuntu 20.04 Systemd fails to configure bridged network

2020-05-13 Thread Junien Fridrick
systemd-245.4-4ubuntu3.1 fixes the problem for me as well

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1860926

Title:
  Ubuntu 20.04  Systemd fails to configure bridged network

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Eoan:
  In Progress
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Groovy:
  Fix Committed

Bug description:
  [impact]

  A bridged interface with static ipv4 address and gateway configuration
  will fail to properly add the route via the gateway, leaving the
  system without a globally working network.

  [test case]

  On a Focal system, remove all network configuration and create this
  netplan:

  network:
    version: 2
    renderer: networkd
    ethernets:
  enp4s0:
    dhcp4: false
    bridges:
  br0:
    interfaces: [enp4s0]
    dhcp4: no
    addresses: [192.168.0.4/24]
    gateway4: 192.168.0.1
    nameservers:
  search: [mydomain]
  addresses: [192.168.0.1,192.168.0.2,192.168.0.3]

  Replace the interface name 'enp4s0' with the actual interface name on
  the test system.

  Reboot the system, and check the route to the gateway, which will be
  missing:

  root@lp1860926-f:~# ip r
  192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.4

  The route is expected to be present, e.g.:

  ubuntu@lp1860926-e:~$ ip r
  default via 192.168.0.1 dev br0 proto static
  192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.4

  [regression potential]

  Any regression would likely involve incorrectly configured network
  after an interface carrier gain/loss.

  [scope]

  This is needed for Focal, Eoan, and Bionic.

  While this only reproduces at boot for Focal, the general loss of
  configuration on carrier loss even when ConfigureWithoutCarrier=true
  is reproducable on all releases except Xenial, which does not have the
  ConfigureWithoutCarrier= parameter.

  [original description]

  Freshly installed Ubuntu 20.04 fully patched to days date with static
  IP address works fine and survives a reboot

  network:
    version: 2
    renderer: networkd
    ethernets:
  enp4s0:
    dhcp4: false
    addresses: [192.168.0.4/24]
    gateway4: 192.168.0.1
    nameservers:
  search: [mydomain]
  addresses: [192.168.0.1,192.168.0.2,192.168.0.3]

  however when converted to a bridged network for kvm

  network:
    version: 2
    renderer: networkd
    ethernets:
  enp4s0:
    dhcp4: false
    bridges:
  br0:
    interfaces: [enp4s0]
    dhcp4: no
    addresses: [192.168.0.4/24]
    gateway4: 192.168.0.1
    nameservers:
  search: [mydomain]
  addresses: [192.168.0.1,192.168.0.2,192.168.0.3]

  will not survive a reboot and required systemd-network to be restarted or
  @reboot /usr/sbin/netplan apply
  added to the crontab

  after a reboot the network can not b eaccseed and a
  systemctl status systemd-networkd produces

  systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; 
vendor preset: enabled)
   Active: active (running) since Sun 2020-01-26 16:36:28 UTC; 2min 27s ago
  TriggeredBy: ● systemd-networkd.socket
     Docs: man:systemd-networkd.service(8)
     Main PID: 979 (systemd-network)
   Status: "Processing requests..."
    Tasks: 1 (limit: 57662)
   Memory: 4.1M
   CGroup: /system.slice/systemd-networkd.service
   └─979 /lib/systemd/systemd-networkd

  Jan 26 16:38:02 firebolt systemd-networkd[979]: rtnl: received neighbor for 
link '5' we don't know about, ignoring.
  Jan 26 16:38:02 firebolt systemd-networkd[979]: virbr0-nic: rtnl: received 
neighbor message with invalid family, ignoring.
  Jan 26 16:38:02 firebolt systemd-networkd[979]: virbr0-nic: rtnl: received 
neighbor message with invalid family, ignoring.
  Jan 26 16:38:02 firebolt systemd-networkd[979]: virbr0: rtnl: received 
neighbor message with invalid family, ignoring.
  Jan 26 16:38:02 firebolt systemd-networkd[979]: virbr0-nic: Link UP
  Jan 26 16:38:02 firebolt systemd-networkd[979]: virbr0-nic: Gained carrier
  Jan 26 16:38:02 firebolt systemd-networkd[979]: virbr0: Link UP
  Jan 26 16:38:02 firebolt systemd-networkd[979]: virbr0-nic: Link DOWN
  Jan 26 16:38:02 firebolt systemd-networkd[979]: virbr0-nic: Lost carrier
  Jan 26 16:38:02 firebolt systemd-networkd[979]: virbr0-nic: Kernel removed an 
address we don't remember: fe80::5054:ff:fed9:7e26/64 (valid forever), ignoring.

  systemctl restart systemd-networkd resolved the issue and a

  systemctl status systemd-network producessystemd-networkd.service - Network 
Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enable

[Touch-packages] [Bug 1871540] Re: Include IPs in apt-get output

2020-04-09 Thread Junien Fridrick
@juliank : could we at least get a debug flag of some sort that would
just log everything ? With timings ? So that we could map, for each
file, the IP of the server it got downloaded from, time when the
download started (maybe even time when the HTTP request got sent, time
when we start receiving data), time at the end of transfer. And also,
very important, proxy information as well, if any.

And so whenever someones reports "slowness" or misbehaviour, we can give
him this flag and ask for output and debug on our end.

Would that be possible ?

Thanks !

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1871540

Title:
  Include IPs in apt-get output

Status in apt package in Ubuntu:
  New

Bug description:
  Hi,

  When running apt-get update/dist-upgrade, output looks like this:

  | Hit:6 http://archive.ubuntu.com/ubuntu focal-updates InRelease
  | Get:7 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages [972 kB]
  | Get:8 http://archive.ubuntu.com/ubuntu focal/main amd64 c-n-f Metadata 
[29.1 kB]
  | ...
  | Need to get 101 MB of archives.
  | After this operation, 10.5 MB of additional disk space will be used.
  | Do you want to continue? [Y/n] y
  | Get:1 http://archive.ubuntu.com/ubuntu focal/main amd64 dpkg amd64 
1.19.7ubuntu3 [1128 kB]
  | Get:2 http://archive.ubuntu.com/ubuntu focal/main amd64 login amd64 
1:4.8.1-1ubuntu4 [221 kB]
  | Get:3 http://archive.ubuntu.com/ubuntu focal/main amd64 libc6-dbg amd64 
2.31-0ubuntu7 [5673 kB]

  With various online CI/CD services such as GitHub Actions, it looks
  like this:

  | Get:14 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages [833 kB]
  | Get:16 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main 
Translation-en [292 kB]
  | Get:17 http://azure.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages [1044 kB]
  | ...
  | Get:31 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
cmake amd64 3.10.2-1ubuntu2.18.04.1 [3152 kB]
  | Get:32 http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu bionic/main 
amd64 gdb amd64 8.2-0ubuntu1~18.04 [3024 kB]
  | Get:33 http://azure.archive.ubuntu.com/ubuntu bionic/universe amd64 epstool 
amd64 3.08+repack-7 [108 kB]

  archive.u.c resolves to multiple IPs. azure.archive.u.c resolves to a
  load balancer (Azure's Traffic Manager). It would be nice if we also
  had the IPs of the servers/hosts in the output and would really help
  us in determining which servers or regions users may be experiencing
  issues with.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1871540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1871540] Re: Include IPs in apt-get output

2020-04-09 Thread Junien Fridrick
** Changed in: apt (Ubuntu)
   Status: Won't Fix => New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1871540

Title:
  Include IPs in apt-get output

Status in apt package in Ubuntu:
  New

Bug description:
  Hi,

  When running apt-get update/dist-upgrade, output looks like this:

  | Hit:6 http://archive.ubuntu.com/ubuntu focal-updates InRelease
  | Get:7 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages [972 kB]
  | Get:8 http://archive.ubuntu.com/ubuntu focal/main amd64 c-n-f Metadata 
[29.1 kB]
  | ...
  | Need to get 101 MB of archives.
  | After this operation, 10.5 MB of additional disk space will be used.
  | Do you want to continue? [Y/n] y
  | Get:1 http://archive.ubuntu.com/ubuntu focal/main amd64 dpkg amd64 
1.19.7ubuntu3 [1128 kB]
  | Get:2 http://archive.ubuntu.com/ubuntu focal/main amd64 login amd64 
1:4.8.1-1ubuntu4 [221 kB]
  | Get:3 http://archive.ubuntu.com/ubuntu focal/main amd64 libc6-dbg amd64 
2.31-0ubuntu7 [5673 kB]

  With various online CI/CD services such as GitHub Actions, it looks
  like this:

  | Get:14 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages [833 kB]
  | Get:16 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main 
Translation-en [292 kB]
  | Get:17 http://azure.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages [1044 kB]
  | ...
  | Get:31 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
cmake amd64 3.10.2-1ubuntu2.18.04.1 [3152 kB]
  | Get:32 http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu bionic/main 
amd64 gdb amd64 8.2-0ubuntu1~18.04 [3024 kB]
  | Get:33 http://azure.archive.ubuntu.com/ubuntu bionic/universe amd64 epstool 
amd64 3.08+repack-7 [108 kB]

  archive.u.c resolves to multiple IPs. azure.archive.u.c resolves to a
  load balancer (Azure's Traffic Manager). It would be nice if we also
  had the IPs of the servers/hosts in the output and would really help
  us in determining which servers or regions users may be experiencing
  issues with.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1871540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1871540] Re: Include IPs in apt-get output

2020-04-08 Thread Junien Fridrick
Can we maybe get IP and download speed displayed if a "verbose" or
"debug" or something flag is specified on the command line ?

Something like this maybe :

 | Get:7 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages [972
kB] 91.189.88.142 12kB/s

What do you think ?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1871540

Title:
  Include IPs in apt-get output

Status in apt package in Ubuntu:
  New

Bug description:
  Hi,

  When running apt-get update/dist-upgrade, output looks like this:

  | Hit:6 http://archive.ubuntu.com/ubuntu focal-updates InRelease
  | Get:7 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages [972 kB]
  | Get:8 http://archive.ubuntu.com/ubuntu focal/main amd64 c-n-f Metadata 
[29.1 kB]
  | ...
  | Need to get 101 MB of archives.
  | After this operation, 10.5 MB of additional disk space will be used.
  | Do you want to continue? [Y/n] y
  | Get:1 http://archive.ubuntu.com/ubuntu focal/main amd64 dpkg amd64 
1.19.7ubuntu3 [1128 kB]
  | Get:2 http://archive.ubuntu.com/ubuntu focal/main amd64 login amd64 
1:4.8.1-1ubuntu4 [221 kB]
  | Get:3 http://archive.ubuntu.com/ubuntu focal/main amd64 libc6-dbg amd64 
2.31-0ubuntu7 [5673 kB]

  With various online CI/CD services such as GitHub Actions, it looks
  like this:

  | Get:14 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages [833 kB]
  | Get:16 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main 
Translation-en [292 kB]
  | Get:17 http://azure.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages [1044 kB]
  | ...
  | Get:31 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
cmake amd64 3.10.2-1ubuntu2.18.04.1 [3152 kB]
  | Get:32 http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu bionic/main 
amd64 gdb amd64 8.2-0ubuntu1~18.04 [3024 kB]
  | Get:33 http://azure.archive.ubuntu.com/ubuntu bionic/universe amd64 epstool 
amd64 3.08+repack-7 [108 kB]

  archive.u.c resolves to multiple IPs. azure.archive.u.c resolves to a
  load balancer (Azure's Traffic Manager). It would be nice if we also
  had the IPs of the servers/hosts in the output and would really help
  us in determining which servers or regions users may be experiencing
  issues with.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1871540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1825000] Re: Add ability for mirrors to distinguish interactive and non-interactive apt runs

2020-04-02 Thread Junien Fridrick
I think "User-Agent: Debian APT-HTTP/1.3 (2.0.1) non-interactive" would
be enough.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1825000

Title:
  Add ability for mirrors to distinguish interactive and non-interactive
  apt runs

Status in apt package in Ubuntu:
  In Progress
Status in apt source package in Eoan:
  Triaged

Bug description:
  As part of a larger scale plan to manage traffic to the main archive
  servers it would be useful if apt could provide a facility for us to
  identify interactive vs. non-interactive traffic on the server side,
  ideally via a header of some kind.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1825000/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1825000] Re: Add ability for mirrors to distinguish interactive and non-interactive apt runs

2020-03-26 Thread Junien Fridrick
Probably ! What is it going to be for interactive uses though ?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1825000

Title:
  Add ability for mirrors to distinguish interactive and non-interactive
  apt runs

Status in apt package in Ubuntu:
  In Progress
Status in apt source package in Eoan:
  Triaged

Bug description:
  As part of a larger scale plan to manage traffic to the main archive
  servers it would be useful if apt could provide a facility for us to
  identify interactive vs. non-interactive traffic on the server side,
  ideally via a header of some kind.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1825000/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 871907] Re: vim should have "set bg=dark" by default

2019-04-25 Thread Junien Fridrick
** Information type changed from Public Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to vim in Ubuntu.
https://bugs.launchpad.net/bugs/871907

Title:
  vim should have "set bg=dark" by default

Status in vim package in Ubuntu:
  Opinion

Bug description:
  The default GNOME Terminal settings have a dark background.  When
  syntax highlighting is active, the text is difficult to read.  The
  default vim settings should work better with the default terminal
  settings.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/871907/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1511840] Re: cannot apport-bug from IPv6-only network

2019-01-15 Thread Junien Fridrick
Noted, I'll see what I can do - login.launchpad.net currently lives in
an IPv4-only cloud.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1511840

Title:
  cannot apport-bug from IPv6-only network

Status in apport package in Ubuntu:
  Fix Released

Bug description:
  Attempting to report a bug using apport-bug from a machine without a
  legacy IP address fails:

  # apport-bug foopackage

  ...

  *** Uploading problem information

  The collected information is being sent to the bug tracking system.
  This might take a few minutes.

  *** Error: Network problem

  Cannot connect to crash database, please check your Internet
  connection.

  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1511840/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1260855] Re: http://start.ubuntu.com/connectivity-check.html and other ubiquity services are not accessible over IPv6 (no internet connectivity in ubiquity)

2019-01-15 Thread Junien Fridrick
** Changed in: apport (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1260855

Title:
  http://start.ubuntu.com/connectivity-check.html and other ubiquity
  services are not accessible over IPv6 (no internet connectivity in
  ubiquity)

Status in apport package in Ubuntu:
  Invalid
Status in ubiquity package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released

Bug description:
  When installing on an IPv6 only network, the installer incorrectly
  reports that no Internet connectivity is available.

  Steps to reproduce:
  - Download desktop ISO. I used 
http://cdimage.ubuntu.com/xubuntu/daily-live/current/trusty-desktop-amd64.iso 
current at Fri Dec 13 15:00 EST
  - Boot ISO on a computer where only IPv6 connectivity is available
  - Choose Install Xubuntu
  - Choose language

  Results:
  - At "Preparing to install Xubuntu screen" it states
For best results, please ensure that this computer:
✓ has at least 5.5GB available drive space
✕ is connected to the Internet

  Expected results:
  - A checkmark next to "is connected to the internet"

  The install is able to complete from the ISO. Once the installed
  machine is booted, updates are able to be applied indicating Internet
  connectivity is indeed available.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1260855/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1511840] Re: cannot apport-bug from IPv6-only network

2019-01-15 Thread Junien Fridrick
This should now work. If it doesn't please let me know :)

** Changed in: apport (Ubuntu)
 Assignee: Canonical IS (canonical-is-public) => Junien Fridrick (axino)

** Changed in: apport (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1511840

Title:
  cannot apport-bug from IPv6-only network

Status in apport package in Ubuntu:
  Fix Released

Bug description:
  Attempting to report a bug using apport-bug from a machine without a
  legacy IP address fails:

  # apport-bug foopackage

  ...

  *** Uploading problem information

  The collected information is being sent to the bug tracking system.
  This might take a few minutes.

  *** Error: Network problem

  Cannot connect to crash database, please check your Internet
  connection.

  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1511840/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1656979] Re: No support for DHE ciphers (TLS)

2018-03-12 Thread Junien Fridrick
** Changed in: openldap (Ubuntu)
   Status: Expired => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1656979

Title:
  No support for DHE ciphers (TLS)

Status in openldap package in Ubuntu:
  Incomplete

Bug description:
  Hi,

  Seems the OpenLDAP shipped with Xenial (and prior) built against
  GnuTLS does not support DHE cipher suites.

  | hloeung@ldap-server:~$ apt-cache policy slapd
  | slapd:
  |   Installed: 2.4.42+dfsg-2ubuntu3.1
  |   Candidate: 2.4.42+dfsg-2ubuntu3.1
  |   Version table:
  |  *** 2.4.42+dfsg-2ubuntu3.1 500
  | 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  | 100 /var/lib/dpkg/status
  |  2.4.42+dfsg-2ubuntu3 500
  | 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  Our LDAP server is configured with the following:

  | TLSCertificateFile /etc/ssl/certs/ldap-server.crt
  | TLSCertificateKeyFile /etc/ssl/private/ldap-server.key
  | TLSCACertificateFile /etc/ssl/certs/ldap-server_chain.crt
  | TLSProtocolMin 1.0
  | TLSCipherSuite 
PFS:-VERS-SSL3.0:-DHE-DSS:-ARCFOUR-128:-3DES-CBC:-CAMELLIA-128-GCM:-CAMELLIA-256-GCM:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC:%SERVER_PRECEDENCE
  | TLSDHParamFile /etc/ssl/private/dhparams.pem

  I know TLSDHParamFile isn't used by OpenLDAP when built with GnuTLS,
  but thought I'd try anyways. cipherscan[1] shows the following list of
  cipher suites:

  | prio  ciphersuite  protocols  pfs   
  curves
  | 1 ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 2 ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 3 ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 4 ECDHE-RSA-AES128-SHA256  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 5 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 6 ECDHE-RSA-AES256-SHA384  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1

  Even with TLSCipherSuite config commented out, we see the following
  cipher suites:

  | prio  ciphersuite  protocols  pfs   
  curves
  | 1 ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 2 ECDHE-RSA-AES256-SHA384  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 3 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 4 AES256-GCM-SHA384TLSv1.2None  
  None
  | 5 AES256-SHA256TLSv1.2None  
  None
  | 6 AES256-SHA   TLSv1,TLSv1.1,TLSv1.2  None  
  None
  | 7 CAMELLIA256-SHA  TLSv1,TLSv1.1,TLSv1.2  None  
  None
  | 8 ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 9 ECDHE-RSA-AES128-SHA256  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 10ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 11AES128-GCM-SHA256TLSv1.2None  
  None
  | 12AES128-SHA256TLSv1.2None  
  None
  | 13AES128-SHA   TLSv1,TLSv1.1,TLSv1.2  None  
  None
  | 14CAMELLIA128-SHA  TLSv1,TLSv1.1,TLSv1.2  None  
  None
  | 15ECDHE-RSA-DES-CBC3-SHA   TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 16DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2  None  
  None

  I think the fix is in the patch below that's released in 2.4.39:

  
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=622d13a32ec8d623c26a11b60b63e443dc86df99

  
  Thanks,

  Haw

  
  [1]https://github.com/jvehent/cipherscan

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1656979/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1658236] Re: php abstraction not updated for php7

2018-01-31 Thread Junien Fridrick
Hi,

When can we hope having progress on this bug ?

Thanks

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1658236

Title:
  php abstraction not updated for php7

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  The php abstraction (also wrongly named php5 now) was not updated for
  php7. Attached is a diff I used...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1658236/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1656979] Re: No support for DHE ciphers (TLS)

2018-01-07 Thread Junien Fridrick
** Changed in: openldap (Ubuntu)
   Status: Expired => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1656979

Title:
  No support for DHE ciphers (TLS)

Status in openldap package in Ubuntu:
  Incomplete

Bug description:
  Hi,

  Seems the OpenLDAP shipped with Xenial (and prior) built against
  GnuTLS does not support DHE cipher suites.

  | hloeung@ldap-server:~$ apt-cache policy slapd
  | slapd:
  |   Installed: 2.4.42+dfsg-2ubuntu3.1
  |   Candidate: 2.4.42+dfsg-2ubuntu3.1
  |   Version table:
  |  *** 2.4.42+dfsg-2ubuntu3.1 500
  | 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  | 100 /var/lib/dpkg/status
  |  2.4.42+dfsg-2ubuntu3 500
  | 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  Our LDAP server is configured with the following:

  | TLSCertificateFile /etc/ssl/certs/ldap-server.crt
  | TLSCertificateKeyFile /etc/ssl/private/ldap-server.key
  | TLSCACertificateFile /etc/ssl/certs/ldap-server_chain.crt
  | TLSProtocolMin 1.0
  | TLSCipherSuite 
PFS:-VERS-SSL3.0:-DHE-DSS:-ARCFOUR-128:-3DES-CBC:-CAMELLIA-128-GCM:-CAMELLIA-256-GCM:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC:%SERVER_PRECEDENCE
  | TLSDHParamFile /etc/ssl/private/dhparams.pem

  I know TLSDHParamFile isn't used by OpenLDAP when built with GnuTLS,
  but thought I'd try anyways. cipherscan[1] shows the following list of
  cipher suites:

  | prio  ciphersuite  protocols  pfs   
  curves
  | 1 ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 2 ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 3 ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 4 ECDHE-RSA-AES128-SHA256  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 5 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 6 ECDHE-RSA-AES256-SHA384  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1

  Even with TLSCipherSuite config commented out, we see the following
  cipher suites:

  | prio  ciphersuite  protocols  pfs   
  curves
  | 1 ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 2 ECDHE-RSA-AES256-SHA384  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 3 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 4 AES256-GCM-SHA384TLSv1.2None  
  None
  | 5 AES256-SHA256TLSv1.2None  
  None
  | 6 AES256-SHA   TLSv1,TLSv1.1,TLSv1.2  None  
  None
  | 7 CAMELLIA256-SHA  TLSv1,TLSv1.1,TLSv1.2  None  
  None
  | 8 ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 9 ECDHE-RSA-AES128-SHA256  TLSv1.2
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 10ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 11AES128-GCM-SHA256TLSv1.2None  
  None
  | 12AES128-SHA256TLSv1.2None  
  None
  | 13AES128-SHA   TLSv1,TLSv1.1,TLSv1.2  None  
  None
  | 14CAMELLIA128-SHA  TLSv1,TLSv1.1,TLSv1.2  None  
  None
  | 15ECDHE-RSA-DES-CBC3-SHA   TLSv1,TLSv1.1,TLSv1.2  
ECDH,P-256,256bits  prime192v1,secp224r1,prime256v1,secp384r1,secp521r1
  | 16DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2  None  
  None

  I think the fix is in the patch below that's released in 2.4.39:

  
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=622d13a32ec8d623c26a11b60b63e443dc86df99

  
  Thanks,

  Haw

  
  [1]https://github.com/jvehent/cipherscan

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1656979/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1511840] Re: cannot apport-bug from IPv6-only network

2017-04-28 Thread Junien Fridrick
** Changed in: apport (Ubuntu)
 Assignee: (unassigned) => Canonical IS (canonical-is-public)

** Changed in: apport (Ubuntu)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1511840

Title:
  cannot apport-bug from IPv6-only network

Status in apport package in Ubuntu:
  In Progress

Bug description:
  Attempting to report a bug using apport-bug from a machine without a
  legacy IP address fails:

  # apport-bug foopackage

  ...

  *** Uploading problem information

  The collected information is being sent to the bug tracking system.
  This might take a few minutes.

  *** Error: Network problem

  Cannot connect to crash database, please check your Internet
  connection.

  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1511840/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1260855] Re: http://start.ubuntu.com/connectivity-check.html and other ubiquity services are not accessible over IPv6 (no internet connectivity in ubiquity)

2017-04-28 Thread Junien Fridrick
Hi,

start.ubuntu.com is now available over IPv6. Any issue, please let me
know.

Cheers

** Changed in: ubiquity (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1260855

Title:
  http://start.ubuntu.com/connectivity-check.html and other ubiquity
  services are not accessible over IPv6 (no internet connectivity in
  ubiquity)

Status in apport package in Ubuntu:
  Confirmed
Status in ubiquity package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released

Bug description:
  When installing on an IPv6 only network, the installer incorrectly
  reports that no Internet connectivity is available.

  Steps to reproduce:
  - Download desktop ISO. I used 
http://cdimage.ubuntu.com/xubuntu/daily-live/current/trusty-desktop-amd64.iso 
current at Fri Dec 13 15:00 EST
  - Boot ISO on a computer where only IPv6 connectivity is available
  - Choose Install Xubuntu
  - Choose language

  Results:
  - At "Preparing to install Xubuntu screen" it states
For best results, please ensure that this computer:
✓ has at least 5.5GB available drive space
✕ is connected to the Internet

  Expected results:
  - A checkmark next to "is connected to the internet"

  The install is able to complete from the ISO. Once the installed
  machine is booted, updates are able to be applied indicating Internet
  connectivity is indeed available.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1260855/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1260855] Re: http://start.ubuntu.com/connectivity-check.html and other ubiquity services are not accessible over IPv6 (no internet connectivity in ubiquity)

2017-04-14 Thread Junien Fridrick
This is tracked internally in RT#66526.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1260855

Title:
  http://start.ubuntu.com/connectivity-check.html and other ubiquity
  services are not accessible over IPv6 (no internet connectivity in
  ubiquity)

Status in apport package in Ubuntu:
  Confirmed
Status in ubiquity package in Ubuntu:
  Triaged
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released

Bug description:
  When installing on an IPv6 only network, the installer incorrectly
  reports that no Internet connectivity is available.

  Steps to reproduce:
  - Download desktop ISO. I used 
http://cdimage.ubuntu.com/xubuntu/daily-live/current/trusty-desktop-amd64.iso 
current at Fri Dec 13 15:00 EST
  - Boot ISO on a computer where only IPv6 connectivity is available
  - Choose Install Xubuntu
  - Choose language

  Results:
  - At "Preparing to install Xubuntu screen" it states
For best results, please ensure that this computer:
✓ has at least 5.5GB available drive space
✕ is connected to the Internet

  Expected results:
  - A checkmark next to "is connected to the internet"

  The install is able to complete from the ISO. Once the installed
  machine is booted, updates are able to be applied indicating Internet
  connectivity is indeed available.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1260855/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1260855] Re: http://start.ubuntu.com/connectivity-check.html and other ubiquity services are not accessible over IPv6 (no internet connectivity in ubiquity)

2017-04-14 Thread Junien Fridrick
Hi all,

I'll take a look soon. Sorry for the huge delay here.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1260855

Title:
  http://start.ubuntu.com/connectivity-check.html and other ubiquity
  services are not accessible over IPv6 (no internet connectivity in
  ubiquity)

Status in apport package in Ubuntu:
  Confirmed
Status in ubiquity package in Ubuntu:
  Triaged
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released

Bug description:
  When installing on an IPv6 only network, the installer incorrectly
  reports that no Internet connectivity is available.

  Steps to reproduce:
  - Download desktop ISO. I used 
http://cdimage.ubuntu.com/xubuntu/daily-live/current/trusty-desktop-amd64.iso 
current at Fri Dec 13 15:00 EST
  - Boot ISO on a computer where only IPv6 connectivity is available
  - Choose Install Xubuntu
  - Choose language

  Results:
  - At "Preparing to install Xubuntu screen" it states
For best results, please ensure that this computer:
✓ has at least 5.5GB available drive space
✕ is connected to the Internet

  Expected results:
  - A checkmark next to "is connected to the internet"

  The install is able to complete from the ISO. Once the installed
  machine is booted, updates are able to be applied indicating Internet
  connectivity is indeed available.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1260855/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1554848] Re: Please randomise automatic updates over a longer period

2016-04-20 Thread Junien Fridrick
Hey,

Are you planning on fixing trusty as well ? That would be awesome. And
probably a much simpler fix.

Thanks !

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1554848

Title:
  Please randomise automatic updates over a longer period

Status in apt package in Ubuntu:
  Fix Released
Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in apt source package in Xenial:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Released

Bug description:
  Load on the main Ubuntu archive servers is rather peakish, and tends
  to create a traffic peak on our Internet links at fairly regular times
  each day, preventing customers from accessing the archive.  This
  impacts the cloud archive mirrors using the ubuntu-repository-cache
  charm also, because they are hitting a squid cache which is backed by
  the main archive.  This effect will be even more pronounced under the
  recently-announced automatic update policy for xenial.

  One solution which would alleviate this to some extent would be to
  spread the load over a longer period by increasing the random sleep
  time in the daily update script from 30 minutes to, say, 1-2 hours.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1554848/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1520225] Re: lxc-stop powered off a server

2015-11-26 Thread Junien Fridrick
Hi,

container config : http://paste.ubuntu.com/13524088/

/etc/apt/sources.list.d just contains a repo for some homemade backports

"dpkg -l | grep lxc" was given in the initial comment, but here it is again :
$ dpkg -l|grep lxc
ii liblxc1 1.0.7-0ubuntu0.10 amd64 Linux Containers userspace tools (library)
ii lxc 1.0.7-0ubuntu0.10 amd64 Linux Containers userspace tools
ii lxc-templates 1.0.7-0ubuntu0.10 amd64 Linux Containers userspace tools 
(templates)
ii python3-lxc 1.0.7-0ubuntu0.10 amd64 Linux Containers userspace tools (Python 
3.x bindings)

I understand that "--share-net 1" can make the container connect to the
host's upstart socket. I still don't think "lxc-stop" should stop the
host, ever.

Cheers

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1520225

Title:
  lxc-stop powered off a server

Status in lxc package in Ubuntu:
  Incomplete

Bug description:
  Hi,

  Earlier today, a server got powered off and I'm 99% sure it's because I ran 
the following command as root :
  # lxc-stop -n 

  The container was started manually with :
  # lxc-start -n  -F --share-net 1

  and it wasn't fully booted (ie I didn't have the console yet).

  syslog just showed :
  Nov 26 11:13:12 foo kernel: [30192021.012313] init: tty4 main process (1298) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013083] init: tty5 main process (1301) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013750] init: 
jujud-unit-landscape-client-0 main process (1303) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.014412] init: jujud-unit-ksplice-0 main 
process (1306) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.015017] init: tty2 main process (1307) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.015592] init: tty3 main process (1309) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016160] init: tty6 main process (1312) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016810] init: jujud-machine-0 main 
process (1313) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.017423] init: 
jujud-unit-ubuntu-basenode-0 main process (1314) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.018583] init: tty1 main process (1784) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019164] init: ttyS1 main process (1791) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019738] init: cron main process (20196) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020328] init: irqbalance main process 
(26014) killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020926] init: cgmanager main process 
(27367) killed by TERM signal

  and that's it. I don't have other relevant logs to offer I'm afraid.

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 14.04.3 LTS
  Release:14.04
  Codename:   trusty

  ~$ dpkg -l|grep lxc
  ii  liblxc1 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (library)
  ii  lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools
  ii  lxc-templates   
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (templates)
  ii  python3-lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (Python 3.x bindings)

  apport information below

  Thanks
  --- 
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.7-0ubuntu0.10
  PackageArchitecture: amd64
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-68-generic 
root=UUID=17a1fdea-b0d0-4f6f-a664-ec532f379c64 ro console=tty0 
console=ttyS1,38400 nosplash
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 3.13.0-68.111-generic 3.13.11-ckt27
  Tags: trusty third-party-packages apparmor
  Uname: Linux 3.13.0-68-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1520225/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1520225] Dependencies.txt

2015-11-26 Thread Junien Fridrick
apport information

** Attachment added: "Dependencies.txt"
   
https://bugs.launchpad.net/bugs/1520225/+attachment/4525785/+files/Dependencies.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1520225

Title:
  lxc-stop powered off a server

Status in lxc package in Ubuntu:
  New

Bug description:
  Hi,

  Earlier today, a server got powered off and I'm 99% sure it's because I ran 
the following command as root :
  # lxc-stop -n 

  The container was started manually with :
  # lxc-start -n  -F --share-net 1

  and it wasn't fully booted (ie I didn't have the console yet).

  syslog just showed :
  Nov 26 11:13:12 foo kernel: [30192021.012313] init: tty4 main process (1298) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013083] init: tty5 main process (1301) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013750] init: 
jujud-unit-landscape-client-0 main process (1303) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.014412] init: jujud-unit-ksplice-0 main 
process (1306) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.015017] init: tty2 main process (1307) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.015592] init: tty3 main process (1309) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016160] init: tty6 main process (1312) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016810] init: jujud-machine-0 main 
process (1313) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.017423] init: 
jujud-unit-ubuntu-basenode-0 main process (1314) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.018583] init: tty1 main process (1784) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019164] init: ttyS1 main process (1791) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019738] init: cron main process (20196) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020328] init: irqbalance main process 
(26014) killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020926] init: cgmanager main process 
(27367) killed by TERM signal

  and that's it. I don't have other relevant logs to offer I'm afraid.

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 14.04.3 LTS
  Release:14.04
  Codename:   trusty

  ~$ dpkg -l|grep lxc
  ii  liblxc1 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (library)
  ii  lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools
  ii  lxc-templates   
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (templates)
  ii  python3-lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (Python 3.x bindings)

  apport information below

  Thanks
  --- 
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.7-0ubuntu0.10
  PackageArchitecture: amd64
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-68-generic 
root=UUID=17a1fdea-b0d0-4f6f-a664-ec532f379c64 ro console=tty0 
console=ttyS1,38400 nosplash
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 3.13.0-68.111-generic 3.13.11-ckt27
  Tags: trusty third-party-packages apparmor
  Uname: Linux 3.13.0-68-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1520225/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1520225] lxc.default.txt

2015-11-26 Thread Junien Fridrick
apport information

** Attachment added: "lxc.default.txt"
   
https://bugs.launchpad.net/bugs/1520225/+attachment/4525789/+files/lxc.default.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1520225

Title:
  lxc-stop powered off a server

Status in lxc package in Ubuntu:
  New

Bug description:
  Hi,

  Earlier today, a server got powered off and I'm 99% sure it's because I ran 
the following command as root :
  # lxc-stop -n 

  The container was started manually with :
  # lxc-start -n  -F --share-net 1

  and it wasn't fully booted (ie I didn't have the console yet).

  syslog just showed :
  Nov 26 11:13:12 foo kernel: [30192021.012313] init: tty4 main process (1298) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013083] init: tty5 main process (1301) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013750] init: 
jujud-unit-landscape-client-0 main process (1303) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.014412] init: jujud-unit-ksplice-0 main 
process (1306) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.015017] init: tty2 main process (1307) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.015592] init: tty3 main process (1309) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016160] init: tty6 main process (1312) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016810] init: jujud-machine-0 main 
process (1313) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.017423] init: 
jujud-unit-ubuntu-basenode-0 main process (1314) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.018583] init: tty1 main process (1784) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019164] init: ttyS1 main process (1791) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019738] init: cron main process (20196) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020328] init: irqbalance main process 
(26014) killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020926] init: cgmanager main process 
(27367) killed by TERM signal

  and that's it. I don't have other relevant logs to offer I'm afraid.

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 14.04.3 LTS
  Release:14.04
  Codename:   trusty

  ~$ dpkg -l|grep lxc
  ii  liblxc1 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (library)
  ii  lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools
  ii  lxc-templates   
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (templates)
  ii  python3-lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (Python 3.x bindings)

  apport information below

  Thanks
  --- 
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.7-0ubuntu0.10
  PackageArchitecture: amd64
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-68-generic 
root=UUID=17a1fdea-b0d0-4f6f-a664-ec532f379c64 ro console=tty0 
console=ttyS1,38400 nosplash
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 3.13.0-68.111-generic 3.13.11-ckt27
  Tags: trusty third-party-packages apparmor
  Uname: Linux 3.13.0-68-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1520225/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1520225] lxc-net.default.txt

2015-11-26 Thread Junien Fridrick
apport information

** Attachment added: "lxc-net.default.txt"
   
https://bugs.launchpad.net/bugs/1520225/+attachment/4525788/+files/lxc-net.default.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1520225

Title:
  lxc-stop powered off a server

Status in lxc package in Ubuntu:
  New

Bug description:
  Hi,

  Earlier today, a server got powered off and I'm 99% sure it's because I ran 
the following command as root :
  # lxc-stop -n 

  The container was started manually with :
  # lxc-start -n  -F --share-net 1

  and it wasn't fully booted (ie I didn't have the console yet).

  syslog just showed :
  Nov 26 11:13:12 foo kernel: [30192021.012313] init: tty4 main process (1298) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013083] init: tty5 main process (1301) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013750] init: 
jujud-unit-landscape-client-0 main process (1303) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.014412] init: jujud-unit-ksplice-0 main 
process (1306) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.015017] init: tty2 main process (1307) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.015592] init: tty3 main process (1309) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016160] init: tty6 main process (1312) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016810] init: jujud-machine-0 main 
process (1313) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.017423] init: 
jujud-unit-ubuntu-basenode-0 main process (1314) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.018583] init: tty1 main process (1784) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019164] init: ttyS1 main process (1791) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019738] init: cron main process (20196) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020328] init: irqbalance main process 
(26014) killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020926] init: cgmanager main process 
(27367) killed by TERM signal

  and that's it. I don't have other relevant logs to offer I'm afraid.

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 14.04.3 LTS
  Release:14.04
  Codename:   trusty

  ~$ dpkg -l|grep lxc
  ii  liblxc1 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (library)
  ii  lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools
  ii  lxc-templates   
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (templates)
  ii  python3-lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (Python 3.x bindings)

  apport information below

  Thanks
  --- 
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.7-0ubuntu0.10
  PackageArchitecture: amd64
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-68-generic 
root=UUID=17a1fdea-b0d0-4f6f-a664-ec532f379c64 ro console=tty0 
console=ttyS1,38400 nosplash
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 3.13.0-68.111-generic 3.13.11-ckt27
  Tags: trusty third-party-packages apparmor
  Uname: Linux 3.13.0-68-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1520225/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1520225] RelatedPackageVersions.txt

2015-11-26 Thread Junien Fridrick
apport information

** Attachment added: "RelatedPackageVersions.txt"
   
https://bugs.launchpad.net/bugs/1520225/+attachment/4525787/+files/RelatedPackageVersions.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1520225

Title:
  lxc-stop powered off a server

Status in lxc package in Ubuntu:
  New

Bug description:
  Hi,

  Earlier today, a server got powered off and I'm 99% sure it's because I ran 
the following command as root :
  # lxc-stop -n 

  The container was started manually with :
  # lxc-start -n  -F --share-net 1

  and it wasn't fully booted (ie I didn't have the console yet).

  syslog just showed :
  Nov 26 11:13:12 foo kernel: [30192021.012313] init: tty4 main process (1298) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013083] init: tty5 main process (1301) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013750] init: 
jujud-unit-landscape-client-0 main process (1303) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.014412] init: jujud-unit-ksplice-0 main 
process (1306) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.015017] init: tty2 main process (1307) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.015592] init: tty3 main process (1309) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016160] init: tty6 main process (1312) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016810] init: jujud-machine-0 main 
process (1313) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.017423] init: 
jujud-unit-ubuntu-basenode-0 main process (1314) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.018583] init: tty1 main process (1784) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019164] init: ttyS1 main process (1791) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019738] init: cron main process (20196) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020328] init: irqbalance main process 
(26014) killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020926] init: cgmanager main process 
(27367) killed by TERM signal

  and that's it. I don't have other relevant logs to offer I'm afraid.

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 14.04.3 LTS
  Release:14.04
  Codename:   trusty

  ~$ dpkg -l|grep lxc
  ii  liblxc1 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (library)
  ii  lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools
  ii  lxc-templates   
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (templates)
  ii  python3-lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (Python 3.x bindings)

  apport information below

  Thanks
  --- 
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.7-0ubuntu0.10
  PackageArchitecture: amd64
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-68-generic 
root=UUID=17a1fdea-b0d0-4f6f-a664-ec532f379c64 ro console=tty0 
console=ttyS1,38400 nosplash
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 3.13.0-68.111-generic 3.13.11-ckt27
  Tags: trusty third-party-packages apparmor
  Uname: Linux 3.13.0-68-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1520225/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1520225] KernLog.txt

2015-11-26 Thread Junien Fridrick
apport information

** Attachment added: "KernLog.txt"
   
https://bugs.launchpad.net/bugs/1520225/+attachment/4525786/+files/KernLog.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1520225

Title:
  lxc-stop powered off a server

Status in lxc package in Ubuntu:
  New

Bug description:
  Hi,

  Earlier today, a server got powered off and I'm 99% sure it's because I ran 
the following command as root :
  # lxc-stop -n 

  The container was started manually with :
  # lxc-start -n  -F --share-net 1

  and it wasn't fully booted (ie I didn't have the console yet).

  syslog just showed :
  Nov 26 11:13:12 foo kernel: [30192021.012313] init: tty4 main process (1298) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013083] init: tty5 main process (1301) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013750] init: 
jujud-unit-landscape-client-0 main process (1303) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.014412] init: jujud-unit-ksplice-0 main 
process (1306) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.015017] init: tty2 main process (1307) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.015592] init: tty3 main process (1309) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016160] init: tty6 main process (1312) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016810] init: jujud-machine-0 main 
process (1313) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.017423] init: 
jujud-unit-ubuntu-basenode-0 main process (1314) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.018583] init: tty1 main process (1784) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019164] init: ttyS1 main process (1791) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019738] init: cron main process (20196) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020328] init: irqbalance main process 
(26014) killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020926] init: cgmanager main process 
(27367) killed by TERM signal

  and that's it. I don't have other relevant logs to offer I'm afraid.

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 14.04.3 LTS
  Release:14.04
  Codename:   trusty

  ~$ dpkg -l|grep lxc
  ii  liblxc1 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (library)
  ii  lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools
  ii  lxc-templates   
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (templates)
  ii  python3-lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (Python 3.x bindings)

  apport information below

  Thanks
  --- 
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.7-0ubuntu0.10
  PackageArchitecture: amd64
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-68-generic 
root=UUID=17a1fdea-b0d0-4f6f-a664-ec532f379c64 ro console=tty0 
console=ttyS1,38400 nosplash
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 3.13.0-68.111-generic 3.13.11-ckt27
  Tags: trusty third-party-packages apparmor
  Uname: Linux 3.13.0-68-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1520225/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1520225] lxcsyslog.txt

2015-11-26 Thread Junien Fridrick
apport information

** Attachment added: "lxcsyslog.txt"
   
https://bugs.launchpad.net/bugs/1520225/+attachment/4525790/+files/lxcsyslog.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1520225

Title:
  lxc-stop powered off a server

Status in lxc package in Ubuntu:
  New

Bug description:
  Hi,

  Earlier today, a server got powered off and I'm 99% sure it's because I ran 
the following command as root :
  # lxc-stop -n 

  The container was started manually with :
  # lxc-start -n  -F --share-net 1

  and it wasn't fully booted (ie I didn't have the console yet).

  syslog just showed :
  Nov 26 11:13:12 foo kernel: [30192021.012313] init: tty4 main process (1298) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013083] init: tty5 main process (1301) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013750] init: 
jujud-unit-landscape-client-0 main process (1303) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.014412] init: jujud-unit-ksplice-0 main 
process (1306) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.015017] init: tty2 main process (1307) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.015592] init: tty3 main process (1309) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016160] init: tty6 main process (1312) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016810] init: jujud-machine-0 main 
process (1313) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.017423] init: 
jujud-unit-ubuntu-basenode-0 main process (1314) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.018583] init: tty1 main process (1784) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019164] init: ttyS1 main process (1791) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.019738] init: cron main process (20196) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020328] init: irqbalance main process 
(26014) killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.020926] init: cgmanager main process 
(27367) killed by TERM signal

  and that's it. I don't have other relevant logs to offer I'm afraid.

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 14.04.3 LTS
  Release:14.04
  Codename:   trusty

  ~$ dpkg -l|grep lxc
  ii  liblxc1 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (library)
  ii  lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools
  ii  lxc-templates   
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (templates)
  ii  python3-lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (Python 3.x bindings)

  apport information below

  Thanks
  --- 
  ApportVersion: 2.14.1-0ubuntu3.19
  Architecture: amd64
  DistroRelease: Ubuntu 14.04
  Package: lxc 1.0.7-0ubuntu0.10
  PackageArchitecture: amd64
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-68-generic 
root=UUID=17a1fdea-b0d0-4f6f-a664-ec532f379c64 ro console=tty0 
console=ttyS1,38400 nosplash
  ProcEnviron:
   TERM=screen-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 3.13.0-68.111-generic 3.13.11-ckt27
  Tags: trusty third-party-packages apparmor
  Uname: Linux 3.13.0-68-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1520225/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1520225] [NEW] lxc-stop powered off a server

2015-11-26 Thread Junien Fridrick
Public bug reported:

Hi,

Earlier today, a server got powered off and I'm 99% sure it's because I ran the 
following command as root :
# lxc-stop -n 

The container was started manually with :
# lxc-start -n  -F --share-net 1

and it wasn't fully booted (ie I didn't have the console yet).

syslog just showed :
Nov 26 11:13:12 foo kernel: [30192021.012313] init: tty4 main process (1298) 
killed by TERM signal
Nov 26 11:13:12 foo kernel: [30192021.013083] init: tty5 main process (1301) 
killed by TERM signal
Nov 26 11:13:12 foo kernel: [30192021.013750] init: 
jujud-unit-landscape-client-0 main process (1303) terminated with status 2
Nov 26 11:13:12 foo kernel: [30192021.014412] init: jujud-unit-ksplice-0 main 
process (1306) terminated with status 2
Nov 26 11:13:12 foo kernel: [30192021.015017] init: tty2 main process (1307) 
killed by TERM signal
Nov 26 11:13:12 foo kernel: [30192021.015592] init: tty3 main process (1309) 
killed by TERM signal
Nov 26 11:13:12 foo kernel: [30192021.016160] init: tty6 main process (1312) 
killed by TERM signal
Nov 26 11:13:12 foo kernel: [30192021.016810] init: jujud-machine-0 main 
process (1313) terminated with status 2
Nov 26 11:13:12 foo kernel: [30192021.017423] init: 
jujud-unit-ubuntu-basenode-0 main process (1314) terminated with status 2
Nov 26 11:13:12 foo kernel: [30192021.018583] init: tty1 main process (1784) 
killed by TERM signal
Nov 26 11:13:12 foo kernel: [30192021.019164] init: ttyS1 main process (1791) 
killed by TERM signal
Nov 26 11:13:12 foo kernel: [30192021.019738] init: cron main process (20196) 
killed by TERM signal
Nov 26 11:13:12 foo kernel: [30192021.020328] init: irqbalance main process 
(26014) killed by TERM signal
Nov 26 11:13:12 foo kernel: [30192021.020926] init: cgmanager main process 
(27367) killed by TERM signal

and that's it. I don't have other relevant logs to offer I'm afraid.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.3 LTS
Release:14.04
Codename:   trusty

~$ dpkg -l|grep lxc
ii  liblxc1 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (library)
ii  lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools
ii  lxc-templates   
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (templates)
ii  python3-lxc 
1.0.7-0ubuntu0.10 amd64Linux Containers 
userspace tools (Python 3.x bindings)

apport information below

Thanks
--- 
ApportVersion: 2.14.1-0ubuntu3.19
Architecture: amd64
DistroRelease: Ubuntu 14.04
Package: lxc 1.0.7-0ubuntu0.10
PackageArchitecture: amd64
ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.13.0-68-generic 
root=UUID=17a1fdea-b0d0-4f6f-a664-ec532f379c64 ro console=tty0 
console=ttyS1,38400 nosplash
ProcEnviron:
 TERM=screen-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.13.0-68.111-generic 3.13.11-ckt27
Tags: trusty third-party-packages apparmor
Uname: Linux 3.13.0-68-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:
 
_MarkForUpload: True
defaults.conf:
 lxc.network.type = veth
 lxc.network.link = lxcbr0
 lxc.network.flags = up
 lxc.network.hwaddr = 00:16:3e:xx:xx:xx

** Affects: lxc (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: apparmor apport-collected third-party-packages trusty

** Tags added: apparmor apport-collected third-party-packages trusty

** Description changed:

  Hi,
  
  Earlier today, a server got powered off and I'm 99% sure it's because I ran 
the following command as root :
  # lxc-stop -n 
  
  The container was started manually with :
  # lxc-start -n  -F --share-net 1
  
  and it wasn't fully booted (ie I didn't have the console yet).
  
  syslog just showed :
  Nov 26 11:13:12 foo kernel: [30192021.012313] init: tty4 main process (1298) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013083] init: tty5 main process (1301) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.013750] init: 
jujud-unit-landscape-client-0 main process (1303) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.014412] init: jujud-unit-ksplice-0 main 
process (1306) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.015017] init: tty2 main process (1307) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.015592] init: tty3 main process (1309) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016160] init: tty6 main process (1312) 
killed by TERM signal
  Nov 26 11:13:12 foo kernel: [30192021.016810] init: jujud-machine-0 main 
process (1313) terminated with status 2
  Nov 26 11:13:12 foo kernel: [30192021.01

[Touch-packages] [Bug 1350947] Re: apparmor: no working rule to allow making a mount private

2015-07-29 Thread Junien Fridrick
Hi Serge, Martin,

As Serge mentioned in #4, this bug will cause breakage if using both "ip
netns" and lxc. As I'm sure you're aware, the OpenStack neutron/quantum
gateway makes heavy use of the "ip netns" feature, and it's valid to
have LXC containers on the server hosting tje quantum gateway.

Given this setup, adding a container to the server hosting the quantum
gateway breaks the netns for the DHCP and L3 agents, which leads to all
sorts of fun.

So, does it make sense to backport this fix to trusty ? If not, then is
manually applying https://github.com/lxc/lxc/pull/393/files a valid
workaround ?

Thanks !

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1350947

Title:
  apparmor: no working rule to allow making a mount private

Status in AppArmor:
  Invalid
Status in lxc package in Ubuntu:
  Fix Released

Bug description:
  NOTE: This bug will be fixed with an update to lxc. However, two
  AppArmor bugs (bug #1401619 and bug #1401621) were identified as a
  result of triaging this bug and they will both be fixed in upstream
  AppArmor.

  When the file system is mounted as MS_SHARED by default (such as under
  systemd, or when the admin configures it so), things like schroot or
  LXC need to make their "guest" mounts private. This currently fails
  under utopic:

  $ sudo lxc-create -t busybox -n c1
  $ sudo mount --make-rshared /
  $ sudo strace -fvvs1024 -e mount  lxc-start -n c1
  [...]
  [pid 10749] mount(NULL, "/", NULL, MS_SLAVE, NULL) = -1 EACCES (Permission 
denied)
  lxc-start: Permission denied - Failed to make / rslave

  dmesg says:
  audit: type=1400 audit(1406825005.687:551): apparmor="DENIED" operation="mo
  unt" info="failed flags match" error=-13 profile="/usr/bin/lxc-start" 
name="/" pid=8228 co
  mm="lxc-start" flags="rw, slave"

  (This happens for all mount points on your system, I'm just showing
  the first one)

  This will leave a couple of leaked mounts on your system. This is an
  useful rune to clean them up:

  $ for i in 1 2 3; do sudo umount `mount|grep lxc|awk '{print $3}'`;
  done

  (needs to be done several times; check with "mount |grep lxc" that
  it's clean)

  I tried to allow that by adding this to
  /etc/apparmor.d/abstractions/lxc/start-container:

    mount options=(rw, slave) -> **,

  then reload the policy and rety with

  $ sudo stop lxc; sudo start lxc; sudo lxc-start -n c1

  (and again clean up the mounts with above rune)

  I tried some variations of this, like

    mount options in (rw, slave, rslave, shared, rshared) -> **,

  but none of them worked. The only things that do work are one of

    mount,
    mount -> **,

  but those are too lax to be an effective security restriction.

  WORKAROUND
  ==
  (Attention: insecure! Don't use for production machines)

  Add this to /etc/apparmor.d/abstractions/lxc/start-container:

     mount,

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: linux-image-3.16.0-6-generic 3.16.0-6.11
  ProcVersionSignature: Ubuntu 3.16.0-6.11-generic 3.16.0-rc7
  Uname: Linux 3.16.0-6-generic x86_64
  ApportVersion: 2.14.5-0ubuntu1
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  martin 1665 F pulseaudio
  CurrentDesktop: Unity
  Date: Thu Jul 31 18:58:18 2014
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2014-02-27 (154 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140224)
  MachineType: LENOVO 2324CTO
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-6-generic.efi.signed 
root=UUID=a2b27321-0b55-44c9-af0d-6c939efa45ce ro quiet splash 
init=/lib/systemd/systemd crashkernel=384M-:128M vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.16.0-6-generic N/A
   linux-backports-modules-3.16.0-6-generic  N/A
   linux-firmware1.132
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/09/2013
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ET95WW (2.55 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2324CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: 0B98401 Pro
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvrG2ET95WW(2.55):bd07/09/2013:svnLENOVO:pn2324CTO:pvrThinkPadX230:rvnLENOVO:rn2324CTO:rvr0B98401Pro:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 2324CTO
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1350947/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp