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