Bug#995793: Info received (Bug#995793: exim4-base: /tmp partition has noexec mount option; exim4-base fails)

Actual workaround is to remove ‘noexec” from both /tmp and /var. Tested it working without “noexec” mount options on ‘apt upgrade exim4-base’ to versio ‘4.94.2-7’ This makes it like a major work-stoppage of dealing with 1,000s of those hardened Debian systems. > On Oct 5, 2021, at 4:00 PM,

Bug#995793: exim4-base: /tmp partition has noexec mount option; exim4-base fails

workaround of removing ‘noexec’ from /tmp partition in /etc/fstab still doesn’t work. 00 [TERM="linux" TTY="/dev/tty1" COLUMNS="80" LINES="25"] [?2004hroot@circa:~# apt upgrade exim4-base [?2004l Reading package lists... 0% Reading package lists... 100% Reading package lists... Done

Bug#995793: exim4-base: /tmp partition has noexec mount option; exim4-base fails

WORKAROUND Remove the “no exec” from /tmp mount point options in /etcfstab, reboot, then attempt ‘apt upgrade exim4-base’ so that Perl script for ‘exam-config’ can continue. OUTPUT of failed upgrade: ~# apt upgrade exim4-base [?2004l Reading package lists... 0% Reading package lists...

Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon

There is still a Mismatched SOCK filespec implemented by chronyd and chronyc. The saving grace was that loopback network interface hid this bug very well and saved the day for nearly everyone (who is not an expert Chronyd configurer)... That is, until the directive 'cmddeny 127.0.0.1' is

Bug#995260: closed by Vincent Blut (Re: Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon)

so why did it not use the Unix socket but fell back to 127.0.0.1 approach? i wonder what happens if i do ‘cmddeny all’?