[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-13 Thread Andreas Hasenack
DO NOT RELEASE TO UPDATES YET
DO NOT RELEASE TO UPDATES YET

The fix is correct and working, but requires a manual restart of the
services until #1928259 is fixed. We will want to fix both at the same
time.

With that in mind, here goes my testing report.


Reproducing the problem with the packages from bionic:

nfs-common: 
  Installed: 1:1.3.4-2.1ubuntu5.3   
  Candidate: 1:1.3.4-2.1ubuntu5.3   
  Version table:
 *** 1:1.3.4-2.1ubuntu5.3 500   
500 http://br.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
500 http://br.archive.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
100 /var/lib/dpkg/status
 1:1.3.4-2.1ubuntu5 500 
500 http://br.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

first attempt:  
$ sudo ./bz1419280_test_threads 
Iter 1  
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035   
Iter 2  
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035   
Iter 3  
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035   
Iter 4  
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035   
reproduced the bug after 4 iterations   
ubuntu@bionic-gssd-bug-1927745:~$ ps axw|grep stat_as   
 8248 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035  
 8317 pts/1S+ 0:00 grep --color=auto stat_as

second attempt (after restarting rpc-gssd): 
$ sudo ./bz1419280_test_threads 
Iter 1  
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035   
Iter 2  
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035   
Iter 3  
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035   
reproduced the bug after 3 iterations   
ubuntu@bionic-gssd-bug-1927745:~$ ps axw|grep stat_as   
 8631 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035  
 8690 pts/1S+ 0:00 grep --color=auto stat_as 

third attempt (also after restarting rpc-gssd): 
$ sudo ./bz1419280_test_threads 
Iter 1  
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035   
Iter 2  
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035   
reproduced the bug after 2 iterations   
$ ps axw|grep stat_as   
 8855 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035  
 8870 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035  
 8945 pts/1S+ 0:00 grep --color=auto stat_as


I then updated the packages, AND MANUALLY RESTARTED nfs-utils.service (SEE 
#1928259):
nfs-common: 
  Installed: 1:1.3.4-2.1ubuntu5.4   
  Candidate: 1:1.3.4-2.1ubuntu5.4   
  Version table:
 *** 1:1.3.4-2.1ubuntu5.4 500   
500 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
100 /var/lib/dpkg/status
 1:1.3.4-2.1ubuntu5.3 500   
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 
500 http://archive.ubuntu.com/ubuntu 

[Bug 1928259] Re: Package upgrade won't restart services

2021-05-12 Thread Andreas Hasenack
** Bug watch added: Debian Bug tracker #988430
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988430

** Also affects: nfs-utils (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988430
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928259

Title:
  Package upgrade won't restart services

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928259/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-12 Thread Andreas Hasenack
I filed https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928259
for the restart issue.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927745

Title:
  Non-thread-safe functions used in multi-threaded rpc.gssd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1928259] [NEW] Package upgrade won't restart services

2021-05-12 Thread Andreas Hasenack
Public bug reported:

Upgrading the nfs-common debian package will not restart its services.

Specifically, the package tries to restart "nfs-utils.service", which is a 
"fake" service meant to coordinate all the other daemons that make up a modern 
NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified

Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target   
dh_systemd_enable -p nfs-kernel-server nfs-server.service   
dh_installinit -pnfs-common -R  
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade 
nfs-server.service

We can see it tries to start and restart it, but that won't work on disabled or 
non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started 
or restarted.
# However, if the job is disabled but has been forced into the running state, 
we *do* stop
# and restart it since this is expected behaviour for the admin who forced the 
start.
# We don't autostart static units either.

The above can be seen while attempting a fresh install (or even upgrade) of 
nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...

Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → 
/lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → 
/lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^

$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
 Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
 Active: inactive (dead)


This was found while testing the fix for bug #1927745. In that bug, the 
affected service is rpc.gssd and it's critical that it be restarted, but it's 
not happening. It will only be restarted if nfs-utils.service is already 
"started".

I'm marking this bug as "high" because it prevents valid fixes from
being deployed after just upgrading a package.

** Affects: nfs-utils (Ubuntu)
 Importance: High
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928259

Title:
  Package upgrade won't restart services

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1928259/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-12 Thread Andreas Hasenack
Testing was kind of successful, in the sense that the patch fixes the
problem. But I found a pre-existing bug in the packaging that manifested
itself in this testing.

After upgrading the packages, not all services are restarted. Critically
for this bug we are addressing here, rpc.gssd is not restarted:

Before upgrade:
  442 ?Ss 0:00 /usr/sbin/blkmapd
 7146 ?Ss 0:00 /usr/sbin/rpc.gssd
 7399 ?Ss 0:00 /usr/sbin/rpc.idmapd
 7406 ?Ss 0:00 /usr/sbin/rpc.mountd --manage-gids
 7400 ?Ss 0:00 /usr/sbin/rpc.svcgssd

After pkg upgrade:
  442 ?Ss 0:00 /usr/sbin/blkmapd
 7146 ?Ss 0:00 /usr/sbin/rpc.gssd
 8421 ?Ss 0:00 /usr/sbin/rpc.idmapd
 8422 ?Ss 0:00 /usr/sbin/rpc.mountd --manage-gids
 8420 ?Ss 0:00 /usr/sbin/rpc.svcgssd

We can see that blkmapd and rpc.gssd were not restarted, which means
that just upgrading the packages doesn't resolve the bug: the user must
issue `sudo systemctl restart nfs-utils.service`.

This happens because the nfs-utils.service is not enabled (and cannot be
enabled: it's a "fake" service just meant to coordinate the several
daemons necessary for NFS).

If nfs-utils.service was ever started or restarted on the machine, then
the upgrade will restart it just fine.

I'm currently investigating what are the best options to address this,
and will probably file a new bug.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927745

Title:
  Non-thread-safe functions used in multi-threaded rpc.gssd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-12 Thread Andreas Hasenack
SRU team pinged. Package is confirmed in the unapproved queue at
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1_text=nfs-
utils

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927745

Title:
  Non-thread-safe functions used in multi-threaded rpc.gssd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-11 Thread Andreas Hasenack
MP approved, package uploaded to bionic-proposed unapproved.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927745

Title:
  Non-thread-safe functions used in multi-threaded rpc.gssd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1918141] Re: nfs-server.service needs name resolution and network online

2021-05-11 Thread Andreas Hasenack
(and posted wrong bug: mine is https://bugs.launchpad.net/ubuntu/+source
/nfs-utils/+bug/1927745)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918141

Title:
  nfs-server.service needs name resolution and network online

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1918141/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1918141] Re: nfs-server.service needs name resolution and network online

2021-05-11 Thread Andreas Hasenack
... and mine* is a pure bugfix ...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918141

Title:
  nfs-server.service needs name resolution and network online

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1918141/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1918141] Re: nfs-server.service needs name resolution and network online

