recovering from disaster....

well because there are mailman references in the files on the new server and I did NOT copy over any folders!
new server cant send any emails at all. even on a domain that is ONLY on the new server!
errors reference missing database /etc/mailman/aliases or some such...

i'll try the removal as you suggest. but again my question how did it GET onto ns11 (the deb12) in the first place?

edit - removal worked nicely thanks till. now the mail seems to be flowing properly.
but a (couple) of questions - do we have instructions for installing mailman3 on debian12?
I know ispconfig wont support, but maybe standalone could be useful.

also perusing the syslog i see:
2025-10-31T14:34:42.970232-04:00 ns11 named[1118]: network unreachable resolving 'hotmail.com/MX/IN': 2603:1061:0:700::cd#532025-10-31T14:34:42.970390-04:00 ns11 named[1118]: network unreachable resolving 'hotmail.com/MX/IN': 2620:1ec:8ec:700::cd#53

I have no ip6 address I assume this is what its complaining about. can we cleanly disable ipv6 in deb12?
thanks!

 

I see some instructions for installing mailman on debian 12:
https://reintech.io/blog/installing-configuring-mailman-debian-12
I note he says apt install mailman, but it seems the package is now called mailman3.
do you think following these will impact ispconfig? or its mail transport arrangements?
am I taking my life in my hands?
thanks till.

 

I understand 'not supported' but will it break anything if I install it?

 

It will definitely not fix anything but will give your more work and problems to deal with. If your original still works after recovery, why don't you simply remove mailman before migrating, if you believe it caused you problems if migrated as is, though we already know it should not as @till have just confirmed it. Also, you can clean it up after migration, if there still exist any mailman. That all're said, there is no mailman support for Debian 12 and Ubuntu for quite sometimes and may not be any in the future, so why risk it?

 

YIKES! touchy are we? ok of course then I wont play with it in deb12. dont want to ruffle any feathers!
but some questions - do you intend mailman3 support in future?
and does any recent auto-installer debian version still support python2 and mailman2?
from what I read buster (deb10) still would support mailman2. does the autoinstaller if installing on a buster systsem work properly? and is running deb10 still a reasonable thing to do?
I guess I can spin up another server with alma or such and put the mailman lists on it?
I would NOT under ANY circumstances want to offend thee!

 

