Upgrading from V12 to V13

Install / Update Deployment
1

Good day all

trust you are all well and healthy

I am currently running V12.29 and have decided to upgrade to V13 simply because I would
like to use the “sequence ID” in BOM operations that V12 does not have.

I have a 4-server multi-tenant system ( sub domains ) so I would like to apprach this process
carefully.

The way I look at it, I have 2 options-

  1. Upgrade the existing system using a procedure I found, here -

But I have a few concerns -
a. My V12 system was built on Ubuntu 18.04 and from what I have been reading, it sounds
as if 20.04 is better for V13 ? IS this correct ?
b. from the procedure listed above, it seems as if my lets-encrypt-certificates will be wiped.
( I have certs for each individuel site). what will happen when I request a cert again for a
site that was previously enlisted with lets-encrypt ? Does the lets-encrypt server keep
track of the domain and hence refuse a cert unless the previous cert is re-voked ?

  1. My second option would be to first install a fresh V13 server and then restore the database
    from my V12 server onto the new server - Once again I have a few concerns -
    a. can a V12 database be restored onto a V13 server ?
    b. Basically the same as 1(b) above - I will have to re-install the certs using a domain that was
    previously loaded with a lets–encrypt-cert… Will my request be rejected by the lets-encrypt server?
    c. Are the settings ( company settings, buying settings etc) also kept in the database, and will hence be transfered?

Thank you for reading such a long post. I trust that someone could spare a moment to supply
me with some insight.

1 Like
2

Hi,

I haven’t dealt with lets encrypt , there is a renew-lets-encrypt and some ssl commands that might be useful. I would want to to understand them completely before proceeding, or have another plan for that issue.

Backup is of course your first and most important task, if a clone of the existing working instance can be made OS and all , do it. Storage is relatively cheap these days. Use the clone to try upgrading scenarios.

Using the methods in the link to upgrade in place , staying on Ubuntu is fine, thought getting to Ubuntu 20 makes it a bit easier in the sense that python 3.8 seems to be the default for Ubuntu 20, and from what I can tell 13 (and 14) like that better than python3.6.

A fresh Ubuntu 20 with the requisites all installed, getting a working bench , create a site with the same name, bench get-app --branch version-12 erpnext , then bench --site <site-name> install erpnext and restore the database backup. Then switch to version 13. Get that all working and make it your production environment.

I hope others will have advice with regards to lets encrypt.

My two cents , er frappeCoins.

3

Thank you very much @smino for your “frappeCoins” !! :slight_smile:

You bring some interesting points to the table. Yes, the backup is in place. This includes
both the data-base-file and csv exports of the tables.

But I like –

  1. “Playing” with a clone-copy of the existing system, until all is sorted.
  2. Shall I call it the “gradual” new install ?? 20.04 → V12 ->V13

One way for the lets-encryppt that I thought of is to first revoke the cert, which should
theoretically take the system back to http-access. And then ofcourse I can use those same
domains for let-encrypt on the new system.

Thank you for your time !

4

Hello,

See below from Lets Encrypt.

They have detailed the number of certificates you can create for a particular domain.

It is generous enough such that you can create a new certificate directly after an upgrade with no issue.

If you are unsure about how to configure it and worry about reaching your limit, you can always use letsencrypt’s staging environment by using the flag --dry-run in certbot. This will renew or create the certificate in a test environment which allows for up to 60 failed attempts instead of 5 for the normal one.

It is worth noting --dry-run means the certificate will not be saved. So after your first success just run certbot one more time without this flag to get it done.

Important note: you can only setup the certificate if your DNS is pointing to your new server. So it may be better to switch to http temporarily until you switch over.

The guide you linked mentions that the “path” to the certificate is deleted, not the certificates themselves.

Upgrading to V13

Regarding the upgrade, I recommend your second option: fresh install of V13. I recommend this guide:

If restoring the database using bench, use the --force flag.

bench --site [sitename] --force restore [path to database backup file]

You could use the following commands to setup any requirements after the installation.

bench setup requirements

…and migrate the old database to V13:

bench migrate

You are likely to face issues when you run bench migrate. Hence, I recommend doing one website at a time, as below, so that you can pinpoint where the issue is and resolve it.

bench --site {site} migrate
2 Likes
5

Thank you @jaycron for your suggestions ! Really appreciate the time you have taken.

Just some feedback—

I created my fresh V13 server.
copied database.sql.gz to new server using Winscp

unzipped the database file-
gunzip database.sql.gz → created database.sql

then the restore-
sudo bench --force --site <mydomain.com> restore /path/to/db-file/database.sql

then I migrated the dtabase -
sudo bench --site <mydomain.com> migrate

a few messages about apps/domains that has been moved. But other than that, no errors.

I have logged onto the front-end and I am now checking if everything is there and working
because I found this post about an encryption-key…

So as a precaution, I made a backup copy of the json file -
site_config.json

I have to say , that I did this only on a single domain system so there is no multi-tenancy or
SSL-certs. Just very basic security. Just to check my procedure. And my original servers are
still intact so I can check and verify a few things. After I have checked everything and I am
happy, I shall create a full multi-tenancy system and start transferring the sites one by
one.

And I know it is going to be expected of me to mark a post as “Solution” which in this case
both @smino and @jaycron have helped e a LOT.

Now to work on doing a few checks and then the time-consuming task of transfering all the
servers. I shall make a final comment once complete. Hopefully I do not get errors as I
move ahead, but in such a case I shall update this post so that others can benefit.

6

Sounds good, the new environment looks like this?

OS: Ubuntu 20.04.4 LTS
Python: 3.8.10
node: v14.19.0
yarn: v1.22.17
Mariadb: Ver 15.1 Distrib 10.3.34-MariaDB
Redis: 5.0.7
Nginx: 1.18.0
Pip3: pip 21.3.1
erpnext 13.24.0
frappe 13.24.0

7

Hi @smino

Your list is the same as mine with these exceptions-

node 14.19.1
mariadb 10.6.7
pip 20.0.2

So far all is well …except 62 of the same error in the error-log.

Error while connecting to email account Notifications

cryptography.exceptions.InvalidSignature: Signature did not match digest.
cryptography.fernet.InvalidToken
frappe.exceptions.ValidationError: Encryption key is invalid, Please check site_config.json

I did not paste the entire trace-back. This is in line with the link that I posted in my previous
post. I did delete the Notificatios Email as well as its corresponding domain and recreated
them again. Seem to have cleared the error because I am not getting any more errors.

I think I shall make another post about this. Let me not digress on the title of this thread.
Although there are no more errors, I need to make sure if someone else out there has not
had the same. I did make a backup of the site_config.json file. I do not see a key in there.
All I see is a db_name and db_password that is encrypted. In the new site_config.json
there is however an encryption key.

Thank you again @smino !

8

Glad to be able to help!

FYI, the new frappe bench does not require you extract the sql.gz file. It supports the compressed sql.gz file directly.

More info on restores here:

You do need to restore the site’s files as well which includes not just the site-config.json but any attachments you had in the previous site.

This can be done by simply manually copying the site folder to the new bench.

Also, with DNS multitenant disabled you may need to modify/add a currentsite.txt file to specify which site bench serves.

The db_username and password are in plain text, not encrypted.

1 Like