2021-05-11 Thread Andreas Hasenack
Guys, this has been sitting in unapproved for about 2 months now, and I
need to push another fix for nfs-utils asap (see
https://bugs.launchpad.net/bugs/1918141). I only noticed this unapproved
upload when I was about to push the git tag, as the upload doesn't show
up in rmadison's output.

I would prefer to not include this fix here in my upload, as it looks
like there is no consensus and it's a bigger behavior change, and my is
a pure bugfix with upstream patches that are already applied in redhat,
debian, and focal+.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918141

Title:
  nfs-server.service needs name resolution and network online

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1918141/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-10 Thread Andreas Hasenack
** Description changed:

  [Impact]
  rpc-gssd can hang or crash when a kerberos nfsv4 mount point is accessed by 
multiple users simultaneously. The problem happens because the daemon uses the 
strtok() function which is not thread safe.
  
  The fix from upstream removes strtok() and uses strsep() instead. These
  patches are already applied in focal and later, via merges from debian.
  
  [Test Plan]
  As with all race conditions, this test case may take a while to reproduce the 
problem.
  
  # Create a bionic VM. It seems to help if it's created with multiple 
cpus/cores. I had more success with 4 cores and 1GiB of RAM.
  # if using lxd to launch a VM, you can run this before: "lxc config set 
vm-name limits.cpu=4". Just don't forget to undo it, or set to your normal 
number of CPUs, after the test
  # Login and get its ip, and take note of it:
  export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
  echo $IP
  
  # adjust /etc/hosts:
  echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
  
  # adjust /etc/resolv.conf:
  echo "search example.com" | sudo tee -a /etc/resolv.conf
  
  # verify hostname -f returns the fqdn of the vm, i.e., a name with the 
.example.com domain:
  hostname -f
  
  # If you still don't get the correct FQDN, try the below, adjusting for your 
hostname if $(hostname) isn't working properly:
  sudo hostnamectl set-hostname $(hostname).example.com
  
  # Run these commands, and when asked:
  # - for realm: EXAMPLE.COM
  # - for kdc and admin server: use the vm's IP
  
  sudo apt update && sudo apt install nfs-server krb5-kdc krb5-admin-
  server krb5-user gcc
  
  # create a kerberos realm. When prompted, use any password you want:
  sudo krb5_newrealm
  
  # create an nfs service ticket, and store it in the keytab
  sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"
  sudo kadmin.local -q "ktadd nfs/$(hostname -f)"
  
  # create test directories
- sudo mkdir -p /mnt/test_krb5/
- sudo mkdir -p /export
+ sudo mkdir -p /mnt/test_krb5/ /export
  sudo touch /export/foo
  
  # adjust nfs config and restart the nfs server:
  sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," 
/etc/default/nfs-kernel-server
  sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common
  sudo systemctl restart nfs-server
  
  # configure an nfs export:
  echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
  sudo exportfs -rva
  
  # confirm it's available
  sudo showmount -e localhost
  
  # mount it
  sudo mount $(hostname -f):/export /mnt/test_krb5/
  sudo ls -la /mnt/test_krb5
  
  # download bug attachments
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496166/+files/stat_as.c
 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads
  chmod +x bz1419280_test_threads
  
  # build reproducer
  gcc stat_as.c -o stat_as
  
  # run test script as root. It may take a few minutes to trigger the bug
  sudo ./bz1419280_test_threads
  
  # wait
  # Once you get the confirmation:
  calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035
  reproduced the bug after 114 iterations
  
  # Check for a "stat_as" D state process:
  $ ps axw|grep stat_as
  17814 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
  
  # To restore functionality, restart rpc-gssd:
  sudo systemctl restart rpc-gssd.service
  
  With the updated packages, the script will not detect the bug and never
  stop.
  
  [Where problems could occur]
  NFS v4 services are more complex than earlier versions, and are comprised of 
several services/daemons. It's possible for the restart done after the 
automatic package upgrade to show up as a regression due to several factors:
  - not all needed services were restarted (bug, but not introduced by this 
change)
  - depending on mount options, client mount points may appear as hung and take 
a while to recover
  - configuration errors on the server which were up until now not noticed, and 
only manifest themselves after a restart
  - some sites, due to the lack of configuration options in /etc/default/nfs-*, 
might have overriden systemd service files and hardcoded other command line 
options there. If not done properly (i.e., not done in /etc/systemd via 
overrides), these local changes will be lost after the package upgrade. I know 
of at least rpc-gssd, which has no command-line options available in 
/etc/default/nfs-*, and I know of users who have tweaked this service in many 
different ways to add things like -v or -n to its command line option.
  
  [Other Info]
  The upstream patches have been applied since February 2017 and have not been 
changed or reverted. They are also applied in Debian and Fedora, and ubuntu 
since focal at least.
  
  There is an additional patch, but part of the fix, which dupes the
  string for appropriate logging. Its memory is also freed.
  
  It may be hard to 

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-10 Thread Andreas Hasenack
** Description changed:

  [Impact]
  rpc-gssd can hang or crash when a kerberos nfsv4 mount point is accessed by 
multiple users simultaneously. The problem happens because the daemon uses the 
strtok() function which is not thread safe.
  
  The fix from upstream removes strtok() and uses strsep() instead. These
  patches are already applied in focal and later, via merges from debian.
  
  [Test Plan]
  As with all race conditions, this test case may take a while to reproduce the 
problem.
  
  # Create a bionic VM. It seems to help if it's created with multiple 
cpus/cores. I had more success with 4 cores and 1GiB of RAM.
+ # if using lxd to launch a VM, you can run this before: "lxc config set 
vm-name limits.cpu=4". Just don't forget to undo it, or set to your normal 
number of CPUs, after the test
  # Login and get its ip, and take note of it:
  export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
  echo $IP
  
  # adjust /etc/hosts:
  echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
  
  # adjust /etc/resolv.conf:
  echo "search example.com" | sudo tee -a /etc/resolv.conf
  
  # verify hostname -f returns the fqdn of the vm, i.e., a name with the 
.example.com domain:
  hostname -f
+ 
+ # If you still don't get the correct FQDN, try the below, adjusting for your 
hostname:
+ sudo hostnamectl set-hostname .example.com
  
  # Run these commands, and when asked:
  # - for realm: EXAMPLE.COM
  # - for kdc and admin server: use the vm's IP
  
  sudo apt update && sudo apt install nfs-server krb5-kdc krb5-admin-
  server krb5-user gcc
  
  # create a kerberos realm. When prompted, use any password you want:
  sudo krb5_newrealm
  
  # create an nfs service ticket, and store it in the keytab
  sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"
  sudo kadmin.local -q "ktadd nfs/$(hostname -f)"
  
  # create test directories
  sudo mkdir -p /mnt/test_krb5/
  sudo mkdir -p /export
  sudo touch /export/foo
  
  # adjust nfs config and restart the nfs server:
  sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," 
/etc/default/nfs-kernel-server
  sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common
  sudo systemctl restart nfs-server
  
  # configure an nfs export:
  echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
  sudo exportfs -rva
  
  # confirm it's available
  sudo showmount -e localhost
  
  # mount it
  sudo mount $(hostname -f):/export /mnt/test_krb5/
  sudo ls -la /mnt/test_krb5
  
  # download bug attachments
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496166/+files/stat_as.c
 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads
  chmod +x bz1419280_test_threads
  
  # build reproducer
  gcc stat_as.c -o stat_as
  
  # run test script as root. It may take a few minutes to trigger the bug
  sudo ./bz1419280_test_threads
  
  # wait
  # Once you get the confirmation:
  calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035
  reproduced the bug after 114 iterations
  
  # Check for a "stat_as" D state process:
  $ ps axw|grep stat_as
  17814 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
  
  # To restore functionality, restart rpc-gssd:
  sudo systemctl restart rpc-gssd.service
  
  With the updated packages, the script will not detect the bug and never
  stop.
  
  [Where problems could occur]
  NFS v4 services are more complex than earlier versions, and are comprised of 
several services/daemons. It's possible for the restart done after the 
automatic package upgrade to show up as a regression due to several factors:
  - not all needed services were restarted (bug, but not introduced by this 
change)
  - depending on mount options, client mount points may appear as hung and take 
a while to recover
  - configuration errors on the server which were up until now not noticed, and 
only manifest themselves after a restart
  - some sites, due to the lack of configuration options in /etc/default/nfs-*, 
might have overriden systemd service files and hardcoded other command line 
options there. If not done properly (i.e., not done in /etc/systemd via 
overrides), these local changes will be lost after the package upgrade. I know 
of at least rpc-gssd, which has no command-line options available in 
/etc/default/nfs-*, and I know of users who have tweaked this service in many 
different ways to add things like -v or -n to its command line option.
  
  [Other Info]
  The upstream patches have been applied since February 2017 and have not been 
changed or reverted. They are also applied in Debian and Fedora, and ubuntu 
since focal at least.
  
  There is an additional patch, but part of the fix, which dupes the
  string for appropriate logging. Its memory is also freed.
  
  It may be hard to reproduce this bug in a test environment. I've gotten
  to the error in as little as a 

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-10 Thread Andreas Hasenack
** Description changed:

  [Impact]
  rpc-gssd can hang or crash when a kerberos nfsv4 mount point is accessed by 
multiple users simultaneously. The problem happens because the daemon uses the 
strtok() function which is not thread safe.
  
  The fix from upstream removes strtok() and uses strsep() instead. These
  patches are already applied in focal and later, via merges from debian.
  
  [Test Plan]
  As with all race conditions, this test case may take a while to reproduce the 
problem.
  
- # Create a bionic VM. Login and get its ip, and take note of it:
+ # Create a bionic VM. It seems to help if it's created with multiple 
cpus/cores. I had more success with 4 cores and 1GiB of RAM.
+ # Login and get its ip, and take note of it:
  export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
  echo $IP
  
  # adjust /etc/hosts:
  echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
  
  # adjust /etc/resolv.conf:
  echo "search example.com" | sudo tee -a /etc/resolv.conf
  
  # verify hostname -f returns the fqdn of the vm, i.e., a name with the 
.example.com domain:
  hostname -f
  
  # Run these commands, and when asked:
  # - for realm: EXAMPLE.COM
  # - for kdc and admin server: use the vm's IP
  
  sudo apt update && sudo apt install nfs-server krb5-kdc krb5-admin-
  server krb5-user gcc
  
  # create a kerberos realm. When prompted, use any password you want:
  sudo krb5_newrealm
  
  # create an nfs service ticket, and store it in the keytab
  sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"
  sudo kadmin.local -q "ktadd nfs/$(hostname -f)"
  
  # create test directories
  sudo mkdir -p /mnt/test_krb5/
  sudo mkdir -p /export
  sudo touch /export/foo
  
  # adjust nfs config and restart the nfs server:
  sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," 
/etc/default/nfs-kernel-server
  sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common
  sudo systemctl restart nfs-server
  
  # configure an nfs export:
  echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
  sudo exportfs -rva
  
  # confirm it's available
  sudo showmount -e localhost
  
  # mount it
  sudo mount $(hostname -f):/export /mnt/test_krb5/
  sudo ls -la /mnt/test_krb5
  
  # download bug attachments
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496166/+files/stat_as.c
 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads
  chmod +x bz1419280_test_threads
  
  # build reproducer
  gcc stat_as.c -o stat_as
  
  # run test script as root. It may take a few minutes to trigger the bug
  sudo ./bz1419280_test_threads
  
  # wait
  # Once you get the confirmation:
  calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035
  reproduced the bug after 114 iterations
  
  # Check for a "stat_as" D state process:
  $ ps axw|grep stat_as
  17814 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
  
  # To restore functionality, restart rpc-gssd:
  sudo systemctl restart rpc-gssd.service
  
  With the updated packages, the script will not detect the bug and never
  stop.
  
  [Where problems could occur]
  NFS v4 services are more complex than earlier versions, and are comprised of 
several services/daemons. It's possible for the restart done after the 
automatic package upgrade to show up as a regression due to several factors:
  - not all needed services were restarted (bug, but not introduced by this 
change)
  - depending on mount options, client mount points may appear as hung and take 
a while to recover
  - configuration errors on the server which were up until now not noticed, and 
only manifest themselves after a restart
  - some sites, due to the lack of configuration options in /etc/default/nfs-*, 
might have overriden systemd service files and hardcoded other command line 
options there. If not done properly (i.e., not done in /etc/systemd via 
overrides), these local changes will be lost after the package upgrade. I know 
of at least rpc-gssd, which has no command-line options available in 
/etc/default/nfs-*, and I know of users who have tweaked this service in many 
different ways to add things like -v or -n to its command line option.
  
  [Other Info]
  The upstream patches have been applied since February 2017 and have not been 
changed or reverted. They are also applied in Debian and Fedora, and ubuntu 
since focal at least.
  
  There is an additional patch, but part of the fix, which dupes the
  string for appropriate logging. Its memory is also freed.
  
  It may be hard to reproduce this bug in a test environment. I've gotten
  to the error in as little as a few seconds, but other times it took
  hundreds of attempts. YMMV.
  
  [Original Description]
  
  Fixed in focal and later, due to sync from debian
  
  Bionic affected.
  
  I'll add a proper description in a moment.
  
  RH: 

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-10 Thread Andreas Hasenack
** Description changed:

  [Impact]
  rpc-gssd can hang or crash when a kerberos nfsv4 mount point is accessed by 
multiple users simultaneously. The problem happens because the daemon uses the 
strtok() function which is not thread safe.
  
  The fix from upstream removes strtok() and uses strsep() instead. These
  patches are already applied in focal and later, via merges from debian.
  
  [Test Plan]
  As with all race conditions, this test case may take a while to reproduce the 
problem.
  
  # Create a bionic VM. Login and get its ip, and take note of it:
  export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
  echo $IP
  
  # adjust /etc/hosts:
  echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
  
  # adjust /etc/resolv.conf:
  echo "search example.com" | sudo tee -a /etc/resolv.conf
  
  # verify hostname -f returns the fqdn of the vm, i.e., a name with the 
.example.com domain:
  hostname -f
  
  # Run these commands, and when asked:
  # - for realm: EXAMPLE.COM
  # - for kdc and admin server: use the vm's IP
  
  sudo apt update && sudo apt install nfs-server krb5-kdc krb5-admin-
  server krb5-user gcc
  
  # create a kerberos realm. When prompted, use any password you want:
  sudo krb5_newrealm
  
  # create an nfs service ticket, and store it in the keytab
  sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"
  sudo kadmin.local -q "ktadd nfs/$(hostname -f)"
  
  # create test directories
  sudo mkdir -p /mnt/test_krb5/
  sudo mkdir -p /export
  sudo touch /export/foo
  
  # adjust nfs config and restart the nfs server:
  sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," 
/etc/default/nfs-kernel-server
  sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common
  sudo systemctl restart nfs-server
  
  # configure an nfs export:
  echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
  sudo exportfs -rva
  
  # confirm it's available
  sudo showmount -e localhost
  
  # mount it
  sudo mount $(hostname -f):/export /mnt/test_krb5/
  sudo ls -la /mnt/test_krb5
  
  # download bug attachments
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496166/+files/stat_as.c
 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads
  chmod +x bz1419280_test_threads
  
  # build reproducer
  gcc stat_as.c -o stat_as
  
  # run test script as root. It may take a few minutes to trigger the bug
  sudo ./bz1419280_test_threads
  
  # wait
  # Once you get the confirmation:
  calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035
  reproduced the bug after 114 iterations
  
  # Check for a "stat_as" D state process:
  $ ps axw|grep stat_as
  17814 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
  
  # To restore functionality, restart rpc-gssd:
  sudo systemctl restart rpc-gssd.service
  
  With the updated packages, the script will not detect the bug and never
  stop.
  
  [Where problems could occur]
- 
-  * Think about what the upload changes in the software. Imagine the change is
-    wrong or breaks something else: how would this show up?
- 
-  * It is assumed that any SRU candidate patch is well-tested before
-    upload and has a low overall risk of regression, but it's important
-    to make the effort to think about what ''could'' happen in the
-    event of a regression.
- 
-  * This must '''never''' be "None" or "Low", or entirely an argument as to why
-    your upload is low risk.
- 
-  * This both shows the SRU team that the risks have been considered,
-    and provides guidance to testers in regression-testing the SRU.
+ NFS v4 services are more complex than earlier versions, and are comprised of 
several services/daemons. It's possible for the restart done after the 
automatic package upgrade to show up as a regression due to several factors:
+ - not all needed services were restarted (bug, but not introduced by this 
change)
+ - depending on mount options, client mount points may appear as hung and take 
a while to recover
+ - configuration errors on the server which were up until now not noticed, and 
only manifest themselves after a restart
+ - some sites, due to the lack of configuration options in /etc/default/nfs-*, 
might have overriden systemd service files and hardcoded other command line 
options there. If not done properly (i.e., not done in /etc/systemd via 
overrides), these local changes will be lost after the package upgrade
  
  [Other Info]
+ The upstream patches have been applied since February 2017 and have not been 
changed or reverted. They are also applied in Debian and Fedora, and ubuntu 
since focal at least.
  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
-  * and address these questions in advance
+ There is an additional patch, but part of the fix, which dupes 

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-10 Thread Andreas Hasenack
** Description changed:

  [Impact]
- rpc-gssd can hang or crash when a kerberos nfsv4 mount point is accessed by 
multiple users simultaneously. This is caused because the daemon uses the 
strtok() function which is not thread safe.
+ rpc-gssd can hang or crash when a kerberos nfsv4 mount point is accessed by 
multiple users simultaneously. The problem happens because the daemon uses the 
strtok() function which is not thread safe.
  
  The fix from upstream removes strtok() and uses strsep() instead. These
  patches are already applied in focal and later, via merges from debian.
  
  [Test Plan]
  # Create a bionic VM. Login and get its ip, and take note of it:
  export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
  echo $IP
  
  # adjust /etc/hosts:
  echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
  
  # adjust /etc/resolv.conf:
  echo "search example.com" | sudo tee -a /etc/resolv.conf
  
  # verify hostname -f returns the fqdn of the vm, i.e., a name with the 
.example.com domain:
  hostname -f
  
  # Run these commands, and when asked:
  # - for realm: EXAMPLE.COM
  # - for kdc and admin server: use the vm's IP
  
  sudo apt update && sudo apt install nfs-server krb5-kdc krb5-admin-
  server krb5-user gcc
  
  # create a kerberos realm. When prompted, use any password you want:
  sudo krb5_newrealm
  
  # create an nfs service ticket, and store it in the keytab
  sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"
  sudo kadmin.local -q "ktadd nfs/$(hostname -f)"
  
  # create test directories
  sudo mkdir -p /mnt/test_krb5/
  sudo mkdir -p /export
  sudo touch /export/foo
  
  # adjust nfs config and restart the nfs server:
  sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," 
/etc/default/nfs-kernel-server
  sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common
  sudo systemctl restart nfs-server
  
  # configure an nfs export:
  echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
  sudo exportfs -rva
  
  # confirm it's available
  sudo showmount -e localhost
  
  # mount it
  sudo mount $(hostname -f):/export /mnt/test_krb5/
  sudo ls -la /mnt/test_krb5
  
  # download bug attachments
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496166/+files/stat_as.c
 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads
  chmod +x bz1419280_test_threads
  
  # build reproducer
  gcc stat_as.c -o stat_as
  
  # run test script as root. It may take a few minutes to trigger the bug
  sudo ./bz1419280_test_threads
  
  # wait
  # Once you get the confirmation:
  calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035
  reproduced the bug after 114 iterations
  
  # Check for a "stat_as" D state process:
  $ ps axw|grep stat_as
  17814 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
  
- # With the updated packages, the script will not detect the bug and
- never stop.
+ # To restore functionality, restart rpc-gssd:
+ sudo systemctl restart rpc-gssd.service
+ 
+ 
+ With the updated packages, the script will not detect the bug and never stop.
  
  [Where problems could occur]
  
   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [Other Info]
  
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance
  
  [Original Description]
  
  Fixed in focal and later, due to sync from debian
  
  Bionic affected.
  
  I'll add a proper description in a moment.
  
  RH: https://bugzilla.redhat.com/show_bug.cgi?id=1419280
  Debian BTS: https://bugs.debian.org/895381
  ML: http://www.spinics.net/lists/linux-nfs/msg62111.html
  ML: http://www.spinics.net/lists/linux-nfs/msg62099.html

** Description changed:

  [Impact]
  rpc-gssd can hang or crash when a kerberos nfsv4 mount point is accessed by 
multiple users simultaneously. The problem happens because the daemon uses the 
strtok() function which is not thread safe.
  
  The fix from upstream removes strtok() and uses strsep() instead. These
  patches are already applied in focal and later, via merges from debian.
  
  [Test Plan]
+ As with all race conditions, this test case may take a while to reproduce the 
problem.
+ 
  # Create a 

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-10 Thread Andreas Hasenack
** Description changed:

  [Impact]
+ rpc-gssd can hang or crash when a kerberos nfsv4 mount point is accessed by 
multiple users simultaneously. This is caused because the daemon uses the 
strtok() function which is not thread safe.
  
-  * An explanation of the effects of the bug on users and
- 
-  * justification for backporting the fix to the stable release.
- 
-  * In addition, it is helpful, but not required, to include an
-    explanation of how the upload fixes this bug.
+ The fix from upstream removes strtok() and uses strsep() instead. These
+ patches are already applied in focal and later, via merges from debian.
  
  [Test Plan]
  # Create a bionic VM. Login and get its ip, and take note of it:
  export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
  echo $IP
  
  # adjust /etc/hosts:
  echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
  
  # adjust /etc/resolv.conf:
  echo "search example.com" | sudo tee -a /etc/resolv.conf
  
  # verify hostname -f returns the fqdn of the vm, i.e., a name with the 
.example.com domain:
  hostname -f
  
  # Run these commands, and when asked:
  # - for realm: EXAMPLE.COM
  # - for kdc and admin server: use the vm's IP
  
  sudo apt update && sudo apt install nfs-server krb5-kdc krb5-admin-
  server krb5-user gcc
  
  # create a kerberos realm. When prompted, use any password you want:
  sudo krb5_newrealm
  
  # create an nfs service ticket, and store it in the keytab
  sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"
  sudo kadmin.local -q "ktadd nfs/$(hostname -f)"
  
  # create test directories
  sudo mkdir -p /mnt/test_krb5/
  sudo mkdir -p /export
  sudo touch /export/foo
  
  # adjust nfs config and restart the nfs server:
  sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," 
/etc/default/nfs-kernel-server
  sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common
  sudo systemctl restart nfs-server
  
  # configure an nfs export:
  echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
  sudo exportfs -rva
  
  # confirm it's available
  sudo showmount -e localhost
  
  # mount it
  sudo mount $(hostname -f):/export /mnt/test_krb5/
  sudo ls -la /mnt/test_krb5
  
  # download bug attachments
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496166/+files/stat_as.c
 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads
  chmod +x bz1419280_test_threads
  
  # build reproducer
  gcc stat_as.c -o stat_as
  
  # run test script as root. It may take a few minutes to trigger the bug
  sudo ./bz1419280_test_threads
  
  # wait
  # Once you get the confirmation:
  calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035
  reproduced the bug after 114 iterations
  
  # Check for a "stat_as" D state process:
  $ ps axw|grep stat_as
  17814 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
  
  # With the updated packages, the script will not detect the bug and
  never stop.
  
  [Where problems could occur]
  
   * Think about what the upload changes in the software. Imagine the change is
     wrong or breaks something else: how would this show up?
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This must '''never''' be "None" or "Low", or entirely an argument as to why
     your upload is low risk.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [Other Info]
  
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance
  
  [Original Description]
  
  Fixed in focal and later, due to sync from debian
  
  Bionic affected.
  
  I'll add a proper description in a moment.
  
  RH: https://bugzilla.redhat.com/show_bug.cgi?id=1419280
  Debian BTS: https://bugs.debian.org/895381
  ML: http://www.spinics.net/lists/linux-nfs/msg62111.html
  ML: http://www.spinics.net/lists/linux-nfs/msg62099.html

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927745

Title:
  Non-thread-safe functions used in multi-threaded rpc.gssd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-10 Thread Andreas Hasenack
Reproducer script from RH bug

** Attachment added: "bz1419280_test_threads"
   
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads

** Description changed:

  [Impact]
  
   * An explanation of the effects of the bug on users and
  
   * justification for backporting the fix to the stable release.
  
   * In addition, it is helpful, but not required, to include an
     explanation of how the upload fixes this bug.
  
  [Test Plan]
  # Create a bionic VM. Login and get its ip, and take note of it:
  export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
  echo $IP
  
  # adjust /etc/hosts:
- echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts   
  
+ echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
  
  # adjust /etc/resolv.conf:
- echo "search example.com" | sudo tee -a /etc/resolv.conf  
  
+ echo "search example.com" | sudo tee -a /etc/resolv.conf
  
  # verify hostname -f returns the fqdn of the vm, i.e., a name with the 
.example.com domain:
  hostname -f
  
  # Run these commands, and when asked:
  # - for realm: EXAMPLE.COM
  # - for kdc and admin server: use the vm's IP
  
  sudo apt update && apt install nfs-server krb5-kdc krb5-admin-server
  krb5-user gcc
  
- 
  # adjust nfs config and restart the nfs server:
  sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," 
/etc/default/nfs-kernel-server
- sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common 
- sudo systemctl restart nfs-server 
  
- 
+ sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common
+ sudo systemctl restart nfs-server
  
  # create a kerberos realm. When prompted, use any password you want:
- sudo krb5_newrealm
  
+ sudo krb5_newrealm
  
  # create an nfs service ticket, and store it in the keytab
- sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"   
  
- sudo kadmin.local -q "ktadd nfs/$(hostname -f)"   
  
- 
+ sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"
+ sudo kadmin.local -q "ktadd nfs/$(hostname -f)"
  
  # create test directories
- sudo mkdir -p /mnt/test_krb5/ 
  
- sudo mkdir -p /export 
  
+ sudo mkdir -p /mnt/test_krb5/
+ sudo mkdir -p /export
  sudo touch /export/foo
  
  # configure an nfs export:
- echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a 
/etc/exports  
- sudo exportfs -rva
  
+ echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
+ sudo exportfs -rva
  
  # confirm it's available
- sudo showmount -e localhost   
   
- 
+ sudo showmount -e localhost
  
  # mount it
- sudo mount $(hostname -f):/export /mnt/test_krb5/ 
  
+ sudo mount $(hostname -f):/export /mnt/test_krb5/
  sudo ls -la /mnt/test_krb5
  
- 
  # download bug attachments
- (TBD)
+ wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496166/+files/stat_as.c
 
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads
+ chmod +x bz1419280_test_threads
  
  # build reproducer
- gcc stat_as.c -o stat_as  
  
+ gcc stat_as.c -o stat_as
  
- # run as root 
  
- sudo ./bz1419280_test_threads 
  
-   
  
- # wait
  
- # Once you get the confirmation:  
  
- calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035 
  
- reproduced the bug after 114 iterations   
  
-   
  
- # Check for a "stat_as" D state process:  
  
- $ ps axw|grep stat_as 
  
- 17814 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
  
-   
  
- # With the updated packages, the script will not detect the bug and never 
stop.
+ # run as root
+ sudo ./bz1419280_test_threads
  
+ # wait
+ # Once you get the confirmation:
+ calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035
+ reproduced the bug after 114 iterations
+ 
+ # Check for a "stat_as" D state process:
+ $ ps 

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-10 Thread Andreas Hasenack
Reproducer tool from RH bug

** Description changed:

  [Impact]
  
-  * An explanation of the effects of the bug on users and
+  * An explanation of the effects of the bug on users and
  
-  * justification for backporting the fix to the stable release.
+  * justification for backporting the fix to the stable release.
  
-  * In addition, it is helpful, but not required, to include an
-explanation of how the upload fixes this bug.
+  * In addition, it is helpful, but not required, to include an
+    explanation of how the upload fixes this bug.
  
  [Test Plan]
+ # Create a bionic VM. Login and get its ip, and take note of it:
+ export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
+ echo $IP
  
-  * detailed instructions how to reproduce the bug
+ # adjust /etc/hosts:
+ echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts   
  
  
-  * these should allow someone who is not familiar with the affected
-package to reproduce the bug and verify that the updated package fixes
-the problem.
+ # adjust /etc/resolv.conf:
+ echo "search example.com" | sudo tee -a /etc/resolv.conf  
  
  
-  * if other testing is appropriate to perform before landing this update,
-this should also be described here.
+ # verify hostname -f returns the fqdn of the vm, i.e., a name with the 
.example.com domain:
+ hostname -f
+ 
+ # Run these commands, and when asked:
+ # - for realm: EXAMPLE.COM
+ # - for kdc and admin server: use the vm's IP
+ 
+ sudo apt update && apt install nfs-server krb5-kdc krb5-admin-server
+ krb5-user gcc
+ 
+ 
+ # adjust nfs config and restart the nfs server:
+ sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," 
/etc/default/nfs-kernel-server
+ sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common 
+ sudo systemctl restart nfs-server 
  
+ 
+ 
+ # create a kerberos realm. When prompted, use any password you want:
+ sudo krb5_newrealm
  
+ 
+ # create an nfs service ticket, and store it in the keytab
+ sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"   
  
+ sudo kadmin.local -q "ktadd nfs/$(hostname -f)"   
  
+ 
+ 
+ # create test directories
+ sudo mkdir -p /mnt/test_krb5/ 
  
+ sudo mkdir -p /export 
  
+ sudo touch /export/foo
+ 
+ # configure an nfs export:
+ echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a 
/etc/exports  
+ sudo exportfs -rva
  
+ 
+ # confirm it's available
+ sudo showmount -e localhost   
   
+ 
+ 
+ # mount it
+ sudo mount $(hostname -f):/export /mnt/test_krb5/ 
  
+ sudo ls -la /mnt/test_krb5
+ 
+ 
+ # download bug attachments
+ (TBD)
+ 
+ # build reproducer
+ gcc stat_as.c -o stat_as  
  
+ 
+ # run as root 
  
+ sudo ./bz1419280_test_threads 
  
+   
  
+ # wait
  
+ # Once you get the confirmation:  
  
+ calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035 
  
+ reproduced the bug after 114 iterations   
  
+   
  
+ # Check for a "stat_as" D state process:  
  
+ $ ps axw|grep stat_as 
  
+ 17814 pts/1D  0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
  
+   
  
+ # With the updated packages, the script will not detect the bug and never 
stop.
+ 
  
  [Where problems could occur]
  
-  * Think about what the upload changes in the software. Imagine the change is
-wrong or breaks something else: how would this show up?
+  * Think about what the upload changes in the software. Imagine the change is
+    wrong or breaks something else: how would this show up?
  
-  * It is assumed that any SRU candidate patch is well-tested before
-upload and has a low overall risk of regression, but it's important
-to make the effort to think about what ''could'' happen in the
-event of a regression.
+  * It is assumed that any SRU candidate patch is well-tested before
+    upload and has a low overall risk of regression, but it's important
+    to make the effort to think about what 

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-10 Thread Andreas Hasenack
** Description changed:

+ [Impact]
+ 
+  * An explanation of the effects of the bug on users and
+ 
+  * justification for backporting the fix to the stable release.
+ 
+  * In addition, it is helpful, but not required, to include an
+explanation of how the upload fixes this bug.
+ 
+ [Test Plan]
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+package to reproduce the bug and verify that the updated package fixes
+the problem.
+ 
+  * if other testing is appropriate to perform before landing this update,
+this should also be described here.
+ 
+ [Where problems could occur]
+ 
+  * Think about what the upload changes in the software. Imagine the change is
+wrong or breaks something else: how would this show up?
+ 
+  * It is assumed that any SRU candidate patch is well-tested before
+upload and has a low overall risk of regression, but it's important
+to make the effort to think about what ''could'' happen in the
+event of a regression.
+ 
+  * This must '''never''' be "None" or "Low", or entirely an argument as to why
+your upload is low risk.
+ 
+  * This both shows the SRU team that the risks have been considered,
+and provides guidance to testers in regression-testing the SRU.
+ 
+ [Other Info]
+  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
+  * and address these questions in advance
+ 
+ [Original Description]
+ 
  Fixed in focal and later, due to sync from debian
  
  Bionic affected.
  
  I'll add a proper description in a moment.
  
  RH: https://bugzilla.redhat.com/show_bug.cgi?id=1419280
  Debian BTS: https://bugs.debian.org/895381
  ML: http://www.spinics.net/lists/linux-nfs/msg62111.html
  ML: http://www.spinics.net/lists/linux-nfs/msg62099.html

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927745

Title:
  Non-thread-safe functions used in multi-threaded rpc.gssd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-07 Thread Andreas Hasenack
** Bug watch added: Debian Bug tracker #895381
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895381

** Also affects: nfs-utils (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895381
   Importance: Unknown
   Status: Unknown

** Bug watch added: Red Hat Bugzilla #1419280
   https://bugzilla.redhat.com/show_bug.cgi?id=1419280

** Also affects: nfs-utils (Fedora) via
   https://bugzilla.redhat.com/show_bug.cgi?id=1419280
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927745

Title:
  Non-thread-safe functions used in multi-threaded rpc.gssd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1927745] [NEW] Non-thread-safe functions used in multi-threaded rpc.gssd

2021-05-07 Thread Andreas Hasenack
Public bug reported:

Fixed in focal and later, due to sync from debian

Bionic affected.

I'll add a proper description in a moment.

RH: https://bugzilla.redhat.com/show_bug.cgi?id=1419280
Debian BTS: https://bugs.debian.org/895381
ML: http://www.spinics.net/lists/linux-nfs/msg62111.html
ML: http://www.spinics.net/lists/linux-nfs/msg62099.html

** Affects: nfs-utils (Ubuntu)
 Importance: High
 Assignee: Andreas Hasenack (ahasenack)
 Status: Fix Released

** Affects: nfs-utils (Ubuntu Bionic)
 Importance: High
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Also affects: nfs-utils (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: nfs-utils (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: nfs-utils (Ubuntu Bionic)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: nfs-utils (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: nfs-utils (Ubuntu)
   Importance: Undecided => High

** Changed in: nfs-utils (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927745

Title:
  Non-thread-safe functions used in multi-threaded rpc.gssd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1913810] Re: restart doesn't test for syntax errors

2021-05-03 Thread Andreas Hasenack
yeah, it's specifically restart that we want to check

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1913810

Title:
  restart doesn't test for syntax errors

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1925064] Re: shim(-signed)? does not boot on T420

2021-04-20 Thread Andreas Hasenack
I'm getting a list of packages that I have now, and then I will try a
dist-upgrade to hirsute, and see if it breaks again, then we can compare
the set.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925064

Title:
   shim(-signed)? does not boot on T420

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1925064] Re: shim(-signed)? does not boot on T420

2021-04-20 Thread Andreas Hasenack
I then reinstalled all *grub* and *shim* packages from groovy, and the
laptop reboots fine.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925064

Title:
   shim(-signed)? does not boot on T420

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1925064] Re: shim(-signed)? does not boot on T420

2021-04-20 Thread Andreas Hasenack
I downgraded to the shim* packages from groovy, like this:
oot@nsn7:/var/cache/apt/archives# l
total 1,1M
drwxr-xr-x 3 root root 140K abr 19 17:16 .
drwxr-xr-x 3 root root 4,0K abr 19 17:15 ..
-rw-r- 1 root root0 out 15  2020 lock
drwx-- 2 _apt root 4,0K abr 19 17:16 partial
-rw-r--r-- 1 root root 566K ago  3  2020 
shim_15+1552672080.a4a1fbe-0ubuntu2_amd64.deb
-rw-r--r-- 1 root root 338K out 21 06:18 
shim-signed_1.45+15+1552672080.a4a1fbe-0ubuntu2_amd64.deb
root@nsn7:/var/cache/apt/archives# scp shim* ~/
root@nsn7:/var/cache/apt/archives# cd
root@nsn7:~# dpkg -i shim*
dpkg: warning: downgrading shim from 15.4-0ubuntu1 to 
15+1552672080.a4a1fbe-0ubuntu2
(Reading database ... 228150 files and directories currently installed.)
Preparing to unpack shim_15+1552672080.a4a1fbe-0ubuntu2_amd64.deb ...
Unpacking shim (15+1552672080.a4a1fbe-0ubuntu2) over (15.4-0ubuntu1) ...
Replaced by files in installed package shim-signed (1.46+15.4-0ubuntu1) ...
dpkg: warning: downgrading shim-signed from 1.46+15.4-0ubuntu1 to 
1.45+15+1552672080.a4a1fbe-0ubuntu2
Preparing to unpack shim-signed_1.45+15+1552672080.a4a1fbe-0ubuntu2_amd64.deb 
...
Unpacking shim-signed (1.45+15+1552672080.a4a1fbe-0ubuntu2) over 
(1.46+15.4-0ubuntu1) ...
Setting up shim (15+1552672080.a4a1fbe-0ubuntu2) ...
Setting up shim-signed (1.45+15+1552672080.a4a1fbe-0ubuntu2) ...
Installing grub to /boot/efi.
Installing for x86_64-efi platform.
Installation finished. No error reported.

And then rebooted. It failed the same way, so it seems to indicate it's
not a problem with the shim, as these packages I had installed just
before doing the do-release-upgrade.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925064

Title:
   shim(-signed)? does not boot on T420

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1925064] [NEW] shim(-signed)? does not boot on T420

