| 2022-10-05 14:52:35 |
Alessandro Ratti |
bug |
|
|
added bug |
| 2022-10-05 15:33:54 |
Alessandro Ratti |
bug |
|
|
added subscriber Andreas Hasenack |
| 2022-10-05 20:20:40 |
Andreas Hasenack |
frr (Ubuntu): status |
New |
Triaged |
|
| 2022-10-05 20:20:46 |
Andreas Hasenack |
frr (Ubuntu): importance |
Undecided |
High |
|
| 2022-10-05 20:20:56 |
Andreas Hasenack |
tags |
|
server-todo |
|
| 2022-10-05 20:21:04 |
Andreas Hasenack |
bug |
|
|
added subscriber Canonical Server |
| 2022-10-05 20:21:11 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Server |
| 2022-10-06 09:32:28 |
Alessandro Ratti |
attachment added |
|
0001-attempt-to-fix-LP-1991812.patch https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1991812/+attachment/5621632/+files/0001-attempt-to-fix-LP-1991812.patch |
|
| 2022-10-06 12:33:53 |
Ubuntu Foundations Team Bug Bot |
tags |
server-todo |
patch server-todo |
|
| 2022-10-06 12:34:00 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2022-10-28 11:50:25 |
Andreas Hasenack |
frr (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2022-10-28 11:50:28 |
Andreas Hasenack |
frr (Ubuntu): status |
Triaged |
In Progress |
|
| 2022-10-28 17:09:29 |
Andreas Hasenack |
description |
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
[ 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]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
|
| 2022-10-28 17:13:16 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-10-28 17:13:16 |
Andreas Hasenack |
bug task added |
|
frr (Ubuntu Jammy) |
|
| 2022-10-28 17:13:16 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Focal |
|
| 2022-10-28 17:13:16 |
Andreas Hasenack |
bug task added |
|
frr (Ubuntu Focal) |
|
| 2022-10-28 17:13:16 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Kinetic |
|
| 2022-10-28 17:13:16 |
Andreas Hasenack |
bug task added |
|
frr (Ubuntu Kinetic) |
|
| 2022-10-28 17:13:24 |
Andreas Hasenack |
frr (Ubuntu Focal): status |
New |
Incomplete |
|
| 2022-10-28 17:13:28 |
Andreas Hasenack |
frr (Ubuntu Focal): status |
Incomplete |
In Progress |
|
| 2022-10-28 17:13:31 |
Andreas Hasenack |
frr (Ubuntu Jammy): status |
New |
In Progress |
|
| 2022-10-28 17:13:33 |
Andreas Hasenack |
frr (Ubuntu Kinetic): status |
New |
In Progress |
|
| 2022-10-28 17:13:36 |
Andreas Hasenack |
frr (Ubuntu Focal): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2022-10-28 17:13:38 |
Andreas Hasenack |
frr (Ubuntu Jammy): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2022-10-28 17:13:41 |
Andreas Hasenack |
frr (Ubuntu Kinetic): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2022-10-28 17:29:44 |
Andreas Hasenack |
description |
[ 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]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
[ Impact ]
Due to the previous frr bug #1958162, or perhaps other reasons, some users might have chosen to handle frr logging in a different way. If that change includes removing the syslog user from the system, then the current frr package will have a failure in postinst when it tries to adjust the ownership of log files to this syslog user.
The fix here is to gate that postinst chown action on the existence of the syslog user. If this user does not exist, we assume that this system is handling logging in some other way and won't attempt to change ownership of logfiles to syslog.
The added change is a valid sanity check, and is minimal in nature in the sense that it doesn't try to further complicate the logging adjustments in postinst. It should have been done in the previous change, but it was thought to be a corner case to not have the syslog user installed. Turns out it's quite possible and doable. One could argue it's still an exceptional case, but since the consequences are really bad (package fails to install), it's worth it fixing.
[ Test Plan ]
The test plan is a bit destructive, as it includes removing the syslog user.
# remove rsyslog
sudo apt update && sudo apt remove rsyslog -y
# remove the syslog user
sudo userdel syslog
# install frr
# without the fix, the installation will fail:
(...)
Adding new user `frr' (UID 103) with group `frr' ...
Not creating home directory `/nonexistent'.
chown: invalid user: ‘syslog:adm’
(...)
Installing the fixed package will work.
[ Where problems could occur ]
We are now *not* taking action if the syslog user does not exist. That user not existing is a strong indication of local user changes, and this is probably the safest action.
There might still be other ways out there users figured to adjust the logging of frr. Trying to cope with all of them can quickly become a complicated rabbit hole. We need to have the default install of ubuntu working well, and not break users who have added their own customizations.
[ 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]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
|
| 2022-10-28 17:30:54 |
Andreas Hasenack |
description |
[ Impact ]
Due to the previous frr bug #1958162, or perhaps other reasons, some users might have chosen to handle frr logging in a different way. If that change includes removing the syslog user from the system, then the current frr package will have a failure in postinst when it tries to adjust the ownership of log files to this syslog user.
The fix here is to gate that postinst chown action on the existence of the syslog user. If this user does not exist, we assume that this system is handling logging in some other way and won't attempt to change ownership of logfiles to syslog.
The added change is a valid sanity check, and is minimal in nature in the sense that it doesn't try to further complicate the logging adjustments in postinst. It should have been done in the previous change, but it was thought to be a corner case to not have the syslog user installed. Turns out it's quite possible and doable. One could argue it's still an exceptional case, but since the consequences are really bad (package fails to install), it's worth it fixing.
[ Test Plan ]
The test plan is a bit destructive, as it includes removing the syslog user.
# remove rsyslog
sudo apt update && sudo apt remove rsyslog -y
# remove the syslog user
sudo userdel syslog
# install frr
# without the fix, the installation will fail:
(...)
Adding new user `frr' (UID 103) with group `frr' ...
Not creating home directory `/nonexistent'.
chown: invalid user: ‘syslog:adm’
(...)
Installing the fixed package will work.
[ Where problems could occur ]
We are now *not* taking action if the syslog user does not exist. That user not existing is a strong indication of local user changes, and this is probably the safest action.
There might still be other ways out there users figured to adjust the logging of frr. Trying to cope with all of them can quickly become a complicated rabbit hole. We need to have the default install of ubuntu working well, and not break users who have added their own customizations.
[ 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]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
[ Impact ]
Due to the previous frr bug #1958162, or perhaps other reasons, some users might have chosen to handle frr logging in a different way. If that change includes removing the syslog user from the system, then the current frr package will have a failure in postinst when it tries to adjust the ownership of log files to this syslog user.
The fix here is to gate that postinst chown action on the existence of the syslog user. If this user does not exist, we assume that this system is handling logging in some other way and won't attempt to change ownership of logfiles to syslog.
The added change is a valid sanity check, and is minimal in nature in the sense that it doesn't try to further complicate the logging adjustments in postinst. It should have been done in the previous change, but it was thought to be a corner case to not have the syslog user installed. Turns out it's quite possible and doable. One could argue it's still an exceptional case, but since the consequences are really bad (package fails to install), it's worth it fixing.
[ Test Plan ]
The test plan is a bit destructive, as it includes removing the syslog user.
# remove rsyslog
sudo apt update && sudo apt remove rsyslog -y
# remove the syslog user
sudo userdel syslog
# install frr
# without the fix, the installation will fail:
(...)
Adding new user `frr' (UID 103) with group `frr' ...
Not creating home directory `/nonexistent'.
chown: invalid user: ‘syslog:adm’
(...)
Installing the fixed package will work.
[ Where problems could occur ]
We are now *not* taking action if the syslog user does not exist. That user not existing is a strong indication of local user changes, and this is probably the safest action.
There might still be other ways out there users figured to adjust the logging of frr. Trying to cope with all of them can quickly become a complicated rabbit hole. We need to have the default install of ubuntu working well, and not break users who have added their own customizations.
[ Other Info ]
None at this time.
[Original Description]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
|
| 2022-10-28 17:33:00 |
Andreas Hasenack |
description |
[ Impact ]
Due to the previous frr bug #1958162, or perhaps other reasons, some users might have chosen to handle frr logging in a different way. If that change includes removing the syslog user from the system, then the current frr package will have a failure in postinst when it tries to adjust the ownership of log files to this syslog user.
The fix here is to gate that postinst chown action on the existence of the syslog user. If this user does not exist, we assume that this system is handling logging in some other way and won't attempt to change ownership of logfiles to syslog.
The added change is a valid sanity check, and is minimal in nature in the sense that it doesn't try to further complicate the logging adjustments in postinst. It should have been done in the previous change, but it was thought to be a corner case to not have the syslog user installed. Turns out it's quite possible and doable. One could argue it's still an exceptional case, but since the consequences are really bad (package fails to install), it's worth it fixing.
[ Test Plan ]
The test plan is a bit destructive, as it includes removing the syslog user.
# remove rsyslog
sudo apt update && sudo apt remove rsyslog -y
# remove the syslog user
sudo userdel syslog
# install frr
# without the fix, the installation will fail:
(...)
Adding new user `frr' (UID 103) with group `frr' ...
Not creating home directory `/nonexistent'.
chown: invalid user: ‘syslog:adm’
(...)
Installing the fixed package will work.
[ Where problems could occur ]
We are now *not* taking action if the syslog user does not exist. That user not existing is a strong indication of local user changes, and this is probably the safest action.
There might still be other ways out there users figured to adjust the logging of frr. Trying to cope with all of them can quickly become a complicated rabbit hole. We need to have the default install of ubuntu working well, and not break users who have added their own customizations.
[ Other Info ]
None at this time.
[Original Description]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
[ Impact ]
Due to the previous frr bug #1958162, or perhaps other reasons, some users might have chosen to handle frr logging in a different way. If that change includes removing the syslog user from the system, then the current frr package will have a failure in postinst when it tries to adjust the ownership of log files to this syslog user.
The fix here is to gate that postinst chown action on the existence of the syslog user. If this user does not exist, we assume that this system is handling logging in some other way and won't attempt to change ownership of logfiles to syslog.
The added change is a valid sanity check, and is minimal in nature in the sense that it doesn't try to further complicate the logging adjustments in postinst. It should have been done in the previous change, but it was thought to be a corner case to not have the syslog user installed. Turns out it's quite possible and doable. One could argue it's still an exceptional case, but since the consequences are really bad (package fails to install), it's worth it fixing.
[ Test Plan ]
The test plan is a bit destructive, as it includes removing the syslog user.
# remove rsyslog
sudo apt update && sudo apt remove rsyslog -y
# remove the syslog user
sudo userdel syslog
# install frr
# without the fix, the installation will fail:
(...)
Adding new user `frr' (UID 103) with group `frr' ...
Not creating home directory `/nonexistent'.
chown: invalid user: ‘syslog:adm’
(...)
Installing the fixed package will work.
[ Where problems could occur ]
We are now *not* taking action if the syslog user does not exist. That user not existing is a strong indication of local user changes, and this is probably the safest action. There is no guarantee that frr logging will be working in this case.
There might still be other ways out there users figured to adjust the logging of frr. Trying to cope with all of them can quickly become a complicated rabbit hole. We need to have the default install of ubuntu working well, and not break users who have added their own customizations.
[ Other Info ]
None at this time.
[Original Description]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
|
| 2022-10-28 17:37:26 |
Andreas Hasenack |
description |
[ Impact ]
Due to the previous frr bug #1958162, or perhaps other reasons, some users might have chosen to handle frr logging in a different way. If that change includes removing the syslog user from the system, then the current frr package will have a failure in postinst when it tries to adjust the ownership of log files to this syslog user.
The fix here is to gate that postinst chown action on the existence of the syslog user. If this user does not exist, we assume that this system is handling logging in some other way and won't attempt to change ownership of logfiles to syslog.
The added change is a valid sanity check, and is minimal in nature in the sense that it doesn't try to further complicate the logging adjustments in postinst. It should have been done in the previous change, but it was thought to be a corner case to not have the syslog user installed. Turns out it's quite possible and doable. One could argue it's still an exceptional case, but since the consequences are really bad (package fails to install), it's worth it fixing.
[ Test Plan ]
The test plan is a bit destructive, as it includes removing the syslog user.
# remove rsyslog
sudo apt update && sudo apt remove rsyslog -y
# remove the syslog user
sudo userdel syslog
# install frr
# without the fix, the installation will fail:
(...)
Adding new user `frr' (UID 103) with group `frr' ...
Not creating home directory `/nonexistent'.
chown: invalid user: ‘syslog:adm’
(...)
Installing the fixed package will work.
[ Where problems could occur ]
We are now *not* taking action if the syslog user does not exist. That user not existing is a strong indication of local user changes, and this is probably the safest action. There is no guarantee that frr logging will be working in this case.
There might still be other ways out there users figured to adjust the logging of frr. Trying to cope with all of them can quickly become a complicated rabbit hole. We need to have the default install of ubuntu working well, and not break users who have added their own customizations.
[ Other Info ]
None at this time.
[Original Description]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
[ Impact ]
Due to the previous frr bug #1958162, or perhaps other reasons, some users might have chosen to handle frr logging in a different way. If that change includes removing the syslog user from the system, then the current frr package will have a failure in postinst when it tries to adjust the ownership of log files to this syslog user.
The fix here is to gate that postinst chown action on the existence of the syslog user. If this user does not exist, we assume that this system is handling logging in some other way and won't attempt to change ownership of logfiles to syslog.
The added change is a valid sanity check, and is minimal in nature in the sense that it doesn't try to further complicate the logging adjustments in postinst. It should have been done in the previous change, but it was thought to be a corner case to not have the syslog user installed. Turns out it's quite possible and doable. One could argue it's still an exceptional case, but since the consequences are really bad (package fails to install), it's worth it fixing.
[ Test Plan ]
The test plan is a bit destructive, as it includes removing the syslog user.
# remove rsyslog
sudo apt update && sudo apt remove rsyslog -y
# remove the syslog user
sudo userdel syslog
# install frr
# without the fix, the installation will fail:
sudo apt install frr -y
(...)
Adding new user `frr' (UID 103) with group `frr' ...
Not creating home directory `/nonexistent'.
chown: invalid user: ‘syslog:adm’
(...)
Installing the fixed package will work.
[ Where problems could occur ]
We are now *not* taking action if the syslog user does not exist. That user not existing is a strong indication of local user changes, and this is probably the safest action. There is no guarantee that frr logging will be working in this case.
There might still be other ways out there users figured to adjust the logging of frr. Trying to cope with all of them can quickly become a complicated rabbit hole. We need to have the default install of ubuntu working well, and not break users who have added their own customizations.
[ Other Info ]
None at this time.
[Original Description]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
|
| 2022-10-28 17:46:21 |
Andreas Hasenack |
description |
[ Impact ]
Due to the previous frr bug #1958162, or perhaps other reasons, some users might have chosen to handle frr logging in a different way. If that change includes removing the syslog user from the system, then the current frr package will have a failure in postinst when it tries to adjust the ownership of log files to this syslog user.
The fix here is to gate that postinst chown action on the existence of the syslog user. If this user does not exist, we assume that this system is handling logging in some other way and won't attempt to change ownership of logfiles to syslog.
The added change is a valid sanity check, and is minimal in nature in the sense that it doesn't try to further complicate the logging adjustments in postinst. It should have been done in the previous change, but it was thought to be a corner case to not have the syslog user installed. Turns out it's quite possible and doable. One could argue it's still an exceptional case, but since the consequences are really bad (package fails to install), it's worth it fixing.
[ Test Plan ]
The test plan is a bit destructive, as it includes removing the syslog user.
# remove rsyslog
sudo apt update && sudo apt remove rsyslog -y
# remove the syslog user
sudo userdel syslog
# install frr
# without the fix, the installation will fail:
sudo apt install frr -y
(...)
Adding new user `frr' (UID 103) with group `frr' ...
Not creating home directory `/nonexistent'.
chown: invalid user: ‘syslog:adm’
(...)
Installing the fixed package will work.
[ Where problems could occur ]
We are now *not* taking action if the syslog user does not exist. That user not existing is a strong indication of local user changes, and this is probably the safest action. There is no guarantee that frr logging will be working in this case.
There might still be other ways out there users figured to adjust the logging of frr. Trying to cope with all of them can quickly become a complicated rabbit hole. We need to have the default install of ubuntu working well, and not break users who have added their own customizations.
[ Other Info ]
None at this time.
[Original Description]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
[ Impact ]
Due to the previous frr bug #1958162, or perhaps other reasons, some users might have chosen to handle frr logging in a different way. If that change includes removing the syslog user from the system, then the current frr package will have a failure in postinst when it tries to adjust the ownership of log files to this syslog user.
The fix here is to gate that postinst chown action on the existence of the syslog user. If this user does not exist, we assume that this system is handling logging in some other way and won't attempt to change ownership of logfiles to syslog.
The added change is a valid sanity check, and is minimal in nature in the sense that it doesn't try to further complicate the logging adjustments in postinst. It should have been done in the previous change, but it was thought to be a corner case to not have the syslog user installed. Turns out it's quite possible and doable. One could argue it's still an exceptional case, but since the consequences are really bad (package fails to install), it's worth it fixing.
[ Test Plan ]
The test plan is a bit destructive, as it includes removing the syslog user.
a) Specific test for this bug
# remove rsyslog
sudo apt update && sudo apt remove rsyslog -y
# remove the syslog user
sudo userdel syslog
# install frr
# without the fix, the installation will fail:
sudo apt install frr -y
(...)
Adding new user `frr' (UID 103) with group `frr' ...
Not creating home directory `/nonexistent'.
chown: invalid user: ‘syslog:adm’
(...)
Installing the fixed package will work.
b) Regression test
Let's also make sure we are not regressing bug #1958162.
b1) Upgrade
# On a fresh system, install frr from updates (i.e., not the version from proposed):
sudo apt update && sudo apt install frr -y
# restart frr to trigger some logging
sudo systemctl restart frr
ls -lah /var/log/frr/frr.log
-rw-r----- 1 syslog adm 1.4K Oct 28 17:41 /var/log/frr/frr.log
Now upgrade to the package in proposed and repeat the steps above (restart and check for updates in the log file):
$ sudo systemctl restart frr
$ l /var/log/frr/frr.log
-rw-r----- 1 syslog adm 2.8K Oct 28 17:43 /var/log/frr/frr.log
b2) Fresh install of proposed package
# On a fresh system, install frr from *proposed*:
sudo apt update && sudo apt install frr -y
# restart frr to trigger some logging
sudo systemctl restart frr
$ l /var/log/frr/frr.log
-rw-r----- 1 syslog adm 1.4K Oct 28 17:45 /var/log/frr/frr.log
[ Where problems could occur ]
We are now *not* taking action if the syslog user does not exist. That user not existing is a strong indication of local user changes, and this is probably the safest action. There is no guarantee that frr logging will be working in this case.
There might still be other ways out there users figured to adjust the logging of frr. Trying to cope with all of them can quickly become a complicated rabbit hole. We need to have the default install of ubuntu working well, and not break users who have added their own customizations.
[ Other Info ]
None at this time.
[Original Description]
Ubuntu released a few weeks ago version 7.2.1-1ubuntu0.1 of Frr for Focal.
It's a minor change that attempts to fix a permission issue due to the inability of rsyslog to write within /var/log/frr, owned by the user frr, whereas the user syslog own's the rsyslog's process.
In our setup, we replaced rsyslog with syslog-ng, whose process runs as root and we removed the user syslog.
The new Frr package fails the postinstall script while performing the chown of the /var/log/frr and its content, breaking apt and leaving the package half installed.
When our config mgmt system tries to fix the issue, it fails because apt returns a non-zero code and doesn't apply the configuration needed by Frr to work correctly.
This issue is valid not only for Focal but also for Ubuntu Jammy. |
|
| 2022-10-28 17:49:26 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/frr/+git/frr/+merge/432329 |
|
| 2022-10-28 17:50:37 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/frr/+git/frr/+merge/432330 |
|
| 2022-10-28 17:50:50 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/frr/+git/frr/+merge/432331 |
|
| 2022-10-28 17:51:12 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/frr/+git/frr/+merge/432332 |
|
| 2022-11-20 05:23:14 |
Launchpad Janitor |
frr (Ubuntu): status |
In Progress |
Fix Released |
|
| 2022-12-02 12:54:02 |
Timo Aaltonen |
frr (Ubuntu Kinetic): status |
In Progress |
Fix Committed |
|
| 2022-12-02 12:54:04 |
Timo Aaltonen |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-12-02 12:54:08 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2022-12-02 12:54:13 |
Timo Aaltonen |
tags |
patch server-todo |
patch server-todo verification-needed verification-needed-kinetic |
|
| 2022-12-02 12:56:18 |
Timo Aaltonen |
frr (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2022-12-02 12:56:30 |
Timo Aaltonen |
tags |
patch server-todo verification-needed verification-needed-kinetic |
patch server-todo verification-needed verification-needed-jammy verification-needed-kinetic |
|
| 2022-12-02 13:02:53 |
Timo Aaltonen |
frr (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2022-12-02 13:03:02 |
Timo Aaltonen |
tags |
patch server-todo verification-needed verification-needed-jammy verification-needed-kinetic |
patch server-todo verification-needed verification-needed-focal verification-needed-jammy verification-needed-kinetic |
|
| 2022-12-07 14:49:58 |
Andreas Hasenack |
tags |
patch server-todo verification-needed verification-needed-focal verification-needed-jammy verification-needed-kinetic |
patch server-todo verification-done-kinetic verification-needed verification-needed-focal verification-needed-jammy |
|
| 2022-12-07 20:32:34 |
Andreas Hasenack |
tags |
patch server-todo verification-done-kinetic verification-needed verification-needed-focal verification-needed-jammy |
patch server-todo verification-done-jammy verification-done-kinetic verification-needed verification-needed-focal |
|
| 2022-12-07 20:49:17 |
Andreas Hasenack |
tags |
patch server-todo verification-done-jammy verification-done-kinetic verification-needed verification-needed-focal |
patch server-todo verification-done-focal verification-done-jammy verification-done-kinetic verification-needed |
|
| 2022-12-13 00:31:33 |
Launchpad Janitor |
frr (Ubuntu Kinetic): status |
Fix Committed |
Fix Released |
|
| 2022-12-13 00:31:38 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2022-12-13 00:31:54 |
Launchpad Janitor |
frr (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2022-12-13 00:32:13 |
Launchpad Janitor |
frr (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
