[joshklein]

Configuring sudo is such a footgun that it was deemed necessary to fork a text editor purpose-built for only modifying sudo configurations (visudo).

So, that’s why not sudo. As for why doas, see:

* https://flak.tedunangst.com/post/doas

* https://flak.tedunangst.com/post/doas-mastery

[supergarfield]

visudo isn't a fork, it just locks the sudoers file against concurrent edits, runs whatever standard editor you want, waits for it to finish, and validate the new file before committing it to the real location.

I can agree that process is too complex, but they're not maintaining a fork of vi for that purpose.

[KronisLV]

> and validate the new file before committing it to the real location

Controversial take: i think that it'd be really good to have EVERY configuration file have something like that. For example, if i'm working on a long bit of configuration for fstab, cron, Apache2, Nginx, Tomcat or any other pieces of software, i'd want to see whether everything i've written will be considered valid ahead of time, e.g. a "dry run" of sorts. A bit like we have language servers for VS Code, we could have validation servers as well, for configuration.

That said, i don't think we'll ever have that, since it's easier to just write code in an ad-hoc manner, as opposed to extracting validation of configuration as a separate bit of code that can be called from some CLI, not just at runtime, especially since many configuration files allow nested includes.

Regardless, thinking more about models and validation methods would be nice, e.g. XSD. If we leverage type systems in programming languages, we might as well do that at an operating system level - something like shellcheck built in. A validation handler for every file type.

[zinekeller]

Nginx does have a "dry run" mode for checking configs (unless that something external - like unresponsive servers - is experiencing problems).

[KronisLV]

Thanks for this information, had to actually look it up and check, seems like that's indeed true: https://www.nginx.com/resources/wiki/start/topics/tutorials/...

Here's an example:

  $ docker run --rm nginx:1.20.2 nginx -t -g "daemon off;"
  
  /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
  /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
  /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
  10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
  10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
  /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
  /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
  /docker-entrypoint.sh: Configuration complete; ready for start up
  nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
  nginx: configuration file /etc/nginx/nginx.conf test is successful

Every piece of software should definitely have something like that! Ansible is another piece of software that i can recall with an explicit dry mode run like that: https://docs.ansible.com/ansible/latest/user_guide/playbooks...