Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore
On Mon, 21 Dec 2020, Bernhard Schmidt wrote: I have a recursive diff of both config dirs, but haven't been able to see what has done what. I still have a test-server so I can help with providing more info is so needed. Please attach the diff to this bug report. I attached the diff. Thanks. Thanks, this one sounds like the culprit. Only in freeradius-debian-9.0/3.0/sites-enabled: default Only in freeradius-debian-9.0/3.0/sites-enabled: inner-tunnel Can you "ls -la" the sites-enabled directory in both the working and the non-working configuration? ~# ls -l /etc/freeradius-debian-9.0/3.0/sites-enabled/ total 52 -rw-r- 1 freerad freerad 2040 Feb 23 2018 control-socket -rw-r- 1 freerad freerad 27043 Feb 23 2018 default -rw-r- 1 freerad freerad 728 Feb 23 2018 eduroam -rw-r- 1 freerad freerad 625 Feb 23 2018 eduroam-inner-tunnel -rw-r- 1 freerad freerad 11784 Feb 23 2018 inner-tunnel ~# ls -l /etc/freeradius-debian-10.0/3.0/sites-enabled/ total 12 -rw-r- 1 freerad freerad 2040 Feb 23 2018 control-socket -rw-r- 1 freerad freerad 728 Feb 23 2018 eduroam -rw-r- 1 freerad freerad 625 Feb 23 2018 eduroam-inner-tunnel So they are regular files. The code in postinst responsible for enabling this on upgrades would install symlinks --- # Create links for default sites, but only if this is an initial # install or an upgrade from before there were links; users may # want to remove them... if [ -z "$2" ] || dpkg --compare-versions "$2" lt 2.0.4+dfsg-4; then for site in default inner-tunnel; do if test ! -h /etc/freeradius/3.0/sites-enabled/$site && \ test ! -e /etc/freeradius/3.0/sites-enabled/$site; then ln -s ../sites-available/$site /etc/freeradius/3.0/sites-enabled/$site fi done fi --- Have you verified that this is indeed the missing change (readding the file/symlink fixes the issue)? Sorry no, I can test this later tonight. Can you show the full output of /var/log/dpkg.log* for the radius related packages? I can't find any reason why it would delete the old files in there. # grep '^2020-12-17.*freeradius' /var/log/dpkg.log 2020-12-17 14:04:42 upgrade freeradius-common:all 3.0.12+dfsg-5+deb9u1 3.0.17+dfsg-1.1 2020-12-17 14:04:42 status half-configured freeradius-common:all 3.0.12+dfsg-5+deb9u1 2020-12-17 14:04:42 status unpacked freeradius-common:all 3.0.12+dfsg-5+deb9u1 2020-12-17 14:04:42 status half-installed freeradius-common:all 3.0.12+dfsg-5+deb9u1 2020-12-17 14:04:42 status half-installed freeradius-common:all 3.0.12+dfsg-5+deb9u1 2020-12-17 14:04:42 status unpacked freeradius-common:all 3.0.17+dfsg-1.1 2020-12-17 14:04:42 status unpacked freeradius-common:all 3.0.17+dfsg-1.1 2020-12-17 14:04:43 upgrade freeradius-config:amd64 3.0.12+dfsg-5+deb9u1 3.0.17+dfsg-1.1 2020-12-17 14:04:43 status half-configured freeradius-config:amd64 3.0.12+dfsg-5+deb9u1 2020-12-17 14:04:43 status unpacked freeradius-config:amd64 3.0.12+dfsg-5+deb9u1 2020-12-17 14:04:43 status half-installed freeradius-config:amd64 3.0.12+dfsg-5+deb9u1 2020-12-17 14:04:43 status half-installed freeradius-config:amd64 3.0.12+dfsg-5+deb9u1 2020-12-17 14:04:43 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:04:43 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:41 configure freeradius-common:all 3.0.17+dfsg-1.1 2020-12-17 14:05:41 status unpacked freeradius-common:all 3.0.17+dfsg-1.1 2020-12-17 14:05:41 status half-configured freeradius-common:all 3.0.17+dfsg-1.1 2020-12-17 14:05:41 status installed freeradius-common:all 3.0.17+dfsg-1.1 2020-12-17 14:05:51 configure freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64 3.0.17+dfsg-1.1 2020-12-17 14:05:51 status unpacked freeradius-config:amd64
Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore
Hi, > I have a recursive diff of both config dirs, but haven't been > able to see what has done what. I still have a test-server so > I can help with providing more info is so needed. Please attach the diff to this bug report. >>> >>> I attached the diff. Thanks. >> >> Thanks, this one sounds like the culprit. >> >> Only in freeradius-debian-9.0/3.0/sites-enabled: default >> Only in freeradius-debian-9.0/3.0/sites-enabled: inner-tunnel >> >> Can you "ls -la" the sites-enabled directory in both the working and the >> non-working configuration? > > ~# ls -l /etc/freeradius-debian-9.0/3.0/sites-enabled/ > total 52 > -rw-r- 1 freerad freerad 2040 Feb 23 2018 control-socket > -rw-r- 1 freerad freerad 27043 Feb 23 2018 default > -rw-r- 1 freerad freerad 728 Feb 23 2018 eduroam > -rw-r- 1 freerad freerad 625 Feb 23 2018 eduroam-inner-tunnel > -rw-r- 1 freerad freerad 11784 Feb 23 2018 inner-tunnel > ~# ls -l /etc/freeradius-debian-10.0/3.0/sites-enabled/ > total 12 > -rw-r- 1 freerad freerad 2040 Feb 23 2018 control-socket > -rw-r- 1 freerad freerad 728 Feb 23 2018 eduroam > -rw-r- 1 freerad freerad 625 Feb 23 2018 eduroam-inner-tunnel So they are regular files. The code in postinst responsible for enabling this on upgrades would install symlinks --- # Create links for default sites, but only if this is an initial # install or an upgrade from before there were links; users may # want to remove them... if [ -z "$2" ] || dpkg --compare-versions "$2" lt 2.0.4+dfsg-4; then for site in default inner-tunnel; do if test ! -h /etc/freeradius/3.0/sites-enabled/$site && \ test ! -e /etc/freeradius/3.0/sites-enabled/$site; then ln -s ../sites-available/$site /etc/freeradius/3.0/sites-enabled/$site fi done fi --- Have you verified that this is indeed the missing change (readding the file/symlink fixes the issue)? Can you show the full output of /var/log/dpkg.log* for the radius related packages? I can't find any reason why it would delete the old files in there. Bernhard
Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore
On Mon, 21 Dec 2020, Bernhard Schmidt wrote: Am 21.12.20 um 10:21 schrieb Harald Hannelius: Hi Harald, I have a recursive diff of both config dirs, but haven't been able to see what has done what. I still have a test-server so I can help with providing more info is so needed. Please attach the diff to this bug report. I attached the diff. Thanks. Thanks, this one sounds like the culprit. Only in freeradius-debian-9.0/3.0/sites-enabled: default Only in freeradius-debian-9.0/3.0/sites-enabled: inner-tunnel Can you "ls -la" the sites-enabled directory in both the working and the non-working configuration? ~# ls -l /etc/freeradius-debian-9.0/3.0/sites-enabled/ total 52 -rw-r- 1 freerad freerad 2040 Feb 23 2018 control-socket -rw-r- 1 freerad freerad 27043 Feb 23 2018 default -rw-r- 1 freerad freerad 728 Feb 23 2018 eduroam -rw-r- 1 freerad freerad 625 Feb 23 2018 eduroam-inner-tunnel -rw-r- 1 freerad freerad 11784 Feb 23 2018 inner-tunnel ~# ls -l /etc/freeradius-debian-10.0/3.0/sites-enabled/ total 12 -rw-r- 1 freerad freerad 2040 Feb 23 2018 control-socket -rw-r- 1 freerad freerad 728 Feb 23 2018 eduroam -rw-r- 1 freerad freerad 625 Feb 23 2018 eduroam-inner-tunnel There are some code paths touching those directories in postinst, but they appear to be correctly guarded to be executed only from jessie to stretch, not from stretch to buster. Something missing in the postinst-scripts then I guess. -- Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020
Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore
Am 21.12.20 um 10:21 schrieb Harald Hannelius: Hi Harald, > >>> I have a recursive diff of both config dirs, but haven't been >>> able to see what has done what. I still have a test-server so >>> I can help with providing more info is so needed. >> >> Please attach the diff to this bug report. > > I attached the diff. Thanks. Thanks, this one sounds like the culprit. Only in freeradius-debian-9.0/3.0/sites-enabled: default Only in freeradius-debian-9.0/3.0/sites-enabled: inner-tunnel Can you "ls -la" the sites-enabled directory in both the working and the non-working configuration? There are some code paths touching those directories in postinst, but they appear to be correctly guarded to be executed only from jessie to stretch, not from stretch to buster. Bernhard
Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore
On Fri, 18 Dec 2020, Bernhard Schmidt wrote: Earlier Harald Hannelius wrote: I have a recursive diff of both config dirs, but haven't been able to see what has done what. I still have a test-server so I can help with providing more info is so needed. Please attach the diff to this bug report. I attached the diff. Thanks. -- Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020diff -u -r freeradius-debian-9.0/3.0/README.rst freeradius-debian-10.0/3.0/README.rst --- freeradius-debian-9.0/3.0/README.rst2017-08-10 10:05:06.0 +0300 +++ freeradius-debian-10.0/3.0/README.rst 2019-04-23 00:23:36.0 +0300 @@ -76,8 +76,8 @@ Modules can be enabled by creating a soft link. For module ``foo``, do:: - $ cd raddb - $ ln -s mods-available/foo mods-enabled/foo + $ cd raddb/mods-enabled + $ ln -s ../mods-available/foo To create "local" versions of the modules, we suggest copying the file instead. This leaves the original file (with documentation) in the @@ -660,6 +660,6 @@ Dialup_admin -The dialip_admin directory has been removed. No one stepped forward +The dialup_admin directory has been removed. No one stepped forward to maintain it, and the code had not been changed in many years. diff -u -r freeradius-debian-9.0/3.0/certs/Makefile freeradius-debian-10.0/3.0/certs/Makefile --- freeradius-debian-9.0/3.0/certs/Makefile2017-08-10 10:05:06.0 +0300 +++ freeradius-debian-10.0/3.0/certs/Makefile 2019-04-23 00:23:36.0 +0300 @@ -5,16 +5,22 @@ # # See the README file in this directory for more information. # -# $Id: cc12464c6c7754aff2f0c8d6e116708c94ff2168 $ +# $Id: 16447a023d2cdce2d16d39cf31bcde4dba600df5 $ # ## DH_KEY_SIZE= 2048 +OPENSSL= openssl +EXTERNAL_CA= $(wildcard external_ca.*) + +ifneq "$(EXTERNAL_CA)" "" +PARTIAL= -partial_chain +endif # # Set the passwords # --include passwords.mk +include passwords.mk ## # @@ -33,11 +39,15 @@ .PHONY: server server: server.pem server.vrfy +.PHONY: inner-server +inner-server: inner-server.pem inner-server.vrfy + .PHONY: verify verify: server.vrfy client.vrfy -passwords.mk: server.cnf ca.cnf client.cnf +passwords.mk: server.cnf ca.cnf client.cnf inner-server.cnf @echo "PASSWORD_SERVER = '$(shell grep output_password server.cnf | sed 's/.*=//;s/^ *//')'" > $@ + @echo "PASSWORD_INNER = '$(shell grep output_password inner-server.cnf | sed 's/.*=//;s/^ *//')'" >> $@ @echo "PASSWORD_CA = '$(shell grep output_password ca.cnf | sed 's/.*=//;s/^ *//')'" >> $@ @echo "PASSWORD_CLIENT = '$(shell grep output_password client.cnf | sed 's/.*=//;s/^ *//')'" >> $@ @echo "USER_NAME= '$(shell grep emailAddress client.cnf | grep '@' | sed 's/.*=//;s/^ *//')'" >> $@ @@ -49,7 +59,7 @@ # ## dh: - openssl gendh -out dh -2 $(DH_KEY_SIZE) + $(OPENSSL) dhparam -out dh -2 $(DH_KEY_SIZE) ## # @@ -59,11 +69,12 @@ ca.key ca.pem: ca.cnf @[ -f index.txt ] || $(MAKE) index.txt @[ -f serial ] || $(MAKE) serial - openssl req -new -x509 -keyout ca.key -out ca.pem \ + $(OPENSSL) req -new -x509 -keyout ca.key -out ca.pem \ -days $(CA_DEFAULT_DAYS) -config ./ca.cnf + chmod g+r ca.key ca.der: ca.pem - openssl x509 -inform PEM -outform DER -in ca.pem -out ca.der + $(OPENSSL) x509 -inform PEM -outform DER -in ca.pem -out ca.der ## # @@ -71,20 +82,23 @@ # ## server.csr server.key: server.cnf - openssl req -new -out server.csr -keyout server.key -config ./server.cnf + $(OPENSSL) req -new -out server.csr -keyout server.key -config ./server.cnf + chmod g+r server.key server.crt: server.csr ca.key ca.pem - openssl ca -batch -keyfile ca.key -cert ca.pem -in server.csr -key $(PASSWORD_CA) -out server.crt -extensions xpserver_ext -extfile xpextensions -config ./server.cnf + $(OPENSSL) ca -batch -keyfile ca.key -cert ca.pem -in server.csr -key $(PASSWORD_CA) -out server.crt -extensions xpserver_ext -extfile xpextensions -config ./server.cnf server.p12: server.crt - openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -passin pass:$(PASSWORD_SERVER) -passout pass:$(PASSWORD_SERVER) + $(OPENSSL) pkcs12 -export -in server.crt -inkey server.key -out server.p12 -passin pass:$(PASSWORD_SERVER) -passout pass:$(PASSWORD_SERVER) + chmod g+r server.p12 server.pem:
Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore
On Fri, 18 Dec 2020, Bernhard Schmidt wrote: Control: severity -1 important Control: tags -1 moreinfo Hi Harald, I'm going to downgrade this because - it does not break unrelated software ... The radius server not running might cause other software not to be able to authenticate anymore, but Radius can be easily made redundant. - this is the first report received from oldstable to stable (which has been out for 1,5 years), so I don't think it's widespread. Fair enough, and expected. That being said... I then copied the whole /etc/freeradius directory from the previous setup, and started freeradius -X again. The output is now as it should; [...] I have a recursive diff of both config dirs, but haven't been able to see what has done what. I still have a test-server so I can help with providing more info is so needed. Please attach the diff to this bug report. I will, I have to sanitize it a bit first. -- Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020
Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore
Control: severity -1 important Control: tags -1 moreinfo Hi Harald, I'm going to downgrade this because - it does not break unrelated software ... The radius server not running might cause other software not to be able to authenticate anymore, but Radius can be easily made redundant. - this is the first report received from oldstable to stable (which has been out for 1,5 years), so I don't think it's widespread. That being said... > I then copied the whole /etc/freeradius directory from the previous > setup, and started freeradius -X again. The output is now as it should; [...] > I have a recursive diff of both config dirs, but haven't been > able to see what has done what. I still have a test-server so > I can help with providing more info is so needed. Please attach the diff to this bug report. Bernhard
Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore
Package: freeradius
Version: 3.0.17+dfsg-1.1
Severity: critical
Justification: breaks unrelated software
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
I upgraded debian 9 to debian 10, this upgrading freeradius-3.0.12 to
freeradius-3.0.17
at the same time.
After the upgrade freeradius starts, but doesn't answer any network requests.
The
end of the output of 'freeradius -X' says the following;
radiusd: Opening IP addresses and Ports
listen {
type = "control"
listen {
socket = "/var/run/freeradius/freeradius.sock"
peercred = yes
}
}
Listening on command file /var/run/freeradius/freeradius.sock
Ready to process requests
EOF
I didn't allow the upgrade process to do any changes in the config
files.
I then copied the whole /etc/freeradius directory from the previous
setup, and started freeradius -X again. The output is now as it should;
listen {
type = "acct"
ipv6addr = ::
port = 0
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}
Listening on command file /var/run/freeradius/freeradius.sock
Listening on auth address * port 1812 bound to server default
Listening on acct address * port 1813 bound to server default
Listening on auth address :: port 1812 bound to server default
Listening on acct address :: port 1813 bound to server default
Listening on proxy address * port 45082
Listening on proxy address :: port 38835
Ready to process requests
EOF
I would have expected a minor software version number upgrade to
lead to a little smoother end result.
I put this as critical, since a radius server might be quite
important for infrastructures. Sorry if that sounded an alarm
or something like that.
There's clearly some changes that have happened during the
upgrade to debian 10 that shouldn't have been done.
I have a recursive diff of both config dirs, but haven't been
able to see what has done what. I still have a test-server so
I can help with providing more info is so needed.
Thank You all for freeradius!
-- System Information:
Debian Release: 10.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages freeradius depends on:
ii freeradius-common 3.0.17+dfsg-1.1
ii freeradius-config 3.0.17+dfsg-1.1
ii libc6 2.28-10
ii libcap21:2.25-2
ii libct4 1.00.104-1+deb10u1
ii libfreeradius3 3.0.17+dfsg-1.1
ii libgdbm6 1.18.1-4
ii libpam0g 1.3.1-5
ii libpcre3 2:8.39-12
ii libperl5.285.28.1-6+deb10u1
ii libreadline7 7.0-5
ii libsqlite3-0 3.27.2-3+deb10u1
ii libssl1.1 1.1.1d-0+deb10u4
ii libtalloc2 2.1.14-2
ii libwbclient0 2:4.9.5+dfsg-5+deb10u1
ii lsb-base 10.2019051400
Versions of packages freeradius recommends:
ii freeradius-utils 3.0.17+dfsg-1.1
Versions of packages freeradius suggests:
pn freeradius-krb5
ii freeradius-ldap3.0.17+dfsg-1.1
pn freeradius-mysql
pn freeradius-postgresql
pn freeradius-python2
ii snmp 5.7.3+dfsg-5+deb10u1
-- no debconf information
