EPIC - extend support range 22.04 => 24.04 => 26.04

[lemanschik]

PR: WiP extend support range 22.04 => 24.04 => 26.04

• Fix: venv via intrudcuing uv as python version manager.
  • align questions and management sh via introducing uv install first
• Fix: Spamd(bevore Spamassassine) Configuration eg etc/default/spamassine is now spamd
• Fix: preflight needs upgrade to support >= 22.04
• Fix: fail2ban owncloud login it does not track all login attempts.
  • fail2ban does not block failed owncloud/nextcloud logins #2505
• Add: SMTPUTF8 Support for the full stack remove the info from README.md that it is not supported
  • postfix/main.cf smtputf8_enable=yes
• Add: Native certbot based autorenw of ssl certs with DANE TLS support via --reuse-key
  • Fix: replace csr flow with reuse-key certbot cli args
• Remove: Over 100 SLOC while running better and more stable then ever before.
• Add migration for all existing old boxes based on 22.04 include apt-get upgrade dist release.
• Add: projecttoml + init.py files setuptools meta to allow simple installation.
  • # Gunicorn loads the 'wsgi' module from the installed 'management' package uv run gunicorn -b localhost:10222 -w 1 --timeout 630 management.wsgi:app
• Fix: /var/lib/mailinabox should be the default storage directory. var is special for growing content. eg /var/backups stores already backups of the system logs and so on

TODO:

• Identifiy .py files that include main create wrappers for them
• Come up with better aligned miab cli clint that enforces env $HOME $PATH $PWD

Conclusion all stuff that changes between 22.04 => 26.04

• python version management as all run diffrent python version in 22.04 python 3.10 is python-dev in 24.04 is python-dev 3.12 maybe soon 3.14
  • Solution Switch to UV for the current releases and the upcoming so we use a stable Python version
• Spamassaine migration to Spamd will be maybe even backported.
  • check if the /etc/default is the old spamassine one or the spamd one
• Systemd gets more strict when enabling links.
  • keep linking but use readlink

Hotfixes: Only FYI you should not apply them and when on own risk

## replicated in ./management.sh
# used by the management daemon.
inst_dir=/usr/local/lib/mailinabox
mkdir -p $inst_dir
venv=$inst_dir/env
if [ ! -d $venv ]; then
    if apt-cache show "python3-venv" >/dev/null 2>&1; then
        apt-get -q -q update	
        apt_get_quiet install dialog python3 python3-pip python3-dev python3-venv || exit 1
        # Ubuntu 24.04 and Python 3.12 requires venv
        # export DEB_PYTHON_INSTALL_LAYOUT='deb'
        hide_output python3 -m venv $venv

        source $venv/bin/activate
        # Upgrade pip because the Ubuntu-packaged version is out of date.
        hide_output $venv/bin/pip install --upgrade pip
        
        # Installing email_validator is repeated in setup/management.sh, but in setup/management.sh
        # we install it inside a virtualenv.
        hide_output $venv/bin/pip install "email_validator>=1.0.0" || exit 1
    fi
else
    source $venv/bin/activate
fi

correction for the service loading

cp --remove-destination conf/munin.service /lib/systemd/system/munin.service # target was previously a symlink so remove first
hide_output systemctl link -f /lib/systemd/system/munin.service
hide_output systemctl daemon-reload
hide_output systemctl unmask munin.service
hide_output systemctl enable $(readlink -f /etc/systemd/system/munin.service)

Redundancy Note

hide_output systemctl link -f /lib/systemd/system/munin.service
Action: Informs systemd about a unit file that has been manually added or modified outside of standard packaging mechanisms.
Purpose: While daemon-reload (Step 3) handles units in standard locations, the link command is often used to ensure that systemd immediately recognizes the unit and updates its internal status/cache. The -f (force) ensures it proceeds even if the file is already known.
Redundancy Note: If this service file is in a standard location (/lib/systemd/system/), systemctl daemon-reload is usually sufficient. However, using link ensures that the unit is fully registered before attempting subsequent operations like enable or unmask.

[Synchro]

I wouldn't bother doing this. 22.04 is still perfectly functional and supported, and 26.04 is only 6 months away. I'd recommend targeting 26.04 so that MiaB can be ready for it when it arrives.

[lemanschik]

@Synchro thats not a problem will now start on targeting 26.04 also but i guess there will not be much upgrade problems from 24.04 the biggest change is the python handling and spamassine upgrade.

But will verify now if it also directly works on 26.04

[kiekerjan]

Check here for some upgrade work somebody else already did to make things work with 24.04.

[kiekerjan]

@kiekerjan shame on you i did now look into that and it is a horror i hope that was a bad joke?

Well, you didn't say what changes you already had finished, and in my experience the changes in the referred topic were needed to install on 24.04. Just trying to help.

[lemanschik]

@kiekerjan no problem i understand that but i guess even you should have seen that this PR can never get merged he did even write it him self he named it hackery that is not replicate able.

He did a total messup without knowing what he does he did not even handle the spamassasine case the defualt config for it is now /etc/default/spamd and so on and so on we should all ignore the hackery

every one should know that breaking the systems python version that all other apt packages use is a NO NO NO NO!