configctl commands list?

[Wolfspyre]

the configctl tool is pretty cool!

however,
it's a little obtuse to use at the moment, due to a lack of

'heres what I can do'
guidance.

There is no inbuilt mechanism to query configctl about what faces it has, and what options those faces respond to.

There is no hinting as to where one might look in attempt to deduce this for themselves.

The user is expected to know this through osmosis.

I'm sure that as someone who works with it day in and day out, these papercuts aren't really noticeable..

However, for someone who logs into their firewall at 0400 because something's busted, half awake, and needing to restore homeostasis as expediently as possible, this problem's significance potentiates immensely.


I recognize that configctl's abilities are somewhat dynamic, based on the services installed and the scripts they feed to configctl...

however... pointing the user to `look in $directory for a list of configctl subcommands`

or coalescing the data at package install time, and saving it somepace for subsequent recall on invocation
doesn't intuitively feel especially burdensome, given the benefit a user would derive after the dreaded 0-dark-thirty page...

Thoughts?

[franco]

Hi,

configd is more or less a tool for the backend to trade data with the GUI or for the GUI to run a privileged action for configuration purposes. You may want to look at:

# configctl configd actions

The actions are self-documenting in the respective configuration files (all have a message that they send to syslog when executing and some have descriptions shown above that mostly pertain to their ability to be used by the Cron GUI manually). These might be the most interesting so you can filter:

# configctl configd actions | grep -v "\[  \]"

Of note is pluginctl as well since it's more tailored to be a debug tool and digs a bit deeper into the code (root priviliges needed).

# pluginctl -h

It can do a couple of things and tries to be self-documenting as well listing available configuration options when none was selected, e.g.

# pluginctl -c

And then you run a reload of Unbound like this:

# pluginctl -c dns:unbound

or all of the DNS via

# pluginctl -c dns

And the tool will try to be chatty about what it is doing.

That being said the primary focus is the GUI or the console menu. Special conditions require special tasks that would be too lengthy to document while maintaining usefulness (someone has to find their case and read the docs that were written and discussed before).


Cheers,
Franco

[Wolfspyre]

hiya!
thanks for your thoughts, and  yep… I agree…

the thought/ desire I had was more along the lines of
‘does it make sense to include a pointer to “configctl configd actions” when configctl is run with -h’ or something to remind those of us with poor memory how to find that output again.

i’m aware it’s not intended to be super user friendly…

and if you make it TOO user friendly you run the risk of asking for more borderline sane requests like this one

what would you think would be a good reminder/hint/clue here?

thanks again.
I sincerely appreciate your work.

[franco]

Ok how about this then... https://github.com/opnsense/core/commit/e50780e531a



Cheers,
Franco

[Wolfspyre]

THANK YOU.

that will likely REALLY help (HOPEFULLY more than just me) next time I'm trying to remember syntax.

... now.... what did I do with my keys...