REALLY old system upgrade help needed 14.04/v0.27 to 22.04/current

piks · July 17, 2024, 8:23am

Greetings all!

I’ve got a VERY old miab setup - v 0.27 on Ubuntu 14.04 and it’s been a ‘production’ machine since setup in 2014. A testament to this great software!

The background:
I took over admin of the system not too long ago after being called in to fix a problem here and there over the last few years, but not touching the heart of the system, or questioning it.

One of those fixes was several years ago. Let’s encrypt seemed to change where it put certs and the system stopped using any new certs, so after digging into things, with a philosophy of touching the least necessary to fix, I was able to point the relevant nginx conf file to where the certs where showing up and all was well. The system undergoes no architectural changes (and none since 2014), but it seems the conf file gets rewritten occassionally with the original locations, so I made the conf file immutable and all is fine.

Because it’s so old, and on small hardware, I need to migrate this to another machine with NO hiccup in service. I’ve looked around and while there are upgrade instructions from Ubuntu 18 and pre-5x systems, I don’t know if v 0.27 is included or is too old… Not to mention moving from Ubuntu 14.04.

My plan/thinking is to either:

set up a shiny new system and somehow move the mailboxes and settings over from the old
or
rsync the whole system (/home/user-dir) to the new machine and try an inplace upgrade with setup.sh, then point DNS to the new machine’s IP and go.

Thoughts at this point?

I really need help understanding hidden gotchas and limitations of each approach, or better ways. I can see that copying the old system brings my hacks with it. Would they get replaced in an upgrade? If I try to just copy data, what should move over and are there file definition changes since v 0.27 that preclude that?

I’m open to other ideas, but would really like users to have their old mail available afterward, and no downtime and somehow testable before flipping the switch for good.

I’m sure I will have more questions from the replies, so please bear with me.

Thanks in advance.

piks · July 17, 2024, 10:15am

BTW, forgot to mention I have rsync capability directly between machines and can copy /home/user-data and the mailinabox directories as-is to the new machine. I looked at the python backup.py code, and while I’m not too literate with python, it looks like that’s all. Is that right?

I also looked at setup.py and it does address 14.04 but will only update to v30 and makes no mention beyond that. It does talk about bringing 5x system on 18.04 up to current though. No mention of 14.04 systems to 18.04 and then 22.04… This could be interpreted as not possible for v30 and earlier systems.

I also can’t tell how it will handle seeing a full user-data dir but no installed programs (dovecot, etc) and will ‘fill in the blanks’ as they say and install all missing packages and convert any data files as needed and update config files. There is also the issue of correcting any odd configuration changes like the Let’s Encrypt references that exist in the old system and would be copied to the new at first (immutable bit on the conf file would be turned back off of course).

Thanks.

JoshData · July 17, 2024, 12:59pm

The thing that makes upgrading hard is ownCloud/Nextcloud. Are your users using ownCloud? If so, upgrades will be difficult because ownCloud/Nextcloud only reportedly supports upgrades between consecutive major versions, and each version supports a different range of PHP versions, so you will probably need multiple versions of PHP and a large number of upgrade steps. We’ve restricted permissible Mail-in-a-Box upgrade paths to ensure that it all works out. It’s also possible that upgrading straight to the latest version will work, but we’ve never tied it.

If your users aren’t using ownCloud, you can ignore all that and just rsync /home/user-data to the new machine and install Mail-in-a-Box and probably it will all work fine. (Other than precautions to avoid downtime and losing mail.)

KiekerJan · July 17, 2024, 4:12pm

There’s a user here that got various advice, but they never reported what worked for them.
My thinking is that the easiest way is:

Read Mail-in-a-Box Maintenance Guide
Update to v0.30
Save your user-data folder
Install the new machine with Ubuntu 22.04 and the latest Mail in a Box
Restore the user-data folder, as per the maintenance guide.
See if it works.

But that might not work, as JoshData indicates you will skip a number of upgrade steps. If it doesn’t work, you might have to upgrade with an intermediate step via Ubuntu 18.04. So:

