Support

UNiTE, Remote CLI, eXtract Wizard

#32556 – UNITE dbprefix default value vs Kickstart default prefix

Posted in ‘UNiTE, Remote CLI, eXtract Wizard’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Wednesday, 26 February 2020 03:59 CST
extly
Looking to optimize the operation with Unite, I'm finding that Unite does not have a default value for the dbprefix setting. On the other hand, Kickstart does have a default prefix. I guess that somewhere in the backup file, the db prefix is stored.

Is there a way to recover the db prefix to use it on the Unite template?

Regards

Custom Fields

Which tool do you want support for? Unite
Tool version (in x.y.z format) 4.0.4
 
Wednesday, 26 February 2020 07:39 CST
nicholas
Kickstart most definitely does not have a default dbprefix (or any dbprefix at all) since it only extracts backup archive files. It does not restore them. You are probably mistaking Kickstart – the archive extraction script – with ANGIE. ANGIE is the restoration script which is included in the backup archive.

ANGIE is interactive. UNiTE is non-interactive; The "UN" in its name stands for UNattanded.

An interactive application like ANGIE can present you with defaults because you can override them before proceeding with the restoration.

A non-interactive, unattended application cannot do that by definition. It needs to be explicitly given all of the parameters it will be using for restoration which, at a minimum, are the location of the archive file, the absolute path to the site's root and the database connection information (hostname, database name, username, password, table name prefix).

As for your question, dbprefix is already documented to be a mandatory configuration parameter:

If AND ONLY if you are restoring an extra database, NOT the main database of your site, which already didn't have a prefix attached to it during backup, you can leave the value blank, that is the tag should read <dbprefix />



Warning

YOU MUST NEVER LEAVE THIS BLANK FOR THE MAIN DATABASE OF A JOOMLA! OR WORDPRESS SITE! Using a blank prefix WILL lead to a restoration FAILURE as neither Joomla! nor WordPress are designed to work with an empty database prefix.


Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Wednesday, 26 February 2020 07:52 CST
extly

Ok. Thanks. I need to restore the backups via the command line, and the original prefix is a requirement. If I understand correctly, ANGIE does have the original db prefix and it is inside the JPA/ANGIE. I'll look into the structure to retrieve that part.

Regards,



 
Wednesday, 26 February 2020 09:34 CST
nicholas
The information you are looking for is stored in the installation/sql/databases.json. However, you don't have that file until you extract the backup archive... which means that UNiTE has already read its configuration and is currently running.

Obviously time travel is not a solution :)

The next best thing is creating backup archive in ZIP format. Since you know the name of the JSON file you can use unzip on the command line to extract just this file. Or you could use JPA / JPS archives and Kickstart command-line (something like: php kickstart.php your_file.jpa --extract=installation/sql/databases.json)

You could then use something like JSON.awk to extract the prefix, pass it through sed and update your XML file, then run UNiTE.

As with all things command-line there are several ways to skin a cat.


Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Wednesday, 26 February 2020 12:28 CST
extly

Excellent, thanks.

If I may suggest an improvement to Unite, it would be great to have the option to load the original installation settings. For instance, a tag like <dbprefix installation="site.sql.prefix" />.

Bets Regards
 
Thursday, 27 February 2020 02:17 CST
nicholas
No, this will not be implemented. There are some very good architectural reasons for that.

UNiTE's configuration needs to be immutable. If we start trading it as mutable we risk introducing bugs.

Even if we accept this risk (which we don't, but for the sake of argument let's say we were unscrupulous and did), Akeeba Backup allows you to exclude the database settings from the backup archive. In this case the databases.json file contains empty values. We wouldn't know until it's too late: the archive is extracted, people can't access your site and UNiTE reports an error that's hard to debug because the validation passed even though the database connection information is empty.

Furthermore, allowing the validation to pass with empty / delegated configuration values opens up the possibility of a genuine mistake in UNiTE's configuration. Think about someone blithely restoring a backup archive on a different hosting account on the same server, without realizing that they are now overwriting the main site's database. I know you think that's unlikely but 13 years of tech support tell me that until I introduced the aforementioned check and had ANGIE explicitly blank out the db connection information if the domain name and path in the URL doesn't match exactly the ones the backup was taken from we had half a dozen people a month with that issue. It's not just the increase in our support load, it's the fact that each and every of these cases represents a broken live site and one person losing trust in our software.

Furthermore, UNiTE hands over the restoration process to ANGIE itself. We construct ANGIE's configuration state from the UNiTE configuration and simply call ANGIE's models to run the restoration. The Models, as they should in an MVC world, are oblivious to the source of the method call. They will dutifully carry out their task based on the provided configuration state. If we removed ANGIE's checks for empty / delegated database connection information we'd re-introduce the problem we solved or, worse, would allow ANGIE to use the default MySQL connection defined in php.ini with an empty database prefix. The resulting site cannot be backed up and it's basically trashed. That's one big honkin' bug!

Finally, your use case is extremely rare. You are talking about restoring a site with the same prefix as the site you backed up without knowing what you backed up. Frankly, that's not what UNiTE is designed to do. It's designed to automate site restoration when you know WHAT you are restoring and WHERE you are restoring it to. But even if you do want to abuse it like that I told you how you can automate it. Just make sure that you do cover for the case that databases.json does not include a prefix so you can apply a default one (e.g. "res_").

Based on the rarity of your use case, the problems implementing a solution for it would introduce to the overwhelming majority of our clients and the availability of alternative automation options outlined previously I can tell you in no uncertain terms that your feature request will not be implemented.

As a side note, we are currently working on a new major version of UNiTE. The direction we are moving towards is removing all features which can be reproduced with standard command line tools. For example, sending emails after the restoration is complete or fails had a reason for existence in 2009 when UNiTE was born but are completely irrelevant in 2020; the standard output of UNiTE can be redirected to a mail script or automatically mailed to you by the CRON daemon, depending on how you launch it. Considering that your use case can be automated with standard command line tools there's a further reason for us not to implement your feature request on the principle that it moves against the direction we are taking UNiTE. Monolithic tools are not the way to go. They are restrictive. The direction we need to move is nimble tools which are conducive to automation, i.e. the UNIX way.


Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Thursday, 27 February 2020 02:47 CST
extly
Thanks for the detailed explanation.

Best Regards
 
Thursday, 27 February 2020 03:02 CST
nicholas
You're welcome!


Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Saturday, 28 March 2020 18:17 CDT
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!