b) is my current favorite. I could easily add scripts such as:

• /usr/lib/uwt/set-by-script/uwt-global-disable
• /usr/lib/uwt/set-by-script/uwt-global-enable

Those could be run by whonixsetup / whonix-setup-wizard and/or whoever.

whonixsetup / whonix-setup-wizard would then be just a graphical user interface and documentation around these.

@troubadour, what do you think?

Personally I would prefer to see something along the line of option b. Develop some type of API that applications can communicate with to change these settings and at the same time allow a command line interface.

Again, IMO the API should be centralized for all settings; get, set, delete. One API so that a user or developer does not have to search around what configuration file to run. type whonix-config --help and all the options are right there. The advantage of this approach allows the API to be re-written without effecting any of the applications using it, or command line interfaces. For instance, it would be trivial to then add on a web interface which would communicate with a well defined API.

I also think the front-end to the API should be written in python since it has a nice arg parser which is very configurable and easy to use. Take a look at that Debian parser code I made at the argparse section (debian-parser. This allows for easy help and command line access like:
whonix-config uwt disable [option]

Since I know you prefer scripting at the moment, the python API can make the system calls to your scripts to do the actual work leaving the python portion solely to handle processing the jobs. Bash scripts can just call the API as an end user would with parameters on the command line while python applications can access the API more directly.

I would also prefer to see the worker scripts you create all be named well and placed in the same directory structure so everything is easy to find and review which provides incentive for more developers to help out. One of my biggest frustrations is trying to follow the logic of some of the scripts since they often have many includes and gets really difficult to understand.

I really do not want to see even more packages if they are not absolutely necessary :)

Anyway, that's my two cents worth!

I'd consider shipping /usr/lib/*/set-by-script/set-del-or-get-command a service by a friendly upstream. To get an overview, by convention ls /usr/lib/*/set-by-script/ could be used. How does that sound?

A centralized API aka whonix-config gets difficult. Most packages worth configuration that way I consider not tied to Whonix, such as uwt, tb-updater, sdwdate, and will try to get them upstreamed or upstream them at some point.

It would have to be a generalized method, that can be reused by any package from anywhere. I worry about reinventing the wheel. The closest that exists is debconf, that is tied to Debian. Is there any generalized alternative?

hehe, I may start sounding like a broken record here...

Salt is like debconf but not tied to any distribution or even operating system as it also works on the Mac and Windows. You would only need to use the minion. If you developed a configuration system around Salt (as this is what it is designed for) it can be easily ported to other management platforms like Puppet if someone had the inkling to do so.

You would create salt states and sometimes modules for more complicated configurations. They already have a command line interface and python interface. For the simpler configurations where you are just modifying a file, adding one, deleting one etc you just need to create simple yaml configuration files. The system can also be used to check every part of the sytem is in an expected state, and change it if not (file permissions are correct. files exist or do not exist). So using your example above, this is how you do it in salt.

From the command line:
salt '*' state.sls uwt.absent - disabled globally
salt '*' state.sls uwt.present - enabled globally

Configuratoin file would look like:

uwt/present.sls

/etc/uwt/50-uwt:
file.managed:
- source: salt://salt/files/50-uwt
- user: root
- group: root

uwt/absent.sls

/etc/uwt/50-uwt:
file
  -absent

There is also what they call a top file that lists all the states you want enforced and this can be run at any time, enforcing all the states at once; or just one or a group at a time.

This provides a standardized configuration option which I think meets your needs although there is a learning curve to use it, but you have way more than enough technical skills to get going on it quickly. Just start with the more simple configurations that do not require a value like present, absent, or adding, removing predefined vars/text from files. You can later add web interface and python scripts can use the python api, while your scripting can use the command line interface.

It might be overkill though for your needs as it is primarily meant to be a remote management and configuration system. I personally use it to set up my virtual machine quickly to a base state, then I have more configurations for different machines Salt on Qubes

The system can do pretty much anything you can think of as its built for large enterprises to mange and deploy thousand of machines.

You can do it all using scipts, but this gives the advantage of built in api and standardized approach with a very structured but at the same time very flexible configuration system. Any new package or module you come across just plugs in. There are also commands to list available commands and states.

That would be a complete config file architecture change?

Using /etc/uwt rather than /etc/uwd.d?

No more /etc/uwd.d folder, where snippets can be dropped and extend preconfigured settings?

Shell scripts using that config system would then use the salt command line interface to figure out their settings rather than sourceing configuration files?

Do you know any example shell script that uses salt? How much effort would it be for you to create a proof of concept example using salt? For example porting uwt's config to salt?

All current configuration snippets could be kept in current locations and salt can be used to update them. Salt is just a configuration management system. I will look into a few script examples for you.

Even if you do not use salt, once thing that IMO would be very nice is to have all whonix related configuration scripts in one place, so you can easily see what is available to modify and configure. The proper location for this would be in the '/srv/' directory. Something like this:

/srv/whonix <- root dir
/srv/whonx/uwt <- all configurations related to uwt, no libs or binaries
/srv/whonix/tor <- tor configs
/srv/whonix/admin <- admin? contains first_boot_completed, .whonix_setup_completed, type things

So anything that the use can modify that is part of Whonix would go in /srv; just the configurations, no scripts. Scripts, can remain where they are.

All current configuration snippets could be kept in current locations and salt can be used to update them. Salt is just a configuration management system. I will look into a few script examples for you.

Ok.

Even if you do not use salt, once thing that IMO would be very nice is to have all whonix related configuration scripts in one place, so you can easily see what is available to modify and configure. The proper location for this would be in the '/srv/' directory. Something like this:

Most packages worth configuration that way I consider not tied to Whonix, such as uwt, tb-updater, sdwdate, and will try to get them upstreamed or upstream them at some point. Those are generic packages and anyone or any distribution is welcome to use them outside of Whonix. That is also the idea behind anondist. Putting configuration files into a non-standard location /src/ would prevent these packages from ever entering Debian, because it is a policy violation. Standard location for configuration files on Debian [and most distributions?] is /etc/.

What however maybe could be done is creating a optional package, that symlinks folders such as /etc/uwt.d to /srv/whonix for all packages developed under the Whonix umbrella. But how would that help?

/srv/whonix/tor <- tor configs

Tor does not have a .d style configuration folder yet. And taking over ownership of /etc/tor/torrc without breakage when the maintainer of the Debian tor package updates it is non-trivial. We are using config-package-dev as a robust solution.

The other Tor config file is /usr/share/tor/tor-service-defaults-torrc [.anondist]. But it is not supposed to be edited by users or scripts at the moment. Only option is /etc/tor/torrc. Anything else seems not feasible at the moment.

/srv/whonix/admin <- admin? contains first_boot_completed, .whonix_setup_completed, type things

I had something similar in mind. Created T155 for it.