Read Mail-in-a-Box Maintenance Guide
Update to v0.30
Save your user-data folder
Install the new machine with Ubuntu 18.04 and the latest Mail in a Box
Restore the user-data folder, as per the maintenance guide.
Save your user-data folder
Install the new machine with Ubuntu 22.04 and the latest Mail in a Box
Restore the user-data folder, as per the maintenance guide.
See if it works.

You might want to do a dry run of this first, before you stop using the old server.

Make sense?

piks · July 18, 2024, 8:51am

Nextcloud isn’t used. Only the mail part, and webmail and imap for users.

Let me ask if rsyncing user-data and the mailinabox (admin) folder do the same as a backup=>copy backup=>restore on machine #2. Would that be as complete?

Also, will running setup on the new machine after copy leave any configurations, users, email, etc as-is?

Is there any advantage to updating the OS to 16.04 (or whatever Ubuntu’s next LTS upgrade wants to be), then running MIAB setup again? Where will that take me (up to somewhere between 30 and 40?)? Is MIAB aware of what OS level it’s compatable with and stop from going beyond? Then I go to 18.04 and run setup again, then 20.04, run setup, then 22.04, and then again setup. Is this safer? I don’t mind more time up front to save debug time later or the rest of my life…

Is backup/restore more tolerant of version jumps if restoring to a newer system? Or will old configs and file formats overwrite the newly installed one if I install it new and restore the old user-data?

And I run a few Nextcloud servers elsewhere, so I understand about php and such. Without Nextcloud, I assume php is not used? Are there any other system or repository-sourced packages that might have version level incompatibilities, going across these levels?

BTW, I used to manage mail systems with sendmail and some UUCP 30+ years ago, so really depending on MIAB. It probably goes downhill fast if I start touching any software directly…

Thanks.

JoshData · July 18, 2024, 9:58am

Ok great, then you probably won’t run into any issues.

It’s basically the same. The backup/restore doesn’t preserve the /root/mailinabox folder or any backup data in the original user-data folder (they’re not necessary), but otherwise it’s the same process.

It will re-configure the system outside of the user-data folder, but inside the user-data folder it won’t clobber any files. It will do some data migrations like on the main users database.

Without ownCloud, I don’t think so.

Yes.

Webmail (Roundcube) also uses PHP.

If you’re restoring Mail-in-a-Box to a fresh machine with the latest version of Mail-in-a-Box, then it will pull the right packages, etc.

Hope that helps.

KiekerJan · July 18, 2024, 10:05am

That’s actually more complete, as the MiaB backup only does the user-data folder. I think the mailinabox (admin) folder you mention is “just” the github clone used to run MiaB. That will be changed by installing a new version, and you do not need to copy it.
In summary, what you need is the user-data folder. It’s not needed to use the backup proces, you can indeed use rsync, or anything else to transfer the user-data folder.

Well, any is a bit big. But the MiaB configuration, users, email etc will be kept, as it is stored under user-data. Note that modifications you might have made to the /etc for e.g. nginx or postfix will probably be overridden.

Mail-in-a-Box does not support 16.04 and 20.04, so you should go directly from 14.04 to 18.04. But is recommended to do a clean install of the box, then do the Mail-in-a-Box installation.
Theoretically, the most clean upgrade path is:

Upgrade MiaB to latest version (for ubuntu 14.04 that is 0.30 I think)
Install a clean Ubuntu 18.04 box, install Mail-in-a-Box and recover user-data. That will take you to MiaB 57 I think.
Install a clean Ubuntu 22.04 box, install Mail-in-a-Box and recover user-data (from the box containing Miab 57). That will take you to the latest MiaB.

I say this is most clean as it will run all the upgrade steps that are defined in the MiaB code. Since you’re not using nextcloud, you might be able to skip step 2.
MiaB is indeed aware of the OS version, and will not install on 16.04 (or 20.04), and not upgrade to the latest version on older Ubuntu installations than 22.04

The installation/upgrade code will look at your existing configuration and files and use those. So after restore of your user-data, run the miab installation again, and the user-data folder will be “upgraded” where necessary.

Roundcube (the webmail) also uses php, but only Nextcloud is very particular about the version it needs. There’s lots of headaches in the upgrade code there …

Again, please try the whole upgrade process beforehand on a new box, before removing the old box from production…

piks · July 19, 2024, 7:50am