thought mail was flowing properly on ns11 (the target of my migration from ns10 - but I notice a couple of things -
ping ns10 from itself leads to correct ip address (internal 192.168.2.20)
pinging ns11 from itself comes back with the 127.0.0.1 address (not 192.168.2.15 as it should be).
/etc/network/interfaces is correct with static ip 192.168.2.15.

when I pull up ns11.cdbsystems.com:8080 our certificate is correct.
but the cert for ns11.cdbsystems.com and ns11.cdbsystems.com/roundcube both are wrong and cannot connect to them?

did getting rid of mailman disrupt these?
thanks till.

 

Not sure why you are getting that, but try pinging from another device, instead of.from itself. And other than network interfaces, are all of them rightly set in the /etc/hosts? In multiserver setup, there are a lot of lines just for IPs and its other servers' fqdn in there.

ISPConfig never setup certs for those two, so when you access them via browser, of course it will complain about the certs. If you are using acme.sh, it is discouraged for you to setup server fqdn for port 80 and 443, but just 8080, and for roundcube (and any other apps), the right access with valid certs shall be via port 8081.

You could customize ISPConfig and the apps access to other port number but for them to use port 443, the best ia via proxy but you have to search for the right proxy setup as I don't have one handy with me.

 

well, further investigation shows -
/etc/hosts did not have the 192.168.2.15 static address, so adding that made the internal pings behave properly.

letsencrypt fails to issue a cert for ns11 (vhost subdomain of cdbsystems.com) and it has a python traceback error with 'choose account'.

Code:

2025-11-03 10:10:05,865:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 33, in <module>
    sys.exit(load_entry_point('certbot==2.1.0', 'console_scripts', 'certbot')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 19, in main
    return internal_main.main(cli_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 1736, in main
    return config.func(config, plugins)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 1572, in certonly
    le_client = _init_le_client(config, auth, installer)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 827, in _init_le_client
    acc, acme = _determine_account(config)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 725, in _determine_account
    potential_acc = display_ops.choose_account(accounts)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/display/ops.py", line 86, in choose_account
    code, index = display_util.menu("Please choose an account", labels, force_interactive=True)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 80, in menu
    return obj.get_display().menu(message, choices, default=default, cli_flag=cli_flag,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/display/obj.py", line 470, in menu
    raise self._interaction_fail(message, cli_flag, "Choices: " + repr(choices))
certbot.errors.MissingCommandlineFlag: Missing command line flag or config entry for this setting:
Please choose an account
Choices: ['ns9.cdbsystems.com@2018-03-09T14:07:50Z (6476)', 'ns11.cdbsystems.com@2025-10-12T15:12:05Z (671a)']
2025-11-03 10:10:05,866:ERROR:certbot._internal.log:Missing command line flag or config entry for this setting:
Please choose an account
Choices: ['ns9.cdbsystems.com@2018-03-09T14:07:50Z (6476)', 'ns11.cdbsystems.com@2025-10-12T15:12:05Z (671a)']
2025-11-03 10:12:02,623:DEBUG:certbot._internal.main:certbot version: 2.1.0
2025-11-03 10:12:02,624:DEBUG:certbot._internal.main:Location of certbot entry point: /usr/bin/certbot
2025-11-03 10:12:02,624:DEBUG:certbot._internal.main:Arguments: ['-n', '--text', '--agree-tos', '--cert-name', 'ns11.cdbsystems.com_ecc', '--authenticator', 'webroot', '--server', 'https://acme-v02.api.letsencrypt.org/directory', '--elliptic-curve', 'secp256r1', '--email', '[email protected]', '--webroot-map', '{"ns11.cdbsystems.com":"\\/usr\\/local\\/ispconfig\\/interface\\/acme"}']
2025-11-03 10:12:02,624:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2025-11-03 10:12:02,629:DEBUG:certbot._internal.log:Root logging level set at 30
2025-11-03 10:12:02,630:DEBUG:certbot._internal.plugins.selection:Requested authenticator webroot and installer None
2025-11-03 10:12:02,630:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * webroot
Description: Place files in webroot directory
Interfaces: Authenticator, Plugin
Entry point: webroot = certbot._internal.plugins.webroot:Authenticator
Initialized: <certbot._internal.plugins.webroot.Authenticator object at 0x7fd8d5a46fd0>
Prep: True
2025-11-03 10:12:02,630:DEBUG:certbot._internal.plugins.selection:Selected authenticator <certbot._internal.plugins.webroot.Authenticator object at 0x7fd8d5a46fd0> and installer None
2025-11-03 10:12:02,630:INFO:certbot._internal.plugins.selection:Plugins selected: Authenticator webroot, Installer None
2025-11-03 10:12:02,704:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 33, in <module>
    sys.exit(load_entry_point('certbot==2.1.0', 'console_scripts', 'certbot')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 19, in main
    return internal_main.main(cli_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 1736, in main
    return config.func(config, plugins)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 1572, in certonly
    le_client = _init_le_client(config, auth, installer)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 827, in _init_le_client
    acc, acme = _determine_account(config)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/main.py", line 725, in _determine_account
    potential_acc = display_ops.choose_account(accounts)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/display/ops.py", line 86, in choose_account
    code, index = display_util.menu("Please choose an account", labels, force_interactive=True)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 80, in menu
    return obj.get_display().menu(message, choices, default=default, cli_flag=cli_flag,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/certbot/_internal/display/obj.py", line 470, in menu
    raise self._interaction_fail(message, cli_flag, "Choices: " + repr(choices))
certbot.errors.MissingCommandlineFlag: Missing command line flag or config entry for this setting:
Please choose an account

I seem to remember from a while back, that I have 2 accounts under /etc/letsencrypt/accounts and in fact I do:

drwx------ 4 root root 90 Nov 18 2023 .
drwxr-xr-x 9 root root 230 Nov 3 03:14 ..
drwx------ 3 root root 31 Mar 9 2018 acme-v01.api.letsencrypt.org
drwx------ 2 root root 31 Nov 9 2021 acme-v02.api.letsencrypt.org

oddly on ns10 I have the same 2 accounts but it seems to issue certs properly. now if I could remember what I did to 'fix' the situation on ns10....I thought one of the accounts had to be deleted??

moving the v01 account folder under /root - now ispconfig reports ns11.cdbsystems.com (vhost) DOES have a valid SSL (it did not before) but SSL is still not correct on the site. and the letsencrypt.log still complains about account v01 being missing...
weird. wish I could remember how on earth it got tangled like this.

is there any way to tell it 'blow away all SSLs from before and issue all new ones'?

also when I look under /etc/letsencrypt/renewals I see
ns11.cdbsystems.com_ecc.conf
I vaguely remember the _ecc was not a good thing?

 

On the contrary, it is one of the good latest thing from ISPConfig. The old one use RSA, so to differentiate, the new one add ecc at the end of it. Just leave it that way, that is the new default.

 

ok I have restored the v01 back to /etc/letsencrypt/accounts
now under each api, there is a big longnumber folder and meta.json. in one (v01) refers to ns9 (currently dead) the other (v02) refers to ns11.
so do I delete the biglongnumber folder starting with 647 under v01 then?
root@ns11:/etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org# cd directory
root@ns11:/etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory# ls -al
total 12
drwx------ 3 root root 4096 Dec 19 2021 .
drwx------ 3 root root 4096 Mar 9 2018 ..
drwx------ 2 root root 4096 Nov 3 10:31 6476580782071d4d31e788842978bc53
root@ns11:/etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory# ls 647*
meta.json private_key.json regr.json
root@ns11:/etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory#

the meta.json here refers to ns9...
{"creation_host": "ns9.cdbsystems.com", "creation_dt": "2018-03-09T14:07:50Z"}

so do i delete meta.json , the contents of the folder, or the folder itself to correct this?
and how does it work on ns10 i wonder? seems same situation

oh - some domains have expired/been deleted. is it sufficient to delete the domain in ispconfig? and do I need to do anything in the /etc/letsencrypt folders to delete a certificate thats causing problems?
I may need to do that anyway!

 

any thoughts? the v01 letsencrypt api /accounts/directory/meta.json refers to a server (ns9) that does not exist anymore.
can I move the files from the /directory? or is there some certbot command?

 

Let's Encrypt v01 has long been deprecated, so personally I would delete it and just kept v02. You can check the renewal conf files, whether there exist any traces of it. New certbot should have changed that automatically to v02 already, so that could be just the left overs, in the folder you mentioned above.

Also if I am not mistaken, I think current version of ISPConfig should be deleting all related files and certs for any web site(s) removed via ISPConfig panel, but I haven't tested this though.

In any event, if certbot worries you too much, may be you should migrate to acme.sh as it is also possible to do so. Yeah, I know it is not advisable, but it is doable. Last time I checked, if you remove all /etc/letsencrypt and uninstall certbot, ISPConfig force update will take care of installing acme.sh.

I haven't tested resync function whether the installed acme.sh can thereafter also create existing active web sites certs, but that is may be for you to venture, in a test vm, before testing on production ones. Otherwise, do it in old ways, of unticking and reticking the letsencrypt button in the ISPConfig panel.