Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "occ config:*" to manage config values #16368

Merged
merged 20 commits into from
Jul 7, 2015
Merged

Conversation

nickvergessen
Copy link
Contributor

When we are able to set/import configs via a console command, this can be added to scripts. So in the end, people don't need to use a second.config.php to publish configs when setting up the same owncloud on multiple servers. In the end this makes it possible, to start getting rid of the writable config.php file, which causes problems from time to time since ever. Ideally only a minimum set of configuration values is in the config.php. Especially any values that are/can be changed via the web UI should not be written to the file.

TODO

  • Add a command to export/list the existing configs (system + apps):
./occ config:list --help
Usage:
 config:list [--output[="..."]] [--public] [app]

Arguments:
 app                   Name of the app ("system" to get the config.php values, "all" for all apps and system) (default: "all")

Options:
 --output              Output format (plain, json or json_pretty, default is plain) (default: "plain")
 --public              Use this option when you want to exclude sensitive configs like passwords, salts, ...
  • Add a command to import configs (system + apps)
    Can either be a file on the system we are importing, or ./occ config:import < admin-mashine-file
./occ config:import --help
Usage:
 config:import [file]

Arguments:
 file                  File with the json array to import
  • Add command to set a system config value
  • Add command to get a system config value
  • Add command to delete a system config value
  • Add command to set an app config value
  • Add command to get an app config value
  • Add command to delete an app config value
  • Adjust issue template similar to Add occ app:list and ldap:show-config to issue_template.md #16846

