[Touch-packages] [Bug 1921562] Re: Intermittent hangs during ldap_search_ext when TLS enabled

2021-04-25 Thread Utkarsh Gupta
** Tags removed: verification-needed
** Tags added: verification-done

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

Title:
  Intermittent hangs during ldap_search_ext when TLS enabled

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Focal:
  Fix Committed
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  

  When connecting to an LDAP server with TLS, ldap_search_ext can hang
  if during the initial TLS handshake a signal is received by the
  process. The cause of this bug is the same as
  https://bugs.openldap.org/show_bug.cgi?id=8650.

  In our case this bug cause failures in the SSSD LDAP backend at least
  once per day, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit.

  
  [Test Plan]
  ===

  When using openldap on 20.04, this bug causes failures in the SSSD
  LDAP backend, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit:

  Mar 19 19:05:31 mail auth[867454]: pam_sss(dovecot:auth): received for user 
redacted: 4 (System error)
  Mar 19 19:05:32 mail sssd_be[867455]: Starting up

  With the patched version, this should no longer be a problem.

  
  [Where Problems Could Occur]
  

  With this patch applied, there may be few edge cases in (and varying
  b/w) different versions of GnuTLS. And also some bits that are
  discussed in https://bugs.openldap.org/show_bug.cgi?id=8650.

  But that said, the patched version is already being run in production
  for over two weeks time (at the time of writing - 07/04/21). So I
  believe the SRU will clearly benefit from this and has lower risk of
  regression.

  
  [More Info]
  ===

  A reduced version of the patch linked above can be found attached to
  this bug report. This patch has been applied to version 2.4.49+dfsg-
  2ubuntu1.7 and has been running in production for approximately a week
  and the issue has no longer occurred. No other issues have appeared
  during this period.

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

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


[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together

2021-04-23 Thread Utkarsh Gupta
s/Invalid/Won't Fix/g.

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

Title:
  rsync conceals file deletions from reporting when --dry-run --remove-
  source-files are used together

Status in rsync package in Ubuntu:
  Won't Fix

Bug description:
  Rsync has an astonishing and dangerous bug:

  The dry run feature (-n / --dry-run) inhibits reporting of file
  deletions when --remove-source-files is used. This is quite serious.
  People use --dry-run to see if an outcome will work as expected before
  a live run. When the simulated run shows *less* destruction than the
  live run, the consequences can be serious because rsync may
  unexpectedly destroy the only copy(*) of a file.

  Users rely on --dry-run. Although users probably expect --dry-run to
  have limitations, we don't expect destructive operations to be under
  reported. If it were reversed, such that the live run were less
  destructive than the dry run, this wouldn't be as serious.

  Reproducer:

  $ mkdir -p /tmp/src /tmp/dest
  $ printf '%s\n' 'yada yada' > /tmp/src/foo.txt
  $ printf '%s\n' 'yada yada' > /tmp/src/bar.txt
  $ cp /tmp/src/foo.txt /tmp/dest
  $ ls /tmp/src/ /tmp/dest/
  /tmp/dest/:
  foo.txt

  /tmp/src/:
  bar.txt  foo.txt

  $ rsync -na --info=remove1 --remove-source-files --existing src/* dest/
  (no output)

  $ rsync -a --info=remove1 --remove-source-files --existing src/* dest/
  sender removed foo.txt

  $ ls /tmp/src/ /tmp/dest/
  /tmp/dest/:
  foo.txt

  /tmp/src/:
  bar.txt

  (*) note when I say it can destroy the only copy of a file, another
  circumstance is needed: that is, rsync does not do a checksum by
  default.  It checks for identical files based on superficial
  parameters like name and date.  So it's possible that two files match
  in the default superficial comparison but differ in the actual
  content.  Losing a unique file in this scenario is perhaps a rare
  corner case, but this bug should be fixed nonetheless.  In the typical
  case of losing files at the source, there is still a significant
  inconvenience of trying to identify what files to copy back.

  Note this bug is similar but differs in a few ways:
  https://bugzilla.samba.org/show_bug.cgi?id=3844

  I've marked this as a security vulnerability because it causes
  unexpected data loss due to --dry-run creating a false expectation.

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

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


[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together

2021-04-23 Thread Utkarsh Gupta
Hi Bill,

Such bugs are worth reporting upstream and once they're fixed there, we
can pick it from there and provide it via the packages we ship, as
exactly what Paride mentioned.

Since you don't want to open an issue upstream, maybe you'd like to use their 
mailing lists?
cf: https://rsync.samba.org/lists.html

That said, I am marking this as "Invalid" here because of the above
reasons. Thanks!

** Changed in: rsync (Ubuntu)
   Status: Triaged => Invalid

** Changed in: rsync (Ubuntu)
   Status: Invalid => Won't Fix

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

Title:
  rsync conceals file deletions from reporting when --dry-run --remove-
  source-files are used together

Status in rsync package in Ubuntu:
  Won't Fix

Bug description:
  Rsync has an astonishing and dangerous bug:

  The dry run feature (-n / --dry-run) inhibits reporting of file
  deletions when --remove-source-files is used. This is quite serious.
  People use --dry-run to see if an outcome will work as expected before
  a live run. When the simulated run shows *less* destruction than the
  live run, the consequences can be serious because rsync may
  unexpectedly destroy the only copy(*) of a file.

  Users rely on --dry-run. Although users probably expect --dry-run to
  have limitations, we don't expect destructive operations to be under
  reported. If it were reversed, such that the live run were less
  destructive than the dry run, this wouldn't be as serious.

  Reproducer:

  $ mkdir -p /tmp/src /tmp/dest
  $ printf '%s\n' 'yada yada' > /tmp/src/foo.txt
  $ printf '%s\n' 'yada yada' > /tmp/src/bar.txt
  $ cp /tmp/src/foo.txt /tmp/dest
  $ ls /tmp/src/ /tmp/dest/
  /tmp/dest/:
  foo.txt

  /tmp/src/:
  bar.txt  foo.txt

  $ rsync -na --info=remove1 --remove-source-files --existing src/* dest/
  (no output)

  $ rsync -a --info=remove1 --remove-source-files --existing src/* dest/
  sender removed foo.txt

  $ ls /tmp/src/ /tmp/dest/
  /tmp/dest/:
  foo.txt

  /tmp/src/:
  bar.txt

  (*) note when I say it can destroy the only copy of a file, another
  circumstance is needed: that is, rsync does not do a checksum by
  default.  It checks for identical files based on superficial
  parameters like name and date.  So it's possible that two files match
  in the default superficial comparison but differ in the actual
  content.  Losing a unique file in this scenario is perhaps a rare
  corner case, but this bug should be fixed nonetheless.  In the typical
  case of losing files at the source, there is still a significant
  inconvenience of trying to identify what files to copy back.

  Note this bug is similar but differs in a few ways:
  https://bugzilla.samba.org/show_bug.cgi?id=3844

  I've marked this as a security vulnerability because it causes
  unexpected data loss due to --dry-run creating a false expectation.

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

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


[Touch-packages] [Bug 1522675] Re: Warning messages about unsandboxed downloads

2021-04-22 Thread Utkarsh Gupta
Hey, still hitting this in a Hirsute VM :/

** Also affects: apt (Ubuntu Hirsute)
   Importance: Low
   Status: Fix Released

** Also affects: aptitude (Ubuntu Hirsute)
   Importance: Low
   Status: Fix Released

** Also affects: synaptic (Ubuntu Hirsute)
   Importance: Low
   Status: Triaged

** Also affects: update-notifier (Ubuntu Hirsute)
   Importance: Medium
 Assignee: Julian Andres Klode (juliank)
   Status: Fix Released

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

Title:
  Warning messages about unsandboxed downloads

Status in apt package in Ubuntu:
  Fix Released
Status in aptitude package in Ubuntu:
  Fix Released
Status in synaptic package in Ubuntu:
  Triaged
Status in update-notifier package in Ubuntu:
  Fix Released
Status in aptitude source package in Xenial:
  Confirmed
Status in synaptic source package in Xenial:
  Confirmed
Status in update-notifier source package in Xenial:
  Fix Released
Status in apt source package in Hirsute:
  Fix Released
Status in aptitude source package in Hirsute:
  Fix Released
Status in synaptic source package in Hirsute:
  Triaged
Status in update-notifier source package in Hirsute:
  Fix Released
Status in apt package in Debian:
  Fix Released
Status in aptitude package in Debian:
  Fix Released
Status in synaptic package in Debian:
  New

Bug description:
  READ ME FIRST
  =
  This is only a regression on a cosmetic level. Previous versions of apt did 
not have any sandboxing whatsoever, so this means apt reverted back to that old 
behavior.

  update-notifier SRU
  ---
  [Impact]
  Cosmetic. Warnings when installing packages using update-notifier downloading 
stuff

  [Test case]

  Install flashplugin-installer with apt and check that the output does
  not contain a message like this:

  W: Can't drop privileges for downloading as file '...' couldn't be
  accessed by user '_apt'

  [Regression Potential]

  It just chowns /var/lib/update-notifier/package-data-
  downloads/partial/ to _apt:root, there should not be any regression.

  Original report
  ---

  Recently we got new versions for synaptic 0.82+build1 & apt 1.1.3, but
  now get that error when installing/upgrading some packages:

  Setting up libc6-dbg:amd64 (2.21-0ubuntu5) ...
  Processing triggers for libc-bin (2.21-0ubuntu5) ...
  W: Can't drop privileges for downloading as file 
'/root/.synaptic/tmp//tmp_cl' couldn't be accessed by user '_apt'. - 
pkgAcquire::Run (13: Permission denied)

  From nautilus, i'm seeing a /root/ folder locked (x on its icon) and
  the folder is empty (no /.synaptic/ sub-folder or file), so the above
  error.

  oem@u64:~$ ls -l .synaptic
  total 4
  -rw-rw-r-- 1 oem oem   0 Aug 25 11:19 options
  -rw-rw-r-- 1 oem oem 236 Aug 25 11:19 synaptic.conf

  oem@u64:~$ ls -l /var/lib/apt/lists/
  
  -rw-r- 1 root root0 Sep 20 06:36 lock
  drwx-- 2 _apt root16384 Sep 24 15:25 partial
  ..

  oem@u64:~$ sudo ls -l /var/lib/update-notifier/package-data-downloads/
  .
  drwxr-xr-x 2 _apt root 4096 Sep 22 23:33 partial

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: synaptic 0.82+build1
  ProcVersionSignature: Ubuntu 4.3.0-1.10-generic 4.3.0
  Uname: Linux 4.3.0-1-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.19.2-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Fri Dec  4 05:23:25 2015
  SourcePackage: synaptic
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1924597] Re: package openssh-server 1:8.3p1-1ubuntu0.1 failed to install/upgrade: podproces zainstalowany pakiet openssh-server skrypt post-installation zwrócił kod błędu 1

2021-04-16 Thread Utkarsh Gupta
Hello jerryd,

Thanks for taking the time to file the bug and making Ubuntu server
better.

Seeing from the logs that you posted, I can see:
"Not replacing deleted config file /etc/ssh/sshd_config"
...which essentially means that you might have tried to remove the 
/etc/ssh/sshd_config manually and thus it fails to re-install properly.

For this issue you can do the following to fix this back:
$ apt purge openssh-server
$ apt install openssh-server

This should fix everything and the installation should go fine.

Furthermore, I also tried to install openssh-server in a Groovy
container and the installation went fine! Since this is not really a bug
in the package and more of a local issue, I am marking this as
"Invalid", but should you feel that it's really a bug in the package,
please let us know why and provide more details and set the status to
"New" again. Once you do, we'll pick this up again and we can work out
something together.

Thanks, again!

** Changed in: openssh (Ubuntu)
   Status: New => Invalid

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

Title:
  package openssh-server 1:8.3p1-1ubuntu0.1 failed to install/upgrade:
  podproces zainstalowany pakiet openssh-server skrypt post-installation
  zwrócił kod błędu 1

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  that happen when i try to install ssh

  ProblemType: Package
  DistroRelease: Ubuntu 20.10
  Package: openssh-server 1:8.3p1-1ubuntu0.1
  ProcVersionSignature: Ubuntu 5.8.0-49.55-generic 5.8.18
  Uname: Linux 5.8.0-49-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.5
  AptOrdering:
   ncurses-term:amd64: Install
   openssh-sftp-server:amd64: Install
   openssh-server:amd64: Install
   ssh-import-id:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Thu Apr 15 19:12:21 2021
  ErrorMessage: podproces zainstalowany pakiet openssh-server skrypt 
post-installation zwrócił kod błędu 1
  InstallationDate: Installed on 2021-04-15 (0 days ago)
  InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  Python3Details: /usr/bin/python3.8, Python 3.8.6, python3-minimal, 
3.8.6-0ubuntu1
  PythonDetails: N/A
  RebootRequiredPkgs: gnome-shell
  RelatedPackageVersions:
   dpkg 1.20.5ubuntu2
   apt  2.1.10ubuntu0.3
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 1: 
/etc/ssh/sshd_config: No such file or directory
  SourcePackage: openssh
  Title: package openssh-server 1:8.3p1-1ubuntu0.1 failed to install/upgrade: 
podproces zainstalowany pakiet openssh-server skrypt post-installation zwrócił 
kod błędu 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.ssh.moduli: [deleted]

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

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


[Touch-packages] [Bug 1921562] Re: Intermittent hangs during ldap_search_ext when TLS enabled

2021-04-14 Thread Utkarsh Gupta
Hi Vincent,

> The bug hasn't returned since I installed the fixed package and no
> new issues have cropped up.

Awesome, thank you for your confirmation! \o/

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

Title:
  Intermittent hangs during ldap_search_ext when TLS enabled

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Focal:
  In Progress
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  

  When connecting to an LDAP server with TLS, ldap_search_ext can hang
  if during the initial TLS handshake a signal is received by the
  process. The cause of this bug is the same as
  https://bugs.openldap.org/show_bug.cgi?id=8650.

  In our case this bug cause failures in the SSSD LDAP backend at least
  once per day, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit.

  
  [Test Plan]
  ===

  When using openldap on 20.04, this bug causes failures in the SSSD
  LDAP backend, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit:

  Mar 19 19:05:31 mail auth[867454]: pam_sss(dovecot:auth): received for user 
redacted: 4 (System error)
  Mar 19 19:05:32 mail sssd_be[867455]: Starting up

  With the patched version, this should no longer be a problem.

  
  [Where Problems Could Occur]
  

  With this patch applied, there may be few edge cases in (and varying
  b/w) different versions of GnuTLS. And also some bits that are
  discussed in https://bugs.openldap.org/show_bug.cgi?id=8650.

  But that said, the patched version is already being run in production
  for over two weeks time (at the time of writing - 07/04/21). So I
  believe the SRU will clearly benefit from this and has lower risk of
  regression.

  
  [More Info]
  ===

  A reduced version of the patch linked above can be found attached to
  this bug report. This patch has been applied to version 2.4.49+dfsg-
  2ubuntu1.7 and has been running in production for approximately a week
  and the issue has no longer occurred. No other issues have appeared
  during this period.

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

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


[Touch-packages] [Bug 1921562] Re: Intermittent hangs during ldap_search_ext when TLS enabled

2021-04-07 Thread Utkarsh Gupta
** Merge proposal linked:
   
https://code.launchpad.net/~utkarsh/ubuntu/+source/openldap/+git/openldap/+merge/400754

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

Title:
  Intermittent hangs during ldap_search_ext when TLS enabled

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Focal:
  In Progress

Bug description:
  [Impact]
  

  When connecting to an LDAP server with TLS, ldap_search_ext can hang
  if during the initial TLS handshake a signal is received by the
  process. The cause of this bug is the same as
  https://bugs.openldap.org/show_bug.cgi?id=8650.

  In our case this bug cause failures in the SSSD LDAP backend at least
  once per day, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit.

  
  [Test Plan]
  ===

  When using openldap on 20.04, this bug causes failures in the SSSD
  LDAP backend, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit:

  Mar 19 19:05:31 mail auth[867454]: pam_sss(dovecot:auth): received for user 
redacted: 4 (System error)
  Mar 19 19:05:32 mail sssd_be[867455]: Starting up

  With the patched version, this should no longer be a problem.

  
  [Where Problems Could Occur]
  

  With this patch applied, there may be few edge cases in (and varying
  b/w) different versions of GnuTLS. And also some bits that are
  discussed in https://bugs.openldap.org/show_bug.cgi?id=8650.

  But that said, the patched version is already being run in production
  for over two weeks time (at the time of writing - 07/04/21). So I
  believe the SRU will clearly benefit from this and has lower risk of
  regression.

  
  [More Info]
  ===

  A reduced version of the patch linked above can be found attached to
  this bug report. This patch has been applied to version 2.4.49+dfsg-
  2ubuntu1.7 and has been running in production for approximately a week
  and the issue has no longer occurred. No other issues have appeared
  during this period.

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

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


[Touch-packages] [Bug 1921562] Re: Intermittent hangs during ldap_search_ext when TLS enabled

2021-04-07 Thread Utkarsh Gupta
** Description changed:

+ [Impact]
+ 
+ 
  When connecting to an LDAP server with TLS, ldap_search_ext can hang if
  during the initial TLS handshake a signal is received by the process.
  The cause of this bug is the same as
- https://bugs.openldap.org/show_bug.cgi?id=8650 which was fixed in
- https://git.openldap.org/openldap/openldap/-/commit/735e1ab and was
- released as part of version 2.4.50. This bug effects Ubuntu 20.04 LTS
- and potentially earlier Ubuntu releases. Later Ubuntu releases use an
- openldap version that is at least 2.4.50 and are therefore not affected.
+ https://bugs.openldap.org/show_bug.cgi?id=8650.
  
  In our case this bug cause failures in the SSSD LDAP backend at least
  once per day, resulting in authentication errors followed by a sssd_be
+ restart after a timeout has been hit.
+ 
+ 
+ [Test Plan]
+ ===
+ 
+ When using openldap on 20.04, this bug causes failures in the SSSD LDAP
+ backend, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit:
  
  Mar 19 19:05:31 mail auth[867454]: pam_sss(dovecot:auth): received for user 
redacted: 4 (System error)
  Mar 19 19:05:32 mail sssd_be[867455]: Starting up
+ 
+ With the patched version, this should no longer be a problem.
+ 
+ 
+ [Where Problems Could Occur]
+ 
+ 
+ With this patch applied, there may be few edge cases in (and varying
+ b/w) different versions of GnuTLS. And also some bits that are discussed
+ in https://bugs.openldap.org/show_bug.cgi?id=8650.
+ 
+ But that said, the patched version is already being run in production
+ for over two weeks time (at the time of writing - 07/04/21). So I
+ believe the SRU will clearly benefit from this and has lower risk of
+ regression.
+ 
+ 
+ [More Info]
+ ===
  
  A reduced version of the patch linked above can be found attached to
  this bug report. This patch has been applied to version 2.4.49+dfsg-
  2ubuntu1.7 and has been running in production for approximately a week
  and the issue has no longer occurred. No other issues have appeared
  during this period.
- 
- As this bug affects all systems using LDAP with TLS, I suggest that the
- fix for this bug is ported to Ubuntu 20.04 LTS and potentially earlier
- versions.

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

Title:
  Intermittent hangs during ldap_search_ext when TLS enabled

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Focal:
  In Progress

Bug description:
  [Impact]
  

  When connecting to an LDAP server with TLS, ldap_search_ext can hang
  if during the initial TLS handshake a signal is received by the
  process. The cause of this bug is the same as
  https://bugs.openldap.org/show_bug.cgi?id=8650.

  In our case this bug cause failures in the SSSD LDAP backend at least
  once per day, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit.

  
  [Test Plan]
  ===

  When using openldap on 20.04, this bug causes failures in the SSSD
  LDAP backend, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit:

  Mar 19 19:05:31 mail auth[867454]: pam_sss(dovecot:auth): received for user 
redacted: 4 (System error)
  Mar 19 19:05:32 mail sssd_be[867455]: Starting up

  With the patched version, this should no longer be a problem.

  
  [Where Problems Could Occur]
  

  With this patch applied, there may be few edge cases in (and varying
  b/w) different versions of GnuTLS. And also some bits that are
  discussed in https://bugs.openldap.org/show_bug.cgi?id=8650.

  But that said, the patched version is already being run in production
  for over two weeks time (at the time of writing - 07/04/21). So I
  believe the SRU will clearly benefit from this and has lower risk of
  regression.

  
  [More Info]
  ===

  A reduced version of the patch linked above can be found attached to
  this bug report. This patch has been applied to version 2.4.49+dfsg-
  2ubuntu1.7 and has been running in production for approximately a week
  and the issue has no longer occurred. No other issues have appeared
  during this period.

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

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


[Touch-packages] [Bug 1921562] Re: Intermittent hangs during ldap_search_ext when TLS enabled

2021-04-07 Thread Utkarsh Gupta
Hello Vincent,

I've uploaded a fixed package in my PPA:
https://launchpad.net/~utkarsh/+archive/ubuntu/experimental-dump. Could
you please test this if it work alright for you before I push this to
the official archive?

Thanks!

** Changed in: openldap (Ubuntu Focal)
 Assignee: (unassigned) => Utkarsh Gupta (utkarsh)

** Changed in: openldap (Ubuntu Focal)
   Status: Triaged => In Progress

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

Title:
  Intermittent hangs during ldap_search_ext when TLS enabled

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Focal:
  In Progress

Bug description:
  When connecting to an LDAP server with TLS, ldap_search_ext can hang
  if during the initial TLS handshake a signal is received by the
  process. The cause of this bug is the same as
  https://bugs.openldap.org/show_bug.cgi?id=8650 which was fixed in
  https://git.openldap.org/openldap/openldap/-/commit/735e1ab and was
  released as part of version 2.4.50. This bug effects Ubuntu 20.04 LTS
  and potentially earlier Ubuntu releases. Later Ubuntu releases use an
  openldap version that is at least 2.4.50 and are therefore not
  affected.

  In our case this bug cause failures in the SSSD LDAP backend at least
  once per day, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit:

  Mar 19 19:05:31 mail auth[867454]: pam_sss(dovecot:auth): received for user 
redacted: 4 (System error)
  Mar 19 19:05:32 mail sssd_be[867455]: Starting up

  A reduced version of the patch linked above can be found attached to
  this bug report. This patch has been applied to version 2.4.49+dfsg-
  2ubuntu1.7 and has been running in production for approximately a week
  and the issue has no longer occurred. No other issues have appeared
  during this period.

  As this bug affects all systems using LDAP with TLS, I suggest that
  the fix for this bug is ported to Ubuntu 20.04 LTS and potentially
  earlier versions.

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

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


[Touch-packages] [Bug 1921562] Re: Intermittent hangs during ldap_search_ext when TLS enabled

2021-04-05 Thread Utkarsh Gupta
Hello Vincent,

Since the Debian version has these fixes incorporated, this would be
fixed in Hirsute already (as it's in sync (with a minor delta)). For
Focal, it will need somebody affected to commit to doing the necessary
QA after the update is prepared (without that QA, we won't be able to
land the update).

The process is documented at
https://wiki.ubuntu.com/StableReleaseUpdates#Procedure. I'll add this
task to the server team's backlog. If you'd like to do it sooner, you
are welcome to prepare the update yourself following the documented
process.

Thanks!

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

** Changed in: openldap (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: openldap (Ubuntu Focal)
   Status: New => Triaged

** Tags added: bitesize server-next

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

Title:
  Intermittent hangs during ldap_search_ext when TLS enabled

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Focal:
  Triaged

Bug description:
  When connecting to an LDAP server with TLS, ldap_search_ext can hang
  if during the initial TLS handshake a signal is received by the
  process. The cause of this bug is the same as
  https://bugs.openldap.org/show_bug.cgi?id=8650 which was fixed in
  https://git.openldap.org/openldap/openldap/-/commit/735e1ab and was
  released as part of version 2.4.50. This bug effects Ubuntu 20.04 LTS
  and potentially earlier Ubuntu releases. Later Ubuntu releases use an
  openldap version that is at least 2.4.50 and are therefore not
  affected.

  In our case this bug cause failures in the SSSD LDAP backend at least
  once per day, resulting in authentication errors followed by a sssd_be
  restart after a timeout has been hit:

  Mar 19 19:05:31 mail auth[867454]: pam_sss(dovecot:auth): received for user 
redacted: 4 (System error)
  Mar 19 19:05:32 mail sssd_be[867455]: Starting up

  A reduced version of the patch linked above can be found attached to
  this bug report. This patch has been applied to version 2.4.49+dfsg-
  2ubuntu1.7 and has been running in production for approximately a week
  and the issue has no longer occurred. No other issues have appeared
  during this period.

  As this bug affects all systems using LDAP with TLS, I suggest that
  the fix for this bug is ported to Ubuntu 20.04 LTS and potentially
  earlier versions.

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

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


[Touch-packages] [Bug 1922212] Re: SSHD does not honor configuration files

2021-04-02 Thread Utkarsh Gupta
Hello Jerrey,

Thank you for taking out time to file a bug and making the Ubuntu server
better.

It's a bit upsetting that you're hitting this bug. Can you share your
entire conf, please? This would help me better analyze the problem and
help me reproduce it.

While at it, could you also help me provide steps to reproduce this
easily? I can make out the issue but having straightforward steps
written will help me debug this fast enough.

That said, I found a link to stack exchange that might help: 
https://unix.stackexchange.com/questions/218034/disabling-ssh-password-authentication-does-not-work-on-my-debian-vps
Let me know if it helps? Also, does restarting sshd help?

I am marking this bug as "Incomplete" for now. Once you provide the
necessary details, please mark it back to "New" and then we can take a
look and help debug further. Thanks! :)

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

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

Title:
  SSHD does not honor configuration files

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  I'm working on Ubuntu 20, x86_64, fully patched.

 # lsb_release -a
 Distributor ID:Ubuntu
 Description:   Ubuntu 20.04.2 LTS
 ...

  We are seeing reports of failed password-based logins using root:

 jounralctl -xe
 ...
 Apr 01 09:08:21 localhost sshd[239302]: Failed password for root from 
49.88.112.77 port 36206 ssh2
 Apr 01 09:08:21 localhost sshd[239302]: Failed password for root from 
49.88.112.77 port 36206 ssh2
 ...

  There are three attempts every second or two (literally):

 # journalctl -xe | grep -i -c 'Failed password for root'
 324

  Our OpenSSH server is configured with both no-password based logins
  and no-root logins.

 # ls /etc/ssh/sshd_config.d/
 10_pubkey_auth.conf  20_disable_root_login.conf

 # cat /etc/ssh/sshd_config.d/10_pubkey_auth.conf 
 # Disable passwords
 PasswordAuthentication no
 ChallengeResponseAuthentication no
 UsePAM no
 # Enable public key
 PubkeyAuthentication yes

 # cat /etc/ssh/sshd_config.d/20_disable_root_login.conf 
 PermitRootLogin no

  The config files are included last in our /etc/ssh/sshd_config file:

 # tail -n 3 /etc/ssh/sshd_config

 # For some reason OpenSSH does not include additional conf files by 
default.
 Include /etc/ssh/sshd_config.d/*.conf

  I dislike modifying /etc/ssh/sshd_config since it will be overwritten
  by the distro. With that said, I modified it without success.

  It really annoys me that we can't secure this service. Something looks
  very broken here.

  -

  # apt-cache show openssh-server
  Package: openssh-server
  Architecture: amd64
  Version: 1:8.2p1-4ubuntu0.2
  Multi-Arch: foreign
  Priority: optional
  Section: net
  Source: openssh
  Origin: Ubuntu
  Maintainer: Ubuntu Developers 
  Original-Maintainer: Debian OpenSSH Maintainers 
  Bugs: https://bugs.launchpad.net/ubuntu/+filebug

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

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


[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-03-19 Thread Utkarsh Gupta
Hello,

I just did the verification and the upgrade seems to be working as
intended for me. I went ahead and added the verficiation-done tag (and
the release-specific tags as well!).

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

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Bionic:
  Fix Committed
Status in isc-dhcp source package in Focal:
  Fix Committed
Status in isc-dhcp source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

  When checking isc-dhcp-server unit file it was seen that isc-dhcp-
  server is being started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  This causes the service to listen on all interfaces, which is what the
  user might not want. In case the user wants to use *only* IPv6 and not
  IPv4, this could maybe lead to problems as what the user intended to
  do could be really different from what the outcome turns out to be
  (because of this bug).

  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so
  long.

  The SRU would split the variables into respective names, thereby
  making sure that what /etc/default/isc-dhcp-serve sets, is available
  in the respective service file.

  [Test Plan]

  To reproduce this bug, simply do the following:

  $ lxc launch ubuntu-daily:focal isc-dhcp-lp1894172-focal

  $ lxc shell isc-dhcp-lp1894172-focal

  # apt update && apt install isc-dhcp-server -y

  # grep "INTERFACES" /etc/default/isc-dhcp-server
  INTERFACESv4=""
  INTERFACESv6=""

  grep "INTERFACES" /lib/systemd/system/isc-dhcp-server.service
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  # grep "INTERFACES" /lib/systemd/system/isc-dhcp-server6.service
  exec dhcpd -user dhcpd -group dhcpd -f -6 -pf /run/dhcp-server/dhcpd6.pid 
-cf $CONFIG_FILE $INTERFACES'

  With this, it is clearly visible that even though /lib/systemd/system
  /isc-dhcp-server{,6}.service file uses the INTERFACES variable but the
  /etc/default/isc-dhcp-server defines 2 different variables,
  INTERFACESv4 and INTERFACESv6.

  After the SRU is performed, the respective services files should use
  INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.

  To ensure smooth upgrade of this package, we'd check if the user
  hasn't manually set a INTERFACESv{4,6} variable to workaround this
  bug. If they have, then we simply check and make sure, we use the
  correct variable.

  [Where problems could occur]

  The problem could occur if the user has manually set some different
  workaround for this bug and so the usual upgrade could break some of
  their old configuration(s).

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

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


[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-03-12 Thread Utkarsh Gupta
Hey,

The above regression was a false-positive; there were several retries,
all of them passed (cf:
https://autopkgtest.ubuntu.com/packages/c/chrony/bionic/armhf).

So this should be good to go (regression-wise)! \o/

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Bionic:
  Fix Committed
Status in isc-dhcp source package in Focal:
  Fix Committed
Status in isc-dhcp source package in Groovy:
  Fix Committed

Bug description:
  [Impact]

  When checking isc-dhcp-server unit file it was seen that isc-dhcp-
  server is being started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  This causes the service to listen on all interfaces, which is what the
  user might not want. In case the user wants to use *only* IPv6 and not
  IPv4, this could maybe lead to problems as what the user intended to
  do could be really different from what the outcome turns out to be
  (because of this bug).

  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so
  long.

  The SRU would split the variables into respective names, thereby
  making sure that what /etc/default/isc-dhcp-serve sets, is available
  in the respective service file.

  [Test Plan]

  To reproduce this bug, simply do the following:

  $ lxc launch ubuntu-daily:focal isc-dhcp-lp1894172-focal

  $ lxc shell isc-dhcp-lp1894172-focal

  # apt update && apt install isc-dhcp-server -y

  # grep "INTERFACES" /etc/default/isc-dhcp-server
  INTERFACESv4=""
  INTERFACESv6=""

  grep "INTERFACES" /lib/systemd/system/isc-dhcp-server.service
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  # grep "INTERFACES" /lib/systemd/system/isc-dhcp-server6.service
  exec dhcpd -user dhcpd -group dhcpd -f -6 -pf /run/dhcp-server/dhcpd6.pid 
-cf $CONFIG_FILE $INTERFACES'

  With this, it is clearly visible that even though /lib/systemd/system
  /isc-dhcp-server{,6}.service file uses the INTERFACES variable but the
  /etc/default/isc-dhcp-server defines 2 different variables,
  INTERFACESv4 and INTERFACESv6.

  After the SRU is performed, the respective services files should use
  INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.

  To ensure smooth upgrade of this package, we'd check if the user
  hasn't manually set a INTERFACESv{4,6} variable to workaround this
  bug. If they have, then we simply check and make sure, we use the
  correct variable.

  [Where problems could occur]

  The problem could occur if the user has manually set some different
  workaround for this bug and so the usual upgrade could break some of
  their old configuration(s).

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

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


[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-03-09 Thread Utkarsh Gupta
** Description changed:

  [Impact]
  
  When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
  is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
  
  This causes the service to listen on all interfaces, which is what the
  user might not want. In case the user wants to use *only* IPv6 and not
  IPv4, this could maybe lead to problems as what the user intended to do
  could be really different from what the outcome turns out to be (because
  of this bug).
  
  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so long.
  
  The SRU would split the variables into respective names, thereby making
  sure that what /etc/default/isc-dhcp-serve sets, is available in the
  respective service file.
  
  [Test Plan]
  
- To reproduce, simply install isc-dhcp-server via apt.
- Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable.
+ To reproduce this bug, simply do the following:
+ 
+ $ lxc launch ubuntu-daily:focal isc-dhcp-lp1894172-focal
+ 
+ $ lxc shell isc-dhcp-lp1894172-focal
+ 
+ # apt update && apt install isc-dhcp-server -y
+ 
+ # grep "INTERFACES" /etc/default/isc-dhcp-server 
+ INTERFACESv4=""
+ INTERFACESv6=""
+ 
+ grep "INTERFACES" /lib/systemd/system/isc-dhcp-server.service
+ exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
+ 
+ # grep "INTERFACES" /lib/systemd/system/isc-dhcp-server6.service
+ exec dhcpd -user dhcpd -group dhcpd -f -6 -pf /run/dhcp-server/dhcpd6.pid 
-cf $CONFIG_FILE $INTERFACES'
+ 
+ 
+ With this, it is clearly visible that even though 
/lib/systemd/system/isc-dhcp-server{,6}.service file uses $INTERFACES variable 
but the /etc/default/isc-dhcp-server defines 2 different variables, 
INTERFACESv4 and INTERFACESv6.
  
  After the SRU is performed, the respective services files should use
  INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.
  
  To ensure smooth upgrade of this package, we'd check if the user hasn't
  manually set a INTERFACESv{4,6} variable to workaround this bug. If they
  have, then we simply check and make sure, we use the correct variable.
  
  [Where problems could occur]
  
  The problem could occur if the user has manually set some different
  workaround for this bug and so the usual upgrade could break some of
  their old configuration(s).

** Description changed:

  [Impact]
  
  When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
  is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
  
  This causes the service to listen on all interfaces, which is what the
  user might not want. In case the user wants to use *only* IPv6 and not
  IPv4, this could maybe lead to problems as what the user intended to do
  could be really different from what the outcome turns out to be (because
  of this bug).
  
  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so long.
  
  

[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-03-09 Thread Utkarsh Gupta
** Description changed:

  [Impact]
  
  When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
  is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
- CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
- if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
- [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
- chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
- chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
- exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
+ CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
+ if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
+ [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
+ chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
+ chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
+ exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
+ 
+ This causes the service to listen on all interfaces, which is what the
+ user might not want. In case the user wants to use *only* IPv6 and not
+ IPv4, this could maybe lead to problems as what the user intended to do
+ and what the outcome turns out because of this bug could be really
+ different.
  
  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so long.
  
  The SRU would split the variables into respective names, thereby making
  sure that what /etc/default/isc-dhcp-serve sets, is available in the
  respective service file.
  
- 
  [Test Plan]
  
  To reproduce, simply install isc-dhcp-server via apt.
- Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable. 
+ Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable.
  
  After the SRU is performed, the respective services files should use
  INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.
  
  To ensure smooth upgrade of this package, we'd check if the user hasn't
  manually set a INTERFACESv{4,6} variable to workaround this bug. If they
  have, then we simply check and make sure, we use the correct variable.
  
- 
  [Where problems could occur]
  
  The problem could occur if the user has manually set some different
  workaround this bug and so the usual upgrade could break some of their
  old configuration.

** Description changed:

  [Impact]
  
  When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
  is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
  
  This causes the service to listen on all interfaces, which is what the
  user might not want. In case the user wants to use *only* IPv6 and not
  IPv4, this could maybe lead to problems as what the user intended to do
- and what the outcome turns out because of this bug could be really
- different.
+ could be really different from what the outcome turns out to be (because
+ of this bug).
  
  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so long.
  
  The SRU would split the variables into 

[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-03-09 Thread Utkarsh Gupta
** Description changed:

- When checking isc-dhcp-server unit file I saw isc-dhcp-server is being
- started by:
+ [Impact]
+ 
+ When checking isc-dhcp-server unit file it was seen that isc-dhcp-server
+ is being started by:
  
  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf
  
  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'
  
  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.
  
- This has only been working because cmdline sets -4 and subnet
- declaration in dhcpd.conf file makes dhcp-server to bind to the correct
- interfaces, as it looks like.
+ The previous upload(er) forgot to mention (and split) the INTERFACES
+ variable to v4 and v6 and as a result, it has been this way for so long.
+ 
+ The SRU would split the variables into respective names, thereby making
+ sure that what /etc/default/isc-dhcp-serve sets, is available in the
+ respective service file.
+ 
+ 
+ [Test Plan]
+ 
+ To reproduce, simply install isc-dhcp-server via apt.
+ Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable. 
+ 
+ After the SRU is performed, the respective services files should use
+ INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.
+ 
+ To ensure smooth upgrade of this package, we'd check if the user hasn't
+ manually set a INTERFACESv{4,6} variable to workaround this bug. If they
+ have, then we simply check and make sure, we use the correct variable.
+ 
+ 
+ [Where problems could occur]
+ 
+ The problem could occur if the user has manually set some different
+ workaround this bug and so the usual upgrade could break some of their
+ old configuration.

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Bionic:
  Confirmed
Status in isc-dhcp source package in Focal:
  Confirmed
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  [Impact]

  When checking isc-dhcp-server unit file it was seen that isc-dhcp-
  server is being started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  The previous upload(er) forgot to mention (and split) the INTERFACES
  variable to v4 and v6 and as a result, it has been this way for so
  long.

  The SRU would split the variables into respective names, thereby
  making sure that what /etc/default/isc-dhcp-serve sets, is available
  in the respective service file.

  
  [Test Plan]

  To reproduce, simply install isc-dhcp-server via apt.
  Now, if you see the /etc/default/isc-dhcp-server file, it sets 2 variables, 
namely, INTERFACESv4 and INTERFACESv6. However, if you check the respective 
services file, that is, /lib/systemd/system/isc-dhcp-server.service and 
/lib/systemd/system/isc-dhcp-server6.service, it is still using the INTERFACES 
variable. 

  After the SRU is performed, the respective services files should use
  INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.

  To ensure smooth upgrade of this package, we'd check if the user
  hasn't manually set a 

[Touch-packages] [Bug 1891548] Re: autofs-ldap's /etc/ldap/schema/autofs.schema crashes slapd

2021-03-08 Thread Utkarsh Gupta
Hiya,

This was fixed in Debian via 5.1.6-4, which is merged in Hirsute release
(5.1.6-4ubuntu1). Therefore, I am marking this as "Fix Released" for
Hirsute. Should you have any questions or problems wrt this, let me
know!

Thanks.

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

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

Title:
  autofs-ldap's /etc/ldap/schema/autofs.schema crashes slapd

Status in autofs package in Ubuntu:
  Fix Released
Status in openldap package in Ubuntu:
  New
Status in autofs package in Debian:
  Fix Released

Bug description:
  Ubuntu Release:
  # lsb_release -rd
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  Version of packages in use:
  # dpkg -l autofs autofs-ldap slapd | grep '^ii'
  ii  autofs 5.1.6-2ubuntu0.1   amd64kernel-based 
automounter for Linux
  ii  autofs-ldap5.1.6-2ubuntu0.1   amd64LDAP map support for 
autofs
  ii  slapd  2.4.49+dfsg-2ubuntu1.3 amd64OpenLDAP server (slapd)

  Expected:
  No errors from slaptest

  Actual Output:
  5f359370 /etc/ldap/schema/autofs.schema: line 14 attributetype: AttributeType 
inappropriate matching rule: "caseExactMatch"

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

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


[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-02-26 Thread Utkarsh Gupta
** Changed in: isc-dhcp (Ubuntu)
   Status: In Progress => Fix Released

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Bionic:
  Confirmed
Status in isc-dhcp source package in Focal:
  Confirmed
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  When checking isc-dhcp-server unit file I saw isc-dhcp-server is being
  started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  This has only been working because cmdline sets -4 and subnet
  declaration in dhcpd.conf file makes dhcp-server to bind to the
  correct interfaces, as it looks like.

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

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


[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-02-26 Thread Utkarsh Gupta
** Changed in: isc-dhcp (Ubuntu Groovy)
   Status: Fix Released => Confirmed

** Changed in: isc-dhcp (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: isc-dhcp (Ubuntu)
 Assignee: (unassigned) => Utkarsh Gupta (utkarsh)

** Changed in: isc-dhcp (Ubuntu Bionic)
 Assignee: (unassigned) => Utkarsh Gupta (utkarsh)

** Changed in: isc-dhcp (Ubuntu Focal)
 Assignee: (unassigned) => Utkarsh Gupta (utkarsh)

** Changed in: isc-dhcp (Ubuntu Groovy)
 Assignee: (unassigned) => Utkarsh Gupta (utkarsh)

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Bionic:
  Confirmed
Status in isc-dhcp source package in Focal:
  Confirmed
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  When checking isc-dhcp-server unit file I saw isc-dhcp-server is being
  started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  This has only been working because cmdline sets -4 and subnet
  declaration in dhcpd.conf file makes dhcp-server to bind to the
  correct interfaces, as it looks like.

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

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


[Touch-packages] [Bug 1774342] Re: /lib/systemd/system/isc-dhcp-server.service $INTERFACES variable

2021-02-26 Thread Utkarsh Gupta
*** This bug is a duplicate of bug 1894172 ***
https://bugs.launchpad.net/bugs/1894172

** Also affects: isc-dhcp (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: isc-dhcp (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

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

Title:
  /lib/systemd/system/isc-dhcp-server.service $INTERFACES variable

Status in isc-dhcp package in Ubuntu:
  New
Status in isc-dhcp source package in Bionic:
  New
Status in isc-dhcp source package in Focal:
  New
Status in isc-dhcp source package in Groovy:
  New
Status in isc-dhcp source package in Hirsute:
  New

Bug description:
  package: isc-dhcp-server

  /etc/default/isc-dhcp-server define the variables INTERFACESv4 and
  INTERFACESv6 for define listening network interface, but
  /lib/systemd/system/isc-dhcp-server.service and /lib/systemd/system
  /isc-dhcp-server6.service use the variable INTERFACES (exec dhcpd
  -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf
  $CONFIG_FILE $INTERFACES'). This causes the service to listen on all
  interfaces.

  The correct way would be for /lib/systemd/system/isc-dhcp-server.service:
  ..
   exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf 
$CONFIG_FILE $INTERFACESv4'
  ..

  for /lib/systemd/system/isc-dhcp-server.service:
  ..
  exec dhcpd -user dhcpd -group dhcpd -f -6 -pf /run/dhcp-server/dhcpd6.pid -cf 
$CONFIG_FILE $INTERFACESv6'
  .

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

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


[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-02-26 Thread Utkarsh Gupta
** Changed in: isc-dhcp (Ubuntu Bionic)
   Status: Triaged => Confirmed

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in isc-dhcp source package in Bionic:
  Confirmed
Status in isc-dhcp source package in Focal:
  Confirmed
Status in isc-dhcp source package in Groovy:
  Fix Released

Bug description:
  When checking isc-dhcp-server unit file I saw isc-dhcp-server is being
  started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  This has only been working because cmdline sets -4 and subnet
  declaration in dhcpd.conf file makes dhcp-server to bind to the
  correct interfaces, as it looks like.

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

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


[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-02-26 Thread Utkarsh Gupta
** Changed in: isc-dhcp (Ubuntu)
   Status: Fix Released => Confirmed

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in isc-dhcp source package in Bionic:
  Triaged
Status in isc-dhcp source package in Focal:
  Confirmed
Status in isc-dhcp source package in Groovy:
  Fix Released

Bug description:
  When checking isc-dhcp-server unit file I saw isc-dhcp-server is being
  started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  This has only been working because cmdline sets -4 and subnet
  declaration in dhcpd.conf file makes dhcp-server to bind to the
  correct interfaces, as it looks like.

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

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


[Touch-packages] [Bug 1774342] Re: /lib/systemd/system/isc-dhcp-server.service $INTERFACES variable

2021-02-26 Thread Utkarsh Gupta
*** This bug is a duplicate of bug 1894172 ***
https://bugs.launchpad.net/bugs/1894172

** No longer affects: isc-dhcp (Ubuntu Groovy)

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

Title:
  /lib/systemd/system/isc-dhcp-server.service $INTERFACES variable

Status in isc-dhcp package in Ubuntu:
  New
Status in isc-dhcp source package in Bionic:
  New
Status in isc-dhcp source package in Focal:
  New

Bug description:
  package: isc-dhcp-server

  /etc/default/isc-dhcp-server define the variables INTERFACESv4 and
  INTERFACESv6 for define listening network interface, but
  /lib/systemd/system/isc-dhcp-server.service and /lib/systemd/system
  /isc-dhcp-server6.service use the variable INTERFACES (exec dhcpd
  -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf
  $CONFIG_FILE $INTERFACES'). This causes the service to listen on all
  interfaces.

  The correct way would be for /lib/systemd/system/isc-dhcp-server.service:
  ..
   exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf 
$CONFIG_FILE $INTERFACESv4'
  ..

  for /lib/systemd/system/isc-dhcp-server.service:
  ..
  exec dhcpd -user dhcpd -group dhcpd -f -6 -pf /run/dhcp-server/dhcpd6.pid -cf 
$CONFIG_FILE $INTERFACESv6'
  .

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

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


[Touch-packages] [Bug 1774342] Re: /lib/systemd/system/isc-dhcp-server.service $INTERFACES variable

2021-02-26 Thread Utkarsh Gupta
*** This bug is a duplicate of bug 1894172 ***
https://bugs.launchpad.net/bugs/1894172

** Also affects: isc-dhcp (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: isc-dhcp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: isc-dhcp (Ubuntu Groovy)
   Importance: Undecided
   Status: New

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

Title:
  /lib/systemd/system/isc-dhcp-server.service $INTERFACES variable

Status in isc-dhcp package in Ubuntu:
  New
Status in isc-dhcp source package in Bionic:
  New
Status in isc-dhcp source package in Focal:
  New

Bug description:
  package: isc-dhcp-server

  /etc/default/isc-dhcp-server define the variables INTERFACESv4 and
  INTERFACESv6 for define listening network interface, but
  /lib/systemd/system/isc-dhcp-server.service and /lib/systemd/system
  /isc-dhcp-server6.service use the variable INTERFACES (exec dhcpd
  -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf
  $CONFIG_FILE $INTERFACES'). This causes the service to listen on all
  interfaces.

  The correct way would be for /lib/systemd/system/isc-dhcp-server.service:
  ..
   exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf 
$CONFIG_FILE $INTERFACESv4'
  ..

  for /lib/systemd/system/isc-dhcp-server.service:
  ..
  exec dhcpd -user dhcpd -group dhcpd -f -6 -pf /run/dhcp-server/dhcpd6.pid -cf 
$CONFIG_FILE $INTERFACESv6'
  .

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

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


[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES

2021-02-25 Thread Utkarsh Gupta
** Changed in: isc-dhcp (Ubuntu)
   Status: Triaged => Fix Released

** Also affects: isc-dhcp (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Changed in: isc-dhcp (Ubuntu Groovy)
   Status: New => Fix Released

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

Title:
  isc-dhcp-server using wrong env variable for INTERFACES

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Bionic:
  Triaged
Status in isc-dhcp source package in Focal:
  Confirmed
Status in isc-dhcp source package in Groovy:
  Fix Released

Bug description:
  When checking isc-dhcp-server unit file I saw isc-dhcp-server is being
  started by:

  ConditionPathExists=/etc/default/isc-dhcp-server
  ConditionPathExists=|/etc/ltsp/dhcpd.conf
  ConditionPathExists=|/etc/dhcp/dhcpd.conf

  [Service]
  EnvironmentFile=/etc/default/isc-dhcp-server
  RuntimeDirectory=dhcp-server
  # The leases files need to be root:dhcpd even when dropping privileges
  ExecStart=/bin/sh -ec '\
  CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
  if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; 
fi; \
  [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
  chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
  chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
  exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid 
-cf $CONFIG_FILE $INTERFACES'

  But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
  $INTERFACESv6.

  This has only been working because cmdline sets -4 and subnet
  declaration in dhcpd.conf file makes dhcp-server to bind to the
  correct interfaces, as it looks like.

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

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