2021-04-19 Thread Andreas Hasenack
Public bug reported:

Almost identical to bug #1925010, but the T420 is an UEFI v2.00 machine,
so I'm filing this separate bug.

This is a T420 in uefi mode, but not secure boot. I was running groovy,
and just upgraded to hirsute with do-release-upgrade -d. It just
wouldn't boot from the disk anymore after that. Black screen, no disk
activity, no ctrl-alt-del response. I always had to power cycle it.

I then performed the steps from comment 2 of that bug, and the machine booted 
normally after that:
"""
Can you please check that the machine boots with just grub without shim.

Aka, replace /EFI/Boot/BOOTX64.efi & /ef/ubuntu/shimx64.efi files wtih 
/efi/ubuntu/grubx64.efi => this could possibly be a workaround, given that 
secureboot is not possible on Mac platforms.
"""


My BIOS version is 1.49 (83ET79WW), model is 4177CTO. I can attach more info if 
needed, and it's also simple to restore the buggy behavior.

dmesg says "efi: EFI v2.00 by Lenovo"

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925064

Title:
   shim(-signed)? does not boot on T420

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1925010] Re: shim-signed does not boot on MBA 5,2; T420

2021-04-19 Thread Andreas Hasenack
I moved the T420 issue to
https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1925064

** Summary changed:

- shim-signed does not boot on MBA 5,2; T420
+ shim-signed does not boot on MBA 5,2

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925010

Title:
  shim-signed does not boot on MBA 5,2

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1925010] Re: shim-signed does not boot on MBA 5,2; T420

2021-04-19 Thread Andreas Hasenack
** Summary changed:

- shim-signed does not boot on MBA 5,2
+ shim-signed does not boot on MBA 5,2; T420

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925010

Title:
  shim-signed does not boot on MBA 5,2; T420

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1925010] Re: shim-signed does not boot on MBA 5,2

2021-04-19 Thread Andreas Hasenack
More details, it's a T420 in uefi mode, but not secure boot. I was
running groovy, and just upgraded to hirsute with do-release-upgrade -d.
It just wouldn't boot from the disk anymore after that. Black screen, no
disk activity, no ctrl-alt-del response. I always had to power cycle it.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925010

Title:
  shim-signed does not boot on MBA 5,2

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1925010] Re: shim-signed does not boot on MBA 5,2

2021-04-19 Thread Andreas Hasenack
Comment #2 also fixed this issue for my T420 laptop.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1925010

Title:
  shim-signed does not boot on MBA 5,2

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1924793] [NEW] groovy to hirsute on arm64: KeyError: 'ubuntu-desktop-rapsi'

2021-04-16 Thread Andreas Hasenack
Public bug reported:

I did a release-upgrade from groovy to hirsute on my groovy pi4, and got
this backtrace:

(...)
KeyError: "The cache has no package named 'ubuntu-desktop-rapsi'"
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/problem_report.py", line 477, in 
add_to_existing
self.write(f)
  File "/usr/lib/python3/dist-packages/problem_report.py", line 430, in write
block = f.read(1048576)
  File "/usr/lib/python3.8/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid 
start byte

Original exception was:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 281, in __getitem__
rawpkg = self._cache[key]
KeyError: 'ubuntu-desktop-rapsi'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/ubuntu-release-upgrader-42aqo0hw/hirsute", line 8, in 
sys.exit(main())
  File "/tmp/ubuntu-release-upgrader-42aqo0hw/DistUpgrade/DistUpgradeMain.py", 
line 236, in main
if app.run():
  File 
"/tmp/ubuntu-release-upgrader-42aqo0hw/DistUpgrade/DistUpgradeController.py", 
line 2024, in run
return self.fullUpgrade()
  File 
"/tmp/ubuntu-release-upgrader-42aqo0hw/DistUpgrade/DistUpgradeController.py", 
line 2005, in fullUpgrade
self.doPostUpgrade()
  File 
"/tmp/ubuntu-release-upgrader-42aqo0hw/DistUpgrade/DistUpgradeController.py", 
line 1395, in doPostUpgrade
self.quirks.run("PostUpgrade")
  File 
"/tmp/ubuntu-release-upgrader-42aqo0hw/DistUpgrade/DistUpgradeQuirks.py", line 
99, in run
func()
  File 
"/tmp/ubuntu-release-upgrader-42aqo0hw/DistUpgrade/DistUpgradeQuirks.py", line 
146, in hirsutePostUpgrade
if cache['ubuntu-desktop-rapsi'].is_installed:
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 283, in __getitem__
raise KeyError('The cache has no package named %r' % key)
KeyError: "The cache has no package named 'ubuntu-desktop-rapsi'"

** Affects: ubuntu-release-upgrader (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1924793

Title:
  groovy to hirsute on arm64: KeyError: 'ubuntu-desktop-rapsi'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1924793/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 388605] Re: [MIR] rsyslog

2021-03-30 Thread Andreas Hasenack
Actually, Christian didn't explicitly ack the stable releases in that
comment (but he did in the MPs I raised for the seed changes). I'll ask
him tomorrow to flip the statuses.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/388605

Title:
  [MIR] rsyslog

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 388605] Re: [MIR] rsyslog

2021-03-30 Thread Andreas Hasenack
Given Christian's comments in comment #6, and the fact that the seed
changes were done, I'm going to mark the tasks for the stable releases
as "fix committed"

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/388605

Title:
  [MIR] rsyslog

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 388605] Re: [MIR] rsyslog

2021-03-25 Thread Andreas Hasenack
Meeting minutes: https://new.ubottu.com/meetingology/logs/ubuntu-
meeting/2021/ubuntu-meeting.2021-03-25-15.00.moin.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/388605

Title:
  [MIR] rsyslog

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 388605] Re: [MIR] rsyslog

2021-03-25 Thread Andreas Hasenack
I'll provide MPs for bionic, focal and groovy to change the seeds to
pull rsyslog-gnutls into main, as discussed in #ubuntu-meeting with
Foundations today, and then ping an archive admin.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/388605

Title:
  [MIR] rsyslog

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 388605] Re: [MIR] rsyslog

2021-03-23 Thread Andreas Hasenack
We would like to retroactively promote rsyslog-gnutls, a binary package
built from src:rsyslog (subject of this completed MIR), into main.

rsyslog-gnutls provides a gnutls plugin which allows rsyslog to encrypt
the data it sends to log servers. We believe this is a common scenario,
and very much needed for compliance nowadays, and this package should be
in main because of that.

rsyslog-gnutls was already part of this MIR, but was left in universe
because nothing pulled it into main (dependency or seed change).

I didn't see any comments here in the bug, or in the MIR report
(https://wiki.ubuntu.com/MainInclusionReport/rsyslog), that would be
specific about rsyslog-gnutls and why it should not be promoted. There
was just a list of dependencies, and they were ok for main inclusion,
and remain so to this date:

bionic: 8.32.0-1ubuntu4
Depends: libc6 (>= 2.14), libgnutls30 (>= 3.5.6), rsyslog (= 8.32.0-1ubuntu4)
Suggests: gnutls-bin

Depends are all in main, and Suggests is in universe, which is ok.


focal: 8.2001.0-1ubuntu1.1
Depends: libc6 (>= 2.14), libgnutls30 (>= 3.6.12), rsyslog (= 
8.2001.0-1ubuntu1.1)
Suggests: gnutls-bin

Same deps.


groovy: 8.2006.0-2ubuntu1
Depends: libc6 (>= 2.14), libgnutls30 (>= 3.6.12), rsyslog (= 8.2006.0-2ubuntu1)
Suggests: gnutls-bin

Same deps.


Hirsute: 8.2102.0-2ubuntu1
Depends: libc6 (>= 2.33), libgnutls30 (>= 3.7.0), rsyslog (= 8.2102.0-2ubuntu1)
Suggests: gnutls-bin

Same deps.


List of rsyslog CVEs in the Ubuntu CVE tracker: 
https://ubuntu.com/security/cve?q==rsyslog===
None are related to encryption support.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/388605

Title:
  [MIR] rsyslog

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 388605] Re: [MIR] rsyslog

2021-03-23 Thread Andreas Hasenack
** Also affects: rsyslog (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: rsyslog (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: rsyslog (Ubuntu Hirsute)
   Importance: Undecided
 Assignee: Kees Cook (kees)
   Status: Fix Released

** Also affects: rsyslog (Ubuntu Focal)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/388605

Title:
  [MIR] rsyslog

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1913187] Re: iproute2 segfaults when filtering sockets

2021-02-25 Thread Andreas Hasenack
postgresql-common amd64 and i386: passed after a retry
ubuntu-fan: see previous comment, known flaky test, and analysis of the test 
output shows that the test actually passed. I retried both amd64 and s390x, but 
I ask the SRU team to consider those runs green if they failed again (update: 
amd64 just passed, s390x still pending results).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1913187

Title:
  iproute2 segfaults when filtering sockets

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1830180] Re: Bionic autopkgtests failing due to stderr output present and not ignored

2021-02-25 Thread Andreas Hasenack
Actuall, the bug was specifically about bionic, so let's adjust the
tasks.

** Also affects: ubuntu-fan (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: ubuntu-fan (Ubuntu Bionic)
   Status: New => Confirmed

** Changed in: ubuntu-fan (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830180

Title:
  Bionic autopkgtests failing due to stderr output present and not
  ignored

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1830180] Re: Bionic autopkgtests failing due to stderr output present and not ignored

2021-02-25 Thread Andreas Hasenack
This was fixed in 0.12.11 by adding allow-stderr to the dep8
restrictions. Last affected ubuntu release is bionic and earlier.
Closing the bug.

** Changed in: ubuntu-fan (Ubuntu)
   Status: New => Fix Released

** Changed in: ubuntu-fan (Ubuntu)
   Status: Fix Released => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830180

Title:
  Bionic autopkgtests failing due to stderr output present and not
  ignored

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1913187] Re: iproute2 segfaults when filtering sockets

2021-02-25 Thread Andreas Hasenack
ubuntu-fan dep8 failures are due to
https://bugs.launchpad.net/ubuntu/+source/ubuntu-fan/+bug/1830180. It
was fixed in focal+, but in bionic it remains flaky. Explanation is in
https://bugs.launchpad.net/ubuntu/+source/ubuntu-
fan/+bug/1830180/comments/1

I'll retry it once or twice, but we can see from the test output that the test 
worked, and the stderr text is just noise that happened because systemd-resolve 
was called too soon:
Starting fanatic-test
lxd test: Waiting for addresses on eth0 ...
lxd test: Waiting for addresses on eth0 ...
lxd test: Waiting for addresses on eth0 ...
lxd test: Waiting for addresses on eth0 ...
lxd test: Waiting for addresses on eth0 ...
slave: detected primary route through eth0
sd_bus_open_system: No such file or directory <-- too soon
slave: waiting for systemd resolver...
slave: DNS: systemd(250.40.8.1) <--- now it worked, and the test continues
...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1913187

Title:
  iproute2 segfaults when filtering sockets

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1830180] Re: Bionic autopkgtests failing due to stderr output present and not ignored

2021-02-25 Thread Andreas Hasenack
This happens because systemd-resolve --status $nic can be called in this loop 
before it's ready to answer:
   while [ $timeout -gt 0 ]; do
