[Touch-packages] [Bug 2039252] Re: The packages ntp and ntpsec are not equivalent
You are correct that the multicast support has been removed in NTPsec. This was intentional: https://docs.ntpsec.org/latest/ntpsec.html "Broadcast- and multicast modes, which are impossible to secure, have been removed." The Debian maintainers of the "ntp" package decided to stop maintaining it. Rather than orphaning it, they asked on debian-devel and the consensus was to drop it entirely in favor of "ntpsec" (which I was already maintaining in Debian). It would be a pain, but if you wanted to pick up maintaining "ntp" in Debian again, that's theoretically possible. I wouldn't recommend it, and certainly not if the only missing thing is multicast support. Instead, I recommend you configure all of your clients to speak unicast to your NTP server. This is more-or-less the same effect anyway. It gives you the option to then "upgrade" to NTS (Network Time Security), if you desire. ** Changed in: ntp (Debian) Status: New => Invalid ** Changed in: ntp (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/2039252 Title: The packages ntp and ntpsec are not equivalent Status in ntp package in Ubuntu: Invalid Status in ntp package in Debian: Invalid Bug description: I recently did an install of Ubuntu 23.04 and then configured ntp as I have been doing so for more than 8 years. With previous versions of Debian and Ubuntu using the real ntp package, the details at https://wiki.ubuntu.com/JonathanFerguson/NTP?action=recall=38 created the desired results. I updated the details at https://wiki.ubuntu.com/JonathanFerguson/NTP with the new location of ntp.conf, after restarting I noticed that the resultant output was missing requisite details. Compare the following and the lack of ".MCST." and ".ACST.": Original ntp on Apollo-Lake-N3150 jonathan@Apollo-Lake-N3450:~$ lsb_release -rd Description:Ubuntu 22.04.3 LTS Release:22.04 jonathan@Apollo-Lake-N3450:~$ ntpq -p remote refid st t when poll reach delay offset jitter == 0.ubuntu.pool.n .POOL. 16 p- 6400.000 +0.000 0.000 1.ubuntu.pool.n .POOL. 16 p- 6400.000 +0.000 0.000 2.ubuntu.pool.n .POOL. 16 p- 6400.000 +0.000 0.000 3.ubuntu.pool.n .POOL. 16 p- 6400.000 +0.000 0.000 ntp.ubuntu.com .POOL. 16 p- 6400.000 +0.000 0.000 ntp.mcast.net .MCST. 16 M- 6400.000 +0.000 0.000 ff0e::101 .MCST. 16 M- 6400.000 +0.000 0.000 ntp.mcast.net .ACST. 16 a- 6400.000 +0.000 0.000 ff0e::101 .ACST. 16 a- 6400.000 +0.000 0.000 *time.cloudflare 10.242.8.77 3 u 469 1024 367 234.691 -0.929 67.380 +2001-44b8-2100- 42.3.115.79 2 u 581 1024 377 487.209 +55.669 57.154 +2001-44b8-2100- 4.179.66.17 3 u 215 1024 377 489.637 +57.002 35.399 jonathan@Apollo-Lake-N3450:~$ NTPsec on Braswell-N3150 jonathan@Braswell-N3150:~$ lsb_release -rd No LSB modules are available. Description:Ubuntu 23.04 Release:23.04 jonathan@Braswell-N3150:~$ ntpq -p remote refid st t when poll reach delay offset jitter === 0.ubuntu.pool.ntp.org .POOL. 16 p- 2560 0. 0. 0.0002 1.ubuntu.pool.ntp.org .POOL. 16 p- 2560 0. 0. 0.0002 2.ubuntu.pool.ntp.org .POOL. 16 p- 2560 0. 0. 0.0002 3.ubuntu.pool.ntp.org .POOL. 16 p- 640 0. 0. 0.0002 +prod-ntp-5.ntp1.ps5.canonical.com 37.15.221.1892 u 141 1024 367 383.4932 -19.6895 35.0534 *time.tfmcloud.au203.35.83.2422 u 325 1024 367 325.9317 -0.1496 43.0522 +any.time.nl 133.243.238.243 2 u 158 1024 373 300.7941 -20.8962 136.1422 +ntp2.its.waikato.ac.nz .GPS.1 u 363 1024 377 356.5361 -18.2740 140.5984 +2001-44b8-2100-3f00---007b-0004 42.3.115.79 2 u 214 1024 367 490.3898 28.3416 2.7728 +tic.ntp.telstra.net 203.35.83.2422 u 13 1024 367 566.0744 -14.1332 6.0377 +863xqmprtfqv69pv7nwc.ip6.superloop.au 192.168.1.1 2 u 79 1024 367 330.2658 -14.3483 16.2172 +gps-ads.10mrlp.juneks.com.au.PPS.1 u 271 1024 367 443.4812 -71.8020 44.6332 +x.ns.gin.ntt.net
[Touch-packages] [Bug 1892108] Re: ping prints ip address octets backwards on host redirect
I was able to verify this is fixed in iputils-ping 20210202-1. That is, I saw this same problem, grabbed those sources from Debian, built them, and tested again. Accordingly, this should already be fixed in Ubuntu impish. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1892108 Title: ping prints ip address octets backwards on host redirect Status in iputils package in Ubuntu: Confirmed Bug description: Description: Ubuntu 20.04.1 LTS Release: 20.04 Just noticed a weird thing with ping on Ubuntu 20.04, which I recently updated to. This is what I get when pinging a host on my network: user@ubuntu2004:~$ ping 10.156.0.63 PING 10.156.0.63 (10.156.0.63) 56(84) bytes of data. From 10.15.0.1 icmp_seq=2 Redirect Host(New nexthop: 2.0.15.10) The ubuntu2004 machine is located in the 10.15.0.x network. 10.15.0.1 is a DSL router. 10.15.0.2 is a firewall between multiple networks. 10.156.0.63 is a machine on a different local network. All traffic not destined for the internet is routed from 10.15.0.1 to 10.15.0.2, so I would expect the printout to read "New nexthop: 10.15.0.2". However, as you can see this is not the case. Instead the octets are printed in reverse order. To verify this I tried the same on another machine in the same network, running Ubuntu 18.04: user@ubuntu1804:~$ ping 10.156.0.63 PING 10.156.0.63 (10.156.0.63) 56(84) bytes of data. From 10.15.0.1: icmp_seq=2 Redirect Host(New nexthop: 10.15.0.2) As you can see, the printout is correct here: "New nexthop: 10.15.0.2" I further verified the discrepancy by using tcpdump to interpret the ICMP packets on the ubuntu2004 machine, and there seems to be no problem for tcpdump to display the correct IP address. My assumption is that there is something wrong in the print function which displays the IP address for a host redirect. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1892108/+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 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
** 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 rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
Fix Released
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
Fix Committed
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
Fix Committed
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
Fix Released
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak will be fixed.
[Where problems could occur]
If a regression were to occur, it would be limited to users of the
imrelp module, which is a part of the rsyslogd-relp package, and
depends on librelp.
rsyslog-relp is not part of a default installation of rsyslog, and is
opt in by changing a configuration file to enable imrelp.
The changes to rsyslog implement a testcase which exercises the problematic
code to ensure things are working as expected; this
can be enabled manually on build, and has been verified to pass (#7).
[Other]
Upstream bug list:
https://github.com/rsyslog/rsyslog/issues/4350
https://github.com/rsyslog/rsyslog/issues/4005
https://github.com/rsyslog/librelp/issues/188
https://github.com/rsyslog/librelp/pull/193
The following commits fix the problem:
rsyslogd
commit baee0bd5420649329793746f0daf87c4f59fe6a6
Author: Andre lorbach
Date: Thu Apr 9 13:00:35 2020 +0200
Subject: testbench: Add test for imrelp to check broken session handling.
Link:
https://github.com/rsyslog/rsyslog/commit/baee0bd5420649329793746f0daf87c4f59fe6a6
librelp
===
commit 7907c9c57f6ed94c8ce5a4e63c3c4e019f71cff0
Author: Andre lorbach
Date: Mon May 11 14:59:55 2020 +0200
Subject: fix memory leak on session break.
Link:
[Touch-packages] [Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
I tested this on Focal. I installed librelp0 and restart rsyslog. Prior
to the change, sockets were stacking up in CLOSE-WAIT (both from normal
use and from the netcat test). After the change, sockets are being
closed correctly.
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
Fix Released
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
Fix Committed
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
Fix Committed
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
Fix Released
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak will be fixed.
[Where problems could occur]
If a regression were to occur, it would be limited to users of the
imrelp module, which is a part of the rsyslogd-relp package, and
depends on librelp.
rsyslog-relp is not part of a default installation of rsyslog, and is
opt in by changing a configuration file to enable imrelp.
The changes to rsyslog implement a testcase which exercises the problematic
code to ensure things are working as expected; this
can be enabled manually on build, and has been verified to pass (#7).
[Other]
Upstream bug list:
https://github.com/rsyslog/rsyslog/issues/4350
https://github.com/rsyslog/rsyslog/issues/4005
https://github.com/rsyslog/librelp/issues/188
https://github.com/rsyslog/librelp/pull/193
The following commits fix the problem:
rsyslogd
commit baee0bd5420649329793746f0daf87c4f59fe6a6
Author: Andre lorbach
Date: Thu Apr 9 13:00:35 2020 +0200
Subject: testbench: Add test for imrelp to check broken session handling.
Link:
https://github.com/rsyslog/rsyslog/commit/baee0bd5420649329793746f0daf87c4f59fe6a6
[Touch-packages] [Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
The test package fixes the issue for me.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
In Progress
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
In Progress
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
In Progress
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
In Progress
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak will be fixed.
[Where problems could occur]
If a regression were to occur, it would be limited to users of the
imrelp module, which is a part of the rsyslogd-relp package, and
depends on librelp.
rsyslog-relp is not part of a default installation of rsyslog, and is
opt in by changing a configuration file to enable imrelp.
The changes to rsyslog implement a testcase which exercises the
problematic code to ensure things are working as expected, and should
run during autopkgtest time.
[Other]
Upstream bug list:
https://github.com/rsyslog/rsyslog/issues/4350
https://github.com/rsyslog/rsyslog/issues/4005
https://github.com/rsyslog/librelp/issues/188
https://github.com/rsyslog/librelp/pull/193
The following commits fix the problem:
rsyslogd
commit baee0bd5420649329793746f0daf87c4f59fe6a6
Author: Andre lorbach
Date: Thu Apr 9 13:00:35 2020 +0200
Subject: testbench: Add test for imrelp to check broken session handling.
Link:
https://github.com/rsyslog/rsyslog/commit/baee0bd5420649329793746f0daf87c4f59fe6a6
librelp
===
commit 7907c9c57f6ed94c8ce5a4e63c3c4e019f71cff0
Author: Andre lorbach
Date: Mon May 11 14:59:55 2020 +0200
Subject: fix memory leak on session break.
Link:
https://github.com/rsyslog/librelp/commit/7907c9c57f6ed94c8ce5a4e63c3c4e019f71cff0
commit
[Touch-packages] [Bug 1872118] Re: [SRU] DHCP Cluster crashes after a few hours
First I reverted isc-dhcp-server back to the original focal version, since I had an updated version from the PPA: $ sudo apt install isc-dhcp-server=4.4.1-2.1ubuntu5 isc-dhcp-common=4.4.1-2.1ubuntu5 Then I install the update packages: $ sudo apt update $ sudo apt install libdns-export1109/focal-proposed libirs-export161/focal-proposed libisc-export1105/focal-proposed $ dpkg --status libdns-export1109 libirs-export161 libisc-export1105 | grep Version Version: 1:9.11.16+dfsg-3~ubuntu1 Version: 1:9.11.16+dfsg-3~ubuntu1 Version: 1:9.11.16+dfsg-3~ubuntu1 Then I restarted dhcpd: sudo systemctl restart isc-dhcp-server It has been running for four hours on both systems. ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- 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/1872118 Title: [SRU] DHCP Cluster crashes after a few hours Status in DHCP: New Status in bind9-libs package in Ubuntu: Fix Released Status in isc-dhcp package in Ubuntu: Invalid Status in bind9-libs source package in Focal: Fix Committed Status in isc-dhcp source package in Focal: Invalid Status in bind9-libs source package in Groovy: Fix Released Status in isc-dhcp source package in Groovy: Invalid Bug description: [Description] isc-dhcp-server uses libisc-export (coming from bind9-libs package) for handling the socket event(s) when configured in peer mode (master/secondary). It's possible that a sequence of messages dispatched by the master that requires acknowledgment from its peers holds a socket in a pending to send state, a timer or a subsequent write request can be scheduled into this socket and the !sock->pending_send assertion will be raised when trying to write again at the time data hasn't been flushed entirely and the pending_send flag hasn't been reset to 0 state. If this race condition happens, the following stacktrace will be hit: (gdb) info threads Id Target Id Frame * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait (futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52 3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, processes_to_wake=1, futex_word=) at ../sysdeps/nptl/futex-internal.h:364 4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable (private=, expected=0, futex_word=0x7fb4de6cd0d0) at ../sysdeps/nptl/futex-internal.h:183 (gdb) frame 2 #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 "../../../../lib/isc/unix/socket.c", line=line@entry=3361, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at ../../../lib/isc/assertions.c:52 (gdb) bt #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79 #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 "../../../../lib/isc/unix/socket.c", line=line@entry=3361, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at ../../../lib/isc/assertions.c:52 #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at ../../../../lib/isc/unix/socket.c:4041 #4 process_fd (writeable=, readable=, fd=11, manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054 #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211 #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397 #7 0x7fb4dea68609 in start_thread (arg=) at pthread_create.c:477 #8 0x7fb4deba4103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) frame 3 #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at ../../../../lib/isc/unix/socket.c:4041 4041 in ../../../../lib/isc/unix/socket.c (gdb) p sock->pending_send $2 = 1 [TEST CASE] 1) Install isc-dhcp-server in 2 focal machine(s). 2) Configure peer/cluster mode as follows: Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/ Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/ 2) Run dhcpd as follows in both machine(s) # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4 3) Leave the cluster running for a long (2h) period until the crash/race condition is reproduced. [REGRESSION POTENTIAL] * The fix will prevent the assertion to happen in the dispatch_send path, later versions of isch-dhcp upstream lack this logic and entirely removed the existence of this flag. Therefore, removing the need for this assertion at process_fd shouldn't be problematic. To manage notifications about this bug go to: https://bugs.launchpad.net/dhcp/+bug/1872118/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages
[Touch-packages] [Bug 1872118] Re: [SRU] DHCP Cluster crashes after a few hours
Andrew, 1:9.11.16+dfsg-3~build1 is wrong. The correct version is 1:9.11.16+dfsg-3~ubuntu1 (~ubuntu1 instead of ~build1). -- 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/1872118 Title: [SRU] DHCP Cluster crashes after a few hours Status in DHCP: New Status in bind9-libs package in Ubuntu: Fix Released Status in isc-dhcp package in Ubuntu: Invalid Status in bind9-libs source package in Focal: Fix Committed Status in isc-dhcp source package in Focal: Invalid Status in bind9-libs source package in Groovy: Fix Released Status in isc-dhcp source package in Groovy: Invalid Bug description: [Description] isc-dhcp-server uses libisc-export (coming from bind9-libs package) for handling the socket event(s) when configured in peer mode (master/secondary). It's possible that a sequence of messages dispatched by the master that requires acknowledgment from its peers holds a socket in a pending to send state, a timer or a subsequent write request can be scheduled into this socket and the !sock->pending_send assertion will be raised when trying to write again at the time data hasn't been flushed entirely and the pending_send flag hasn't been reset to 0 state. If this race condition happens, the following stacktrace will be hit: (gdb) info threads Id Target Id Frame * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait (futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52 3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, processes_to_wake=1, futex_word=) at ../sysdeps/nptl/futex-internal.h:364 4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable (private=, expected=0, futex_word=0x7fb4de6cd0d0) at ../sysdeps/nptl/futex-internal.h:183 (gdb) frame 2 #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 "../../../../lib/isc/unix/socket.c", line=line@entry=3361, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at ../../../lib/isc/assertions.c:52 (gdb) bt #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79 #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 "../../../../lib/isc/unix/socket.c", line=line@entry=3361, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at ../../../lib/isc/assertions.c:52 #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at ../../../../lib/isc/unix/socket.c:4041 #4 process_fd (writeable=, readable=, fd=11, manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054 #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211 #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397 #7 0x7fb4dea68609 in start_thread (arg=) at pthread_create.c:477 #8 0x7fb4deba4103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) frame 3 #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at ../../../../lib/isc/unix/socket.c:4041 4041 in ../../../../lib/isc/unix/socket.c (gdb) p sock->pending_send $2 = 1 [TEST CASE] 1) Install isc-dhcp-server in 2 focal machine(s). 2) Configure peer/cluster mode as follows: Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/ Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/ 2) Run dhcpd as follows in both machine(s) # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4 3) Leave the cluster running for a long (2h) period until the crash/race condition is reproduced. [REGRESSION POTENTIAL] * The fix will prevent the assertion to happen in the dispatch_send path, later versions of isch-dhcp upstream lack this logic and entirely removed the existence of this flag. Therefore, removing the need for this assertion at process_fd shouldn't be problematic. To manage notifications about this bug go to: https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: [SRU] DHCP Cluster crashes after a few hours
Excellent. I'm available to test the -proposed update for focal whenever it is ready. -- 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/1872118 Title: [SRU] DHCP Cluster crashes after a few hours Status in DHCP: New Status in bind9-libs package in Ubuntu: Fix Released Status in isc-dhcp package in Ubuntu: Invalid Status in bind9-libs source package in Focal: In Progress Status in isc-dhcp source package in Focal: Invalid Status in bind9-libs source package in Groovy: Fix Released Status in isc-dhcp source package in Groovy: Invalid Bug description: [Description] isc-dhcp-server uses libisc-export (coming from bind9-libs package) for handling the socket event(s) when configured in peer mode (master/secondary). It's possible that a sequence of messages dispatched by the master that requires acknowledgment from its peers holds a socket in a pending to send state, a timer or a subsequent write request can be scheduled into this socket and the !sock->pending_send assertion will be raised when trying to write again at the time data hasn't been flushed entirely and the pending_send flag hasn't been reset to 0 state. If this race condition happens, the following stacktrace will be hit: (gdb) info threads Id Target Id Frame * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait (futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52 3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, processes_to_wake=1, futex_word=) at ../sysdeps/nptl/futex-internal.h:364 4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable (private=, expected=0, futex_word=0x7fb4de6cd0d0) at ../sysdeps/nptl/futex-internal.h:183 (gdb) frame 2 #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 "../../../../lib/isc/unix/socket.c", line=line@entry=3361, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at ../../../lib/isc/assertions.c:52 (gdb) bt #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79 #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 "../../../../lib/isc/unix/socket.c", line=line@entry=3361, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at ../../../lib/isc/assertions.c:52 #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at ../../../../lib/isc/unix/socket.c:4041 #4 process_fd (writeable=, readable=, fd=11, manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054 #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211 #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397 #7 0x7fb4dea68609 in start_thread (arg=) at pthread_create.c:477 #8 0x7fb4deba4103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) frame 3 #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at ../../../../lib/isc/unix/socket.c:4041 4041 in ../../../../lib/isc/unix/socket.c (gdb) p sock->pending_send $2 = 1 [TEST CASE] 1) Install isc-dhcp-server in 2 focal machine(s). 2) Configure peer/cluster mode as follows: Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/ Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/ 2) Run dhcpd as follows in both machine(s) # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4 3) Leave the cluster running for a long (2h) period until the crash/race condition is reproduced. [REGRESSION POTENTIAL] * The fix will prevent the assertion to happen in the dispatch_send path, later versions of isch-dhcp upstream lack this logic and entirely removed the existence of this flag. Therefore, removing the need for this assertion at process_fd shouldn't be problematic. To manage notifications about this bug go to: https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: [SRU] DHCP Cluster crashes after a few hours
Jorge, I agree with Gianfranco Costamagna that a rebuild of isc-dhcp is NOT required. Why do you think it is? Presumably BIND also uses these libraries? If so, it seems like the Test Case should involve making sure BIND still seems to work, and that BIND should be mentioned in the Regression Potential. My DHCP servers also run BIND for recursive DNS and that has been fine with the patch applied. -- 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/1872118 Title: [SRU] DHCP Cluster crashes after a few hours Status in DHCP: New Status in bind9-libs package in Ubuntu: In Progress Status in isc-dhcp package in Ubuntu: In Progress Status in bind9-libs source package in Focal: In Progress Status in isc-dhcp source package in Focal: In Progress Status in bind9-libs source package in Groovy: In Progress Status in isc-dhcp source package in Groovy: In Progress Bug description: [Description] isc-dhcp-server uses libisc-export (coming from bind9-libs package) for handling the socket event(s) when configured in peer mode (master/secondary). It's possible that a sequence of messages dispatched by the master that requires acknowledgment from its peers holds a socket in a pending to send state, a timer or a subsequent write request can be scheduled into this socket and the !sock->pending_send assertion will be raised when trying to write again at the time data hasn't been flushed entirely and the pending_send flag hasn't been reset to 0 state. If this race condition happens, the following stacktrace will be hit: (gdb) info threads Id Target Id Frame * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait (futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52 3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, processes_to_wake=1, futex_word=) at ../sysdeps/nptl/futex-internal.h:364 4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable (private=, expected=0, futex_word=0x7fb4de6cd0d0) at ../sysdeps/nptl/futex-internal.h:183 (gdb) frame 2 #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 "../../../../lib/isc/unix/socket.c", line=line@entry=3361, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at ../../../lib/isc/assertions.c:52 (gdb) bt #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79 #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 "../../../../lib/isc/unix/socket.c", line=line@entry=3361, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at ../../../lib/isc/assertions.c:52 #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at ../../../../lib/isc/unix/socket.c:4041 #4 process_fd (writeable=, readable=, fd=11, manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054 #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211 #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397 #7 0x7fb4dea68609 in start_thread (arg=) at pthread_create.c:477 #8 0x7fb4deba4103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) frame 3 #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at ../../../../lib/isc/unix/socket.c:4041 4041 in ../../../../lib/isc/unix/socket.c (gdb) p sock->pending_send $2 = 1 [TEST CASE] 1) Install isc-dhcp-server in 2 focal machine(s). 2) Configure peer/cluster mode as follows: Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/ Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/ 2) Run dhcpd as follows in both machine(s) # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4 3) Leave the cluster running for a long (2h) period until the crash/race condition is reproduced. [REGRESSION POTENTIAL] * The fix will prevent the assertion to happen in the dispatch_send path, later versions of isch-dhcp upstream lack this logic and entirely removed the existence of this flag. Therefore, removing the need for this assertion at process_fd shouldn't be problematic. To manage notifications about this bug go to: https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: DHCP Cluster crashes after a few hours
No crashes to report. -- 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/1872118 Title: DHCP Cluster crashes after a few hours Status in DHCP: New Status in bind9-libs package in Ubuntu: New Status in isc-dhcp package in Ubuntu: Confirmed Status in bind9-libs source package in Focal: New Status in isc-dhcp source package in Focal: New Status in bind9-libs source package in Groovy: New Status in isc-dhcp source package in Groovy: Confirmed Bug description: I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All worked perfectly until recently, when they started stopping with code=killed, status=6/ABRT. This is being fixed by https://bugs.launchpad.net/bugs/1870729 However now one stops after a few hours with the following errors. One can stay on line but not both. Syslog shows Apr 10 17:20:15 dhcp-primary sh[6828]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ?? nothing in kern.log apport.log shows ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, signal 6, core limit 0, dump mode 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid with dump mode of 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: /usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf") ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report /var/crash/_usr_sbin_dhcpd.0.crash /var/crash/_usr_sbin_dhcpd.0.crash shows ProblemType: Crash Architecture: amd64 CrashCounter: 1 Date: Fri Apr 10 17:20:15 2020 DistroRelease: Ubuntu 20.04 ExecutablePath: /usr/sbin/dhcpd ExecutableTimestamp: 1586210315 ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf ProcEnviron: Error: [Errno 13] Permission denied: 'environ' ProcMaps: Error: [Errno 13] Permission denied: 'maps' ProcStatus: Name: dhcpd Umask: 0022 State: D (disk sleep) Tgid: 6828 Ngid: 0 Pid: 6828 PPid: 1 TracerPid: 0 Uid: 113 113 113 113 Gid: 118 118 118 118 FDSize:128 Groups: NStgid:6828 NSpid: 6828 NSpgid:6828 NSsid: 6828 VmPeak: 236244 kB VmSize: 170764 kB VmLck:0 kB VmPin:0 kB VmHWM:12064 kB VmRSS:12064 kB RssAnon: 5940 kB RssFile: 6124 kB RssShmem: 0 kB VmData: 30792 kB VmStk: 132 kB VmExe: 592 kB VmLib: 5424 kB VmPTE: 76 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 1 THP_enabled: 1 Threads: 4 SigQ: 0/7609 SigPnd: ShdPnd: SigBlk: SigIgn:1000 SigCgt:00018000 CapInh: CapPrm: CapEff: CapBnd:003f CapAmb: NoNewPrivs:0 Seccomp: 0 Speculation_Store_Bypass: thread vulnerable Cpus_allowed: 3 Cpus_allowed_list: 0-1 Mems_allowed: ,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,0001 Mems_allowed_list: 0 voluntary_ctxt_switches: 111 nonvoluntary_ctxt_switches:144 Signal: 6 Uname: Linux 5.4.0-21-generic x86_64 UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: DHCP Cluster crashes after a few hours
Jorge, it sounds like ISC might think there is a more fundamental issue here: https://gitlab.isc.org/isc-projects/dhcp/-/issues/121#note_152804 ** Bug watch added: gitlab.isc.org/isc-projects/dhcp/-/issues #121 https://gitlab.isc.org/isc-projects/dhcp/-/issues/121 -- 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/1872118 Title: DHCP Cluster crashes after a few hours Status in DHCP: New Status in bind9-libs package in Ubuntu: New Status in isc-dhcp package in Ubuntu: Confirmed Status in bind9-libs source package in Focal: New Status in isc-dhcp source package in Focal: New Status in bind9-libs source package in Groovy: New Status in isc-dhcp source package in Groovy: Confirmed Bug description: I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All worked perfectly until recently, when they started stopping with code=killed, status=6/ABRT. This is being fixed by https://bugs.launchpad.net/bugs/1870729 However now one stops after a few hours with the following errors. One can stay on line but not both. Syslog shows Apr 10 17:20:15 dhcp-primary sh[6828]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ?? nothing in kern.log apport.log shows ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, signal 6, core limit 0, dump mode 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid with dump mode of 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: /usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf") ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report /var/crash/_usr_sbin_dhcpd.0.crash /var/crash/_usr_sbin_dhcpd.0.crash shows ProblemType: Crash Architecture: amd64 CrashCounter: 1 Date: Fri Apr 10 17:20:15 2020 DistroRelease: Ubuntu 20.04 ExecutablePath: /usr/sbin/dhcpd ExecutableTimestamp: 1586210315 ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf ProcEnviron: Error: [Errno 13] Permission denied: 'environ' ProcMaps: Error: [Errno 13] Permission denied: 'maps' ProcStatus: Name: dhcpd Umask: 0022 State: D (disk sleep) Tgid: 6828 Ngid: 0 Pid: 6828 PPid: 1 TracerPid: 0 Uid: 113 113 113 113 Gid: 118 118 118 118 FDSize:128 Groups: NStgid:6828 NSpid: 6828 NSpgid:6828 NSsid: 6828 VmPeak: 236244 kB VmSize: 170764 kB VmLck:0 kB VmPin:0 kB VmHWM:12064 kB VmRSS:12064 kB RssAnon: 5940 kB RssFile: 6124 kB RssShmem: 0 kB VmData: 30792 kB VmStk: 132 kB VmExe: 592 kB VmLib: 5424 kB VmPTE: 76 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 1 THP_enabled: 1 Threads: 4 SigQ: 0/7609 SigPnd: ShdPnd: SigBlk: SigIgn:1000 SigCgt:00018000 CapInh: CapPrm: CapEff: CapBnd:003f CapAmb: NoNewPrivs:0 Seccomp: 0 Speculation_Store_Bypass: thread vulnerable Cpus_allowed: 3 Cpus_allowed_list: 0-1 Mems_allowed: ,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,0001 Mems_allowed_list: 0 voluntary_ctxt_switches: 111 nonvoluntary_ctxt_switches:144 Signal: 6 Uname: Linux 5.4.0-21-generic x86_64 UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: DHCP Cluster crashes after a few hours
Jorge, I have been running for 25 hours on the patched version with no crashes on either server. -- 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/1872118 Title: DHCP Cluster crashes after a few hours Status in DHCP: New Status in bind9-libs package in Ubuntu: New Status in isc-dhcp package in Ubuntu: Confirmed Status in bind9-libs source package in Focal: New Status in isc-dhcp source package in Focal: New Status in bind9-libs source package in Groovy: New Status in isc-dhcp source package in Groovy: Confirmed Bug description: I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All worked perfectly until recently, when they started stopping with code=killed, status=6/ABRT. This is being fixed by https://bugs.launchpad.net/bugs/1870729 However now one stops after a few hours with the following errors. One can stay on line but not both. Syslog shows Apr 10 17:20:15 dhcp-primary sh[6828]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ?? nothing in kern.log apport.log shows ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, signal 6, core limit 0, dump mode 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid with dump mode of 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: /usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf") ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report /var/crash/_usr_sbin_dhcpd.0.crash /var/crash/_usr_sbin_dhcpd.0.crash shows ProblemType: Crash Architecture: amd64 CrashCounter: 1 Date: Fri Apr 10 17:20:15 2020 DistroRelease: Ubuntu 20.04 ExecutablePath: /usr/sbin/dhcpd ExecutableTimestamp: 1586210315 ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf ProcEnviron: Error: [Errno 13] Permission denied: 'environ' ProcMaps: Error: [Errno 13] Permission denied: 'maps' ProcStatus: Name: dhcpd Umask: 0022 State: D (disk sleep) Tgid: 6828 Ngid: 0 Pid: 6828 PPid: 1 TracerPid: 0 Uid: 113 113 113 113 Gid: 118 118 118 118 FDSize:128 Groups: NStgid:6828 NSpid: 6828 NSpgid:6828 NSsid: 6828 VmPeak: 236244 kB VmSize: 170764 kB VmLck:0 kB VmPin:0 kB VmHWM:12064 kB VmRSS:12064 kB RssAnon: 5940 kB RssFile: 6124 kB RssShmem: 0 kB VmData: 30792 kB VmStk: 132 kB VmExe: 592 kB VmLib: 5424 kB VmPTE: 76 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 1 THP_enabled: 1 Threads: 4 SigQ: 0/7609 SigPnd: ShdPnd: SigBlk: SigIgn:1000 SigCgt:00018000 CapInh: CapPrm: CapEff: CapBnd:003f CapAmb: NoNewPrivs:0 Seccomp: 0 Speculation_Store_Bypass: thread vulnerable Cpus_allowed: 3 Cpus_allowed_list: 0-1 Mems_allowed: ,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,0001 Mems_allowed_list: 0 voluntary_ctxt_switches: 111 nonvoluntary_ctxt_switches:144 Signal: 6 Uname: Linux 5.4.0-21-generic x86_64 UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: DHCP Cluster crashes after a few hours
I ran: sudo apt install \ isc-dhcp-server=4.4.1-2.1ubuntu6~ppa1 \ libdns-export1109=1:9.11.16+dfsg-3~ppa1 \ libirs-export161=1:9.11.16+dfsg-3~ppa1 \ libisc-export1105=1:9.11.16+dfsg-3~ppa1 && \ sudo systemctl restart isc-dhcp-server The restart at the end was just for extra good measure, to make sure I was running on the new libraries. I'm coming up on 3 hours running, which is a good sign. -- 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/1872118 Title: DHCP Cluster crashes after a few hours Status in DHCP: New Status in bind9-libs package in Ubuntu: New Status in isc-dhcp package in Ubuntu: Confirmed Status in bind9-libs source package in Focal: New Status in isc-dhcp source package in Focal: New Status in bind9-libs source package in Groovy: New Status in isc-dhcp source package in Groovy: Confirmed Bug description: I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All worked perfectly until recently, when they started stopping with code=killed, status=6/ABRT. This is being fixed by https://bugs.launchpad.net/bugs/1870729 However now one stops after a few hours with the following errors. One can stay on line but not both. Syslog shows Apr 10 17:20:15 dhcp-primary sh[6828]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ?? nothing in kern.log apport.log shows ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, signal 6, core limit 0, dump mode 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid with dump mode of 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: /usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf") ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report /var/crash/_usr_sbin_dhcpd.0.crash /var/crash/_usr_sbin_dhcpd.0.crash shows ProblemType: Crash Architecture: amd64 CrashCounter: 1 Date: Fri Apr 10 17:20:15 2020 DistroRelease: Ubuntu 20.04 ExecutablePath: /usr/sbin/dhcpd ExecutableTimestamp: 1586210315 ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf ProcEnviron: Error: [Errno 13] Permission denied: 'environ' ProcMaps: Error: [Errno 13] Permission denied: 'maps' ProcStatus: Name: dhcpd Umask: 0022 State: D (disk sleep) Tgid: 6828 Ngid: 0 Pid: 6828 PPid: 1 TracerPid: 0 Uid: 113 113 113 113 Gid: 118 118 118 118 FDSize:128 Groups: NStgid:6828 NSpid: 6828 NSpgid:6828 NSsid: 6828 VmPeak: 236244 kB VmSize: 170764 kB VmLck:0 kB VmPin:0 kB VmHWM:12064 kB VmRSS:12064 kB RssAnon: 5940 kB RssFile: 6124 kB RssShmem: 0 kB VmData: 30792 kB VmStk: 132 kB VmExe: 592 kB VmLib: 5424 kB VmPTE: 76 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 1 THP_enabled: 1 Threads: 4 SigQ: 0/7609 SigPnd: ShdPnd: SigBlk: SigIgn:1000 SigCgt:00018000 CapInh: CapPrm: CapEff: CapBnd:003f CapAmb: NoNewPrivs:0 Seccomp: 0 Speculation_Store_Bypass: thread vulnerable Cpus_allowed: 3 Cpus_allowed_list: 0-1 Mems_allowed: ,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,0001 Mems_allowed_list: 0 voluntary_ctxt_switches: 111 nonvoluntary_ctxt_switches:144 Signal: 6 Uname: Linux 5.4.0-21-generic x86_64 UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/dhcp/+bug/1872118/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe :
[Touch-packages] [Bug 1872118] Re: DHCP Cluster crashes after a few hours
** Bug watch added: gitlab.isc.org/isc-projects/dhcp/issues #128 https://gitlab.isc.org/isc-projects/dhcp/issues/128 ** Also affects: dhcp via https://gitlab.isc.org/isc-projects/dhcp/issues/128 Importance: Unknown Status: Unknown -- 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/1872118 Title: DHCP Cluster crashes after a few hours Status in DHCP: Unknown Status in isc-dhcp package in Ubuntu: Confirmed Bug description: I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All worked perfectly until recently, when they started stopping with code=killed, status=6/ABRT. This is being fixed by https://bugs.launchpad.net/bugs/1870729 However now one stops after a few hours with the following errors. One can stay on line but not both. Syslog shows Apr 10 17:20:15 dhcp-primary sh[6828]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ?? nothing in kern.log apport.log shows ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, signal 6, core limit 0, dump mode 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid with dump mode of 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: /usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf") ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report /var/crash/_usr_sbin_dhcpd.0.crash /var/crash/_usr_sbin_dhcpd.0.crash shows ProblemType: Crash Architecture: amd64 CrashCounter: 1 Date: Fri Apr 10 17:20:15 2020 DistroRelease: Ubuntu 20.04 ExecutablePath: /usr/sbin/dhcpd ExecutableTimestamp: 1586210315 ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf ProcEnviron: Error: [Errno 13] Permission denied: 'environ' ProcMaps: Error: [Errno 13] Permission denied: 'maps' ProcStatus: Name: dhcpd Umask: 0022 State: D (disk sleep) Tgid: 6828 Ngid: 0 Pid: 6828 PPid: 1 TracerPid: 0 Uid: 113 113 113 113 Gid: 118 118 118 118 FDSize:128 Groups: NStgid:6828 NSpid: 6828 NSpgid:6828 NSsid: 6828 VmPeak: 236244 kB VmSize: 170764 kB VmLck:0 kB VmPin:0 kB VmHWM:12064 kB VmRSS:12064 kB RssAnon: 5940 kB RssFile: 6124 kB RssShmem: 0 kB VmData: 30792 kB VmStk: 132 kB VmExe: 592 kB VmLib: 5424 kB VmPTE: 76 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 1 THP_enabled: 1 Threads: 4 SigQ: 0/7609 SigPnd: ShdPnd: SigBlk: SigIgn:1000 SigCgt:00018000 CapInh: CapPrm: CapEff: CapBnd:003f CapAmb: NoNewPrivs:0 Seccomp: 0 Speculation_Store_Bypass: thread vulnerable Cpus_allowed: 3 Cpus_allowed_list: 0-1 Mems_allowed: ,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,0001 Mems_allowed_list: 0 voluntary_ctxt_switches: 111 nonvoluntary_ctxt_switches:144 Signal: 6 Uname: Linux 5.4.0-21-generic x86_64 UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: DHCP Cluster crashes after a few hours
I was able to reproduce this with 4.4.2 plus the Ubuntu packaging. I did not try with stock 4.4.2 from source. -- 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/1872118 Title: DHCP Cluster crashes after a few hours Status in isc-dhcp package in Ubuntu: Confirmed Bug description: I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All worked perfectly until recently, when they started stopping with code=killed, status=6/ABRT. This is being fixed by https://bugs.launchpad.net/bugs/1870729 However now one stops after a few hours with the following errors. One can stay on line but not both. Syslog shows Apr 10 17:20:15 dhcp-primary sh[6828]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ?? Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ?? nothing in kern.log apport.log shows ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, signal 6, core limit 0, dump mode 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid with dump mode of 2 ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: /usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf") ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report /var/crash/_usr_sbin_dhcpd.0.crash /var/crash/_usr_sbin_dhcpd.0.crash shows ProblemType: Crash Architecture: amd64 CrashCounter: 1 Date: Fri Apr 10 17:20:15 2020 DistroRelease: Ubuntu 20.04 ExecutablePath: /usr/sbin/dhcpd ExecutableTimestamp: 1586210315 ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf ProcEnviron: Error: [Errno 13] Permission denied: 'environ' ProcMaps: Error: [Errno 13] Permission denied: 'maps' ProcStatus: Name: dhcpd Umask: 0022 State: D (disk sleep) Tgid: 6828 Ngid: 0 Pid: 6828 PPid: 1 TracerPid: 0 Uid: 113 113 113 113 Gid: 118 118 118 118 FDSize:128 Groups: NStgid:6828 NSpid: 6828 NSpgid:6828 NSsid: 6828 VmPeak: 236244 kB VmSize: 170764 kB VmLck:0 kB VmPin:0 kB VmHWM:12064 kB VmRSS:12064 kB RssAnon: 5940 kB RssFile: 6124 kB RssShmem: 0 kB VmData: 30792 kB VmStk: 132 kB VmExe: 592 kB VmLib: 5424 kB VmPTE: 76 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 1 THP_enabled: 1 Threads: 4 SigQ: 0/7609 SigPnd: ShdPnd: SigBlk: SigIgn:1000 SigCgt:00018000 CapInh: CapPrm: CapEff: CapBnd:003f CapAmb: NoNewPrivs:0 Seccomp: 0 Speculation_Store_Bypass: thread vulnerable Cpus_allowed: 3 Cpus_allowed_list: 0-1 Mems_allowed: ,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,0001 Mems_allowed_list: 0 voluntary_ctxt_switches: 111 nonvoluntary_ctxt_switches:144 Signal: 6 Uname: Linux 5.4.0-21-generic x86_64 UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872118/+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 1888926] [NEW] tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0
Public bug reported:
rsyslogd: error during parsing file /etc/rsyslog.d/FILENAME.conf, on or
before line 22: imrelp: librelp does not support input parameter
'tls.tlscfgcmd'; it probably is too old (1.5.0 or higher should be
fine); ignoring setting now. [v8.2001.0 try
https://www.rsyslog.com/e/2207 ]
Here is the config:
module(load="imrelp" tls.tlslib="openssl")
input(
type="imrelp" port="2515"
tls="on"
# This should work in rsyslog 8.2006.0:
#tls.mycert="/etc/rsyslog.tls/fullchain.pem"
# for now we use the work-around discussed in:
# https://github.com/rsyslog/rsyslog/issues/4360
tls.cacert="/etc/rsyslog.tls/chain.pem"
tls.mycert="/etc/rsyslog.tls/cert.pem"
tls.myprivkey="/etc/rsyslog.tls/privkey.pem"
tls.tlscfgcmd="ServerPreference
CipherString=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
Ciphersuites=TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
MinProtocol=TLSv1.2"
)
This error comes from this code in plugins/imrelp/imrelp.c:
#if defined(HAVE_RELPENGINESETTLSCFGCMD)
inst->tlscfgcmd =
(uchar*)es_str2cstr(pvals[i].val.d.estr, NULL);
#else
parser_errmsg("imrelp: librelp does not support input
parameter 'tls.tlscfgcmd'; "
"it probably is too old (1.5.0 or higher should
be fine); ignoring setting now.");
#endif
The build log for focal:
https://launchpadlibrarian.net/464665610/buildlog_ubuntu-focal-arm64.rsyslog_8.2001.0-1ubuntu1_BUILDING.txt.gz
says:
checking for relpSrvSetTlsConfigCmd... no
checking for relpSrvSetTlsConfigCmd... (cached) no
The build log for groovy:
https://launchpadlibrarian.net/486409321/buildlog_ubuntu-groovy-arm64.rsyslog_8.2006.0-2ubuntu1_BUILDING.txt.gz
says:
checking for relpSrvSetTlsConfigCmd... yes
checking for relpSrvSetTlsConfigCmd... (cached) yes
If I rebuild the rsyslog package, I get:
checking for relpSrvSetTlsConfigCmd... yes
checking for relpSrvSetTlsConfigCmd... (cached) yes
I suspect that the rsyslog package was built against and older librelp
version. A simple rebuild of rsyslog should fix this, though a more
complete fix would be to raise the Build-Depends from librelp-dev (>=
1.4.0) to librelp-dev (>= 1.5.0).
** Affects: rsyslog (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1888926
Title:
tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0
Status in rsyslog package in Ubuntu:
New
Bug description:
rsyslogd: error during parsing file /etc/rsyslog.d/FILENAME.conf, on
or before line 22: imrelp: librelp does not support input parameter
'tls.tlscfgcmd'; it probably is too old (1.5.0 or higher should be
fine); ignoring setting now. [v8.2001.0 try
https://www.rsyslog.com/e/2207 ]
Here is the config:
module(load="imrelp" tls.tlslib="openssl")
input(
type="imrelp" port="2515"
tls="on"
# This should work in rsyslog 8.2006.0:
#tls.mycert="/etc/rsyslog.tls/fullchain.pem"
# for now we use the work-around discussed in:
# https://github.com/rsyslog/rsyslog/issues/4360
tls.cacert="/etc/rsyslog.tls/chain.pem"
tls.mycert="/etc/rsyslog.tls/cert.pem"
tls.myprivkey="/etc/rsyslog.tls/privkey.pem"
tls.tlscfgcmd="ServerPreference
CipherString=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
Ciphersuites=TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
MinProtocol=TLSv1.2"
)
This error comes from this code in plugins/imrelp/imrelp.c:
#if defined(HAVE_RELPENGINESETTLSCFGCMD)
inst->tlscfgcmd =
(uchar*)es_str2cstr(pvals[i].val.d.estr, NULL);
#else
parser_errmsg("imrelp: librelp does not support input
parameter 'tls.tlscfgcmd'; "
"it probably is too old (1.5.0 or higher
should be fine); ignoring setting now.");
#endif
The build log for focal:
https://launchpadlibrarian.net/464665610/buildlog_ubuntu-focal-arm64.rsyslog_8.2001.0-1ubuntu1_BUILDING.txt.gz
says:
checking for relpSrvSetTlsConfigCmd... no
checking for relpSrvSetTlsConfigCmd... (cached) no
The build log for groovy:
https://launchpadlibrarian.net/486409321/buildlog_ubuntu-groovy-arm64.rsyslog_8.2006.0-2ubuntu1_BUILDING.txt.gz
says:
checking for relpSrvSetTlsConfigCmd... yes
checking for relpSrvSetTlsConfigCmd... (cached) yes
If I
[Touch-packages] [Bug 1872863] Re: QEMU/KVM display is garbled when booting from kernel EFI stub due to missing bochs-drm module
I have confirmed that the fix in -proposed fixes the issue for me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1872863 Title: QEMU/KVM display is garbled when booting from kernel EFI stub due to missing bochs-drm module Status in kmod package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in kmod source package in Bionic: Fix Committed Status in linux source package in Bionic: Fix Committed Bug description: BugLink: https://bugs.launchpad.net/bugs/1872863 [Impact] A recent grub2 SRU, LP #1864533, now forces the kernel to boot via the kernel EFI stub whenever EFI is enabled. This causes problems for QEMU/KVM virtual machines which use the VGA=std video device, as the efifb driver yields an unreadable garbled screen. See the attached image. The correct framebuffer driver to use in this situation is bochs-drm, and modprobing it from a HWE kernel fixes the issues. bochs-drm is missing from Bionic since CONFIG_DRM_BOCHS was disabled in LP #1378648 due to bochs-drm causing problems in a PowerKVM machine. This problem appears to be fixed now, and bochs-drm has been re-enabled for Disco and up, in LP #1795857 and has been proven safe. This has also come up again in LP #1823152, as well as chatter on LP #1795857 to get this enabled on Bionic. The customer which is experiencing this issue cannot switch to VGA=qxl as a workaround, and must use VGA=std, hence I suggest we re-enable bochs-drm for Bionic. [Fix] I noticed on Focal, if you boot, the framebuffer is initially efifb: [ 0.603716] efifb: probing for efifb [ 0.603733] efifb: framebuffer at 0xc000, using 1876k, total 1875k [ 0.603735] efifb: mode is 800x600x32, linelength=3200, pages=1 [ 0.603736] efifb: scrolling: redraw [ 0.603738] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 0.604462] Console: switching to colour frame buffer device 100x37 [ 0.605829] fb0: EFI VGA frame buffer device This soon changes to bochs-drm about a second later: [ 0.935988] bochs-drm :00:01.0: remove_conflicting_pci_framebuffers: bar 0: 0xc000 -> 0xc0ff [ 0.937023] bochs-drm :00:01.0: remove_conflicting_pci_framebuffers: bar 2: 0xc1c8c000 -> 0xc1c8cfff [ 0.937776] checking generic (c000 1d5000) vs hw (c000 100) [ 0.937776] fb0: switching to bochsdrmfb from EFI VGA [ 0.939085] Console: switching to colour dummy device 80x25 [ 0.939117] bochs-drm :00:01.0: vgaarb: deactivate vga console [ 0.939210] [drm] Found bochs VGA, ID 0xb0c5. [ 0.939212] [drm] Framebuffer size 16384 kB @ 0xc000, mmio @ 0xc1c8c000. [ 0.941955] lpc_ich :00:1f.0: I/O space for GPIO uninitialized [ 0.942069] [TTM] Zone kernel: Available graphics memory: 2006780 KiB [ 0.942081] [TTM] Initializing pool allocator [ 0.942089] [TTM] Initializing DMA pool allocator [ 0.943026] virtio_blk virtio2: [vda] 20971520 512-byte logical blocks (10.7 GB/10.0 GiB) [ 0.944019] [drm] Found EDID data blob. [ 0.944162] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:01.0 on minor 0 [ 0.944979] fbcon: bochs-drmdrmfb (fb0) is primary device [ 0.947712] Console: switching to colour frame buffer device 128x48 On bionic, the framebuffer never changes from efifb, since the bochs- drm kernel module is not built, and it is also present on the module banlist in /etc/modprobe.d/blacklist-framebuffer.conf bochs-drm needs to be enabled to be built in the kernel config, and removed from the module blacklist in kmod. [Testcase] Create a new QEMU/KVM virtual machine, I used virt-manager. Before you install the OS, check the box to modify settings before install. In the "Overview" tab, enable EFI by setting the firmware to "UEFI x86_64: /usr/share/OVMF/OVMF_CODE.secboot.fd". Set the video device to qxl while you install Bionic. Once the install is done, reboot, do a "apt update" and "apt upgrade", to ensure you have grub2 2.02-2ubuntu8.15 installed. Shut the VM down, and set the video device to VGA. Or VGA=std if you use the QEMU command line. Start the VM up, and the screen will be garbled. See attached picture. If you install my test packages, which are available here: https://launchpad.net/~mruffell/+archive/ubuntu/sf272653-test Instructions to install (on a bionic system): 1) Enable bionic-proposed 2) sudo apt-get update 3) sudo apt install linux-image-unsigned-4.15.0-96-generic linux-modules-4.15.0-96-generic linux-modules-extra-4.15.0-96-generic linux-headers-4.15.0-96-generic linux-headers-4.15.0-96 libkmod2 kmod 4) sudo reboot 5) uname -rv 4.15.0-96-generic #97+TEST272653v20200409b1-Ubuntu SMP Thu Apr 9 04:09:18 UTC 2020 If you reboot, the screen will be perfectly readable, since the bochs- drm driver will be in use. [Regression Potential] We are
[Touch-packages] [Bug 1803203] Re: Support preferred_lft for IPv6 addresses
Currently, addresses is a "sequence of scalars" (aka a list). Here is
the example from the Netplan reference you quoted:
addresses: [192.168.14.2/24, "2001:1::1/64"]
This can, currently, also be written in this form (quotes optional):
addresses:
- 192.168.14.2/24
- "2001:1::1/64"
I actually prefer the latter form, so that's what I use today.
In YAML generally (not necessarily Netplan specifically), I think the
obvious extension would be to support dictionaries in addition to
scalars, for the addresses. That would allow for this type of extension:
addresses:
- 192.168.14.2/24
- "2001:1::1/64":
lifetime: 0
other: x
future: y
parameters: z
If you really want the flattened form, it would be:
addresses: [192.168.14.2/24, "2001:1::1/64": {lifetime: 0}]
This is a clean extension from the current syntax and supports other
future parameters.
Whether Netplan's YAML parser currently supports dictionaries is another
question. But this is all normal YAML. See, for example, Ansible:
https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1803203
Title:
Support preferred_lft for IPv6 addresses
Status in netplan:
New
Status in netplan.io package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
Fix Released
Bug description:
There doesn't currently seem to be any way to set the preferred_lft of
an IPv6 address.
With the "ip" command it might be, for example:
# ip address add 2001:db8::2/32 dev eth0 preferred_lft 0
In a systemd unit file it might be:
[Match]
Name=eth0
[Network]
Address=2001:db8::2/32
Gateway=2001:db8::1/32
PreferredLifetime=0
but I can't find any way to express this with netplan.
This is commonly used for per-service IP addresses that should never
be used as source addresses for outgoing traffic.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1803203/+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 1812760] Re: networkd: [Route] PreferredSource not working in *.network files
I was able to verify this on Bionic: rlaager@bison:~$ ip -6 route show 2600:2600::/64 dev ens3 proto kernel metric 256 pref medium fe80::/64 dev ens3 proto kernel metric 256 pref medium default via 2600:2600::254 dev ens3 proto static metric 1024 pref medium rlaager@bison:~$ sudo apt update ... rlaager@bison:~$ sudo apt install -t bionic-proposed systemd Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: linux-image-4.15.0-34-generic linux-image-4.15.0-36-generic linux-image-4.15.0-43-generic linux-modules-4.15.0-34-generic linux-modules-4.15.0-36-generic linux-modules-4.15.0-43-generic linux-modules-extra-4.15.0-34-generic linux-modules-extra-4.15.0-36-generic linux-modules-extra-4.15.0-43-generic Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: libnss-resolve libnss-systemd libsystemd0 Suggested packages: systemd-container policykit-1 Recommended packages: libpam-systemd The following packages will be upgraded: libnss-resolve libnss-systemd libsystemd0 systemd 4 upgraded, 0 newly installed, 0 to remove and 80 not upgraded. Need to get 3,318 kB of archives. After this operation, 3,072 B of additional disk space will be used. Do you want to continue? [Y/n] Y Get:1 http://mirror.steadfast.net/ubuntu bionic-proposed/main amd64 libnss-systemd amd64 237-3ubuntu10.20 [105 kB] Get:2 http://mirror.steadfast.net/ubuntu bionic-proposed/universe amd64 libnss-resolve amd64 237-3ubuntu10.20 [107 kB] Get:3 http://mirror.steadfast.net/ubuntu bionic-proposed/main amd64 systemd amd64 237-3ubuntu10.20 [2,902 kB] Get:4 http://mirror.steadfast.net/ubuntu bionic-proposed/main amd64 libsystemd0 amd64 237-3ubuntu10.20 [204 kB] Fetched 3,318 kB in 0s (13.0 MB/s) (Reading database ... 64877 files and directories currently installed.) Preparing to unpack .../libnss-systemd_237-3ubuntu10.20_amd64.deb ... Unpacking libnss-systemd:amd64 (237-3ubuntu10.20) over (237-3ubuntu10.15) ... Preparing to unpack .../libnss-resolve_237-3ubuntu10.20_amd64.deb ... Unpacking libnss-resolve:amd64 (237-3ubuntu10.20) over (237-3ubuntu10.15) ... Preparing to unpack .../systemd_237-3ubuntu10.20_amd64.deb ... Unpacking systemd (237-3ubuntu10.20) over (237-3ubuntu10.15) ... Preparing to unpack .../libsystemd0_237-3ubuntu10.20_amd64.deb ... Unpacking libsystemd0:amd64 (237-3ubuntu10.20) over (237-3ubuntu10.15) ... Setting up libsystemd0:amd64 (237-3ubuntu10.20) ... Processing triggers for ureadahead (0.100.0-20) ... Processing triggers for libc-bin (2.27-3ubuntu1) ... Setting up systemd (237-3ubuntu10.20) ... Setting up libnss-resolve:amd64 (237-3ubuntu10.20) ... Processing triggers for man-db (2.8.3-2ubuntu0.1) ... Processing triggers for dbus (1.12.2-1ubuntu1) ... Setting up libnss-systemd:amd64 (237-3ubuntu10.20) ... Processing triggers for libc-bin (2.27-3ubuntu1) ... rlaager@bison:~$ sudo systemctl daemon-reload rlaager@bison:~$ sudo netplan apply rlaager@bison:~$ ip -6 route show 2600:2600::/64 dev ens3 proto static src 2600:2600::26 metric 255 pref medium 2600:2600::/64 dev ens3 proto kernel metric 256 pref medium fe80::/64 dev ens3 proto kernel metric 256 pref medium default via 2600:2600::254 dev ens3 proto static src 2600:2600::26 metric 1024 pref medium rlaager@bison:~$ ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1812760 Title: networkd: [Route] PreferredSource not working in *.network files Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Committed Status in systemd source package in Disco: Fix Released Bug description: [Impact] Users cannot create IPv6 routes that specify PreferredSource. This means that users cannot specify a number of valid IPv6 routes that are useful in some circumstances. These routes can be created with the 'ip' tool, just not with systemd. This was reported upstream in systemd issue #5882 is fixed by pulling in the changes in systemd PR #11375 - https://github.com/systemd/systemd/pull/11375 [Test Case] Start a Bionic or Cosmic VM. Add the following netplan yaml (adjust for ethernet card and MAC): network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: 52:54:00:e2:c2:d7 set-name: ens3 addresses: ["fd8f:1d7d:b141::2/64", "fd8f:1d7d:b141::200/64"] routes: - to: "a::/16" via: "fd8f:1d7d:b141::1" from: "fd8f:1d7d:b141::2" - to: "fd8f:1d7d:b141::/64"
[Touch-packages] [Bug 1812760] Re: networkd: [Route] PreferredSource not working in *.network files
I was an affected user. I have confirmed that the package from bionic- proposed works. I do not have any systems installed with Cosmic. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1812760 Title: networkd: [Route] PreferredSource not working in *.network files Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Committed Status in systemd source package in Disco: Fix Released Bug description: [Impact] Users cannot create IPv6 routes that specify PreferredSource. This means that users cannot specify a number of valid IPv6 routes that are useful in some circumstances. These routes can be created with the 'ip' tool, just not with systemd. This was reported upstream in systemd issue #5882 is fixed by pulling in the changes in systemd PR #11375 - https://github.com/systemd/systemd/pull/11375 [Test Case] Start a Bionic or Cosmic VM. Add the following netplan yaml (adjust for ethernet card and MAC): network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: 52:54:00:e2:c2:d7 set-name: ens3 addresses: ["fd8f:1d7d:b141::2/64", "fd8f:1d7d:b141::200/64"] routes: - to: "a::/16" via: "fd8f:1d7d:b141::1" from: "fd8f:1d7d:b141::2" - to: "fd8f:1d7d:b141::/64" scope: link from: "fd8f:1d7d:b141::2" metric: 255 Run netplan apply or reboot. Wait ~10s. Currently, ip -6 route will not include a route to "a::/16", and will not include the route to "fd8f:1d7d:b141::/64" that has "fd8f:1d7d:b141::2" as the source address - both those addresses will be missing. Correct behaviour is for ip -6 route to report the following: ubuntu@b-np:~$ ip -6 route a::/16 via fd8f:1d7d:b141::1 dev ens3 proto static src fd8f:1d7d:b141::2 metric 1024 pref medium fd8f:1d7d:b141::/64 dev ens3 proto static src fd8f:1d7d:b141::2 metric 255 pref medium fd8f:1d7d:b141::/64 dev ens3 proto kernel metric 256 pref medium fe80::/64 dev ens3 proto kernel metric 256 pref medium Check before and after upgrade that 'systemctl status network- online.target' shows that the target has been reached. [Regression Potential] This changes the state machine in systemd which configures the links. It passes systemd's internal tests, and has been approved by systemd maintainers, but it remains possible that the changes will break the configuration of obscure network setups. The backport requires pulling in two further commits that also change behaviour: currently systemd deletes all addresses and routes that were attached to an interface. With this change, it will only delete those that are not specified in the configuration files. A side effect of this is that restarting networkd will not cause remove/add netlink events to be emitted for these addresses, so if anyone is relying on this behavior this will break compatibility; but that is an unlikely thing to be relying on, and it seems worth this risk to reduce unnecessary network state changes. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1812760/+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 1368411] Re: Cannot insert IPV6 rule before IPV4 rules
Attached is an updated version of the patch that builds. The previous one was failing because there's a test case that makes sure an "insert 2" of an IPv6 rule fails. That's enforcing the existence of the behavior that here we are arguing is a bug. ** Patch added: "Updated patch" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1368411/+attachment/5198885/+files/0005-lp1368411.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1368411 Title: Cannot insert IPV6 rule before IPV4 rules Status in ufw: New Status in ufw package in Ubuntu: Confirmed Bug description: I am unable to insert any rules concerning IPV6 before IPV4 rules. Thus, when IPV4 rules are numbered 1 to 5 and IPV6 rules are numbered 6 to 10, the following command: [code] ufw insert 1 deny from 2a02:2210:12:a:b820:fff:fea2:25d1 [/code] errors with "ERROR: Invalid position '1'". However, the command [code] ufw insert 6 deny from 2a02:2210:12:a:b820:fff:fea2:25d1 [/code] succeeds. In my case, this poses a problem, since I am trying to insert rules from a script against brute force attacks. The script needs to insert blocking rules before a number of other rules that open up some ports (since the order of rules is important in ufw). However since the number of IPV4 rules will be changing all the time, the position of the first available number for an IPV6 address is hard to determine. Proposed solution: either allow IPV6 rules to precede IPV4 rules, or implement a keyword defining the first available position; e.g. "ufw insert first deny from 2a02:2210:12:a:b820:fff:fea2:25d1". BTW: this was all figured out with ufw version 0.31.1-1, Ubuntu 12.04.5 LTS, To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1368411/+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 1368411] Re: Cannot insert IPV6 rule before IPV4 rules
Taking into account the two proposed patches, and what I believe the code to be doing, attached is a patch I believe is suitable for inclusion. ** Patch added: "0005-lp1368411.patch" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1368411/+attachment/5198539/+files/0005-lp1368411.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1368411 Title: Cannot insert IPV6 rule before IPV4 rules Status in ufw: New Status in ufw package in Ubuntu: Confirmed Bug description: I am unable to insert any rules concerning IPV6 before IPV4 rules. Thus, when IPV4 rules are numbered 1 to 5 and IPV6 rules are numbered 6 to 10, the following command: [code] ufw insert 1 deny from 2a02:2210:12:a:b820:fff:fea2:25d1 [/code] errors with "ERROR: Invalid position '1'". However, the command [code] ufw insert 6 deny from 2a02:2210:12:a:b820:fff:fea2:25d1 [/code] succeeds. In my case, this poses a problem, since I am trying to insert rules from a script against brute force attacks. The script needs to insert blocking rules before a number of other rules that open up some ports (since the order of rules is important in ufw). However since the number of IPV4 rules will be changing all the time, the position of the first available number for an IPV6 address is hard to determine. Proposed solution: either allow IPV6 rules to precede IPV4 rules, or implement a keyword defining the first available position; e.g. "ufw insert first deny from 2a02:2210:12:a:b820:fff:fea2:25d1". BTW: this was all figured out with ufw version 0.31.1-1, Ubuntu 12.04.5 LTS, To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1368411/+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 1727202] Re: [17.10 regression] AppArmor denial: Failed name lookup - disconnected path
I'm seeing the same errors with NTPsec (a fork of this ntpd, which I have packaged for Debian) on 16.04. The apparmor policy is copied from this ntp package. I'm not able to reproduce the problem at will, but it seems to happen regularly. The proposed change seems to have resolved it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1727202 Title: [17.10 regression] AppArmor denial: Failed name lookup - disconnected path Status in ntp package in Ubuntu: Triaged Status in ntp source package in Artful: New Status in ntp source package in Bionic: Triaged Bug description: Merely installing and starting ntp.service in Ubuntu 17.10 now causes this AppArmor violation: audit: type=1400 audit(1508915894.215:25): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 (many times). This hasn't happened in earlier Ubuntu releases yet. This was spotted by Cockpit's integration tests, as our "ubuntu- stable" image now moved to 17.10 after its release. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ntp 1:4.2.8p10+dfsg-5ubuntu3 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 Date: Wed Oct 25 03:19:34 2017 SourcePackage: ntp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+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 1607920] Re: zfs services fail on firstboot if zfs-utils is integrated into the deployment image
Does ZFS actually have any translations? There are no .po files in the source and no .mo files in the binary package. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sysvinit in Ubuntu. https://bugs.launchpad.net/bugs/1607920 Title: zfs services fail on firstboot if zfs-utils is integrated into the deployment image Status in sysvinit package in Ubuntu: Won't Fix Status in zfs-linux package in Ubuntu: Fix Released Status in sysvinit source package in Xenial: Won't Fix Status in zfs-linux source package in Xenial: In Progress Bug description: [Impact] * zfs services fail on firstboot if zfs-utils is integrated into the deployment image. * Output from systemd - sudo systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● zfs-import-scan.service loaded failed failed Import ZFS pools by device scanning ● zfs-mount.service loaded failed failed Mount ZFS filesystems * This is particularly frustrating for users who use automated monitoring as it means virtual machines must always be restarted before showing as clean. * This failure is due to zfs services starting up before /etc/mtab has a chance to be symlinked to /proc/mounts. [Test Case] 1. Grab a stock xenial image, and unpack it and add zfs-utils to it. Repack it. 2. Boot machine 3. Check systemctl --failed. [Regression Potential] * none expected, patch has been intensively tested by the upsteam zfs test script suite. * This is a upstream commit merge in 0.7.0. * A ubuntu package has been tested (including the upstream commit) by a user of the community facing this bug, and confirmed it addresses the problem (see comment #7). [Other Info] * The "reading" is redirected to /proc/self/mounts. The writing to /etc/mtab. Some distros still need that. The current hope is to replace the writing (and maybe reading) with libmount, in a second phase. * Upstream commit : https://github.com/zfsonlinux/zfs/commit/792517389fad5c495a2738b61c2e9c65dedaaa9a * Upstream bug: https://github.com/zfsonlinux/zfs/issues/4680 * Debian bug : https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=839071 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1607920/+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 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
This is fixed in 16.10. Is there a plan to backport this? I'm guessing not, because of the risk of regressions. If there's no plans to SRU, then this bug should probably be closed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: In Progress Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+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 1601997] Re: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions
I don't see how turning on a new feature is a bug. ** Changed in: e2fsprogs (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1601997 Title: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions Status in e2fsprogs package in Ubuntu: Invalid Bug description: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions (12.04 LTS, 14.04 LTS, 16.04 LTS). Steps to reproduce: 1. Download Ubuntu 16.10 installation media. 2. Install Ubuntu. 3. Try to do fsck -fy /dev/sdX1 from other supported Ubuntu distro. Expected results: User can check and fix errors on ext4 filesystem, created on Ubuntu 16.10. Actual results: User can not check and fix errors on ext4 filesystem because of lack of 'metadata_csum' option in previous LTS Ubuntu versions. The only one working solution was to scan from 16.10 live install media. Note: it is known, that Dan Watkins disabled metadata_csum when creating ext4 filesystems ( see http://bazaar.launchpad.net/~daniel-thewatkins/maas-images/fix-yakkety-builds/revision/305 ). It is good solution. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: e2fsprogs 1.43.1-1 ProcVersionSignature: Ubuntu 4.4.0-30.49-generic 4.4.13 Uname: Linux 4.4.0-30-generic i686 ApportVersion: 2.20.2-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Mon Jul 11 23:42:49 2016 SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+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 1607920] Re: zfs services fail on firstboot if zfs-utils is integrated into the deployment image
The fix was merged upstream here: https://github.com/zfsonlinux/zfs/commit/792517389fad5c495a2738b61c2e9c65dedaaa9a -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sysvinit in Ubuntu. https://bugs.launchpad.net/bugs/1607920 Title: zfs services fail on firstboot if zfs-utils is integrated into the deployment image Status in sysvinit package in Ubuntu: Won't Fix Status in zfs-linux package in Ubuntu: In Progress Bug description: [Impact] * zfs services fail on firstboot if zfs-utils is integrated into the deployment image. * Output from systemd - sudo systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● zfs-import-scan.service loaded failed failed Import ZFS pools by device scanning ● zfs-mount.service loaded failed failed Mount ZFS filesystems * This is particularly frustrating for users who use automated monitoring as it means virtual machines must always be restarted before showing as clean. * This failure is due to zfs services starting up before /etc/mtab has a chance to be symlinked to /proc/mounts. [Test Case] 1. Grab a stock xenial image, and unpack it and add zfs-utils to it. Repack it. 2. Boot machine 3. Check systemctl --failed. [Regression Potential] * [Other Info] * This can likely be resolved in the systemd init scripts, by modifying zfs-linux to depend on /proc/mounts instead, or inclusion of /lib/init/mount-functions.sh in initscripts (sysvinit). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1607920/+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 1618726] Re: ifup & ifdown crash if multiple interfaces are listed in no-scripts
The package from proposed works. I tested version 0.8.10ubuntu1.1. The diff looks correct. ** 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 ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1618726 Title: ifup & ifdown crash if multiple interfaces are listed in no-scripts Status in ifupdown package in Ubuntu: Fix Committed Status in ifupdown source package in Xenial: Fix Committed Status in ifupdown package in Debian: New Bug description: [Impact] ifup and ifupdown segfault if multiple interfaces are listed in no-scripts This is a trivially reproducible crash in ifup/ifdown, with a patch attached. [Test Case] Steps to reproduce: 1) echo no-scripts foo bar >> /etc/network/interfaces 2) ifup baz Expected results: Unknown interface baz Actual results: Segmentation fault (core dumped) It's irrelevant whether the second interface is on the same no-scripts line or separate one. This will crash just the same: echo no-scripts foo >> /etc/network/interfaces echo no-scripts bar >> /etc/network/interfaces [Regression potential] Seems slight. The patch fixes a clear bug in code that is only used to process the no-scripts (and apparently no-auto-down) stanzas. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1618726/+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 1618726] Re: ifup & ifdown crash if multiple interfaces are listed in no-scripts
I did not forward it. I sometimes do, sometimes don't, depending on a lot of factors. In this case, even though I assumed it would affect Debian, I was hesitant to claim the existence of a high priority bug if I hadn't personally verified it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1618726 Title: ifup & ifdown crash if multiple interfaces are listed in no-scripts Status in ifupdown package in Ubuntu: New Bug description: This is a trivially reproducible crash in ifup/ifdown, with a patch attached. Steps to reproduce: 1) echo no-scripts foo bar >> /etc/network/interfaces 2) ifup baz Expected results: Unknown interface baz Actual results: Segmentation fault (core dumped) It's irrelevant whether the second interface is on the same no-scripts line or separate one. This will crash just the same: echo no-scripts foo >> /etc/network/interfaces echo no-scripts bar >> /etc/network/interfaces To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1618726/+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 1618726] Re: ifup & ifdown crash if multiple interfaces are listed in no-scripts
** Patch added: "A fix for yakkety" https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1618726/+attachment/4731336/+files/ifupdown-fix-1618726-yakkety.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1618726 Title: ifup & ifdown crash if multiple interfaces are listed in no-scripts Status in ifupdown package in Ubuntu: New Bug description: This is a trivially reproducible crash in ifup/ifdown, with a patch attached. Steps to reproduce: 1) echo no-scripts foo bar >> /etc/network/interfaces 2) ifup baz Expected results: Unknown interface baz Actual results: Segmentation fault (core dumped) It's irrelevant whether the second interface is on the same no-scripts line or separate one. This will crash just the same: echo no-scripts foo >> /etc/network/interfaces echo no-scripts bar >> /etc/network/interfaces To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1618726/+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 1618726] Re: ifup & ifdown crash if multiple interfaces are listed in no-scripts
** Patch added: "A fix for xenial" https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1618726/+attachment/4731337/+files/ifupdown-fix-1618726-xenial.debdiff ** Description changed: - This is a trivially reproducible crash in ifup/ifdown. + This is a trivially reproducible crash in ifup/ifdown, with a patch + attached. Steps to reproduce: 1) echo no-scripts foo bar >> /etc/network/interfaces 2) ifup baz Expected results: Unknown interface baz Actual results: Segmentation fault (core dumped) It's irrelevant whether the second interface is on the same no-scripts line or separate one. This will crash just the same: echo no-scripts foo >> /etc/network/interfaces echo no-scripts bar >> /etc/network/interfaces -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1618726 Title: ifup & ifdown crash if multiple interfaces are listed in no-scripts Status in ifupdown package in Ubuntu: New Bug description: This is a trivially reproducible crash in ifup/ifdown, with a patch attached. Steps to reproduce: 1) echo no-scripts foo bar >> /etc/network/interfaces 2) ifup baz Expected results: Unknown interface baz Actual results: Segmentation fault (core dumped) It's irrelevant whether the second interface is on the same no-scripts line or separate one. This will crash just the same: echo no-scripts foo >> /etc/network/interfaces echo no-scripts bar >> /etc/network/interfaces To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1618726/+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 1618726] [NEW] ifup & ifdown crash if multiple interfaces are listed in no-scripts
Public bug reported: This is a trivially reproducible crash in ifup/ifdown. Steps to reproduce: 1) echo no-scripts foo bar >> /etc/network/interfaces 2) ifup baz Expected results: Unknown interface baz Actual results: Segmentation fault (core dumped) It's irrelevant whether the second interface is on the same no-scripts line or separate one. This will crash just the same: echo no-scripts foo >> /etc/network/interfaces echo no-scripts bar >> /etc/network/interfaces ** Affects: ifupdown (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1618726 Title: ifup & ifdown crash if multiple interfaces are listed in no-scripts Status in ifupdown package in Ubuntu: New Bug description: This is a trivially reproducible crash in ifup/ifdown. Steps to reproduce: 1) echo no-scripts foo bar >> /etc/network/interfaces 2) ifup baz Expected results: Unknown interface baz Actual results: Segmentation fault (core dumped) It's irrelevant whether the second interface is on the same no-scripts line or separate one. This will crash just the same: echo no-scripts foo >> /etc/network/interfaces echo no-scripts bar >> /etc/network/interfaces To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1618726/+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 1607920] Re: zfs services fail on firstboot if zfs-utils is integrated into the deployment image
chiluk is looking to work on this for upstream. I might jump in too. https://github.com/zfsonlinux/zfs/issues/4680 ** Bug watch added: Github Issue Tracker for ZFS #4680 https://github.com/zfsonlinux/zfs/issues/4680 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sysvinit in Ubuntu. https://bugs.launchpad.net/bugs/1607920 Title: zfs services fail on firstboot if zfs-utils is integrated into the deployment image Status in sysvinit package in Ubuntu: Won't Fix Status in zfs-linux package in Ubuntu: New Bug description: [Impact] * zfs services fail on firstboot if zfs-utils is integrated into the deployment image. * Output from systemd - sudo systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● zfs-import-scan.service loaded failed failed Import ZFS pools by device scanning ● zfs-mount.service loaded failed failed Mount ZFS filesystems * This is particularly frustrating for users who use automated monitoring as it means virtual machines must always be restarted before showing as clean. * This failure is due to zfs services starting up before /etc/mtab has a chance to be symlinked to /proc/mounts. [Test Case] 1. Grab a stock xenial image, and unpack it and add zfs-utils to it. Repack it. 2. Boot machine 3. Check systemctl --failed. [Regression Potential] * [Other Info] * This can likely be resolved in the systemd init scripts, by modifying zfs-linux to depend on /proc/mounts instead, or inclusion of /lib/init/mount-functions.sh in initscripts (sysvinit). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1607920/+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 87023] Re: sudo option "tty_tickets" gives false sense of security due to reused pts numbers
I might be overstepping here, but I'm marking this as Fix Released. I can confirm, as with comment #16, that this is no longer an issue. I'm on Vivid. ** Changed in: sudo (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/87023 Title: sudo option "tty_tickets" gives false sense of security due to reused pts numbers Status in sudo package in Ubuntu: Fix Released Bug description: Binary package hint: sudo When we have the option "tty_tickets" in '/etc/sudoers', for each new terminal (tty) or pseudo-terminal-slave (pts) where we use 'sudo', we get a sudo ticket in '/var/run/sudo/yourusername/'. These are named "tty1", "tty2" etc. for tty's, and "1", "2", "3", etc. for pts's. Also, when we invoke a graphical instance of 'sudo' through e.g. 'kdesu', new pts's are reserved for this purpose. Applications started through 'kdesu' require _two_ pts's, and sudo tickets are assigned corresponding to the numbers of these pts's. This report affects, as I understand it, both 'sudo' and 'kdesu'. I do not know what is the behaviour of 'gksudo' in relation to this bug, so I don't know if this report should also affect it. Now, I will give three different scenarios in which 'sudo' or a graphical application requiring sudo capabilities can be run without a password, but when the user would _not_ expect to be able to do so. N.B.: Before each scenario, we must be sure we have no active sudo tickets in the above mentioned directory. Doing 'sudo su', 'rm /var/run/sudo/yourusername/*' and 'exit' in a terminal should be enough to ensure this. (I will start the examples from a clean desktop with e.g. no Konsole windows running. This is not completely necessary, as the _absolute_ numbers of pts's involved are not important to reproduce the behaviour.) Useful commands for demonstrating what happens are: 'sudo ls --full-time /var/run/sudo/yourusername/' 'ps au' (to show which pts's are in use, and by what processes) 'tty' (run e.g. in Konsole to show which pts we are on) Scenario 1: - Open a Konsole (or Yakuake). - Do 'sudo ls --full-time /var/run/sudo/yourusername', and give your password. - Do 'tty' - Do 'exit'. If you are in Konsole, this should close it completely -> now, start a new Konsole. If you are in Yakuake, it should do this automatically for you (spawn a new shell). - _Now_, we have closed the console we used. It _seems_ reasonable to expect that after we closed the console where 'sudo' was used, the sudo capability would expire. - Do 'sudo foo' or 'sudo ls --full-time /var/run/sudo/yourusername', and you can do this without giving your password. - If we again do 'tty', we will see that we are re-using the previous pts number, which is the cause of this phenomenon. Scenario 2: - Open a Konsole (or Yakuake). - Add a new terminal tab, and in this tab do 'sudo foo', giving your password. Do not close this tab. - Add a third terminal tab, and in this tab do 'sudo foo', giving your password. Now we have three tabs open in Konsole or Yakuake. - Close tabs two and three. (This will free two pts's.) (- In the first tab, just to illustrate, run 'sudo ls --full-time /var/run/sudo/yourusername', again giving your password.) - Run e.g. Adept or Synaptic, expecting to give your password. You should be able to do this without giving your password. - If we again do 'sudo ls --full-time /var/run/sudo/yourusername' in the first terminal tab, we will notice that two of the timestamps have the same time. What happens is that 'kdesu' will utilise the first two free pts's, which we just freed, and which, incidentally, happened to have valid sudo timestamps. Scenario 3: (Optional: - Open a Konsole or Yakuake.) - Run e.g. Adept or Synaptic, this time giving your password. Close it. - Open two new Yakuake tabs or Konsole windows or tabs. (- In the already opened terminal, do 'sudo ls --full-time /var/run/sudo/yourusername', which will give you the number of the valid sudo ticket.) - In the second newly opened terminal, you should be able to run 'sudo foo' without giving your password. (IIRC, I have done this in the first new terminal instance sometime, possibly. It all depends on which pts number we are given. N.B. Normally 'kdesu' leaves behind only one valid sudo ticket, as in this scenario.) (- You can do 'tty' to verify that this is the same terminal that we saw had the valid sudo ticket.) I discovered this misbehaviour in sudo and applications that require sudo capabilities while investigating bug #72545 (and bug #50971). There are two separate issues here, as I understand it. Issue 1. As implied by the title of this bug, this gives the user a false sense of security under some conditions. Case 1.1: The user can (IMO
[Touch-packages] [Bug 346609] Re: Sun Java 6 JRE does not use ca-certificates for SSL
AFAIK, Sun Java is no longer in Ubuntu. Even if it is, it's probably a new version than 6. I'm sure this is broken, but nobody is going to fix it. I just don't care any more. ** Changed in: sun-java6 (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/346609 Title: Sun Java 6 JRE does not use ca-certificates for SSL Status in ca-certificates package in Ubuntu: Invalid Status in sun-java6 package in Ubuntu: Invalid Bug description: Sun Java 6 does not use the Debian/Ubuntu ca-certificates system for SSL root certificates. This means that, for example, installing a corporate CA certificate using the system-wide ca-certificates mechanism will NOT result in it being trusted by Sun Java 6. This can be fixed by symlinking /etc/java-6-sun/security/cacerts to /etc/ssl/certs/java/cacerts. However, that will result in the following CAs (which are currently trusted in Java 6) no longer being trusted. If that presents a problem, they should be added to ca-certificates. The certificates are: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE CN=GTE CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/346609/+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 44880] Re: test man page minor error
** Changed in: help2man (Ubuntu) Status: Triaged => Invalid ** Changed in: help2man Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/44880 Title: test man page minor error Status in Help2Man: Invalid Status in coreutils package in Ubuntu: Won't Fix Status in help2man package in Ubuntu: Invalid Status in coreutils package in Debian: Fix Released Bug description: Binary package hint: coreutils SYNOPSIS test EXPRESSION test [ EXPRESSION ] [ ] [ OPTION The two close brackets are not bold and they should be. To manage notifications about this bug go to: https://bugs.launchpad.net/help2man/+bug/44880/+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 479405] Re: --bwlimit option uses KiB/s, but is documented as (what amounts to) kB/s
This has been fixed in at least Ubuntu vivid. ** Changed in: rsync (Ubuntu) Status: Triaged => Fix Released -- 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/479405 Title: --bwlimit option uses KiB/s, but is documented as (what amounts to) kB/s Status in rsync: Fix Released Status in rsync package in Ubuntu: Fix Released Bug description: Binary package hint: rsync The --bwlimit option seems to use KiB/s, as io.c's sleep_for_bwlimit() function divides by 1024. It's documented as "KBPS", "KBytes per second", and "kilobytes per second". I'm going to attach a patch which standardizes all of this as KiB/s and "kibibytes per second", to match the actual usage. Given that this is a network transfer rate, it'd be more proper (and consistent with other applications) to change the function to work in SI kilobytes per second (i.e. use 1000 instead of 1024), but that's backwards-incompatible. If you'd like to go this route, I can prepare a patch to that effect. To manage notifications about this bug go to: https://bugs.launchpad.net/rsync/+bug/479405/+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 1479652] [NEW] [patch] ntpd rejects source UDP ports less than 123 as bogus
Public bug reported: [Title copied from Debian bug, which was not filed by me. Description below is mine.] If an NTP client sends a request with a source port less than 123, the packet is silently ignored by ntpd. This is occurring in our environment due to NAT. Attached is the patch already accepted upstream which fixes the issue. I've verified it fixes the problem. Debian has been ignoring this patch for almost 3 years. Can we get this in Ubuntu please? ** Affects: ntp Importance: Unknown Status: Unknown ** Affects: ntp (Ubuntu) Importance: Undecided Status: New ** Affects: ntp (Debian) Importance: Unknown Status: Unknown ** Patch added: Patch from upstream, made suitable for debian/patches https://bugs.launchpad.net/bugs/1479652/+attachment/4436105/+files/udp-ports-under-123.patch ** Bug watch added: bugs.ntp.org/ #2174 http://bugs.ntp.org/show_bug.cgi?id=2174 ** Also affects: ntp via http://bugs.ntp.org/show_bug.cgi?id=2174 Importance: Unknown Status: Unknown ** Bug watch added: Debian Bug tracker #691412 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691412 ** Also affects: ntp (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691412 Importance: Unknown Status: Unknown ** Description changed: [Title copied from Debian bug, which was not filed by me. Description below is mine.] If an NTP client sends a request with a source port less than 123, the packet is silently ignored by ntpd. This is occurring in our environment due to NAT. - Attached is the patch from upstream which fixes the issue. I've verified - it fixes the problem. Debian has been ignoring this patch for almost 3 - years. Can we get this in Ubuntu please? + Attached is the patch already accepted upstream which fixes the issue. + I've verified it fixes the problem. Debian has been ignoring this patch + for almost 3 years. Can we get this in Ubuntu please? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1479652 Title: [patch] ntpd rejects source UDP ports less than 123 as bogus Status in NTP: Unknown Status in ntp package in Ubuntu: New Status in ntp package in Debian: Unknown Bug description: [Title copied from Debian bug, which was not filed by me. Description below is mine.] If an NTP client sends a request with a source port less than 123, the packet is silently ignored by ntpd. This is occurring in our environment due to NAT. Attached is the patch already accepted upstream which fixes the issue. I've verified it fixes the problem. Debian has been ignoring this patch for almost 3 years. Can we get this in Ubuntu please? To manage notifications about this bug go to: https://bugs.launchpad.net/ntp/+bug/1479652/+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
