Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore
freeradius:amd64 3.0.12+dfsg-5+deb9u1 2020-12-17 14:11:18 status unpacked freeradius:amd64 3.0.17+dfsg-1.1 2020-12-17 14:11:18 upgrade libfreeradius3:amd64 3.0.12+dfsg-5+deb9u1 3.0.17+dfsg-1.1 2020-12-17 14:11:18 status half-configured libfreeradius3:amd64 3.0.12+dfsg-5+deb9u1 2020-12-17 14:11:18 status unpacked libfreeradius3:amd64 3.0.12+dfsg-5+deb9u1 2020-12-17 14:11:18 status half-installed libfreeradius3:amd64 3.0.12+dfsg-5+deb9u1 2020-12-17 14:11:19 status unpacked libfreeradius3:amd64 3.0.17+dfsg-1.1 2020-12-17 14:12:22 configure libfreeradius3:amd64 3.0.17+dfsg-1.1 2020-12-17 14:12:22 status unpacked libfreeradius3:amd64 3.0.17+dfsg-1.1 2020-12-17 14:12:22 status half-configured libfreeradius3:amd64 3.0.17+dfsg-1.1 2020-12-17 14:12:22 status installed libfreeradius3:amd64 3.0.17+dfsg-1.1 2020-12-17 14:12:22 configure freeradius-utils:amd64 3.0.17+dfsg-1.1 2020-12-17 14:12:22 status unpacked freeradius-utils:amd64 3.0.17+dfsg-1.1 2020-12-17 14:12:22 status half-configured freeradius-utils:amd64 3.0.17+dfsg-1.1 2020-12-17 14:12:22 status installed freeradius-utils:amd64 3.0.17+dfsg-1.1 2020-12-17 14:14:31 configure freeradius:amd64 3.0.17+dfsg-1.1 2020-12-17 14:14:31 status unpacked freeradius:amd64 3.0.17+dfsg-1.1 2020-12-17 14:14:31 status half-configured freeradius:amd64 3.0.17+dfsg-1.1 2020-12-17 14:14:32 status installed freeradius:amd64 3.0.17+dfsg-1.1 2020-12-17 14:14:33 configure freeradius-ldap:amd64 3.0.17+dfsg-1.1 2020-12-17 14:14:33 status unpacked freeradius-ldap:amd64 3.0.17+dfsg-1.1 2020-12-17 14:14:33 status half-configured freeradius-ldap:amd64 3.0.17+dfsg-1.1 2020-12-17 14:14:33 status installed freeradius-ldap:amd64 3.0.17+dfsg-1.1 -- 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
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
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) -pa
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
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
Bug#974206: closed by Ben Hutchings (Re: Bug#974206: debian-installer: When entering an IPv6 address, fe80::1 should be a valid gateway)
On Wed, 11 Nov 2020, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the debian-installer package: #974206: debian-installer: When entering an IPv6 address, fe80::1 should be a valid gateway It has been closed by Ben Hutchings . No, this is a link-local address so you have to also specify the interface name, e.g. "fe80::1%eth0", The installer could then give a hint that %eth0 should be added, or any interface name that was used in the previous step when the interface got it's IP-address. The user doesn't know the correct name for the interface at that stage, it might be ens3, eth0, wlan0, eno1, wlp1s3 or something else. I can't remember when I have had to add the interface name to the gateway since this configuration is usually added in the context of the interface being configured. -- Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020
Bug#974206: debian-installer: When entering an IPv6 address, fe80::1 should be a valid gateway
Package: debian-installer Version: Debian 10.6 Severity: normal Dear Maintainer, I needed to enter an IPv6-address in the installer. When entering fe80::1 as a gateway the installer stops with an error that the address isn't reachable. The address fe80::1 is indeed a valid address for a gateway. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (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
Bug#962695: iftop resolves all IPv6 addresse to the same hostname
Package: iftop Version: 1.0~pre4-4 Severity: minor Dear Maintainer, When running iftop on a server with serveral IPv6-connections ongoing, iftop seems to resolve the ip-addresses to the same hostname. This is a bit confusing. By pressing 'n' to get numerical output everything looks correct. -- System Information: Debian Release: 9.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-11-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, 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) Versions of packages iftop depends on: ii libc62.24-11+deb9u4 ii libncurses5 6.0+20161126-1+deb9u2 ii libpcap0.8 1.8.1-3 ii libtinfo56.0+20161126-1+deb9u2 iftop recommends no packages. iftop suggests no packages. -- no debconf information
Bug#947927: Got it working
It seems like a restart of mimedefang was needed after an upgrade of spamassassin (and spamd). It might be the spamassassin package's responsibility to do that? -- Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020
Bug#947927: mimedefang: Mimedefang is unable to start after upgrade of spamassassin
Package: mimedefang Version: 2.79-2 Severity: grave Justification: causes non-serious data loss Dear Maintainer, There was an update on spamassassin two days ago, that updated to 3.4.2-1~deb9u2 on both our incoming gateways. Both are debian 9, and both are also using mimedefang. Both now cause mail to be queued if the mimedefang-milter is enabled. Jan 2 10:13:05 server mimedefang-multiplexor[1026]: Starting slave 5 (pid 156560) (2 running): Bringing slaves up to minSlaves (2) Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: plugin: failed to parse plugin (from @INC): "qr_to_string" is not exported by the Mail::SpamAssassin::Util module Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Can't continue after import errors at /usr/share/perl5/Mail/SpamAssassin/Plugin/Rule2XSBody.pm line 41. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Plugin/Rule2XSBody.pm line 41. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Compilation failed in require at (eval 94) line 1. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: plugin: failed to parse plugin (from @INC): "compile_regexp" is not exported by the Mail::SpamAssassin::Util module Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Can't continue after import errors at /usr/share/perl5/Mail/SpamAssassin/Plugin/MIMEHeader.pm line 68. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Plugin/MIMEHeader.pm line 68. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Compilation failed in require at (eval 127) line 1. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: plugin: failed to parse plugin (from @INC): "compile_regexp" is not exported by the Mail::SpamAssassin::Util module Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: "qr_to_string" is not exported by the Mail::SpamAssassin::Util module Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Can't continue after import errors at /usr/share/perl5/Mail/SpamAssassin/Plugin/ReplaceTags.pm line 55. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Plugin/ReplaceTags.pm line 55. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Compilation failed in require at (eval 128) line 1. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: plugin: failed to parse plugin (from @INC): Bareword "RULENAME_RE" not allowed while "strict subs" in use at /usr/share/perl5/Mail/SpamAssassin/Plugin/Check.pm line 32. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Compilation failed in require at (eval 131) line 1. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: plugin: failed to parse plugin (from @INC): "compile_regexp" is not exported by the Mail::SpamAssassin::Util module Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Can't continue after import errors at /usr/share/perl5/Mail/SpamAssassin/Plugin/URIDetail.pm line 71. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Plugin/URIDetail.pm line 71. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Compilation failed in require at (eval 134) line 1. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: plugin: failed to parse plugin (from @INC): "compile_regexp" is not exported by the Mail::SpamAssassin::Util module Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Can't continue after import errors at /usr/share/perl5/Mail/SpamAssassin/Plugin/HTMLEval.pm line 27. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Plugin/HTMLEval.pm line 27. Jan 2 10:16:31 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Compilation failed in require at (eval 141) line 1. Jan 2 10:16:32 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Timeout::_run: check: no loaded plugin implements 'check_main': cannot scan! Jan 2 10:16:32 server mimedefang-multiplexor[1026]: 0028GNZ7156694: Slave 8 stderr: Check that the necessary '.pre' files are in the config directory. Jan 2 10:16:32 server mimedefang-multiplex
Bug#928164: backports work
On Mon, 29 Apr 2019, Frederic Peters wrote: Harald Hannelius wrote: I forgot to mention that installing of liblasso3 from stretch backports also fixes the problem and I can operate as an SP and sign requests. Good to know as there's an important diff between 2.5.0 and 2.6.0, and cherrypicking a specific commit may be difficult; I'll still look at bisecting but it may take some time. I don't know how this happened, but there doesn't seem to be a liblasso3 in backports. Somehow the other server worked, but after a reboot I started getting signal 11 on that one too. It worked for a week. I disabled signing och all of the sites through creating static SP Metadata, and now the sites are up again. I would have been OK to have 2.6.0 of liblasso3 in stretch backports, and I was in the believe that I had installed it. But when checking, I'm still running 2.5.0-5+b1. Spooky -- Harald Hannelius | har...@iki.fi | +358505941020
Bug#928164: backports work
On Mon, 29 Apr 2019, Frederic Peters wrote: fixed 928164 2.6.0-2 thanks Will this dribble down to Debian Stretch? -- Harald Hannelius | har...@iki.fi | +358505941020
Bug#928164: backports work
I forgot to mention that installing of liblasso3 from stretch backports also fixes the problem and I can operate as an SP and sign requests. -- Harald Hannelius | har...@iki.fi | +358505941020
Bug#928164: liblasso3 dies with signal 11 if signing of requests is enabled
Package: liblasso3 Version: 2.5.0-5+b1 Severity: important Dear Maintainer, I installed liblasso3 (a requirement for mod_auth_mellon). Configured to use ADFS as authsource. When signing of claims is enabled liblasso3 dies with signal 11 sigsegv. If I disable signing of claims everything works. Also see : https://github.com/Uninett/mod_auth_mellon/issues/203 (gdb) run -X -k start Starting program: /usr/sbin/apache2 -X -k start [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x73a33a1e in RSA_sign () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (gdb) bt #0 0x73a33a1e in RSA_sign () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 #1 0x754b11ea in ?? () from /usr/lib/liblasso.so.3 #2 0x754f66d0 in ?? () from /usr/lib/liblasso.so.3 #3 0x754f6894 in ?? () from /usr/lib/liblasso.so.3 #4 0x754f4d74 in ?? () from /usr/lib/liblasso.so.3 #5 0x754f54ac in ?? () from /usr/lib/liblasso.so.3 #6 0x754fb628 in ?? () from /usr/lib/liblasso.so.3 #7 0x754d312a in lasso_login_build_authn_request_msg () from /usr/lib/liblasso.so.3 #8 0x75eb6b8d in am_init_authn_request_common (r=r@entry=0x7fffddfae0a0, login_return=login_return@entry=0x7fffdea0, idp=idp@entry=0x7fffddfaa770 "http://adfs.arcada.fi/adfs/services/trust";, http_method=http_method@entry=LASSO_HTTP_METHOD_REDIRECT, destination_url=destination_url@entry=0x55bd31a0 "https://adfs.arcada.fi/adfs/ls/";, assertion_consumer_service_url=assertion_consumer_service_url@entry=0x55bb7840 "https://asta.arcada.fi/endpoint/postResponse";, return_to_url=0x7fffddfaa5f0 "https://asta.arcada.fi/";, is_passive=0) at auth_mellon_handler.c:2945 #9 0x75eb77b4 in am_send_login_authn_request (r=r@entry=0x7fffddfae0a0, idp=0x7fffddfaa770 "http://adfs.arcada.fi/adfs/services/trust";, return_to_url=return_to_url@entry=0x7fffddfaa5f0 "https://asta.arcada.fi/";, is_passive=0) at auth_mellon_handler.c:3151 #10 0x75eb8f92 in am_handle_login (r=0x7fffddfae0a0) at auth_mellon_handler.c:3282 #11 am_handler (r=0x7fffddfae0a0) at auth_mellon_handler.c:3540 #12 0x555abd60 in ap_run_handler (r=r@entry=0x7fffddfae0a0) at config.c:170 #13 0x555ac2f6 in ap_invoke_handler (r=r@entry=0x7fffddfae0a0) at config.c:434 #14 0x555c3f33 in ap_process_async_request (r=0x7fffddfae0a0) at http_request.c:436 #15 0x555c4040 in ap_process_request (r=r@entry=0x7fffddfae0a0) at http_request.c:471 #16 0x555c00fd in ap_process_http_sync_connection (c=0x7fffe58be290) at http_core.c:210 #17 ap_process_http_connection (c=0x7fffe58be290) at http_core.c:251 #18 0x555b5bd0 in ap_run_process_connection (c=c@entry=0x7fffe58be290) at connection.c:42 #19 0x555b6120 in ap_process_connection (c=c@entry=0x7fffe58be290, csd=) at connection.c:226 #20 0x7fffeaf456bf in child_main (child_num_arg=child_num_arg@entry=0, child_bucket=child_bucket@entry=0) at prefork.c:723 #21 0x7fffeaf458da in make_child (s=0x77fc34a0, slot=slot@entry=0) at prefork.c:768 #22 0x7fffeaf46dfd in prefork_run (_pconf=, plog=0x77fbe028, s=0x77fc34a0) at prefork.c:975 #23 0x5558f0fe in ap_run_mpm (pconf=0x77ff0028, plog=0x77fbe028, s=0x77fc34a0) at mpm_common.c:94 #24 0x55587cfd in main (argc=, argv=) at main.c:783 -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, 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) Versions of packages liblasso3 depends on: ii libc6 2.24-11+deb9u4 ii libglib2.0-02.50.3-2 ii libssl1.0.2 1.0.2r-1~deb9u1 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii libxmlsec1 1.2.23-0.1 ii libxmlsec1-openssl 1.2.23-0.1 ii libxslt1.1 1.1.29-2.1 ii zlib1g 1:1.2.8.dfsg-5 liblasso3 recommends no packages. liblasso3 suggests no packages. -- no debconf information
Bug#892467: Acknowledgement (spfquery (libspf2-2?) and spf-milter-python falsely report "Void lookup limit exceeded")
Please close this bug. It turned out that the domain mhd.se must have -records for the included 'a:' hostnames in DNS, which they didn't. And by using cloud-based e-mail they are using IPv6 without actually knowing it. $ host f-medby.ita.mdh.se f-medby.ita.mdh.se has address 130.243.84.223 $ host -t f-medby.ita.mdh.se # first void lookup f-medby.ita.mdh.se has no record $ host -t www.netigate.se # second void lookup www.netigate.se has no record $ host -t smtp.quicknet.se # third void lookup smtp.quicknet.se has no record Many thanks to Stuart D. Gathman for pointing this out to me. -- Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020
Bug#892477: Acknowledgement (spf-milter-python: If connection is IPv6, milter says "Void lookup limit of 2 exceeded")
Please close this bug. It turned out that the domain mhd.se must have -records for the included 'a:' hostnames in DNS, which they didn't. And by using cloud-based e-mail they are using IPv6 without actually knowing it. $ host f-medby.ita.mdh.se f-medby.ita.mdh.se has address 130.243.84.223 $ host -t f-medby.ita.mdh.se # first void lookup f-medby.ita.mdh.se has no record $ host -t www.netigate.se # second void lookup www.netigate.se has no record $ host -t smtp.quicknet.se # third void lookup smtp.quicknet.se has no record Many thanks to Stuart D. Gathman for pointing this out to me. -- Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020
Bug#892477: spf-milter-python: If connection is IPv6, milter says "Void lookup limit of 2 exceeded"
Package: spf-milter-python Version: 0.8.18-2 Severity: grave Tags: ipv6 Justification: causes non-serious data loss Dear Maintainer, I noted that when someone at mdh.se tries to send e-mail to us, and the connection is from an IPv6-address (almost all connections are these days), spf-milter-python will reply "Void lookup limit of 2 exceeded". The domain always passes all checks on both mxtoolbox.com/spf.aspx and http://www.kitterman.com/spf/validate.html. I even had a loop running for a day, using spfquery to log the results while waiting for a failing e-mail. When the mail-server responded "Void lookup limit of 2 exceeded", the data in the diagnostic-log looked correct and had not failed. I can reproduce this by telnetting my SMTP-gateway, and pretend to be sending from mdh.se. If I connect over an IPv6-connection I get a "Void lookup limit of 2 exceeded", every time. If I telnet the IPv4-address of the SMTP-gateway i get a soft-error (expected result). I have the same software on the other SMTP-gateway, and it has the same behaviour. -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-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) Versions of packages spf-milter-python depends on: ii adduser3.115 ii lsb-base 9.20161125 ii python 2.7.13-2 ii python-milter 1.0-2 ii python-spf 2.0.12t-3 spf-milter-python recommends no packages. Versions of packages spf-milter-python suggests: ii sendmail 8.15.2-8 -- Configuration Files: /etc/spf-milter-python/spfmilter.cfg changed: [milter] socketname = /var/run/spf-milter-python/spfmiltersock ;umask = 0177 name = pyspffilter ;trusted_relay = internal_connect = 127.0.0.1,192.168.0.0/16,10.0.0.0/8,IPv6:0:0:0:0:0:0:0:1,::1,0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 ;best_guess = v=spf1 a mx ptr ?all ;delegate = domain.com untrapped_exception = CONTINUE [spf] access_file = /etc/mail/access.db ;access_file_nulls = false ;trusted_forwarder = careerbuilder.com -- no debconf information
Bug#892467: spfquery (libspf2-2?) and spf-milter-python falsely report "Void lookup limit exceeded"
Package: spfquery Version: 1.2.10-7+b2 Severity: grave Tags: ipv6 Justification: causes non-serious data loss Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I got notified that another organization was unable to mail us. This didn't happen all the time, but every few e-mail. The error logged by sendmail was 'Void lookup limit exceeded'. I then had a loop running, doing spfquery for that domain every 5 seconds. When the next fail in the mail-log came, the spfquery test succeeded. I then noted that running spfquery for that domain, with an IPv6 address always returns "void lookup limit of 2 exceeded" spfquery --sender=some.u...@mdh.se --ip=2001:708:170:33::200 permerror SPF Permanent Error: Void lookup limit of 2 exceeded spfquery: permanent error in processing domain of mdh.se: Void lookup limit of 2 exceeded Received-SPF: PermError (spfquery: permanent error in processing domain of mdh.se: Void lookup limit of 2 exceeded) client-ip=2001:708:170:33::200; envelope-from="some.u...@mdh.se"; receiver=spfquery; identity=mailfrom # apt-show-versions spfquery libspf2-2 libspf2-2:amd64/stretch 1.2.10-7+b2 uptodate spfquery:amd64/stretch 1.2.10-7+b2 uptodate Running the same on an Ubuntu 17.10 always succeeds; $ spfquery --sender=some.u...@mdh.se --ip=2a01:0111:f400:fe1e::0712 pass spfquery: domain of mdh.se designates 2a01:111:f400:fe1e::712 as permitted sender Received-SPF: pass (spfquery: domain of mdh.se designates 2a01:111:f400:fe1e::712 as permitted sender) client-ip=2a01:111:f400:fe1e::712; envelope-from=some.u...@mdh.se; $ apt-show-versions spfquery libspf2-2 libspf2-2:amd64/artful 1.2.10-7build2 uptodate libspf2-2:i386 not installed spfquery:amd64/artful 1.2.10-7build2 uptodate spfquery:i386 not installed This leads me to believe there's a bug in debian's implementation. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-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) Versions of packages spfquery depends on: ii libc6 2.24-11+deb9u1 ii libspf2-2 1.2.10-7+b2 spfquery recommends no packages. spfquery suggests no packages. -- no debconf information
Bug#819275: check-support-status outputs a blank line, which is not cron friendly
I was about to file a bug as well, since I just got a lot of e-mail from different cron-daemons. The normal convention would be to not say anything if there isn't anything to tell, wouldn't it? At the very least don't output a single newline. -- A: Top Posters! | s/y Charlotta | Q: What is the most annoying thing on mailing lists? |FIN-2674| http://www.fe83.org/ Finn Express Purjehtijat ry | = | Harald H Hannelius | harald (At) iki (dot) fi | GSM +358 50 594 1020
Bug#619240: Typo: position of quote in start-/stop-script /etc/init.d/mimedefang at line 267
This bug is still present in a freshly installed squeeze 64bit 6.0.4 at 7th Mar 2012. The line-number has changed, but the typo it still there. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#469622: First file download from samba dead slow
On Fri, 7 Mar 2008, Steve Langasek wrote: On Thu, Mar 06, 2008 at 10:38:51AM +0200, Harald Hannelius wrote: Windows XP SP2 client, logged on to samba domain. When copying a file from the Samba-server download speed is terrible, estimate 10-15 minutes for a ~150MB file. Connectivity between computers ok. iperf says 92Mbit/s, scp (cygwin) copies the same file from the same etch-server in under 10s 7-8MByte/s. Downloading with firefox on windows using file:///server/share/... gets around 120KB/sec, as does copying the file in Windows Explorer. copy in cmd.exe is slow too. I would suggest pursuing this upstream on the samba user mailing list. Network performance issues can be caused by any combination of network problems, client configuration problems, server configuration problems, or server bugs; the Debian Samba maintainers are not well-equipped to deal with diagnosing such problems. Ok, I dropped a note to the samba-list. It probably got stuck in the moderation queue. I installed slackware-12 with stock samba-3.0.28. With the same smb.conf and all other testing procedures the same I'm now downloading the testfile in under 10s, repeatedly. So I think it's a 64bit or debian problem. But thanks for your time anyways! -- A: Top Posters Q: What is the most annoying thing on mailing lists? Harald H Hannelius | harald/a\arcada.fi | +358 50 594 1020 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469622: First file download from samba dead slow
Package: samba Version: 3.0.24-6etch9 Severity: important Etch server running samba (amd64) as domain member. SMP. Windows XP SP2 client, logged on to samba domain. When copying a file from the Samba-server download speed is terrible, estimate 10-15 minutes for a ~150MB file. Connectivity between computers ok. iperf says 92Mbit/s, scp (cygwin) copies the same file from the same etch-server in under 10s 7-8MByte/s. Downloading with firefox on windows using file:///server/share/... gets around 120KB/sec, as does copying the file in Windows Explorer. copy in cmd.exe is slow too. Copying is slow both from UNC-paths and from a mapped drive. However, if I in the same session start copying another file, the download speed increases massively and the download takes just ~20s or less. It is even enough if I use smbclient from another computer to download any other file, while that download is running both instances are fast, until the other stops. After this the remaining download is slow again, and the estimate fron Windows Explorer starts ticking minutes. It is even enough if a another domain user, using another client windows-computer starts a download of another file and both instances speed up. I built a samba-3.0.28 packages (sid) and installed that, no avail. I have been playing around with different socket options to no avail. -- smb.conf follows - [global] deadtime = 15 # max xmit = 65535 # getwd cache = yes # socket options = SO_KEEPALIVE TCP_NODELAY aio read size = 16384 socket options = TCP_NODELAY SO_SNDBUF=8129 SO_RCVBUF=8192 # socket options = TCP_NODELAY SO_SNDBUF=4096 SO_RCVBUF=4096 netbios name = atrium debug level = 0 workgroup = nova server string = Intranet load printers = no log file = /var/log/samba/log.%m max log size = 100 security = domain password server = domus encrypt passwords = true local master = no os level = 65 preferred master = no utmp = yes syslog = 0 unix extensions = yes dos charset = ISO8859-15 unix charset = ISO8859-1 display charset = ISO8859-15 [intra] path = /tftpboot/intra comment = Nova Intranet guest ok = no browseable = yes read only = no write list = @domadm invalid users = root altiuser directory mode = 2775 create mask = 0665 directory mask = 2775 - smb.conf ends -- -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages samba depends on: ii deb 1.5.11etch1 Debian configuration management sy ii lib 2.2.41-1 Access control list shared library ii lib 2.4.32-1 Extended attribute shared library ii lib 2.3.6.ds1-13etch5GNU C Library: Shared libraries ii lib 1.39+1.40-WIP-2006.11.14+dfsg-2etch1 common error description library ii lib 1.2.7-4etch2 Common UNIX Printing System(tm) - ii lib 1.4.4-3 the GNU TLS library - runtime libr ii lib 1.4.4-7etch4 MIT Kerberos runtime libraries ii lib 2.1.30-13.3 OpenLDAP libraries ii lib 0.79-5 Pluggable Authentication Modules f ii lib 0.79-5 Runtime support for the PAM librar ii lib 0.79-5 Pluggable Authentication Modules l ii lib 1.10-3 lib for parsing cmdline parameters ii log 3.7.1-3 Log rotation utility ii lsb 3.1-23.2etch1Linux Standard Base 3.1 init scrip ii net 4.29 Basic TCP/IP networking system ii pro 1:3.2.7-3/proc file system utilities ii sam 3.0.24-6etch9Samba common files used by both th ii zli 1:1.2.3-13 compression library - runtime Versions of packages samba recommends: pn smbldap-tools (no description available) -- debconf information: samba/run_mode: daemons samba/tdbsam: false samba/generate_smbpasswd: true -- A: Top Posters Q: What is the most annoying thing on mailing lists? Harald H Hannelius | harald/a\arcada.fi | GSM +358 50 594 1020 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
