Add a cli tool to allow easy management of the AIO stack

[gggeek]

I propose to add a command line tool to carry out management operations.

It would reside inside the MC, and be built out of the same codebase that the web interface is.

Speaking from personal experience and after having read many of the GH discussions, it seems that the current approach of "configuration is carried out via a web interface" and "the MC works like magic / black box" is reaching its limits.

Advantages of a command-line tool:

• it works even when, for any reason, the AIO web interface is not working or accessible (observed so far: issues with the authentication due to bad connections to the NC admin interface, networking problems accessing it)
• it is easier to script for automation than sending requests to the AIO interface
• it simplifies authentication required to access it (anyone on the command line who can run docker exec)
• it would probably just as long to implement than a restful interface within the AIO web app, and would be easier to secure
• it could add as "cli reverse proxy" to the NC occ tool, making it simpler to execute all the occ one liners that admins might do, and become the 'single entry point' for running operations from the command line

[szaimen]

Hi, honestly I'd rather think we should focus on making the aio-interface more reliable and harder to break.

Btw, a basic cli tool already exists: https://github.com/nextcloud/all-in-one#how-to-stopstartupdate-containers-or-trigger-the-daily-backup-from-a-script-externally

[szaimen]

I've created a new FR for my idea: #8160

[gggeek]

Hi, honestly I'd rather think we should focus on making the aio-interface more reliable and harder to break.

I agree that the current AIO interface does not seem 100% rock solid. It might be that I am just unlucky, but in 1 year of use, for a very simple setup, I already had a few cases of unexpected behaviour.

My gut feeling is that the interface atm suffers from having been designed from the start with some assumptions about the supported workflows that later turned out to be too restrictive.

Decoupling backups from containers start/stop and from image pulling would go a long way in making things simpler to reason about and test, and thus bring in solidity.

Decoupling AIO management from web access, cookies, domain configuration, http timeouts, ports and firewalls setup also means having an interface which is more reliable and harder to break.

Btw, a basic cli tool already exists ...

I know.

I think that tool is not sufficient. The set of options to pass in is not clear (are they orthogonal to ecah other). Its scope/goal is opaque (does it risk triggering something I do not want). It is way too limited in functionality. It is written in shell, which makes it a no-go proposition for expansion into a proper console-based management tool

[gggeek]

Btw, a basic cli tool already exists ...

Lolz.

I just found out that in fact many more cli tools already exist. They are just stored in a Cron directory within the php sources.

This kind of proves my point (the need for those cli commands was there), and also makes the task of unifying those under a single umbrella much easier.

So, what I am proposing, becomes to start with:

1. take those existing cli tools and make them part of a single "php cli app". Make it reside outside of the Cron dir, as there is no specific requirement for those commands to be run only by cron
2. rewrite in the FAQs all suggestions to use daily_backup.sh for mere containers start/stop to use the cli-app instead
3. add to the main readme FAQ an entry about how to make a shell alias so that the invocation of the cli app within the container, with the right user, becomes easier to type
4. last but not least, rewrite the whole daily_backup.sh as nothing more than one of the commands avalable in the cli-app (barring any issues with user ids and permissions)