dns2=$(systemd-resolve --status $nic1| \
awk '/DNS Servers:/{print; exit}')  
if [ "$dns2" != "" ]; then  
break   
fi  
echo "$role: waiting for systemd resolver..."   
sleep 2 
timeout=$(( timeout - 2 ))  
done

We can see from the logs that in the second loop run (i.e., after 2s), it works 
already, or else it would have printed "$role: waiting for systemd resolver..." 
again:
Starting fanatic-test
lxd test: Waiting for addresses on eth0 ...
lxd test: Waiting for addresses on eth0 ...
lxd test: Waiting for addresses on eth0 ...
lxd test: Waiting for addresses on eth0 ...
lxd test: Waiting for addresses on eth0 ...
slave: detected primary route through eth0
sd_bus_open_system: No such file or directory
slave: waiting for systemd resolver... <- just once, and the first time
slave: DNS: systemd(250.40.8.1)

The fix is to add 2>/dev/null to that systemd-resolve call, or allow for
stderr in the dep8 test.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830180

Title:
  Bionic autopkgtests failing due to stderr output present and not
  ignored

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1913810] [NEW] restart doesn't test for syntax errors

2021-01-29 Thread Andreas Hasenack
Public bug reported:

Tested openssh on bionic and groovy, same issue.

The switch to systemd lost the ability to do a sanity check on the
config file (via sshd -t) before attempting to restart sshd. This was
originally bug #624361 in the SySV days, fixed in the initscript back
then.

The sysv script still does it, but it's not used anymore:
 restart)
check_privsep_dir
check_config
log_daemon_msg "Restarting OpenBSD Secure Shell server" "sshd" || true


And:
check_config() {
if [ ! -e /etc/ssh/sshd_not_to_be_run ]; then
/usr/sbin/sshd $SSHD_OPTS -t || exit 1
fi
}


The systemd service file has only ExecStartPre, which doesn't let it start if 
there is an error, but will happily stop it:
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
...

Example:
# sshd -t   
# systemctl restart sshd
# telnet localhost 22   
Trying 127.0.0.1... 
Connected to localhost. 
Escape character is '^]'.   
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 
^]  
telnet> quit
Connection closed.  

# echo "syntax error" >> /etc/ssh/sshd_config   
# sshd -t   
/etc/ssh/sshd_config: line 123: Bad configuration option: syntax
/etc/ssh/sshd_config: terminating, 1 bad configuration options  

# systemctl restart sshd
Job for ssh.service failed because the control process exited with error code.  
See "systemctl status ssh.service" and "journalctl -xe" for details.

# telnet localhost 22   
Trying 127.0.0.1... 
telnet: Unable to connect to remote host: Connection refused
#

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1913810

Title:
  restart doesn't test for syntax errors

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1913470] Re: sssd also needs `attach_disconnected` in its apparmor profile

2021-01-28 Thread Andreas Hasenack
Something to think about: how common is this use case (of overlayfs),
and if there are other scenarios where the lack of `attach_disconnected`
is troublesome?

We should consider if enabling this option introduces unnecessary
security risks for the supposedly wider audience who is NOT using
overlayfs.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1913470

Title:
  sssd also needs `attach_disconnected` in its apparmor profile

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1899218] Re: Incorrect warning from apparmor_parser on force complained profiles

2021-01-27 Thread Andreas Hasenack
Just saw this in bionic, I guess it's not important enough for an SRU?

# apparmor_parser -r -T -W --Complain /etc/apparmor.d/pam_roles 
/etc/apparmor.d/usr.sbin.sshd
Warning failed to create cache: pam_roles
Warning failed to create cache: usr.sbin.sshd

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899218

Title:
  Incorrect warning from apparmor_parser on force complained profiles

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-25 Thread Andreas Hasenack
TL;DR verification-succeeded

Ok, so here are the details.

I have two vms: one called orig-audit-bionic, the other called sru-
audit-bionic, where I ran the script from comment #23 over the weekend
in multiple scenarios. With auditd-1:2.8.2-1ubuntu1, the bug is
reproduced after a few hours, whereas with 1:2.8.2-1ubuntu1.1 I had it
running over 36h in one case with no failure.

a) orig-audit-bionic
Installed with the original auditd-1:2.8.2-1ubuntu1, I had two runs to verify 
the failure:
a.1) First run
started at Fri Jan 22 19:20:29 UTC 2021
failed at  Fri Jan 22 22:43:51 UTC 2021
Jan 22 22:43:51 orig-audit-bionic systemd[1]: Starting Security Auditing 
Service...
Jan 22 22:43:51 orig-audit-bionic auditd[24058]: Started dispatcher: 
/sbin/audispd pid: 24060
Jan 22 22:43:51 orig-audit-bionic audispd: No plugins found, exiting
Jan 22 22:45:21 orig-audit-bionic systemd[1]: auditd.service: Start operation 
timed out. Terminating.


a.2) Second run, same package
started at Sat Jan 23 14:30:11 UTC 2021
failed at  Sat Jan 23 21:35:20 UTC 2021
Jan 23 21:35:20 orig-audit-bionic systemd[1]: Starting Security Auditing 
Service...
Jan 23 21:35:20 orig-audit-bionic auditd[7794]: Started dispatcher: 
/sbin/audispd pid: 7796
Jan 23 21:35:20 orig-audit-bionic audispd: No plugins found, exiting
Jan 23 21:36:50 orig-audit-bionic systemd[1]: auditd.service: Start operation 
timed out. Terminating.

I then upgraded the auditd package to 1:2.8.2-1ubuntu1.1, and started another 
run:
started at  Sat Jan 23 23:54:35 UTC 2021
manually aborted at Mon Jan 25 12:23:42 UTC 2021
No failure.

b) sru-audit-bionic
Installed the original auditd-1:2.8.2-1ubuntu1, and upgraded it straight away 
to 1:2.8.2-1ubuntu1.1. Then started the script.
started at  Fri Jan 22 19:23:38 UTC 2021
manually aborted at Sun Jan 24 18:53:09 UTC 2021
No failure.

I then downgraded the auditd package back to auditd-1:2.8.2-1ubuntu1 and ran 
the script again.
started at Sun Jan 24 19:00:56 UTC 2021
failed at  Sun Jan 24 23:32:58 UTC 2021
Jan 24 23:32:58 sru-audit-bionic systemd[1]: Starting Security Auditing 
Service...
Jan 24 23:32:58 sru-audit-bionic auditd[11439]: Started dispatcher: 
/sbin/audispd pid: 11441
Jan 24 23:32:58 sru-audit-bionic audispd: No plugins found, exiting
Jan 24 23:34:28 sru-audit-bionic systemd[1]: auditd.service: Start operation 
timed out. Terminating.


Full logs attached as tarballs for, heh, audit purposes :)


** Attachment added: "audit-sru-1848330.tar.xz"
   
https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1848330/+attachment/5456640/+files/audit-sru-1848330.tar.xz

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-23 Thread Andreas Hasenack
I prepared two bionic instances to run over the weekend.

One is running auditd from bionic, and the other is running the SRU
proposed package.

I have auditd being restarted via this script in both (just the email message 
is different, to say which package it was):
#!/bin/bash

result=0

while /bin/true; do
date
sudo systemctl restart auditd || result=$?
if [ "$result" -ne "0" ]; then
echo "FAILED, result=$result"
break
fi
pid=$(pidof auditd) || result=$?
if [ "$result" -ne "0" ]; then
echo "FAILED, auditd not running"
break
fi
echo "auditd pid = $pid"
sleep 2
echo
done
mail -s "ALERT: audit orig test failed" andr...@canonical.com < reaped" isn't shown, which
is exactly the bug: auditd hangs while trying to log that message inside
a signal handler.

So, looking good. Let's see if I can get another failure.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-22 Thread Andreas Hasenack
Dr. Harbott, would you be able to test the new audit packages in bionic-
proposed? The SRU team is reluctant to approve this update without some
sort of confirmation that it fixes the bug, and I haven't been able to
reproduce it myself.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-18 Thread Andreas Hasenack
Since it's difficult to reproduce the bug, what I'm going to do is setup
a system with the previous auditd, setup some rules, confirm they are
working, then upgrade, and confirm it keeps working, also after a
reboot.


# Bionic verification

auditd from bionic:
auditd:
  Installed: 1:2.8.2-1ubuntu1
  Candidate: 1:2.8.2-1ubuntu1
  Version table:
 *** 1:2.8.2-1ubuntu1 500
500 http://br.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Created a simple rule:
#  cat /etc/audit/rules.d/30-shadow.rules 
-w /etc/shadow -p wa -k shadow-changed

Loaded after restart:
# auditctl -l
-w /etc/shadow -p wa -k shadow-changed

Confirmed a change to the file gets logged:
# chmod 0400 /etc/shadow
#

/var/log/audit/auditd.log (parsed with ausearch -i):
type=PROCTITLE msg=audit(01/18/21 17:49:31.077:32) : proctitle=chmod 0400 
/etc/shadow 
type=PATH msg=audit(01/18/21 17:49:31.077:32) : item=0 name=/etc/shadow 
inode=64070 dev=fc:01 mode=file,640 ouid=root ogid=shadow rdev=00:00 
nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=CWD msg=audit(01/18/21 17:49:31.077:32) : cwd=/root 
type=SYSCALL msg=audit(01/18/21 17:49:31.077:32) : arch=x86_64 syscall=fchmodat 
success=yes exit=0 a0=0xff9c a1=0x5577580dc1c0 a2=0400 a3=0x0 items=1 
ppid=1499 pid=1992 auid=ubuntu uid=root gid=root euid=root suid=root fsuid=root 
egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=chmod exe=/bin/chmod 
key=shadow-changed


Now updating the package:
# apt-cache policy auditd
auditd:
  Installed: 1:2.8.2-1ubuntu1.1
  Candidate: 1:2.8.2-1ubuntu1.1
  Version table:
 *** 1:2.8.2-1ubuntu1.1 500
500 http://br.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
 1:2.8.2-1ubuntu1 500
500 http://br.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

(and its deps, like libaudit1, etc).

The same rule continues loaded:
# auditctl -l
-w /etc/shadow -p wa -k shadow-changed

Also after a manual restart:
# systemctl restart auditd
# auditctl -l
-w /etc/shadow -p wa -k shadow-changed

