Login Reset Password |
Saying Goodbye to Open Vistas Networking
Today is the last day that I will have websites on the Open Vistas Networking server. As noted before, we were given 2 weeks (until October 15, 2023) to migrate all websites off the server.
It has been a hectic time. I found a new managed server web hosting service that will allow me unlimited websites, unlimited databases and unlimited storage. I have been able to replicate the website for our main business website on the new server. It was not without drama!
The support group informed me there was no way to restore my Postgresql 15.4 database into their Postgresql 9.6 server. Well after experimenting awhile, I found:
- They actually run a Postgresql 12.6 server. All of the information on the website said it was Postgresql 9.6; the support reps including "their team" said it was Postgresql 9.6; but the actual Postgresql server said it as 12.6
- I was able to restore my 15.4 backup into their 12.6 server
Of course, I had to create a "Plain" text backup and then modify the backup manually. But very simple changes were necessary:
- Change the server generated headers in the file that proclaim the level of the server to match the new hosting site server
- Remove the definition of a bunch of functions. That had to be done even with a backup from the server on the new hosting site. Apparently, those functions require superuser access
- Change the table ownsership from the owner name used on the Open Vistas server to the owner name on the new hosting service
- The Open Vistas server was setup for one Drupal code base serving multiple sites. The new server is a code base per each server. That change in structure changed the file directory structures. So, all links to files needed to be modified
- The Postgresql server included "Publication" directives. Those were removed. The restore actually worked just fine with them in the backup file but the backup process threw errors regarding those directives.
Once I had the db restored, I had to get the website actually running. There was one table that required a new column. I added that column andd everything came up.
Now I had a good database and the website running. BUT, I have a set of Python programs that run on my laptop and access the website database. So, how about remote access?
I use T-Mobile Home Internet for my ISP. In my part of rural Montana, T-Mobile 5G Home Internet is by far the best service. However, T-Mobile uses dynamic IP addresses and they change frequently. I had to have the database whitelist ALL ip addreses; same with the firewall, etc. The new hosting service support rep got the DB whitelisted.
I tried access. It have me a no "pg_hba.conf" entry. Back to support: well, when I asked about the credentials to access the DB, I was told to use the same credentials I used for ssh access. Not quite right. I had to define a user in the Postgresql server and assign that user to the database. That was the credientials I needed for remote access. Local access used the credentials I had for ssh access.
The problem with whitelisting the IP addresses is that it is done for each database. If I delete that database then create it again and restore into the database, the whitelisting is gone and needs to be done again. SIGH!!!
I have not migrated at this time. Much testing needs to be done; in the meantime the DB will be out of synch. Everytime I need to restore, I have to have the IP addresses whitelisted again. I tried just dropping all of the tables in the database. The tables dropped; the sequencing did not AND I could not delete any of the sequencing.
I originally asked about using a VPN. The support rep said no problem; would I prefer the VPN or to whitelist the IP addresses. I like the VPN because, of course, I don't have to go through the whole whitelisting all IP's. I said I didn't need it right then but would get it when I got to the point where I needed to test remote access. I contacted support and asked about it. This support rep said that I could not get a VPN setup on a shared hosting server.
Do I accept that answer? The support rep and "his team" gave me bad information about the Postgresql server; that same support rep gave me bad advice about the credentials to use for remote access. This support rep seemed more knowledgable; but.....
Now I have more chores to do -- and I'm sure calls to the support reps.
- How do I create the additional websites?
- How do I get SSL certificates for the additional websites?
- One of the websites is on BackdropCMS using MySQL rather than Postgresql. The new hosting site seems much more oriented to MySQL than Postgresql; so, maybe it will go better than the Postgresql migration.
I will let you know!