First, THANKS for all the help. For the record, I rsync’d the old user-data on the 14.04 system to the new box running 22.04. I then used the curl one-liner to start the install. Amazingly it seemed to go well with no complaints!

However, nginx didn’t come up. On a whim, and reading where running mailinabox again provides some magic, I ran it and afterward nginx came up. Webmail has the user accounts and all the daemons seem to be running. At this point, the mx record still points to the old box until it’s perfect.

There are a few questions and bits of advice still needed.

First, (and not knowing if the original sysadmin changed this) but there are multiple named processes running. The old system didn’t run it and all of these use an external nameserver. I tried stopping it but the internal lookups fail, so rather than mess around with the local resolver config, I restarted it. What does MiaB do to name resolution in order to redirect to local? If its as easy as a simple source config change, I may disable named and just point to the external nameserver. Good idea or bad re MiaB?

Systems status is mostly green, and mostly expalainable, but for these:

It complains of DNSSEC DS record is not set, but so does the old system. Any pointers or advice on that? I understand it’s optional, but if I can correct that…

It complains IP6 is not set in DNS. I haven’t done anything with IP6 addressing. Is that a problem with MiaB?

It complains about no reverse IP6 DNS. IP4 is set. Any problem? Should these just be a warning as long as one 4/6 address is set?

Several complaints about the domain’s MX record, www, autoconfig, autodiscover - things I know will go away after I switch things in the DNS record. The old system didn’t use autoconfig/autodiscover. Are autodiscover/autoconfig just pointers in dns to the machine and that’s fixed? Is there any config box config needed?

Next to last, the big headache from the old machine in a way: it reports a self-signed certificate only. I cleared the ssl folder (moved off) and ran MiaB again. It generated a new self-signed cert. Then ran

sudo certbot register --register-unsafely-without-email --agree-tos --config-dir /home/user-data/ssl/lets_encrypt

and its log looks great - a key seems to be returned no errors.
BUT, no cert is in use, even after restarting nginx a few times.
If run
certbot renew or with --dry-run, I get
=> No renewals were attempted.

At this point, there are 2 machines in use. a-domain-com is the old mailserver. It answers to a-domain-com (not allowed to use ‘dots’ here yet…) and domain-com as well as www, etc…
b-domain-com is the new one. DNS works and a lookup of b-domain-com returns its IP4. Looking at setup instructions for TLS, the guide ends a short paragraph with:
Just follow the instructions given in the control panel.

I go there (b-domain-com/admin right?) to the TLS page and it says
Self-signed. Get a signed certificate to stop warnings. The domain name does not resolve to this machine: [Not Set] (AAAA).
with the only option of installing from somewhere else manually. I look at the old system and an additional section heads the page with a PROVISION button listing each machine and domain it will get certs for. There is no provision button on the new machine.

I’m not finding any real diagnostic help anywhere other than a few tangential issues, so I’m lost here. Help needed! I’m also not clear on what MiaB sets up re certbot and letsencrypt. I can see there’s a letsencrypt folder, but no .pem files or anything in ssl except for the self-signed one. Am I doing things out of order? I must be missing something (cognitively too…).

And lastly, the old machine is still operating, so still collecting mail. Assuming I should not rsync over the new home/user-data/ssl folder now, can the old user-data folder come over to update the new before a switch? Would I run setup.sh or maininabox afterward and be fine?

I think that after getting the Letsencrypt stuff fixed and DNS switched over (and IP6 items are really just warnings), all should work. Thoughts?

Thanks again. I am so surprised it has been this smooth. I’ve had worse Nextcloud upgrades just going one release forward! This is really well done. Thanks.

piks · July 20, 2024, 10:19am

Maybe my last post was too long…

I think the remaining issue is getting LetsEncrypt and Certbot to work. I’m finding very little info on how they integrate into MiaB. Pointers to detailed info would be appreciated. I haven’t been able to find anything that covers process, file locations and config possibilities and how it all interoperates with nginx. Some of what I need is MiaB, some LE, some Certbot. It seems like the expectation is ‘it just all works together’, but I’m not seeing any errors or success. Is there any diagnostic or detailed architecture info for when it doesn’t?

Nothing is complaining, I get an LE folder in the ssl folder, but it looks like it only has account info. Since the certs are where the old system went bad at some point, I would like to make sure it’s done right here.