And changing /etc/shadow is logged (let's use 0640 this time):
# chmod 0640 /etc/shadow
#

log:
type=PROCTITLE msg=audit(01/18/21 17:54:51.942:56) : proctitle=chmod 0640 
/etc/shadow 
type=PATH msg=audit(01/18/21 17:54:51.942:56) : item=0 name=/etc/shadow 
inode=64070 dev=fc:01 mode=file,400 ouid=root ogid=shadow rdev=00:00 
nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 
type=CWD msg=audit(01/18/21 17:54:51.942:56) : cwd=/root 
type=SYSCALL msg=audit(01/18/21 17:54:51.942:56) : arch=x86_64 syscall=fchmodat 
success=yes exit=0 a0=0xff9c a1=0x563ae04471c0 a2=0640 a3=0x0 items=1 
ppid=1499 pid=2845 auid=ubuntu uid=root gid=root euid=root suid=root fsuid=root 
egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=chmod exe=/bin/chmod 
key=shadow-changed 


I then rebooted the system, performed the same tests, and got the same results 
with the updated package.

It would be great if people who were affected by this bug, and can
reasonably reproduce it, could test the packages from proposed. In the
meantime, I'll mark this as verification succeeded.


** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-16 Thread Andreas Hasenack
All regressions have been resolved after some retries.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-14 Thread Andreas Hasenack
I'm going over the DEP8 failures

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-11 Thread Andreas Hasenack
Package uploaded to the SRU queue

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-11 Thread Andreas Hasenack
** Description changed:

  [Impact]
  
  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.
  
  Upstream troubleshooted this to be caused by calling a syslog() function
  inside a signal handler.
  
  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.
  
  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd
  
  should work reliably. Do not run that in a tight loop, however, as that
  will trigger a it's-restarting-too-frequently failure.
  
  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.
  
  - it's possible to configure the audit system to panic() the machine if
  audit messages are lost or otherwise not able to be recorded (auditctl
  -f 2; default is 1 which is printk())
  
  - the update restarts auditd as expected. Misconfiguration on very very
  busy systems could mean that audit logs would be lost during the brief
  moment the service is restarted. If that's the case, this update would
  just be one more way to trigger it, but not be the root cause of the
  problem
  
  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but was
  never loaded before. The restart will load the config, and will fail in
  such a case.
  
  - this update removes a logging statement that occurs during startup:
  
  ("dispatcher %d reaped", pid)
  
  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.
  
  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
+ The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.
  
  [Original Description]
  
  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from the
  failure looks like this:
  
  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
  
  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  dpkg: error processing package auditd (--configure):
   installed auditd package post-installation script subprocess returned error 
exit status 1

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

To manage notifications about this bug go to:

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-08 Thread Andreas Hasenack
** Description changed:

  [Impact]
  
-  * An explanation of the effects of the bug on users and
+ Sometimes, auditd will get stuck when starting up, causing systemd to
+ kill it after a while since it (systemd) never got the start
+ notification.
  
-  * justification for backporting the fix to the stable release.
- 
-  * In addition, it is helpful, but not required, to include an
-explanation of how the upload fixes this bug.
+ Upstream troubleshooted this to be caused by calling a syslog() function
+ inside a signal handler.
  
  [Test Case]
+ There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.
  
-  * detailed instructions how to reproduce the bug
+ Basically:
+ sudo systemctl stop auditd
+ sudo systemctl start auditd
  
-  * these should allow someone who is not familiar with the affected
-package to reproduce the bug and verify that the updated package fixes
-the problem.
+ should work reliably. Do not run that in a tight loop, however, as that
+ will trigger a it's-restarting-too-frequently failure.
  
  [Where problems could occur]
+ - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.
  
-  * Think about what the upload changes in the software. Imagine the change is
-wrong or breaks something else: how would this show up?
+ - it's possible to configure the audit system to panic() the machine if
+ audit messages are lost or otherwise not able to be recorded (auditctl
+ -f 2; default is 1 which is printk())
  
-  * It is assumed that any SRU candidate patch is well-tested before
-upload and has a low overall risk of regression, but it's important
-to make the effort to think about what ''could'' happen in the
-event of a regression.
+ - the update restarts auditd as expected. Misconfiguration on very very
+ busy systems could mean that audit logs would be lost during the brief
+ moment the service is restarted. If that's the case, this update would
+ just be one more way to trigger it, but not be the root cause of the
+ problem
  
-  * This must '''never''' be "None" or "Low", or entirely an argument as to why
-your upload is low risk.
+ - this update removes a logging statement that occurs during startup:
  
-  * This both shows the SRU team that the risks have been considered,
-and provides guidance to testers in regression-testing the SRU.
+ ("dispatcher %d reaped", pid)
+ 
+ It's unlikely, but possible, that some monitoring software could be
+ looking for that message in the logs. It won't be there anymore after
+ this update.
+ 
  
  [Other Info]
-  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
-  * and address these questions in advance
+ The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  
  
  [Original Description]
  
- 
- This happens sometimes when installing auditd on Ubuntu 18.04.2, most 
installations work successfully, though. Re-running the install also fixes the 
issue, but the failure breaks our automation. The log from the failure looks 
like this:
+ This happens sometimes when installing auditd on Ubuntu 18.04.2, most
+ installations work successfully, though. Re-running the install also
+ fixes the issue, but the failure breaks our automation. The log from the
+ failure looks like this:
  
  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
  
  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-08 Thread Andreas Hasenack
Yikes @Kodiak, sounds painful :(

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-08 Thread Andreas Hasenack
** Description changed:

- This happens sometimes when installing auditd on Ubuntu 18.04.2, most
- installations work successfully, though. Re-running the install also
- fixes the issue, but the failure breaks our automation. The log from the
- failure looks like this:
+ [Impact]
+ 
+  * An explanation of the effects of the bug on users and
+ 
+  * justification for backporting the fix to the stable release.
+ 
+  * In addition, it is helpful, but not required, to include an
+explanation of how the upload fixes this bug.
+ 
+ [Test Case]
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+package to reproduce the bug and verify that the updated package fixes
+the problem.
+ 
+ [Where problems could occur]
+ 
+  * Think about what the upload changes in the software. Imagine the change is
+wrong or breaks something else: how would this show up?
+ 
+  * It is assumed that any SRU candidate patch is well-tested before
+upload and has a low overall risk of regression, but it's important
+to make the effort to think about what ''could'' happen in the
+event of a regression.
+ 
+  * This must '''never''' be "None" or "Low", or entirely an argument as to why
+your upload is low risk.
+ 
+  * This both shows the SRU team that the risks have been considered,
+and provides guidance to testers in regression-testing the SRU.
+ 
+ [Other Info]
+  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
+  * and address these questions in advance
+ 
+ 
+ [Original Description]
+ 
+ 
+ This happens sometimes when installing auditd on Ubuntu 18.04.2, most 
installations work successfully, though. Re-running the install also fixes the 
issue, but the failure breaks our automation. The log from the failure looks 
like this:
  
  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
-Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
-Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
-  Docs: man:auditd(8)
-https://github.com/linux-audit/audit-documentation
-   Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
+    Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
+    Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
+  Docs: man:auditd(8)
+    https://github.com/linux-audit/audit-documentation
+   Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
  
  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  dpkg: error processing package auditd (--configure):
-  installed auditd package post-installation script subprocess returned error 
exit status 1
+  installed auditd package post-installation script subprocess returned error 
exit status 1

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-08 Thread Andreas Hasenack
I'm having difficulties reproducing the bug, to validate the patch. I
build bionic test packages with the patch mentioned earlier, if someone
wants to test: https://launchpad.net/~ahasenack/+archive/ubuntu/audit-
startup-hang-1848330

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-08 Thread Andreas Hasenack
correct source package name is audit, not auditd (apparently we have/had
both)

** Changed in: auditd (Ubuntu)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Bug watch added: Debian Bug tracker #962451
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962451

** Also affects: audit (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962451
   Importance: Unknown
   Status: Unknown

** Package changed: auditd (Ubuntu) => audit (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-08 Thread Andreas Hasenack
Upstream commit: https://github.com/linux-audit/audit-
userspace/commit/ee6608eca034494fc2597b2990852adec236e486

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-08 Thread Andreas Hasenack
https://bugzilla.redhat.com/show_bug.cgi?id=1587995 is probably relevant

2.8.5 also mentions it in its changelog

** Bug watch added: Red Hat Bugzilla #1587995
   https://bugzilla.redhat.com/show_bug.cgi?id=1587995

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-08 Thread Andreas Hasenack
Kodiak, your log doesn't show a timeout like the one in this bug's
description. You may have a syntax error, as it fails to start
immediately. You should check /var/log/audit/audit.log and
/var/log/syslog for other hints too.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1848330] Re: Installing auditd sometimes fails in post-inst

2021-01-08 Thread Andreas Hasenack
Are you also enabling audit in the kernel command line?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848330

Title:
  Installing auditd sometimes fails in post-inst

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 402892] Re: Mouse cursor gets stuck in "drag and drop" mode

2020-12-30 Thread Andreas Hasenack
Happens very frequently for me on a default ubuntu 20.10 desktop. I
basically have to kill my desktop to fix it, and lose all unsaved work.
It's quite problematic.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/402892

Title:
  Mouse cursor gets stuck in "drag and drop" mode

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1824370] Re: [needs-packaging] wiringpi

2020-12-09 Thread Andreas Hasenack
This package is in ubuntu since focal, closing the bug.


$ rmadison wiringpi
 wiringpi | 2.50-0ubuntu1 | focal/universe   | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
 wiringpi | 2.50-0ubuntu1 | groovy/universe  | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x
 wiringpi | 2.50-0ubuntu1 | hirsute/universe | source, amd64, arm64, armhf, 
ppc64el, riscv64, s390x


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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1824370

Title:
  [needs-packaging] wiringpi

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1907458] [NEW] Update for Pi 4b

2020-12-09 Thread Andreas Hasenack
Public bug reported:

I have a raspberry pi 4 with 4Gb of RAM, and wiring pi doesn't work on
it:

andreas@pi4:~$ sudo gpio readall
Oops - unable to determine board type... model: 17


Looks like we need an updated version: 
http://wiringpi.com/wiringpi-updated-to-2-52-for-the-raspberry-pi-4b/

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1907458

Title:
  Update for Pi 4b

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1905302] [NEW] dpkg -V should consider path-exclude/path-include

2020-11-23 Thread Andreas Hasenack
Public bug reported:

Copy of the bug filed in Debian:


I noticed that dpkg -V doesn't seem to take into account the
path-exclude configuration setting.

This config, for example:
$ cat /etc/dpkg/dpkg.cfg.d/excludes
# Drop all man pages
path-exclude=/usr/share/man/*

# Drop all translations
path-exclude=/usr/share/locale/*/LC_MESSAGES/*.mo

# Drop all documentation ...
path-exclude=/usr/share/doc/*

# ... except copyright files ...
path-include=/usr/share/doc/*/copyright