* @throws \UnexpectedValueException when the array is invalid
*/
protected function getArrayFromFile($importFile) {
$helo = file_get_contents($importFile);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to be able to use occ config:import < file.json instead of reading from the filesystem of the owncloud instance. But I failed to understand if that works and how.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is $helo?

@nickvergessen
Copy link
Contributor Author

Rebased, ready to review @MorrisJobke @DeepDiver1975 @LukasReschke

@ghost
Copy link

ghost commented Jul 3, 2015

🚀 Test PASSed.🚀
chuck

@PVince81
Copy link
Contributor

PVince81 commented Jul 6, 2015

I'd suggest to reverse the default: by default do not output the "private" attributes (like the public mode) and only output them if the admin explicitly asks for them. This would align with the way the LDAP config exporter works, see https://github.com/owncloud/core/blob/master/apps/user_ldap/command/showconfig.php#L56

Also I guess this here could obsolete the LDAP specific config commands ? @blizzz

@PVince81
Copy link
Contributor

PVince81 commented Jul 6, 2015

  • I'd prefer to be able to set a value directly using:
    occ config:app:set files_locking enabled no
    instead of:
    occ config:app:set files_locking enabled --value=no
    instead of having to add --value (usually such arguments are rather for optional args)
  • Should we protect the special attributes of apps like version, enabled ? (ok, version might be good to trigger updates)

@PVince81
Copy link
Contributor

PVince81 commented Jul 6, 2015

  • Would be cool to have commands config:system without args that does the same as config:list but only for system. Same with a config:app command. For CLI tools I usually like it when I can "build up" the command by typing more, for example:
    • ./occ config:system => show me a list of system values, so I pick one
    • ./occ config:system logtimezone => show me the value of that argument
    • ./occ config:system logtimezone --setvalue="CEST". => change the value

In the current workflow I'd need to go back and re-edit the left part of the command to add ":get" or ":set" after I saw it.
Anyway, that's just some thought.
Being able to list the values with ./occ config:system should already be enough.

@PVince81
Copy link
Contributor

PVince81 commented Jul 6, 2015

  • We could even push this further and only allow the existing config values for system to avoid setting non-existing values. That would require having a catalog of supported config switches. The same for apps, if they were able to enumerate supported config switches. Probably something for much later.

@PVince81
Copy link
Contributor

PVince81 commented Jul 6, 2015

And now again I types ./occ config:app:get files_locking expecting it to give me all switches for files_locking so I could export that app's config, but it didn't. (admin UX problem 😉)

@nickvergessen
Copy link
Contributor Author

  • I'd prefer to be able to set a value directly using:
    occ config:app:set files_locking enabled no
    instead of:
    occ config:app:set files_locking enabled --value=no
    instead of having to add --value (usually such arguments are rather for optional args)

While this would be nice, we need special treatment for empty strings. so I figured instead of starting two code paths, we can just always use --value

  • Should we protect the special attributes of apps like version, enabled ? (ok, version might be good to trigger updates)

For the *:set we could, but I don't really think we should do that. you can screw it up with import anyway and you can also change stuff in the db directly. occ is risky, you need to know what you are doing...

...

About building the command, the problem is this merges all stuff into one command, ending up in a huge unmaintainable block of code, so sorry if the :set is annoying to you, but I think it's better to have it explicit.

We could even push this further and only allow the existing config values for system to avoid setting non-existing values. That would require having a catalog of supported config switches. The same for apps, if they were able to enumerate supported config switches. Probably something for much later.

We don't do such stuff and we really shouldn't. Maybe you want to set the values before enabling the app, etc. there are a lot of usecases for having it arbitrary.

@PVince81
Copy link
Contributor

PVince81 commented Jul 6, 2015

  • the export function doesn't write the app name in json: occ config:list files_locking --output json > locking.json gives {"enabled":"no","installed_version":"","no":null,"types":"filesystem"}. This means I have to remember which app it was from if I wanted to re-import it.

@nickvergessen
Copy link
Contributor Author

@PVince81 you can not import a single app atm, only the full thing, although that sounds like something we could/should fix

@PVince81
Copy link
Contributor

PVince81 commented Jul 6, 2015

My comments were all from my own usability testing. Would be good to know what other think to.
I'm fine with keeping the commands as is.


$this
->setName('config:app:get')
->setDescription('Set an app config value')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

=> "Get"

@PVince81
Copy link
Contributor

PVince81 commented Jul 6, 2015

About building the command, the problem is this merges all stuff into one command, ending up in a huge unmaintainable block of code

This wouldn't be an issue. The command only be the entry point and call functions in separate classes for separate functionality. But I understand that you might not want to make bigger changes at this point.

@PVince81
Copy link
Contributor

PVince81 commented Jul 6, 2015

Apart from #16368 (comment) I'm fine for merging this.

@karlitschek
Copy link
Contributor

I love it 👍

@karlitschek
Copy link
Contributor

But needs good documentation. @nickvergessen @carlaschroder

@blizzz
Copy link
Contributor

blizzz commented Jul 7, 2015

Also I guess this here could obsolete the LDAP specific config commands ? @blizzz

The LDAP config commands are slightly more sophisticated. In first line because there the configkey contains the config ID for the configuration plus the actual config name. So the commands split it up and let the user just specify the which config they want to see, change or delete.

Another thing: in LDAP we accept multiline values in few cases and output them differently in occ (;-separated) and accept them ;-seperated which is dealt with in the app's set method. This could be resolved in a generic way, though.

Also the --public (yes, better make it --private, #16368 (comment)) switch is not effective for apps.

So, it could obsolete them, but would cost convenience. Would not do it at this stage.

@blizzz
Copy link
Contributor

blizzz commented Jul 7, 2015

I feel not most comfortable with circumventing apps' set methods in general (or disable/enable as @PVince81 pointed out already), while I acknowledge the convenience and helpfulness of this command. Yes, you could change stuff in the DB directly, nevertheless this really lowers the hurdle to do so. For the greater benefit: 👍

@DeepDiver1975
Copy link
Member

@nickvergessen can you plase rebase this before you leave? THX

@nickvergessen
Copy link
Contributor Author

Rebased, fixed the docs typo, inverted the "public" to "private" and made it possible to import config:list system and config:list <app>

@scrutinizer-notifier
Copy link

A new inspection was created.

@ghost
Copy link

ghost commented Jul 7, 2015

🚀 Test PASSed.🚀
chuck

@PVince81
Copy link
Contributor

PVince81 commented Jul 7, 2015

👍

PVince81 pushed a commit that referenced this pull request Jul 7, 2015
Add "occ config:*" to manage config values
@PVince81 PVince81 merged commit d3e26a3 into master Jul 7, 2015
@PVince81 PVince81 deleted the occ-config-commands branch July 7, 2015 12:49
@carlaschroder
Copy link

Holy cow that's a lot of work! I can hear occ breathing.

@nickvergessen
Copy link
Contributor Author

@carlaschroder I will do that for you

@carlaschroder
Copy link

@nickvergessen I meant that's a lot of work on occ. It looks great.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants