Upgrading to v0.30 from v0.29

Dibbyo456 · January 9, 2019, 3:24pm

So, I’m trying to upgrading my MIAB setup from 0.29 to 0.30 along with Ubuntu 18.04 since v0.30 is compatible with 18.04.

My question is how should I proceed?

First I should upgrade my server to 18.04 from 14.04, then reinstall the MIAB?

JoshData · January 9, 2019, 3:35pm

Version 0.30 is NOT compatible with Ubuntu 18.04. That’s still coming.

Dibbyo456 · January 9, 2019, 3:48pm

Oh… I thought it is because of the description on Github.

https://s.put.re/PJ1gC7Wq.png

alento · January 9, 2019, 6:30pm

It appears that the changelog for both branches was updated … the information that you are seeing should only be for the ubuntu_bionic branch at this time. That branch is still in beta, soon to be released as the production branch for MiaB. You can find details elsewhere on the forum if you wish to use that beta, @Dibbyo456

@JoshData

sqeezy80 · January 9, 2019, 7:09pm

it looks like I am on the master branch but I can’t upgrade since I am supposed to be on 18.04. @JoshData is this right ?

root@box:~/mailinabox# git branch

master

root@box:~/mailinabox# mailinabox
Mail-in-a-Box only supports being installed on Ubuntu 18.04, sorry. You are running:

Ubuntu 14.04.5 LTS

We can’t write scripts that run on every possible setup, sorry.

JoshData · January 9, 2019, 8:04pm

The local branch name is generally always master.

If you’re on Ubuntu 14.04, you can upgrade to v0.30 (which I posted this morning). It’s a tag. You can also follow the usual upgrade steps (I think).

The master branch on github is now beyond v0.30.

mklilley · January 7, 2022, 12:27pm

Forgive me for taking soooo long to get around to upgrading my MIAB from v0.29 but here I am… finally.

I have been reading the instructions on upgrading and as I understand the first step is to go from v0.29 to v0.30 by running the usual upgrade script curl https://mailinabox.email/setup.sh | sudo bash. I have experienced two problems when doing this

Error on the curl command (which I managed to overcome by “bashing” the code locally)

curl: (60) SSL certificate problem: certificate has expired
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

I’m not sure where the certificate problem came from - I never had the issue before. I was a long time ago that I upgraded though.

Pip install errors

Installing Mail-in-a-Box system management daemon...

FAILED: pip2 install --upgrade boto
-----------------------------------------
Cannot fetch index base URL https://pypi.python.org/simple/
Could not find any downloads that satisfy the requirement boto in /usr/local/lib/python2.7/dist-packages
Downloading/unpacking boto
Cleaning up...
No distributions at all found for boto in /usr/local/lib/python2.7/dist-packages
Storing debug log for failure in /home/lilley/.pip/pip.log

The pip log shows

Getting page https://pypi.python.org/simple/boto/
Could not fetch URL https://pypi.python.org/simple/boto/: 403 Client Error: SNI is required

After doing some digging I found that it’s a problem with PyPy

github.com/pypa/pypi-support

Deprecation of non-SNI compatible clients.

opened 02:01PM - 24 Mar 21 UTC

closed 09:38AM - 11 May 21 UTC

ewdurbin

network