# ... and Debian changelogs
path-include=/usr/share/doc/*/changelog.Debian.*

A fresh sid container has a clean dpkv -V. I then create the excludes
file above, and install some packages:
# apt install man slapd


dpkg -V is now unhappy:
root@sid:~# dpkg -V|head
??5??   /usr/share/doc/slapd/NEWS.Debian.gz
??5??   /usr/share/doc/slapd/README.DB_CONFIG.gz
??5??   /usr/share/doc/slapd/README.Debian.gz
??5??   /usr/share/doc/slapd/TODO.Debian
??5??   /usr/share/doc/slapd/changelog.gz
??5??   /usr/share/doc/slapd/examples/DB_CONFIG
??5??   /usr/share/doc/slapd/examples/slapd.backup
??5??   /usr/share/doc/slapd/examples/slapd.conf.gz
??5??   /usr/share/man/man5/slapd-bdb.5.gz
??5??   /usr/share/man/man5/slapd-config.5.gz

Since dpkg knows these files are being excluded, it should not warn
about them in the -V operation.

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

** Affects: dpkg (Debian)
 Importance: Unknown
 Status: Unknown

** Bug watch added: Debian Bug tracker #975338
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975338

** Also affects: dpkg (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975338
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1905302

Title:
  dpkg -V should consider path-exclude/path-include

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1651888] Re: IDE crashes immediately if OpenJDK 9 is installed

2020-11-09 Thread Andreas Hasenack
It also crashes on startup on groovy

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1651888

Title:
  IDE crashes immediately if OpenJDK 9 is installed

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1872476] Re: Shared files are shown as folders

2020-11-03 Thread Andreas Hasenack
Focal task reopened due to last comment above

** Changed in: samba (Ubuntu Focal)
   Status: Fix Released => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872476

Title:
  Shared files are shown as folders

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1822632] Re: gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at 0x00000b69c5feaf58 for symbol `' out of range

2020-10-22 Thread Andreas Hasenack
groovy is fine, marking that task as fix released

** Changed in: gosu (Ubuntu Groovy)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822632

Title:
  gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at
  0x0b69c5feaf58 for symbol `' out of range

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1822632] Re: gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at 0x00000b69c5feaf58 for symbol `' out of range

2020-10-22 Thread Andreas Hasenack
Confirmed a rebuild also fixes it for bionic:
ubuntu@ppc64el-bionic:~$ gosu
gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at 
0x0f5fcb4aaf58 for symbol `' out of range

ubuntu@ppc64el-bionic:~/deb/gosu$ sudo dpkg -i *.deb
(Reading database ... 109900 files and directories currently installed.)
Preparing to unpack gosu_1.10-1build1_ppc64el.deb ...
Unpacking gosu (1.10-1build1) over (1.10-1) ...
Setting up gosu (1.10-1build1) ...
ubuntu@ppc64el-bionic:~/deb/gosu$ gosu
Usage: gosu user-spec command [args]
   ie: gosu tianon bash
   gosu nobody:root bash -c 'whoami && id'
   gosu 1000:1 id

gosu version: 1.10 (go1.10.4 on linux/ppc64le; gc)
 license: GPL-3 (full text at https://github.com/tianon/gosu)


** Also affects: gosu (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: gosu (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: gosu (Ubuntu Groovy)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822632

Title:
  gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at
  0x0b69c5feaf58 for symbol `' out of range

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1822632] Re: gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at 0x00000b69c5feaf58 for symbol `' out of range

2020-10-22 Thread Andreas Hasenack
A simple rebuild in focal fixed it for me:

ubuntu@ppc64el-focal:~/deb/gosu$ sudo dpkg -i *.deb
(Reading database ... 116197 files and directories currently installed.)
Preparing to unpack gosu_1.10-1_ppc64el.deb ...
Unpacking gosu (1.10-1) over (1.10-1) ...
Setting up gosu (1.10-1) ...
ubuntu@ppc64el-focal:~/deb/gosu$ gosu /bin/true
Usage: gosu user-spec command [args]
   ie: gosu tianon bash
   gosu nobody:root bash -c 'whoami && id'
   gosu 1000:1 id

gosu version: 1.10 (go1.13.8 on linux/ppc64le; gc)
 license: GPL-3 (full text at https://github.com/tianon/gosu)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822632

Title:
  gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at
  0x0b69c5feaf58 for symbol `' out of range

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1822632] Re: gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at 0x00000b69c5feaf58 for symbol `' out of range

2020-10-22 Thread Andreas Hasenack
I get this in focal as well:
ubuntu@ppc64el-focal:~$ gosu /bin/true
gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at 
0x01800a64af58 for symbol `' out of range

ubuntu@ppc64el-focal:~$ apt-cache policy gosu
gosu:
  Installed: 1.10-1
  Candidate: 1.10-1
  Version table:
 *** 1.10-1 500
500 http://us.ports.ubuntu.com/ubuntu-ports focal/universe ppc64el 
Packages
100 /var/lib/dpkg/status

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822632

Title:
  gosu: error while loading shared libraries: R_PPC64_ADDR16_HA reloc at
  0x0b69c5feaf58 for symbol `' out of range

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1899902] Re: systemd unit service file does not wait for bind9 to be ready

2020-10-19 Thread Andreas Hasenack
https://salsa.debian.org/dns-
team/bind9/-/commit/40fd1691a9b07c36573373eb872139b4e836b722 is the
missing commit, both in ubuntu and current debian sid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899902

Title:
  systemd unit service file does not wait for bind9 to be ready

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-10-19 Thread Andreas Hasenack
According to the nsswitch.conf manpage, [NOTFOUND=continue] is already
an assumed default, same for "UNAVAIL" and "TRYAGAIN", so it's just a
question of whether we should add "files" to that line to cope with this
situation or not.

Alternatively, we could also add conditions to the sssd service unit, so
it won't start if there is no config.

Something like this in [Unit] of 
ConditionFileNotEmpty=/etc/sssd/sssd.conf

And also perhaps
ConditionPathExistsGlob=/etc/sssd/conf.d/*.conf

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1897153/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1899968] Re: samba SMB share certain operations fail

2020-10-15 Thread Andreas Hasenack
What is the filesystem on /media/data on the server?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899968

Title:
  samba SMB share certain operations fail

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1899968] Re: samba SMB share certain operations fail

2020-10-15 Thread Andreas Hasenack
Setting bug status back to "new" as the requested information was
provided.

** Changed in: samba (Ubuntu)
   Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899968

Title:
  samba SMB share certain operations fail

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1899968] Re: samba SMB share certain operations fail

2020-10-15 Thread Andreas Hasenack
Can you clarify one scenario that reproduces the problem, being explicit
about what the server is, and the client? cifs-utils (and the kernel?)
could very well be involved here. Also the server share config please.
Or can you show the bad/good behavior by just by switching servers, and
keeping the same client?

It also may matter which SMB protocol was used for the mount, as
defaults have changed. To be honest, I'm suspecting it's unix extensions
that are not being used, since the default cifs mount option changed
from SMB1 (deprecated nowadays) to SMB2 and higher, and unix extensions
are not yet available for these higher protocol versions.

To see which version was selected, you can type "mount -t cifs" or check
dmesg right after a mount was done.

** Changed in: samba (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899968

Title:
  samba SMB share certain operations fail

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-10-14 Thread Andreas Hasenack
Vladimir, from comment #15, just having sssd failing to start is not
enough for this bug. Are you also having autofs issues, and if yes, what
does your /etc/auto.master look like? Do you also have a map file
without a full path?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1897153/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-10-14 Thread Andreas Hasenack
I understand sssd is failing to start because there is no config, but
I'm trying to understand the bad interaction of automounts with sssd,
which would be via /etc/nsswitch.conf.

(Brainstorming below, pardon me if this is all obvious to you)

autofs will consult /etc/nsswitch.conf when a map file has no path,
i.e., is not really a file.

Something like this in /etc/auto.master:

/mnt auto.mnt

Since it's "auto.mnt" and not, say, "/etc/auto.mnt", /etc/nsswitch.conf
is consulted.

That is exactly the case that was reported in this bug. Recaping:
"""
>From /etc/auto.master:
/mnt/GGData auto.DataVol1 --ghost
"""

I'm not sure what is the fallback when NSS returns "sorry, no such thing
here". Does autofs assumes a file, with a certain path? Let's find out.

...

Ok, it fails miserably. But if I remove "automount: sss" from
/etc/nsswitch.conf, and leave the map without an absolute path, then
autofs works.


I see two options here:

a) /etc/nsswitch.conf change

a) Add files:
automount:  sss files

Also files could be first. Some experimentation and thought required here. We 
can also play with flags, like:
automount:  sss [NOTFOUND=continue] files

The nsswitch.conf(5) manpage documents these. A quick check in our
default nsswitch.conf file shows we (debian/ubuntu) do not use these
flags. I seem to remember that Redhat/Fedora used to play a lot with the
flags.

b) use a path in auto.master. In other words, change your
/etc/auto.master entry to:

/mnt/GGData /etc/auto.DataVol1 --ghost

Or wherever auto.DataVol1 exists.


I have a feeling your setup was relying on this fallback to assuming the 
location of the auto.DataVol1 file.

strace shows autofs assumes /etc in this case, as the path for the file:
4263  connect(9, {sa_family=AF_UNIX, sun_path="/var/lib/sss/pipes/autofs"}, 
110) = -1 ENOENT (No such file or directory)
4263  close(9)  = 0
4263  write(2, "setautomntent: lookup(sss): setautomntent: No such file or 
directory", 68) = 68
4263  write(2, "\n", 1) = 1
4263  write(2, "lookup_nss_read_map: reading map files auto.mnt", 47) = 47
4263  write(2, "\n", 1) = 1
4263  stat("/etc/auto.mnt", {st_mode=S_IFREG|0644, st_size=330, ...}) = 0


So, here is my take: I believe your configuration needs to be fixed, because 
using a map file without a path in /etc/auto.master is documented as doing an 
nsswitch lookup, which is what broke when libnss-sss was installed (due to the 
entry it adds to /etc/nsswitch.fong).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1897153/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-10-12 Thread Andreas Hasenack
** Also affects: ubuntu-release-notes
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-release-notes/+bug/1897153/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898928] Re: package ubuntu-advantage-tools 19.6~ubuntu14.04.4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2

2020-10-07 Thread Andreas Hasenack
What is the output of this command please:

ls -la /etc/os-release

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898928

Title:
  package ubuntu-advantage-tools 19.6~ubuntu14.04.4 failed to
  install/upgrade: subprocess installed post-installation script
  returned error exit status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1898928/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898593] [NEW] Fix sphinx doc building

2020-10-05 Thread Andreas Hasenack
Public bug reported:

This basically the same bug as #1894907, but there I decided to disable
docs rebuilding, after checking that none of the patches were against
the docs source.

Furthermore, we should probably fix these lintian issues:

E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/developer.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/download.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/genindex.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/getsasl.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/index.html You may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/operations.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/packager.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/search.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/setup.html You may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/support.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2 source: source-is-missing doc/html/_static/jquery.js line length 
is 32014 characters (>512)
E: cyrus-sasl2 source: source-is-missing doc/html/_static/js/modernizr.min.js   
E: cyrus-sasl2 source: source-is-missing doc/html/_static/underscore.js line 
length is 519 characters (>512)
E: cyrus-sasl2 source: source-is-missing 
docsrc/exts/themes/cyrus/static/js/modernizr.min.js
E: cyrus-sasl2 source: source-is-missing 
docsrc/exts/themes/sphinx_rtd_theme/static/js/modernizr.min.js

** Affects: cyrus-sasl2 (Ubuntu)
 Importance: Medium
 Status: Triaged

** Summary changed:

- Build docs with sphinx
+ Fix sphinx doc building

** Changed in: cyrus-sasl2 (Ubuntu)
   Status: New => Triaged

** Changed in: cyrus-sasl2 (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898593

Title:
  Fix sphinx doc building

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1898593/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1894907] Re: FTBFS with sphinx 3.2

2020-10-05 Thread Andreas Hasenack
I filed https://bugs.launchpad.net/ubuntu/+source/cyrus-
sasl2/+bug/1898593 to properly fix the doc building with sphinx.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1894907

Title:
  FTBFS with sphinx 3.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/cyrus-sasl2/+bug/1894907/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897967] Re: [SRU] FTBFS in Focal

2020-10-01 Thread Andreas Hasenack
As you said on MM, looks like
https://github.com/prometheus/common/commit/273427a9fd1 was added to
allow to disable http/2, so it was being used already and this debdiff
should not introduce a behavior change, which is good.

Have you checked which other rdeps fail to build?

** Description changed:

  [Impact]
  
- The package FTBFS in Focal likely because a newer version of golang-
- github-prometheus-common was introduced after prometheus-alertmanager
- and a rebuild was not done. Not being able to build the package from
- source does not allow uploads of eventual fixes (security or regular
- ones) which is definitely not good for the users.
+ The package FTBFS in Focal because a newer version of golang-github-
+ prometheus-common was introduced after prometheus-alertmanager and a
+ rebuild was not done. Not being able to build the package from source
+ does not allow uploads of eventual fixes (security or regular ones)
+ which is definitely not good for the users.
  
  The Prometheus common lib API change which is impacting prometheus-
  alertmanager is minor. There is an extra argument in NewClientFromConfig
  function to enable or not HTTP/2. The proposed fix apply a patch
  enabling HTTP/2 in all the calls made to NewClientFromConfig.
  
  [Test Case]
  
  Try to build the package in Focal:
  
  $ lxc launch ubuntu-daily:focal builder
  $ lxc shell builder
  # echo "deb-src http://archive.ubuntu.com/ubuntu/ focal main universe" > \
   /etc/apt/sources.list.d/source.list
  # apt update && apt upgrade -y
  # apt install -y dpkg-dev
  # apt source prometheus-alertmanager
  # apt build-dep -y prometheus-alertmanager
  # cd prometheus-alertmanager-0.15.3+ds
  # dpkg-buildpackage
  
  To fix the FTBFS apply the debdiff attached to this bug and build the
  package again.
  
  [Regression Potential]
  
  In the case where the user environment do not support HTTP/2 there might
  be a regression. HTTP/2 tries to be highly compatible with HTTP/1.1 but
  there might be any corner case. This would not be a change in the
  current behavior because this extra argument was added to allow users to
  disable it, check out this upstream commit:
  
  https://github.com/prometheus/common/commit/273427a9fd1
  
  [Original Description]
  
  Currently, prometheus-alertmanager version 0.15.3+ds-3 FTBFS in Focal:
  
  https://paste.ubuntu.com/p/CcCYC3w3YC/
  
  The Prometheus common golang library changed its API and the
  alertmanager version we have in Focal is not ready for it.

** Description changed:

  [Impact]
  
  The package FTBFS in Focal because a newer version of golang-github-
  prometheus-common was introduced after prometheus-alertmanager and a
  rebuild was not done. Not being able to build the package from source
  does not allow uploads of eventual fixes (security or regular ones)
  which is definitely not good for the users.
  
  The Prometheus common lib API change which is impacting prometheus-
  alertmanager is minor. There is an extra argument in NewClientFromConfig
  function to enable or not HTTP/2. The proposed fix apply a patch
- enabling HTTP/2 in all the calls made to NewClientFromConfig.
+ enabling HTTP/2 in all the calls made to NewClientFromConfig, since this
+ was the previous behavior (http/2 enabled).
  
  [Test Case]
  
  Try to build the package in Focal:
  
  $ lxc launch ubuntu-daily:focal builder
  $ lxc shell builder
  # echo "deb-src http://archive.ubuntu.com/ubuntu/ focal main universe" > \
   /etc/apt/sources.list.d/source.list
  # apt update && apt upgrade -y
  # apt install -y dpkg-dev
  # apt source prometheus-alertmanager
  # apt build-dep -y prometheus-alertmanager
  # cd prometheus-alertmanager-0.15.3+ds
  # dpkg-buildpackage
  
  To fix the FTBFS apply the debdiff attached to this bug and build the
  package again.
  
  [Regression Potential]
  
  In the case where the user environment do not support HTTP/2 there might
  be a regression. HTTP/2 tries to be highly compatible with HTTP/1.1 but
  there might be any corner case. This would not be a change in the
  current behavior because this extra argument was added to allow users to
  disable it, check out this upstream commit:
  
  https://github.com/prometheus/common/commit/273427a9fd1
  
  [Original Description]
  
  Currently, prometheus-alertmanager version 0.15.3+ds-3 FTBFS in Focal:
  
  https://paste.ubuntu.com/p/CcCYC3w3YC/
  
  The Prometheus common golang library changed its API and the
  alertmanager version we have in Focal is not ready for it.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897967

Title:
  [SRU] FTBFS in Focal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/prometheus-alertmanager/+bug/1897967/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-09-30 Thread Andreas Hasenack
The sudo delay is likely due to dns, I see that in other boxes and
ubuntu releases too. But let's see.

** Changed in: sssd (Ubuntu)
   Importance: Low => High

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1894907] Re: FTBFS with sphinx 3.2

2020-09-30 Thread Andreas Hasenack
I got as far as this collection of patches: 
https://paste.ubuntu.com/p/wvRzpByDXT/ :
--- a/docsrc/exts/sphinxlocal/writers/manpage.py
+++ b/docsrc/exts/sphinxlocal/writers/manpage.py
@@ -14,7 +14,6 @@
 
 from docutils import nodes
 from sphinx.writers.manpage import (
-MACRO_DEF,
 ManualPageWriter,
 ManualPageTranslator as BaseTranslator
 )
@@ -73,9 +72,6 @@
 self._docinfo['version'] = builder.config.version
 self._docinfo['manual_group'] = builder.config.project
 
-# since self.append_header() is never called, need to do this here
-self.body.append(MACRO_DEF)
-
 # overwritten -- don't wrap literal_block with font calls
 self.defs['literal_block'] = ('.sp\n.nf\n', '\n.fi\n')
 
--- a/docsrc/exts/sphinxlocal/writers/manpage.py
+++ b/docsrc/exts/sphinxlocal/writers/manpage.py
@@ -13,6 +13,8 @@
 """
 
 from docutils import nodes
+from time import strftime
+
 from sphinx.writers.manpage import (
 ManualPageWriter,
 ManualPageTranslator as BaseTranslator
@@ -21,7 +23,6 @@
 
 from sphinx import addnodes
 from sphinx.locale import admonitionlabels, _
-from sphinx.util.osutil import ustrftime
 
 class CyrusManualPageWriter(ManualPageWriter):
 
@@ -66,7 +67,7 @@
 if builder.config.today:
 self._docinfo['date'] = builder.config.today
 else:
-self._docinfo['date'] = ustrftime(builder.config.today_fmt
+self._docinfo['date'] = strftime(builder.config.today_fmt
   or _('%B %d, %Y'))
 self._docinfo['copyright'] = builder.config.copyright
 self._docinfo['version'] = builder.config.version
diff --git a/docsrc/exts/sphinxlocal/roles/saslman.py 
b/docsrc/exts/sphinxlocal/roles/saslman.py
index f881d98f..bcafeece 100644
--- a/docsrc/exts/sphinxlocal/roles/saslman.py
+++ b/docsrc/exts/sphinxlocal/roles/saslman.py
@@ -18,7 +18,6 @@ from string import Template
 import re
 
 def setup(app):
-app.info('Initializing saslman plugin')
 app.add_crossref_type('saslman', 'saslman', '%s', nodes.generated)
 return
 
diff --git a/docsrc/exts/sphinxlocal/builders/manpage.py 
b/docsrc/exts/sphinxlocal/builders/manpage.py
index a6281f79..126839e0 100644
--- a/docsrc/exts/sphinxlocal/builders/manpage.py
+++ b/docsrc/exts/sphinxlocal/builders/manpage.py
@@ -21,7 +21,6 @@ from docutils.frontend import OptionParser
 from sphinx import addnodes
 from sphinx.errors import SphinxError
 from sphinx.builders import Builder
-from sphinx.environment import NoUri
 from sphinx.util.nodes import inline_all_toctrees
 from sphinx.util.console import bold, darkgreen
 from sphinx.writers.manpage import ManualPageWriter


That moves along a bit, but then fails with;
sed -e 's,[@]LIB_DOOR[@],,g' -e 's,[@]SASL_DL_LIB[@],-ldl,g' -e 
's,[@]LIBS[@],-lresolv ,g' -e 's,[@]VERSION[@],2.1.27,g' -e 
's,[@]libdir[@],/usr/lib/x86_64-linux-gnu,g' -e 's,[@]prefix[@],/usr,g' -e 
's,[@]exec_prefix[@],/usr,g' -e 's,[@]includedir[@],/usr/include,g' < 
../libsasl2.pc.in > libsasl2.pc
/usr/bin/sphinx-build -d docsrc/.doctrees -n -q -b cyrman ./docsrc ./man
WARNING: The config value `author' has type `list', defaults to `str'.
WARNING: The config value `epub_author' has type `str', defaults to `list'.
WARNING: The config value `epub_publisher' has type `str', defaults to `list'.

Extension error:
Handler  for event 
'config-inited' threw an exception (exception: 'list' object has no attribute 
'translate')
['The Cyrus Team']
make[4]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
make[4]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
make[3]: *** [Makefile:686: all-recursive] Error 1
make[3]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
make[2]: *** [Makefile:556: all] Error 2
make[2]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
dh_auto_build: error: cd build-heimdal && make -j4 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 returned exit code 2
make[1]: *** [debian/rules:164: override_dh_auto_build] Error 25
make[1]: Leaving directory '/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2'
make: *** [debian/rules:122: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1894907

Title:
  FTBFS with sphinx 3.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/cyrus-sasl2/+bug/1894907/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1868703] Re: Support new AD requirements (ADV190023)

2020-09-30 Thread Andreas Hasenack
Yes, that's the plan.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868703

Title:
  Support new AD requirements (ADV190023)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cyrus-sasl2/+bug/1868703/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-09-29 Thread Andreas Hasenack
Could you please attach them? I'd like to know what pulled sssd in

On Tue, Sep 29, 2020, 23:55 Vladimir Yerilov <1897...@bugs.launchpad.net>
wrote:

> Hi, I had no intention to use sssd, it was pulled and installed during the
> update. I am sure I had no sssd installed on focal as I am browsing now
> through the image of my root partition created before the update was
> started.
> Yes, I still have update logs.
>
> --
> You received this bug notification because you are subscribed to sssd in
> Ubuntu.
> https://bugs.launchpad.net/bugs/1897153
>
> Title:
>   Automount fails due to SSSD config (Groovy Gorilla)
>
> Status in sssd package in Ubuntu:
>   Confirmed
>
> Bug description:
>   Using the same automount config from 20.04, Groovy Gorilla fails to
> automount mount points with SSD errors such as the following:
>   -From  journalctl -xe:
>   Sep 25 04:04:43 ROC-Cube systemd[1]: Stopping Automounts filesystems on
> demand...
>   ░░ Subject: A stop job for unit autofs.service has begun execution
>   ░░ Defined-By: systemd
>   ░░ Support: http://www.ubuntu.com/support
>   ░░
>   ░░ A stop job for unit autofs.service has begun execution.
>   ░░
>   ░░ The job identifier is 8075.
>   Sep 25 04:04:43 ROC-Cube automount[1838]: umount_autofs_indirect: ask
> umount returned busy /mnt/GGData
>   Sep 25 04:04:44 ROC-Cube systemd[1]: autofs.service: Succeeded.
>   ░░ Subject: Unit succeeded
>   ░░ Defined-By: systemd
>   ░░ Support: http://www.ubuntu.com/support
>   ░░
>   ░░ The unit autofs.service has successfully entered the 'dead' state.
>   Sep 25 04:04:44 ROC-Cube systemd[1]: Stopped Automounts filesystems on
> demand.
>   ░░ Subject: A stop job for unit autofs.service has finished
>   ░░ Defined-By: systemd
>   ░░ Support: http://www.ubuntu.com/support
>   ░░
>   ░░ A stop job for unit autofs.service has finished.
>   ░░
>   ░░ The job identifier is 8075 and the job result is done.
>   Sep 25 04:04:44 ROC-Cube systemd[1]: Starting Automounts filesystems on
> demand...
>   ░░ Subject: A start job for unit autofs.service has begun execution
>   ░░ Defined-By: systemd
>   ░░ Support: http://www.ubuntu.com/support
>   ░░
>   ░░ A start job for unit autofs.service has begun execution.
>   ░░
>   ░░ The job identifier is 8075.
>   Sep 25 04:04:44 ROC-Cube automount[13523]: setautomntent: lookup(sss):
> setautomntent: No such file or directory
>   Sep 25 04:04:44 ROC-Cube systemd[1]: tmp-auto8NobgK.mount: Succeeded.
>   ░░ Subject: Unit succeeded
>   ░░ Defined-By: systemd
>   ░░ Support: http://www.ubuntu.com/support
>   ░░
>   ░░ The unit tmp-auto8NobgK.mount has successfully entered the 'dead'
> state.
>   Sep 25 04:04:44 ROC-Cube automount[13523]: setautomntent: lookup(sss):
> setautomntent: No such file or directory
>   Sep 25 04:04:44 ROC-Cube systemd[2685]: tmp-autoxIakpM.mount: Succeeded.
>   ░░ Subject: Unit succeeded
>   ░░ Defined-By: systemd
>   ░░ Support: http://www.ubuntu.com/support
>   ░░
>   ░░ The unit UNIT has successfully entered the 'dead' state.
>   Sep 25 04:04:44 ROC-Cube systemd[1]: tmp-autoxIakpM.mount: Succeeded.
>   ░░ Subject: Unit succeeded
>   ░░ Defined-By: systemd
>   ░░ Support: http://www.ubuntu.com/support
>   ░░
>   ░░ The unit tmp-autoxIakpM.mount has successfully entered the 'dead'
> state.
>   Sep 25 04:04:44 ROC-Cube systemd[1]: Started Automounts filesystems on
> demand.
>   ░░ Subject: A start job for unit autofs.service has finished successfully
>   ░░ Defined-By: systemd
>   ░░ Support: http://www.ubuntu.com/support
>   ░░
>   ░░ A start job for unit autofs.service has finished successfully.
>   ░░
>   ░░ The job identifier is 8075.
>
>   From tail /var/log/syslog:
>   Sep 25 04:13:38 ROC-Cube automount[13523]: umount_autofs_indirect: ask
> umount returned busy /mnt/GGData
>   Sep 25 04:13:40 ROC-Cube systemd[1]: autofs.service: Succeeded.
>   Sep 25 04:13:40 ROC-Cube systemd[1]: Stopped Automounts filesystems on
> demand.
>   Sep 25 04:13:40 ROC-Cube systemd[1]: Starting Automounts filesystems on
> demand...
>   Sep 25 04:13:40 ROC-Cube automount[15237]: setautomntent: lookup(sss):
> setautomntent: No such file or directory
>   Sep 25 04:13:40 ROC-Cube systemd[2685]: tmp-autonc2nfm.mount: Succeeded.
>   Sep 25 04:13:40 ROC-Cube automount[15237]: setautomntent: lookup(sss):
> setautomntent: No such file or directory
>   Sep 25 04:13:40 ROC-Cube systemd[1]: tmp-autonc2nfm.mount: Succeeded.
>   Sep 25 04:13:40 ROC-Cube systemd[1]: Started Automounts filesystems on
> demand.
>   Sep 25 04:13:40 ROC-Cube systemd[2685]: tmp-autopnDion.mount: Succeeded.
>
>   From auto.DataVol1:
>   root@ROC-Cube:~# cat /etc/auto.DataVol1
>   #/mnt/GGData  -fstype=nfs 10.0.0.13:/GGData
>   Tracktion -fstype=nfs 10.0.0.13:/GGData/Tracktion
>   C64   -fstype=nfs 10.0.0.13:/GGData/C64
>   Development   -fstype=nfs 10.0.0.13:/GGData/Development
>   Retro -fstype=nfs 10.0.0.13:/GGData/Retro
>   Inkscape  -fstype=nfs 10.0.0.13:/GGData/Inkscape
>
>   

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-09-29 Thread Andreas Hasenack
Do you still have the upgrade logs from focal to groovy?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-09-29 Thread Andreas Hasenack
Hi @openmindead, what is your goal with sssd? Or you didn't have it
installed in focal, and it got installed after upgrading to groovy?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1772148] Re: Mount.cifs does not work without keyutils being installed

2020-09-28 Thread Andreas Hasenack
> In addition, DFS support for target shares which are specified as UNC
> names which begin with host names (rather than IP addresses) requires
> a user space helper (such as cifs.upcall) 

So DFS would require /sbin/key.dns_resolver? DFS was the original
requirement for adding keyutils as a Recommends back in 2011 via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504690.

Your list then becomes:
for several scenarios:
- 'cifsacl' option is used or
- kerberos auth is used / spnego is used
- when DFS is used

The extra deps that keyutils pulls in seem minor and already exist on the 
normal system:
Depends: libc6 (>= 2.15), libkeyutils1 (>= 1.6)

FWIW, I would favor promoting keyutils back to Recommends.

** Bug watch added: Debian Bug tracker #504690
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504690

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1772148

Title:
  Mount.cifs does not work without keyutils being installed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1772148/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1772148] Re: Mount.cifs does not work without keyutils being installed

2020-09-28 Thread Andreas Hasenack
Can you elaborate on when this happens " - when kernel level dns
resolution is needed - so the cifs upcall for dns.resolver is required"?
Together with kerberos still?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1772148

Title:
  Mount.cifs does not work without keyutils being installed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1772148/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1772148] Re: Mount.cifs does not work without keyutils being installed

2020-09-28 Thread Andreas Hasenack
Here is some of the history of the keyutils dependency in the cifs-utils
package:

- first added in response to debian bug #504690 in 2011:
cifs-utils (2:4.9-1) unstable; urgency=low  

  [ Luk Claes ] 
  * Add Recommends to keyutils so following DFS links works out of the  
box.  Closes: #504690.  
  * Install README.  Closes: #603094.   
  * Add --without-libcap to dh_auto_configure.  Closes: #615211.

  [ Steve Langasek ]
  * New upstream release.  Closes: #600788. 
- mount.cifs: use original device name as-is for mtab.  
  Closes: #586009, #583508, #589218.

 -- Luk Claes   Sat, 02 Apr 2011 17:10:35 +020


Then downgraded to "suggests" in 2016, in response to debian bug #822841:

cifs-utils (2:6.5-2) unstable; urgency=medium   

  * Team upload 
  * Move keyutils and winbind from Recommends to Suggests (Closes: #822841) 
  * Spring cleaning:
- Standards-Version: 3.9.8 (no change)  
- Use secure Vcs-* URIs 
- Remove cifs-utils.NEWS as mount.cifs is setuid again since 2:5.4-2
  (pre-wheezy)  
- Updated gbp.conf (Old style config section)   
- Renamed cifs-utils.lintian to cifs-utils.lintian-overrides
- Updated copyright file

 -- Mathieu Parent   Tue, 03 May 2016 12:16:18 +0200   


Now, mount.cifs works just fine without cifs-utils installed, for many 
scenarios. Maybe even most of the time? The main problem seems to be to 
identify the cases when keyutils is needed, and clearly communicate that.


** Bug watch added: Debian Bug tracker #967972
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967972

** Also affects: cifs-utils (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967972
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1772148

Title:
  Mount.cifs does not work without keyutils being installed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1772148/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1896740] Re: BIND crashes with failed assertion INSIST(dns_name_issubdomain(>name, >domain))

2020-09-28 Thread Andreas Hasenack
Isn't the 0003-Print-diagnostics patch removing the crash by
*replacing* it with a diagnostics output? The crash was caused by the
INSIST() macro, which calls abort().

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1896740

Title:
  BIND crashes with failed assertion
  INSIST(dns_name_issubdomain(>name, >domain))

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-09-25 Thread Andreas Hasenack
Right, I was going to say it looked like your setup wasn't using sssd,
hence my question about /etc/nsswitch.conf.

sssd needs to be configured after installation, at most it adds "sss" to
/etc/nsswitch.conf, but the actual sssd.conf needs to be populated by
hand, or by another tool such as realm from the realmd package. I think
the sssd package never installed a default sssd.conf.

All that being said, sssd *can* do something with autofs, but it needs
to be configured. I haven't used that feature yet, though. But looks
like it gets in the way if not done properly.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-09-24 Thread Andreas Hasenack
You don't have /etc/sssd/sssd.conf? Do you have "sss" entries in
/etc/nsswitch.conf?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1896740] Re: BIND crashes with failed assertion INSIST(dns_name_issubdomain(>name, >domain))

2020-09-24 Thread Andreas Hasenack
They were already, but for groovy (the ubuntu version currently in
development). This is a case for backporting them to focal. Since I have
no clear way to reproduce this crash, would you be willing to test
packages from a ppa to confirm the fix?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1896740

Title:
  BIND crashes with failed assertion
  INSIST(dns_name_issubdomain(>name, >domain))

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)

2020-09-24 Thread Andreas Hasenack
Are you using a "services=" line in /etc/sssd/sssd.conf, to have sssd
itself start services? It might be conflicting with the individual
systemd services that are trying to start. Not saying it's the cause of
your problem, but might be the cause of some log noise that is getting
in the way of troubleshooting this more accurately.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897153

Title:
  Automount fails due to SSSD config (Groovy Gorilla)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1896194] Re: package samba 2:4.3.11+dfsg-0ubuntu0.16.04.29 failed to install/upgrade: il sottoprocesso installato script di post-installation ha restituito lo stato di errore 1

2020-09-24 Thread Andreas Hasenack
This is the error in your smb.conf:

$ testparm ./smb.conf 
Load smb config files from ./smb.conf
WARNING: The "syslog" option is deprecated
WARNING: Ignoring invalid value 'share' for parameter 'security'
Error loading services.


The "share" parameter for "security" has been deprecated since many versions 
ago. You should go over your config and use a valid value for "security", like 
"user", and evaluate the impact this will have in your configuration. "share" 
won't work anymore.

** Changed in: samba (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1896194

Title:
  package samba 2:4.3.11+dfsg-0ubuntu0.16.04.29 failed to
  install/upgrade: il sottoprocesso installato script di post-
  installation ha restituito lo stato di errore 1

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1281493] Re: Add Glusterfs VFS support

2020-09-23 Thread Andreas Hasenack
*** This bug is a duplicate of bug 1894618 ***
https://bugs.launchpad.net/bugs/1894618

** This bug has been marked a duplicate of bug 1894618
   samba vfs glusterfs shares do not work because glusterfs.so is missing from 
samba-vfs-modules

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1281493

Title:
  Add Glusterfs VFS support

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

  1   2   3   4   5   6   7   8   9   10   >