I would assume I can get a cert for the new box, even if it is only a single machine in the domain among many, and that all the different certs for aliases would set up after the DNS record points everything to it. But, I can’t get anything going for just one little 'ol machine…

Any ideas? References? Ideas?

Thanks again. Here is the Letsencrypt log (sanitized and “.” replaced with “,” otherwise I’m not allowed to post this…):

2024-07-18 08:32:02,143:DEBUG:certbot,_internal,main:certbot version: 1,21,0
2024-07-18 08:32:02,143:DEBUG:certbot,_internal,main:Location of certbot entry point: /usr/bin/certbot
2024-07-18 08:32:02,143:DEBUG:certbot,_internal,main:Arguments: [‘–register-unsafely-without-email’, ‘–agree-tos’, ‘–config-dir’, ‘/home/user-data/ssl/lets_encrypt’]
2024-07-18 08:32:02,143:DEBUG:certbot,_internal,main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2024-07-18 08:32:02,153:DEBUG:certbot,_internal,log:Root logging level set at 30
2024-07-18 08:32:02,154:DEBUG:certbot,_internal,client:Registering without email!
2024-07-18 08:32:02,429:DEBUG:acme,client:Sending GET request to https: acme-v02,api,letsencrypt,org/directory,
2024-07-18 08:32:02,431:DEBUG:urllib3,connectionpool:Starting new HTTPS connection (1): acme-v02,api,letsencrypt,org:443
2024-07-18 08:32:03,072:DEBUG:urllib3,connectionpool:https: acme-v02,api,letsencrypt,org:443 “GET /directory HTTP/1,1” 200 746
2024-07-18 08:32:03,073:DEBUG:acme,client:Received response:
HTTP 200
Server: nginx
Date: Thu, 18 Jul 2024 12:32:03 GMT
Content-Type: application/json
Content-Length: 746
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
“Dci-FZTjH3g”: “https: community,letsencrypt,org/t/adding-random-entries-to-the-directory/33417”,
“keyChange”: “https: acme-v02,api,letsencrypt,org/acme/key-change”,
“meta”: {
“caaIdentities”: [
“letsencrypt,org”
],
“termsOfService”: “https: letsencrypt,org/documents/LE-SA-v1,4-April-3-2024,pdf”,
“website”: “https: letsencrypt,org”
},
“newAccount”: “https: acme-v02,api,letsencrypt,org/acme/new-acct”,
“newNonce”: “https: acme-v02,api,letsencrypt,org/acme/new-nonce”,
“newOrder”: “https: acme-v02,api,letsencrypt,org/acme/new-order”,
“renewalInfo”: “https: acme-v02,api,letsencrypt,org/draft-ietf-acme-ari-03/renewalInfo”,
“revokeCert”: “https: acme-v02,api,letsencrypt,org/acme/revoke-cert”
}
2024-07-18 08:32:03,073:DEBUG:acme,client:Requesting fresh nonce
2024-07-18 08:32:03,073:DEBUG:acme,client:Sending HEAD request to https: acme-v02,api,letsencrypt,org/acme/new-nonce,
2024-07-18 08:32:03,123:DEBUG:urllib3,connectionpool:https: acme-v02,api,letsencrypt,org:443 “HEAD /acme/new-nonce HTTP/1,1” 200 0
2024-07-18 08:32:03,124:DEBUG:acme,client:Received response:
HTTP 200
Server: nginx
Date: Thu, 18 Jul 2024 12:32:03 GMT
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: <https: acme-v02,api,letsencrypt,org/directory>;rel=“index”
Replay-Nonce: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