Our CDN provider is deprecating non-SNI support for access to pypi.org and files….pythonhosted.org. It appears that this rollout has begun and users without SNI support can expect disruptions. # Brownout windows | Dates | Window(s) | |---|---| | March 31st - April 7th | :00-:10 every hour | | April 7th - April 14th | :00-:15 every hour | | April 14th - April 21st | :00-:15 and :30-:40 every hour | | April 21st - April 28th | :00-:15 and :30-:45 every hour | | April 28th - May 3rd | :00-20 and :30-:50 every hour | | May 3rd onward | Support for non-SNI clients disabled in our VCL | | May 5th | Fastly will migrate our host, disabling non-SNI clients completely | Note transitions between phases will occur at 12:00:00 UTC. All but the last phase are fully automated. Until the migration is complete, impacted users can anticipate seeing this error when the brownout is in effect: <img width="1053" alt="Screen Shot 2021-03-31 at 10 56 38 AM" src="https://user-images.githubusercontent.com/1200832/113168489-b5143880-9212-11eb-80a2-3395d5c4e355.png"> That was generated using Python 2.6 and pip 9.0.3, the output to terminal may vary, but the error message is: ``` [[[!!! BREAKING CHANGE !!!]]] Support for clients that do not support Server Name Indication is temporarily disabled and will be permanently deprecated soon. See https://status.python.org/incidents/hzmjhqsdjqgb and https://github.com/pypa/pypi-support/issues/978 [[[!!! END BREAKING CHANGE !!!]]] ``` # Update (2021-03-31) In order to provide visibility for this deprecation and give people a chance to test their fixes we will be implementing rolling brownouts of non-SNI support beginning later today. The mechanism will follow similar pattern to our [TLS1.0/1.1 deprecation](https://github.com/pypa/warehouse/issues/3411). See above for status of these brownouts # Update (2021-03-26) After the initial rollout began, a number of users reached out to Fastly directly, which led to them temporarily rolling back the change. During the rollback a certificate issue was encountered that required re-verifying our domain. This lead to a number of similar but only *slightly* related issues, as well as quite a bit of confusion for everyone involved. We now have a new date for rollout of deprecation for non-SNI compatible clients. **Between May 3rd and May 6th 2021**, a more precise date will be available as the window nears. At some point during that week, non-SNI clients will stop being able to access pypi.org and files.pythonhosted.org. (end of Update 2021-03-26) This impacts approximately: - .37% of traffic for *.pythonhosted.org - .000016% of traffic for pythonhosted.org - .000005 of traffic for *pypi.org Due to the small portion of traffic that is impacted, the PyPI administrators and PSF Infrastructure will not be seeking a work around or alternative CDN. Primarily impacted are pip users running Python versions less than 2.7.9. # For users of Python 2.7.{0...8} Upgrading to the last Python 2.7 release is an option. However, note that Python 2.7 series itself is now End of Life and support in pip was dropped with version 21.0. # For users of Python 2.6.x and lower: Neither the Python core developers, or pip maintainers support Python 2.6 and below. If someone is aware of a work around for this issue (SNI support specifically) they are welcome to share it here for others. There is no recommended solution from the PyPI team.

The advice on Github is to upgrade system python, but I know that will likely cause all kinds of problems.

I am wondering whether you have any advice on how to proceed? I don’t use any of the NextCloud stuff. I only use theRoundCube webmail. Might it be possible to skip v0.30?

Thanks so much for your help - I appreciate that I have brought this on myself for dragging my feet on migrating the data onto a new droplet.

Matt

alento · January 8, 2022, 5:34am

You’re like 3 years too late.
If you did not update your Ubuntu 14.04 before the repositories were taken offline you are going to be in a world of hurt.

How many email users do you have on your system and how much data?
The fact that you are not using NextCloud may be a saving grace.

You may find it to be much simpler to create a new install somewhere else and rsync the data …

Let me know what you are working with and I’ll offer you some advice, or if you’d like to hire me to do the complete upgrade, I’ll be available.

mklilley · January 8, 2022, 8:28am

I know, I know . It’s one of those “if it aint broke don’t fix it” kind of things.

It’s not a lot of data, it’s all personal emails and only 1 email address that’s important (which itself isn’t super important). In terms of data, I guess a good metric is the backup folder which is about 270MB.

I appreciate you taking the time to reply to my message and any bits of advice you might be able to offer regarding extracting the email data. I am not looking to hire anyone as this was more of a fun project for me - an opportunity for me to learn. I’m not a stranger to rolling up my sleeves and getting my hands dirty, but it it’s really going to be a massive pain then I might just start fresh and deal with the data loss.

Thanks again.

Matt

JoshData · January 9, 2022, 6:51pm

If you’re not using Nextcloud, then you can probably safely skip intermediate versions and upgrade to the latest version of Mail-in-a-Box directly. It’s possible the Nextcloud upgrade step will fail - you may have to manually disable that part (e.g. add a # at the start of mailinabox/start.sh at main · mail-in-a-box/mailinabox · GitHub). But there shouldn’t be any other problem.

The safest path is to perform a backup, shut off (but not destroy) the old machine, create a new VM with Ubuntu 18.04, follow the upgrade instructions to restore the backup on the new VM, and then delete the old VM only after you’re satisfied the new one has all of the old data and is working OK.