I am running NS7 and NS8 on a VPS at Contabo datacenter
Both servers have a dedicated IP4 address.
After full migration it is my intention to shut down the NS7 instance
I’d like some pointers on how to proceed migrating applications that are using Samba/AD accountprovider.
Those are:
mailserver + SOGo (with special attention to DKIM and SPF record changes)
Nextcloud + Collabora
And the Local Samba/AD accountprovider itself.
And just for my own state of mind, when and how to update DNS records
Furthermore, there are many other applications running on NS7 that don’t have an NS8 app (yet) Some of those are not really of a lot of importance, but a few are.
List of non-app services:
Matrix-Synapse (with WA bridge) (important)
Diaspora* (important)
Fail2Ban (to be replaced by Crowdsec)
Moodle
Xerte online Toolkits
Funkwhale
Also: Dokuwiki and Wordprerss are installed but do not show up as ‘migratable’
Finally, On my NS7 host I use WEBDAV-Restic for backup to a WEBDAV storage provider. Is this currently possible with NS8? If so, how? If not, what advice do you have to implement backup?
I can provide a few pointers, but not all you may need… I’m not running quite the same “non-app services”, to use your definition, and I don’t use VPS.
As such there’s not much options in migration as to the sequence, you more or less have to do one by one, and the last is AD including FileServer.
Nextcloud, Mail and FileServer/AD are often (not always!) straight-forward. AFAIK, SoGo has to be migrated manually, but no real idea, as I have never used SoGo. If theres a migration option, do try it.
Collabora install manually (available in NS8) after migration.
DNS:
Keep the internal DNS on NS7 running for as long as NS7 is running. NS7 can “live” without external DNS pointing to it.
Prepare your NS8 accordingly with DNS. As soon as migration is done switch all external DNS services, one by one over to NS8. Internally, you can move DNS to NS8 as soon as the service is running.
DokuWiki
DokuWiki does not use a database. Basically, one could rsync several DokuWikis to have an offsite backup / running standby server.
So: move the folder contents over, after making a good note of existing permissions in the NS8 Dokuwiki! You can use whatever you are comfortable with, I would strongly suggest rsync or scp (PuTTY / WinSCP).
Once done, set permissions accordingly. Dokuwiki should work!
(This tip worked for user @capote AFAIK…)
Wordpress:
Each wordpress site needs to be handled manually. Export the database, and the folder structure, files and folders as tar or zip…
There are export tools for WP, I haven’t tried them myself, so YMMV…
Non-app services:
Probably @oneitonitram or @mrmarkuz could help with these.
I’ld just fire up a LXC Container or a VM in Proxmox, but that’s not an option on a VPS…
→ These apps can continue to run on NS7 until you have a viable solution. Just keep the DNS for these pointing there. They won’t get updates anymore, but still have access (NS7 is member server) to AD with users and groups in the meantime.
FailtoBan is replaced with CroudSec, but some GUI options are still lacking. It works…
SSL
Each “App” allows it’s own SSL settings, these seem to work OK in my cases…
Important: A lot of Apps in NS7 accepted a /appname access, like Nextcloud or Dokuwiki. Now each one should use their own dns name (eg dokuwiki.domain.tld).
One additional Question:
NS7 uses the internal DNS-„Server“
Additionally, I use an external DNS server.
How should I deal with the DNS module of NS8?
Can I use only my external DNS server? Is it necessary, to use the DNS module if NS8?
Or are there any outstanding benefits for additional using the DNS module?
Best regards, Marko
Thank you Andy,
I have got my internal server on the proxmox cluster running in exactly the same way using OPNSense. I only use my pihole in my LXC-Contaienr as a web filter, not for DNS/DHCP. That’s handled by the OPNSense.
However, in this thread I was actually referring to my installations for my vServers at my hosting provider.
I may be digressing slightly from the topic, but I would like to add this for the sake of explanation:
In addition to the basic installation with fail2ban, I currently have the following productive services running for each domain:
AD
mail
nextcloud
collabora
at least one web server with a Wordpress installation
one instance even has several web servers with different domains and their own users (you know the trick)
I am still in the process of preparing the migration by setting up the servers again and doing a manual migration.
The question of whether I need to use an AD again and use the DNS module has not yet been answered for me.
Now I have understood that I need the AD again and can do without the additional DNS module.
Best regards, MArko
Hello @capote whoosh, youve got quite a number of non app services
We will begin working on MAtrix with @mrmarkuz once Moodle has been released.
Atleast you will be getting Moodle Soon.
I can Look into working on Xerte, because it aligns with what we do however i feel someone else can work on Diaspora as well as Funkwhale
I have a basic question about migration.
I run a VPS with NS7. Samba4/AD accountprovider
On a new VPS i installed NS8.
In order to migratie applications from NS7 to NS8 I installed the migration package on NS8
Several applications use Samba4/AD accountprovider.
Some of those applications do not have an option to migrate (yet)
What will happen to an application that uses Samba4/AD as accountprovider but stays on NS7 while Samba4/AD migraties to NS8?
Will that application still work as it does now on NS7? Or will it have a problem authenticating?
BTW, mattermost successfully migrated from NS7 to NS8. Because of my concerns regarding the question I am reluctant to migratie other applications.
At the end of a sucessful migration, your AD and FileServer are migrated to NS8.
If DNS is correct, your NS7 will become a “member server” in the new NS8 AD - it will have access to AD users (they show up in NS7 Cockpit) and thus are also available for any apps you can’t migrate (yet).
Depending on apps, you may need to redirect the AD/LDAP query to your new AD, but it will work.