2024-07-18 08:32:03,124:DEBUG:acme,client:Storing nonce: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2024-07-18 08:32:03,124:DEBUG:acme,client:JWS payload:
b’{\n “termsOfServiceAgreed”: true,\n “contact”: \n}’
2024-07-18 08:32:03,127:DEBUG:acme,client:Sending POST request to https: acme-v02,api,letsencrypt,org/acme/new-acct:
{
“protected”: “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”,
“signature”: “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”,
“payload”: “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”
}
2024-07-18 08:32:03,243:DEBUG:urllib3,connectionpool:https: acme-v02,api,letsencrypt,org:443 “POST /acme/new-acct HTTP/1,1” 201 516
2024-07-18 08:32:03,244:DEBUG:acme,client:Received response:
HTTP 201
Server: nginx
Date: Thu, 18 Jul 2024 12:32:03 GMT
Content-Type: application/json
Content-Length: 516
Connection: keep-alive
Boulder-Requester: 1843953487
Cache-Control: public, max-age=0, no-cache
Link: <https: acme-v02,api,letsencrypt,org/directory>;rel=“index”, <https: letsencrypt,org/documents/LE-SA-v1,4-April-3-2024,pdf>;rel=“terms-of-service”
Location: https: acme-v02,api,letsencrypt,org/acme/acct/1843953487
Replay-Nonce: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
“key”: {
“kty”: “RSA”,
“n”: “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”,
“e”: “AQAB”
},
“initialIp”: " xxxx:xxxx:0:a09::ce2b",
“createdAt”: “2024-07-18T12:32:03,218093624Z”,
“status”: “valid”
}
2024-07-18 08:32:03,245:DEBUG:acme,client:Storing nonce: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2024-07-18 08:32:03,247:DEBUG:certbot,_internal,display,obj:Notifying user: Account registered,
2024-07-18 08:40:19,028:DEBUG:certbot,_internal,main:certbot version: 1,21,0
2024-07-18 08:40:19,029:DEBUG:certbot,_internal,main:Location of certbot entry point: /usr/bin/certbot
2024-07-18 08:40:19,029:DEBUG:certbot,_internal,main:Arguments: [‘–register-unsafely-without-email’, ‘–agree-tos’, ‘–config-dir’, ‘/home/user-data/ssl/lets_encrypt’]
2024-07-18 08:40:19,029:DEBUG:certbot,_internal,main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2024-07-18 08:40:19,039:DEBUG:certbot,_internal,log:Root logging level set at 30

and when trying to renew:

DEBUG:certbot,_internal,main:certbot version: 1,21,0
DEBUG:certbot,_internal,main:Location of certbot entry point: /usr/bin/certbot
DEBUG:certbot,_internal,main:Arguments:
DEBUG:certbot,_internal,main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
DEBUG:certbot,_internal,log:Root logging level set at 30
DEBUG:certbot,_internal,display,obj:Notifying user:

DEBUG:certbot,_internal,display,obj:Notifying user: No renewals were attempted,
DEBUG:certbot,_internal,display,obj:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DEBUG:certbot,_internal,renewal:no renewal failures

KiekerJan · July 20, 2024, 1:28pm

There’s nothing you need to do for let’s encrypt to work. However, I think it depends on DNS working properly, and since you didn’t yet move the domain from the old box to the new box (I think) it doesn’t work yet. (the missing Provision button)
There’s a system menu “TLS (SSL) Certificates” where you can manually request to update domain certificates.

KiekerJan · July 20, 2024, 1:31pm

Named (or bind9) is used as local DNS resolver. You will need this as it is used for e.g. blacklist lookups. Usually blocklist providers block the public DNS servers because there are too many lookups. When you have it locally, that is no problem.

This will probably all go away once you moved over the domain. Reverse DNS you can set at your VPS provider.

piks · July 21, 2024, 1:25pm

Thanks for the reply. I figured the DNS would work itself out, but the DNSSEC part doesn’t work on the old box either, and it’s been operating for 10+ years.
Any advice on getting that to work?

The old box does have the provision button, the new one doesn’t, but it’s text talks about incorporating your own manual certs and I don’t want to even start doing manual for that. That’s one of the big problems with the old one - it takes manual intervention. My goal is getting it to be 100% automatic.

I haven’t asked yet, but just remembered postfix wants wants TLS certs and IMAP will need some. Where/when do they happen? Is that taken care of in the mailinthebox command?

It’s probably reading for testing the switchover. Can you guys give me your thoughts on the plan below? Remember, it’s a production machine. I can get the users to stay off. Here is the plan - any missing pieces or wrong steps you can see? It’s current state is having rsync’d the old box days ago, so new mail is present on the old box.

