Sentora Updater

[Me.B]

Until today the procedure for updating zpanel/sentora had been to add to buildup almost an updater per release.

In the updater we had 3 parts:

1. bash routines that would for example change permissions or fix all tweaks in config we made.

2. SQL patch for the database.

3. Panel overwrite. With latest release.

The part 3 looks a bit bulk. I don't know if we should move to update only the latest changes?

Any advice is welcome.

5050

We may use this procedure until we get other solutions.

[TGates]

Just changes, I would think, would be much quicker, but not sure if it's easier...   Kind of a tough call...

[5050]

Hi

I would prefer a unique stable, fixed "base" installer and a patcher for each next change, even if there will be a lot of patchers before a new "base" installed may be released.

The "base" installer wiould do its work (install the base version) and then would apply each patch he can found or on the server.

This scheme adds a few difficulties:
- each patch is more complex to write. He must check first if all requirement are ok, and then skip or apply. But this can be simplifyed by a patche engine, ech patch becoming more a "description" of what to do.
- the patches must be named with sequence number including version they generate to ensure dependencies
- each patch must be documented about what it does.
- it may require to handle dependencies between patches for patch that do large change like database update
- it does not remove completely the need of a new installer, time to time when the number of patch is large enough

But it have a lot of more advantages:
- the installer is stable and does not evolve along life of major release number
- a patche would touch only the few things, so most of the time iit can apply without destroyng customised installs
- a patch can always be applyed again in case of skiped at a moment, even without effect
- a patch can be individualy skipped by an admin whom does not want it
- updates are always compatible, with all installed versions : only apply all patches existing from this version to go up to the last .
- it enables to have the panel more modular on install : module can become a patch. ie everything concernig nameserver can be setup by a patch.
- the patcher engine can be written with ability to reverse a change done by a patch, enabling very high level of safe.

[TGates]

For some reason I feel this is more complicated than it should be... the entire process that is.

Why can't there be a base/main installer/updater... pretty much will never change. Then, you have a DB updater file, file updater file, and config updater file... seems pretty straight forward to me.

For my Windows ZP to Sentora update package all i did was make a file package, the user uploads it to /panel/ folder, navigates to panel.domain.com/update/ and simply clicks 'Upgrade!' The DB is patched, the configs patched... pretty simple. If people are using custom installs to bad! I never finished it 100% like changing the core DB name or folder name from zpanel to sentora... oh well

For one of my other projects, its a 1-click update.

1. New version gets downloaded to hosting space.
   
2. Backups are made of entire site and DB. (For Sentora we would skip hostdata/logs/junk like that I would think..?)
   
3. Files are extracted into panel folder (skipping any configs).
   
4. Updater script is read and DB gets patched as needed.
   
5. Update files and deprecated files are deleted.
   

And the upgrade from ZP > Sen should be it's own entity! Just do the conversion from ZP 10.1.1 > Sentora 1.0.0 and run the normal upgrade scripts from there! I made the basic Windows patch in less than a week, I'm pretty sure you lynux guru's can sort a bash script the same way

I probably could make one in PHP in 2-3 weeks based off my Windows converter

Kick it around, we have lost thousands of ZPanel users by not getting the conversion patch done!

If 90% of it can be done using php, then use it

That's my 25 cents worth
Think it over.

[Me.B]

PHP over bash can offer reusing some tools/classes in GUI.

Some time patching strings can turn bloody and complicated.

But indeed each release will have 2 or 3 sub updaters: DB/Config/Panel files.

[TGates]

I'm hoping we can make some headway on this. I will help out however I can.