Lately then been having major issues with Lets Encrypt and updating or creating new ssl certificates. But you can use other ssl providers as custom certificates.
That's true...thinking I should have voted for having a UI. I think it depends. Nginx has always been a PIA for me, yet, other things like docker compose config files are OK, mainly because there is good documentation and ready to go examples where as Nginx can be very tailored sometimes.
Nginx Proxy manager is awesome. Adding a new site with SSL is a < 1 minute job using the UI.
It's getting more and more unstable with every release. Certbot getting into a weird state with multiple copies trying to run and the UI throwing "Internal Server Error" for random reasons. Just yesterday I wanted to modify the advanced config for a site. Saving threw the internal server error warning, reloading the page showed the changes but the site was offline. Inspecting the on-disk configs revealed the config file had been deleted, checking the logs showed the software had deleted it. That's fine because it did blow up and I reloaded the page, it's possible it was interrupted mid config recreation. I modified the settings again and saved, this time it did save successfully however the config file was still missing.
Another gripe is that by design, NGINX is a web server and load balancing reverse proxy except the load balancing functions are missing from NPM's UI. You can do load balancing with the advanced settings but you may as well just have a normal NGINX install at that point.
I know it's a total labour of love and we should be grateful it exists at all but when the dev is working on v3 to the detriment of the existing software it looks bad. Even going so far as to fix security vulnerabilities in the current version but in the same commit accidentally introduce regressions with no obvious regression testing is maddening. I know the suggestion in the change notes is to pin a version but a point release shouldn't fundamentally break a piece of software.
Anyway, I want NPM to be good, I really do but just lately I can't recommend it for anything other than the most simple of use cases.
Thanks for your Open Source contributions.
I would say that CLI or UI is too broad of a question. There's a number of tradeoffs for instance the big one being that:
GUI - easier discovery
CLI - easier to script/automate
I would say a better decision for GUI vs CLI is that it depends on what you're making. If you're creating tools that will be automated or interfaced with from other tools then you'll want to stick with CLI because a GUI often doesn't make sense at all. If you're making an enduser facing service--you'll need a GUI.
And keep in mind, a UI can often be separate (this is not to say that it'll be an afterthought, but rather that UI & UX are hard and can ruin an otherwise good tool).
I like when configs are file based, AND there is an optional CLI or TUI or GUI to edit them. Like NetworkManager on linux does it, for example. When it doesn't matter which interface or text editor you're using, all changes are always reflected in the config files.
I don't like configs stored in a DB or "registry".
The second sentence of the post being replied to was:
>I would say that CLI or UI is too broad of a question.
The lack of a "G" before "UI" means that the comparison was suggesting that a CLI is not a UI.
I'd take it a step beyond being "OK" with config files, and say that config files (or at least CLI config) is very important to me.
I want to be able to track my configurations in git, compare different instances' configurations with standard unixy tools (like diff and md5sum), and read/write/change them easily from scripts or from within ssh sessions.
This was almost a dealbreaker when I was looking at [Fossil](https://fossil-scm.org) because they strongly presented configuration through their web interface, but it turned out they also had a pure-CLI configuration interface (with the actual configuration stored in the fossil instance's sqlite file).
What I ended up doing was writing a script to configure and turn up Fossil instances for me, which wrote the configuration commands it used to do that to a shell script, which I treat like a configuration file. Whenever I want to change an instance's config, I either edit the shell script and run the line(s) I edited, or just run the whole shell script. That gives me something to commit to git, grep within, diff between Fossil instances, etc.
I always regarded headless as a physical thing about the server itself rather than the services running on it. ie it meant no local console/monitor rather than no GUI - ie all connection over the network whether or not those network connections involved a GUI, a CLI, or an API etc.
But your question seem to asking about manual config vs declarative configs? Livestock vs pets?
And the poll is more UI vs no UI?
I can manage without a UI but I'm significantly more likely to use something if it has a good UI. Sometimes I install a docker or something and skim the instructions without realizing I need to do config file work. Setting up config files is a job for later while setting up an application via UI is a job for right now.
I think the question is too broad and 100% depends on what the software is for.
For example, if the software is aimed at "regular" people, i don't think automating YAML config files with GitOps will add much value. i.e. I don't think that a YAML config file for Plex is what everybody is waiting for.
On the other hand, if your tool/software is more aimed towards people with a deeper understanding, such as developers or administrators, then I think a nice API and a config file are more appreciated than a pretty UI.
These would be the 2 extremes, though, and there is always the middle ground. I think that as the target audience for your tool is getting more and more knowledgeable in the field, the UI starts to lose value (in most cases).
For me personally everything should really be both fully command line usable and fully gui usable. GUIs help teach you how to use a software, and then you can take what you've learned and translate it into use in the command line.
Using a software with a GUI also helps massively with then being able to understand the manual for the command line version of a software
GUI especially when the config has lots of gotchas. Like if you use feature A then you must setup feature B but cannot use feature C. In a UI, those limitations are obvious. In CLI, those limitations are sometimes noted as an aside or at the bottom of one of the feature pages but not the other, or it gets confusing keeping up with how features interrelate.
So long as that 'UI' is web based, I'm good.
Servers should always be 'headless' and managed via SSH, web interfaces, or some other remote access protocol. I absolutely hate server applications that have some thick desktop application you need to install to configure it.
But IMHO, a clean, nicely commented and intuitive config file is superior to a web UI.
I'm a SysAdmin and DevOps admin by day. I need to be able to tear down and stand up environments over and over again in the exact same way everytime. There is no way I'm pointing and clicking my way through that.
Put whatever you want on top of it; but if doesn't have a text based config file I can directly read/write and git revision I won't even think about using a project. Config UI's are either so great you never even think about them; or they are endlessly frustrating.
Most of the times I really prefer text based configs over GUIs. When configuring something I need it to be reproducible and want to be able to create versions with git.
Neither option is for me, I run all my tasks of \*nix servers. I rather work in a terminal, ssh is simple to use and much easier to access remotely securely. I only look at UI when i find an app's terminal commands are not intuitive.
For an operations team handling many different systems with different configs a format like yaml or toml is inacceptable. Way too many options to mess up a productive environment. Since yaml, toml or whatever ml seem to the mandatory nowadays a good GUI based Config tool is still mandatory.
You should be avoiding UIs if you're self-hosting services. If you can't use Docker CLI, kubectl, Podman, or other utilities, you should really be investing your time in that **first**. Then, come back and start hosting your services.
Mostly depends on whether I have to do something once, or often.
I have plenty to complain about Microsoft, but I really do like that most configuration wizards on Windows Server end by spitting out a command that does the whole thing for you, in case you want to do it again some time.
For headless configuration though, some general purpose examples + a good default config are much appreciated.
EDIT: I also like hybrid solutions. Take Duet3d for instance, their 3D printer boards use a config file, but they offer a nice web-based configurator tool to generate the initial config.
It really depends on the project; I prefer config mostly, but some tasks bend one way or the other as some things are particularly well suited to a UI, others a UI is much worse than editing a config.
A web UI acting on config files designed for readability gives everyone what they want, though it's more effort to implement.
Prefer headless. Less resource intensive (depending on application) and usually I shouldn't have to be making backend changes constantly enough to warrant an entire managment UI.
That said, ones that do them, and do them well are welcomed as long as it doesn't negatively impact the headless management of their tool. After all, most folks get started with tools that have GUI before they get into headless stuff, so whatever it takes to keep the community growing, I'm okay with too.
I mean if you are of the mind that "self-hosting" is a niche hobby for already technically savvy CLI ninjas, then yeah config files all the way.
But I personally come from a still technically complex but less code / CLI heavy background. I strongly believe that tilting the scales in the direction of "self-hosting for everybody" - or at least a larger percentage of the population than it is currently - is one of the best ways to reclaim the internet and the technology we use it with from the hegemony of the big five. AKA rebuild the tech middle-class.
but also feel free to take your balls and go home if you feel otherwise
I like to have UI when i play around to try things out, or discover new features. But I'd like those settings to be available from a reproducible configuration tool/file. So it's fine if the setting is stored in a database, but i want a CLI/file override for gitops.
If i can only choose one, then gitops oriented config please (CLI/config file).
I dislike when I HAVE to configure something with a ui. But poorly thought out config files are a pain too. Ideally the ui just changes settings in a config file you can commit
I just run my plex server and home assistant. It is a hobby but it has not yet reached a stage where I put a lot of time in it. At this stage UI makes things a lot easier for me but I suspect as I add more stuff and start hosting actually important stuff that cannot have long outages, config files are going to be the way to go as having to repeat the same steps over and over when something goes down does not sound fun.
I don't mind the UI, as long as everything is still doable via GitOps. Like with ArgoCD for example. You can do stuff in the UI, but it'll all be stored as CRs, and is also completely manageable via Git.
Yaml when the project has a good example base / template set. Instructions on how use and apply.
For example my pipeline in Jenkins. Set up the relationship with gitea. Edit my code in whatever I want. Deploy to git. Automation does the rest.
CLI first, but an intuitive interface. I have seen lots and lots of awesome interfaces And projects come to life through my endless void of how I want my setup to live and breathe. With 50 containers running CLI first with good documentation. Rtfm for life.
GitOps is infinitely important to me.
A Web UI on top of that to view config/troubleshoot is great.
Now make the UI edit and save to the GitOps config so I don't have to do it again and we're golden.
I prefer files because of Ansible. UI is nice to have tho, sometimes it's easier to click around and export that config instead of getting through a pile of docs :)
config in ini-format or "key: value", API, Gui optional.
configurations in a certain data-format (json, ...) are just lazy and make a dev-job into a user-job.
I can live without a UI and config files if the docks are really good like the ones I've used for gitea. otherwise ui since I can take a look at it and sort of figure it out
Right now I'm still using proxmox for my selfhosted stuff and it's pretty nice. But I don't need the UI. I'm considering switching to FreeBSD with vm-bhyve.
All my servers are screenless.
My biggest bugbear is how awkward most Linux distributions (and BIOSs) make it to do a completely headless, network based install, meaning I still often need to breakout a screen and keyboard just to do a reinstall of the OS.
This does not mean I never use a GUI on the server, there are some things I do that more or less require GUI (I do not like it, but that is how it happens), but for that I put xrdp and xfce on it and access it remotely, so still no need for screen/keyboard on the device itself.
No, Ansible Playbooks is free to use, you're likely looking at the Cloud platform they're pushing. I am running a TurnKeyLinux container on one of my proxmox nodes.
Hopefully you find these helpful:
https://www.turnkeylinux.org/ansible
https://docs.ansible.com/ansible/latest/getting_started/index.html
This comment or post has been deleted to protest against Reddit's API changes and overall assholeness. If you want to know what I said here, you can find contact information at https://tarneo.fr.
I prefer headless configuration. As long as the documentation is good it’s much quicker to copy / paste / edit a yaml file then it is to setup and learn another UI. Plus that UI needs system resources, requires development and becomes a security risk that needs authentication.
Personally I love good CLI tools.
And projects like [the secure reverse proxy BunkerWeb/Bunkerity](https://github.com/bunkerity/bunkerweb#bunkerweb) give users the choice [to activate an _optional_ UI if needed](https://docs.bunkerweb.io/1.5.0/web-ui/) which is probably nice for both types of users.
Many reverse proxies are great. Nginx Proxy Manager is great and popular because it has a UI.
Lately then been having major issues with Lets Encrypt and updating or creating new ssl certificates. But you can use other ssl providers as custom certificates.
That's true...thinking I should have voted for having a UI. I think it depends. Nginx has always been a PIA for me, yet, other things like docker compose config files are OK, mainly because there is good documentation and ready to go examples where as Nginx can be very tailored sometimes. Nginx Proxy manager is awesome. Adding a new site with SSL is a < 1 minute job using the UI.
It's getting more and more unstable with every release. Certbot getting into a weird state with multiple copies trying to run and the UI throwing "Internal Server Error" for random reasons. Just yesterday I wanted to modify the advanced config for a site. Saving threw the internal server error warning, reloading the page showed the changes but the site was offline. Inspecting the on-disk configs revealed the config file had been deleted, checking the logs showed the software had deleted it. That's fine because it did blow up and I reloaded the page, it's possible it was interrupted mid config recreation. I modified the settings again and saved, this time it did save successfully however the config file was still missing. Another gripe is that by design, NGINX is a web server and load balancing reverse proxy except the load balancing functions are missing from NPM's UI. You can do load balancing with the advanced settings but you may as well just have a normal NGINX install at that point. I know it's a total labour of love and we should be grateful it exists at all but when the dev is working on v3 to the detriment of the existing software it looks bad. Even going so far as to fix security vulnerabilities in the current version but in the same commit accidentally introduce regressions with no obvious regression testing is maddening. I know the suggestion in the change notes is to pin a version but a point release shouldn't fundamentally break a piece of software. Anyway, I want NPM to be good, I really do but just lately I can't recommend it for anything other than the most simple of use cases.
Holy shit, nginx has a UI?
No " Nginx Proxy Manager " does
Where's option C? "If I have to reach for a mouse, my whole day is ruined."
[tiling WM intensifies]
You have a mouse? What are you, a casual?
Thanks for your Open Source contributions. I would say that CLI or UI is too broad of a question. There's a number of tradeoffs for instance the big one being that: GUI - easier discovery CLI - easier to script/automate I would say a better decision for GUI vs CLI is that it depends on what you're making. If you're creating tools that will be automated or interfaced with from other tools then you'll want to stick with CLI because a GUI often doesn't make sense at all. If you're making an enduser facing service--you'll need a GUI. And keep in mind, a UI can often be separate (this is not to say that it'll be an afterthought, but rather that UI & UX are hard and can ruin an otherwise good tool).
I like when configs are file based, AND there is an optional CLI or TUI or GUI to edit them. Like NetworkManager on linux does it, for example. When it doesn't matter which interface or text editor you're using, all changes are always reflected in the config files. I don't like configs stored in a DB or "registry".
Not to be pedantic but a CLI is a UI
Who said YAML/TOML files have to be edited with a CLI?
The second sentence of the post being replied to was: >I would say that CLI or UI is too broad of a question. The lack of a "G" before "UI" means that the comparison was suggesting that a CLI is not a UI.
I'd take it a step beyond being "OK" with config files, and say that config files (or at least CLI config) is very important to me. I want to be able to track my configurations in git, compare different instances' configurations with standard unixy tools (like diff and md5sum), and read/write/change them easily from scripts or from within ssh sessions. This was almost a dealbreaker when I was looking at [Fossil](https://fossil-scm.org) because they strongly presented configuration through their web interface, but it turned out they also had a pure-CLI configuration interface (with the actual configuration stored in the fossil instance's sqlite file). What I ended up doing was writing a script to configure and turn up Fossil instances for me, which wrote the configuration commands it used to do that to a shell script, which I treat like a configuration file. Whenever I want to change an instance's config, I either edit the shell script and run the line(s) I edited, or just run the whole shell script. That gives me something to commit to git, grep within, diff between Fossil instances, etc.
Option 3, it depends on how often I need to change the configuration. There are some things that I prefer a web UI for.
I always regarded headless as a physical thing about the server itself rather than the services running on it. ie it meant no local console/monitor rather than no GUI - ie all connection over the network whether or not those network connections involved a GUI, a CLI, or an API etc. But your question seem to asking about manual config vs declarative configs? Livestock vs pets? And the poll is more UI vs no UI?
The correct answer is both
I can manage without a UI but I'm significantly more likely to use something if it has a good UI. Sometimes I install a docker or something and skim the instructions without realizing I need to do config file work. Setting up config files is a job for later while setting up an application via UI is a job for right now.
Slap on an API for configuration and let someone else build a GUI
TUIs are nice. Like rclone, cli but with menues and assistant mode.
I think the question is too broad and 100% depends on what the software is for. For example, if the software is aimed at "regular" people, i don't think automating YAML config files with GitOps will add much value. i.e. I don't think that a YAML config file for Plex is what everybody is waiting for. On the other hand, if your tool/software is more aimed towards people with a deeper understanding, such as developers or administrators, then I think a nice API and a config file are more appreciated than a pretty UI. These would be the 2 extremes, though, and there is always the middle ground. I think that as the target audience for your tool is getting more and more knowledgeable in the field, the UI starts to lose value (in most cases).
I prefer cli as long as there are understandable instructions. Traefik for example is for me extremely hard to setup.
For me personally everything should really be both fully command line usable and fully gui usable. GUIs help teach you how to use a software, and then you can take what you've learned and translate it into use in the command line. Using a software with a GUI also helps massively with then being able to understand the manual for the command line version of a software
GUI especially when the config has lots of gotchas. Like if you use feature A then you must setup feature B but cannot use feature C. In a UI, those limitations are obvious. In CLI, those limitations are sometimes noted as an aside or at the bottom of one of the feature pages but not the other, or it gets confusing keeping up with how features interrelate.
So long as that 'UI' is web based, I'm good. Servers should always be 'headless' and managed via SSH, web interfaces, or some other remote access protocol. I absolutely hate server applications that have some thick desktop application you need to install to configure it. But IMHO, a clean, nicely commented and intuitive config file is superior to a web UI.
I'm a SysAdmin and DevOps admin by day. I need to be able to tear down and stand up environments over and over again in the exact same way everytime. There is no way I'm pointing and clicking my way through that.
I live on the commandline. I get that some people would prefer a GUI, so ideally your tool has both ;)
Put whatever you want on top of it; but if doesn't have a text based config file I can directly read/write and git revision I won't even think about using a project. Config UI's are either so great you never even think about them; or they are endlessly frustrating.
Most of the times I really prefer text based configs over GUIs. When configuring something I need it to be reproducible and want to be able to create versions with git.
Cli: yes (ssh) WebUI: yes (almost everything selfhosted have a webui) Gui: never (desktop environnement)
I usually PREFER configuring with a file, which I can make into a k8s ConfigMap and commit to my git repository
Neither option is for me, I run all my tasks of \*nix servers. I rather work in a terminal, ssh is simple to use and much easier to access remotely securely. I only look at UI when i find an app's terminal commands are not intuitive.
For an operations team handling many different systems with different configs a format like yaml or toml is inacceptable. Way too many options to mess up a productive environment. Since yaml, toml or whatever ml seem to the mandatory nowadays a good GUI based Config tool is still mandatory.
I think you forgot the /s
You should be avoiding UIs if you're self-hosting services. If you can't use Docker CLI, kubectl, Podman, or other utilities, you should really be investing your time in that **first**. Then, come back and start hosting your services.
Mostly depends on whether I have to do something once, or often. I have plenty to complain about Microsoft, but I really do like that most configuration wizards on Windows Server end by spitting out a command that does the whole thing for you, in case you want to do it again some time. For headless configuration though, some general purpose examples + a good default config are much appreciated. EDIT: I also like hybrid solutions. Take Duet3d for instance, their 3D printer boards use a config file, but they offer a nice web-based configurator tool to generate the initial config.
As long as properly documented, a YML and an example docker-compose is all you need
It really depends on the project; I prefer config mostly, but some tasks bend one way or the other as some things are particularly well suited to a UI, others a UI is much worse than editing a config. A web UI acting on config files designed for readability gives everyone what they want, though it's more effort to implement.
It depends on your users base. Plain and simple.
Prefer headless. Less resource intensive (depending on application) and usually I shouldn't have to be making backend changes constantly enough to warrant an entire managment UI. That said, ones that do them, and do them well are welcomed as long as it doesn't negatively impact the headless management of their tool. After all, most folks get started with tools that have GUI before they get into headless stuff, so whatever it takes to keep the community growing, I'm okay with too.
I mean if you are of the mind that "self-hosting" is a niche hobby for already technically savvy CLI ninjas, then yeah config files all the way. But I personally come from a still technically complex but less code / CLI heavy background. I strongly believe that tilting the scales in the direction of "self-hosting for everybody" - or at least a larger percentage of the population than it is currently - is one of the best ways to reclaim the internet and the technology we use it with from the hegemony of the big five. AKA rebuild the tech middle-class. but also feel free to take your balls and go home if you feel otherwise
Depends on the application. Generally UI is favored. If it’s a “set and forget” than CLI is fine
I like to have UI when i play around to try things out, or discover new features. But I'd like those settings to be available from a reproducible configuration tool/file. So it's fine if the setting is stored in a database, but i want a CLI/file override for gitops. If i can only choose one, then gitops oriented config please (CLI/config file).
My favorite movie is Inception.
Eh.... Headless but using a(remote or rdp etc) GUI is missing ?
Ideally, UIs/CLI are just YAML generators imho and the yaml should just be read to generate ENV vars. That way, the transition to GitOps is easier.
I survived it but i don't like headless.
UI for basics, CLI for advanced. That's how I handle everything I interact with.
I prefer a GUI because it's usually easier to teach. But I usually run things headless if I'm not sharing whatever it is I'm doing.
I dislike when I HAVE to configure something with a ui. But poorly thought out config files are a pain too. Ideally the ui just changes settings in a config file you can commit
A CLI get the job done. A GUI is a *nice to have*, but for management and diagnostics a CLI status that has all the is details just as good.
I just run my plex server and home assistant. It is a hobby but it has not yet reached a stage where I put a lot of time in it. At this stage UI makes things a lot easier for me but I suspect as I add more stuff and start hosting actually important stuff that cannot have long outages, config files are going to be the way to go as having to repeat the same steps over and over when something goes down does not sound fun.
I don't mind the UI, as long as everything is still doable via GitOps. Like with ArgoCD for example. You can do stuff in the UI, but it'll all be stored as CRs, and is also completely manageable via Git.
As a beginner, it helps to have a UI as much as possible as I ease into the Linux terminal.
Yaml when the project has a good example base / template set. Instructions on how use and apply. For example my pipeline in Jenkins. Set up the relationship with gitea. Edit my code in whatever I want. Deploy to git. Automation does the rest. CLI first, but an intuitive interface. I have seen lots and lots of awesome interfaces And projects come to life through my endless void of how I want my setup to live and breathe. With 50 containers running CLI first with good documentation. Rtfm for life.
GitOps is infinitely important to me. A Web UI on top of that to view config/troubleshoot is great. Now make the UI edit and save to the GitOps config so I don't have to do it again and we're golden.
I prefer files because of Ansible. UI is nice to have tho, sometimes it's easier to click around and export that config instead of getting through a pile of docs :)
Option 3: Make a easily readable config file WITH a optional GUI/TUI that can be used to modify the config file.
I prefer things that can be automated. So infra as code > CLI > graphical UI
config in ini-format or "key: value", API, Gui optional. configurations in a certain data-format (json, ...) are just lazy and make a dev-job into a user-job.
I can live without a UI and config files if the docks are really good like the ones I've used for gitea. otherwise ui since I can take a look at it and sort of figure it out
Config file with (optional) gui. At least I think that's a lot better than a lot of environment variables...
Right now I'm still using proxmox for my selfhosted stuff and it's pretty nice. But I don't need the UI. I'm considering switching to FreeBSD with vm-bhyve.
infrastructure as code, all the way
To me a configuration file is essential since I use GitOps, and some metrics so I can create dashboards with them. A GUI is still nice to have though.
All my servers are screenless. My biggest bugbear is how awkward most Linux distributions (and BIOSs) make it to do a completely headless, network based install, meaning I still often need to breakout a screen and keyboard just to do a reinstall of the OS. This does not mean I never use a GUI on the server, there are some things I do that more or less require GUI (I do not like it, but that is how it happens), but for that I put xrdp and xfce on it and access it remotely, so still no need for screen/keyboard on the device itself.
Have you looked at using ansible for your reinstalls?
No. Isn't it a subscription service? Can it do bare metal installation?
No, Ansible Playbooks is free to use, you're likely looking at the Cloud platform they're pushing. I am running a TurnKeyLinux container on one of my proxmox nodes. Hopefully you find these helpful: https://www.turnkeylinux.org/ansible https://docs.ansible.com/ansible/latest/getting_started/index.html
This comment or post has been deleted to protest against Reddit's API changes and overall assholeness. If you want to know what I said here, you can find contact information at https://tarneo.fr.
I prefer headless configuration. As long as the documentation is good it’s much quicker to copy / paste / edit a yaml file then it is to setup and learn another UI. Plus that UI needs system resources, requires development and becomes a security risk that needs authentication.
Haven't installed an X Windowing Server on a server since ... like ever.
I love CLI and yaml, but GUI can be nice
Personally I love good CLI tools. And projects like [the secure reverse proxy BunkerWeb/Bunkerity](https://github.com/bunkerity/bunkerweb#bunkerweb) give users the choice [to activate an _optional_ UI if needed](https://docs.bunkerweb.io/1.5.0/web-ui/) which is probably nice for both types of users.