Stop postfix on old box to stop inbound mail.
Stop postfix on the new box (will be updating the mailboxes).
rsync only user-data again, without the ssl folder (new keys are on the new box) to update mail that has come in over the last few days.
switch the domain and mx records, wait for propagation.
run mailinthebox (will this bring postfix up to date on mail folders?)
restart postfix on new box if the control panel shows passed. If not, undo the nameserver record changes and restart the old box. I would like to make sure the new box is 100% before openning it up to mail coming in from the net and mail landing on the new machine while having to go back to the old one…

** at this point, according to your post, all the failed points on the control panel should be fixed, right?

would I run certbot again? or do anything regarding getting certs?

Am I missing any prudent steps? Any other daemons that should be stopped?

Now, very important question: the old box hosts 2 domains, with mail. and www. machines for each, all pointing to the single mail. machine… In setting up the new one, setup seemed to take the FQDN of the new machine to get all it needed, but nowhere did I get a chance to enter a second domain. The control panel seems to know about it ( there is output for it in the analysis). Did it get this from what was embedded in user-data brought over from the old machine? I didn’t edit any nginx configs in /etc. Is there anything left to do for this?

** also, will there be enough info already here for certs to get installed for all the different machine names across both domains?
When does this happen in this procedure?

[
In the old days there was no webmail, few used ssl, and the mx record was all I had to worry about
]

Thanks again in advance.

PS, I’ve tried to be complete enough so the topic can be a little bit of a reference on steps to move to a new machine…

piks · July 21, 2024, 8:00pm

While I would still appreciate a scan of my checklist/process above, and the questions it brings up, I thought of a few other things…

The one box will host 2 domains, Y and Z, and there are multiple machine names www, autodiscover, mail, webmail, etc… on each domain. The DNS records are set up and working.

So,

Do I have to run certbot at all? or for each domain? (-d Y -d Z) or for each machine on each domain? in order to get autorenewals all set up?
I don’t see anything (daemons, crontab, etc) on the new machine yet for it.
Looking into certbot, it seems I have to run it with --nginx and -d for each domain (or is it each machine?).
However it’s been said above that it’s all taken care of (unless I misunderstood).

Any recommended certbot setup commandline if it’s needed?
I used the provision button (it appeared) and I see nginx is set up in local.conf for every machine and both domains. How does renewal happen?

I’m also a bit confused about why/when to run
management/ssl_certificates.py
since it seems all set up without my running that. Is it the renewal code? What calls it at 90 days if so? And can it be re-run any time or will that mess things up?

In this configuration of 2 domains on one box (Y and Z), with MiaB, is it best to set the MX record for each domain to “mail. Y. com” for Y and “mail. Z. com” for Z, or set both MX records to the same value (both to “mail. Z. com” for instance)?
IIRC, users would have problems with having the same MX address for both domains and the one that didn’t match had the problems.
I see that postfix and dovecot use the pem file for “mail. Y. com” so “mail. Y. com” may have to be the MX machine for both domains, right?

And how important is it for “mta-sts. mail. Y. com” to have a DNS record? I’m not sure I can set up records that deep at my provider, and do I need a “mta-sts. Y. com” ? These show up like the ‘auto’ ones but I haven’t defined them anywhere, including DNS.

Thanks again in advance.
Sorry for being dense if this is something obvious…

piks · July 22, 2024, 10:38am

Still hoping to get some validation on the final steps and MX record options above, but in the mean time I’ve been going over the process so I can document it for me and perhaps others. I did some things that might not be necessary, so maybe someone could verify.

As I mentioned, I ran certbot when nothing seemed to be populated in the ssl folder:

Later, after finishing the finer points of the DNS record, the Provision button on the control panel showed up, and it seemed to do the job.

Was the certbot command ever needed? Did it / will it cause problems now or later? I found the certbot cron entry in cron.d. Did MiaB set it or my certbot command?

The essential moving process seemed to be:

* perfect the DNS record
* rsync old user-data to new box
* run MiaB setup
* hit the provision button in the control panel

(does certbot need to be in here somewhere?)

Does MiaB handle certbot and EVERYTHING else needed?

If I wanted to force new certs, would I rm the ssl folder contents, run setup, then hit Provision and that’s it?
Individual daemons have their configs in /etc, but that isn’t ever mentioned. Is it shadowed anywhere in user-data? Is there ANY downside to rm -r user-data and then rsync it back over from the old box, run setup, then Provision TLS? Are there any residual things from the current install that would cause problems when doing this?
There are various individual tools in MiaB like ssl_certificates.py that are suggested in various older posts. Are they still needed to be run manually?
Are the configs for the various daemons, incl nginx, kept as source outside of /etc or just copied to ./mailinabox/ or ./user-data and propagated to /etc during setup?
Something a little different: if I don’t move the old owncloud folders over, will setup give me a new up-to-date nextcloud instance when setup is run? (if it does, that’s good for me)
Is there a document that has a ‘what it is’ and ‘when to use it’ for the tools and such in the mailinabox folder? Is there any architecture or process diagram or text that describes what goes on (and maybe dependencies like a perfect DNS record) during install or update?

If that exists, please point me to it. If there isn’t, I would be willing to start/write such a thing if this topic can answer the questions I have and maybe that would help with all the questions I’ve poured through on here for answers.

Thanks again.

malik7861122 · July 22, 2024, 12:09pm

Hi there,

Upgrading a really old system from Ubuntu 14.04 to 22.04 involves a few intermediate steps since you can’t directly jump from 14.04 to 22.04. Here’s a step-by-step guide to help you with the process:

Backup Your Data:

Before starting, ensure you back up all important data to avoid any potential data loss.

Update Current System:

Update your current system to the latest packages for Ubuntu 14.04.

bash

Copy code

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

Upgrade to 16.04:

Start by upgrading from 14.04 to 16.04.

bash

Copy code

sudo do-release-upgrade

Follow the on-screen instructions to complete the upgrade process.

Upgrade to 18.04:

Once on 16.04, update your system again.

bash

Copy code

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

Then, upgrade from 16.04 to 18.04.

bash

Copy code

sudo do-release-upgrade

Upgrade to 20.04:

Repeat the process to update and upgrade from 18.04 to 20.04.

bash

Copy code

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo do-release-upgrade

Upgrade to 22.04:

Finally, upgrade from 20.04 to 22.04.

bash

Copy code

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo do-release-upgrade

Post-Upgrade:

After upgrading to 22.04, check for any additional updates and install them.

bash

Copy code

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

This step-by-step process should help you successfully upgrade your system to the current version. Good luck!

stylnchris · July 22, 2024, 12:10pm

This is not the recommended way to upgrade mail the box and will probably end up breaking things.

tyler · July 22, 2024, 1:21pm

@malik7861122

That is not a good solution. It is infinitely easier to provision a new server and start fresh.

KiekerJan · July 22, 2024, 5:24pm

I would now first run the mailinabox setup, and check the new box that it works.

Last step can be skipped. Also, postfix will be started by the mailinabox setup, so doesn’t need a restart.

Looks good. You don’t need to run certbot yourself. It’s all taken care of by Mailinabox.

Yeah, it’s all in the user-data

KiekerJan · July 22, 2024, 5:31pm

It’s all taken care of.
There’s a cron job /etc/cron.d/mailinabox-nightly, that calls /home/username/mailinabox/management/daily_tasks.sh. This in turn runs ssl_certificates.py which does the renewal when necessary.

You need to check how the DNS records are being managed. It can be done in 2 ways:

Box acts as DNS server.
You don’t need to do anything.
You import all DNS entries into a DNS provider (also called External DNS)
You need to look at the External DNS page of the Admin portal to look what DNS records to configure.

Several ways to check. You can check this on the status page, it will mention something like “don’t worry about this error if your using external DNS”, then it’s probably external DNS.
You can also check at your domain name provider, and look what the settings are for the nameservers of the domain your hosting. If it’s set to something like ns1.box.domainname.tld then the mailinabox is taking care of it.

KiekerJan · July 22, 2024, 5:37pm

Yes

That would probably work, but there might be a nicer way, which I can’t think of right now.

/etc/ is configured on running of mailinabox setup. So if you do it like you mention, it should be fine.

Not in normal operation. Only when something goes wrong (it happens )

Some are modified on setup, e.g. postfix. The nginx configuration is re-generated every night. So, the answer is: it depends.

I think yes.

Architecture picture can be found here. Basically the code is the documentation for the rest