Nginx UI – Access and modify the Nginx configurations files without CLI | Hacker News Reader

Nginx UI – Access and modify the Nginx configurations files without CLI

github.com

281 pointsgilad57 comments

I'm using this https://www.digitalocean.com/community/tools/nginx that I find it pretty good

Oh sweet! Didn’t know about this. Would have definitely helped when I was getting my Django app working on DO and was using NGINX for the first time.

Thanks for sharing. the tool is amazing. I have always been wondering if there is a better way to config NGINX.

Thanks for sharing. This is exactly what I need.

Nice, I love stuff like this. I can then take the generated files and pull them apart for understanding knowing that they are "working" examples.

One directory up they have some other tools people might find useful https://www.digitalocean.com/community/tools

Looks basically like a web-based text-editor. More effort needs to be put into adding UI controls for modifying common settings, or at least some macros for adding settings to a config file. (e.g. insert a common setting at cursor location). Better yet, hide editing the config file in an "advanced" mode, and allow UI controls (checkboxes, input boxes, and dropdowns) for editing parts of the config. (that's what I thought this was going to be).

what's the goal of that? Which person needing to configure nginx does not know how to edit text?

I imagine that if you are creating a web interface, with the associated risks it carries (login, vulnerabilities, permissions), the interface should have some advantages over just going into the terminal and editing the same files in the same way.

In fact, by reading the motivation of the project in the README, it seems that the problem it solved was the authentication part of it, and replaced it with... no authentication?

Without getting into a debate of whether or not it's a good idea for an inexpert person to be configuring nginx, GUIs can alleviate the need to remember specific terms or syntax, and guide the user through the process in general.

If i have to edit text wither way, what's the point of UI?

It's just an extra thing to install, update, maintain and hack.

- better discoverbility of keywords

- less error prone

Yeah, it's a bit early for this to hit HN.

This appears to be a simple UI wrapper over the nginx CLI more than a config generator (like what DigitalOcean has). It's basically an assortment of text boxes for editing the config and then buttons for applying it.

There are also more feature rich control panels:

http://ajenti.org/

http://vestacp.com/

For some use cases, these can feel bloated, so I understand there could be room for a more minimalistic option.

This is certainly a good effort but I've yet to use a web ui to manage web server configs, especially these days when we're moving most of the configuration to code and version control. We usually deploy changes to a test server to test the changes and then move on to production.

Adding a UI doesn’t require you to take config out of your IaaC setup, it could Increase accessibility to logs, monitoring, security warnings, versioning, etc, that your IaaC might be strongly lacking. There are weaknesses to IaaC that a tool like this may supplement.

That’s true if the UI is a read-only dashboard. If the UI can affect behavior then you don’t have IaaC anymore.

Only if you have zero discipline.

People make mistakes. Relying on people to have perfect discipline and make no errors results in incidents in production.

I don't really understand how a tool that enables configuration changes outside of the version controlled loop can improve an IaaC setup. It gives you a shortcut that you may end up taking, making it easier than modifying by hand some configuration via an SSH connection.

Nice way to shoot yourself in the foot if you manage configs without version control

10 years young me would have liked having something like this. Nowadays any manual configuration is a big no-no. All my configuration parsing and building happen in the CI pipeline in an automated manner.

It can give beginners a place to start. Until you have that critical base of understanding it can seem very frustrating starting from scratch.

If you use this, you lose the ability to version control, which is the most important feature of text files.

I'm not against generating configuration, but that should not require an always-running instance.

I think version controlling configuration is important.

I don't understand why you think a GUI necessitates losing version control though, or why you think version control is a "feature" of text files.

If you need version control of always-running live-changing nginx configuration then you can run `nginx -T` to dump the parsed configuration to stdout. Just save that to version control.

"Containerization is now state of the art and therefore the application is delivered in a container."

I wouldn't say it is "state of the art". Solaris had containers in 2004/2005.

"State of the art" doesn't really indicate age. It just means that there's nothing better. I'd be interested in learning about anything that's better than containers.

state of the art /ˌstād ə(v) T͟Hə ˈärt/

phrase of state

the most recent stage in the development of a product, incorporating the newest ideas and the most up-to-date features.

incorporating the newest ideas and the most up-to-date features.

"a new state-of-the-art hospital"

newest =/= new

something can be quite old, but if nothing has replaced it, it's still "newest" and "most up-to-date"

Solaris had zones, which are similar to LXC or OpenVZ, which Linux had almost as long ago. But neither Solaris zones nor LXC/OpenVZ envisioned the sort of container in which this application is being delivered.

(The key insight here is that "containerization" in the modern sense is about norms/expectations/practices and an ecosystem of tooling around a particular design that's convenient for certain use cases; it's not about a technical facility in the OS.)

Delivering applications in chroot/jail had some momentum circa 2003. The tooling was on par with current docker if chosen wisely, but surely not on the level of vagrant/docker-compose/docker swarm/kubernetes.

Surprised nobody else has mentioned the irony of delivering this - a tool designed to help you hand-edit configuration on a pet server - in a container.

NginxProxyManager is the preferred choice in the Unraid (home server) community - good to have another contender to help nginx n00bs like myself.

Is there any security model for this? Or does having access effectively give you complete root control?

Presumably you can set the file root to anything you want.

Maybe do script injection by doing some fancy file loading? Not sure how much nginx config language allows.

Weird. Not sure why i would like to update/change a live config.

That would probably not mean that there is an Infrastructure code in git.

Well i have 1M+ users and still ssh into the VMs and live-change nginx configs. Once in a while the reload fails because i messed up something.

Always run `nginx -t` before reloading to test the new config.

And your solutio is to log into a VM through ssh instead of fixing it?

I don't mean this as offending but my personal action is to fix the underlying issue.

If you add more tests etc. you will have to do that less often until it doesn't is the norm anymore.

I have over 100k uniques daily, 7 servers and I also change nginx config manually via ssh.

But why?

Even if you don't use kubernetes or docker images, you do wanna have it in code right?

Having something like ansible would do the same thing but allows you to have your config backuped by git and allows you to recreate the env without any issues.

How do you keep your mean time to recovery low? How do you document your setup? How do you automated tests if you change your config manual?

Why not?

I have done this for 10+ years and it's still working flawlessly, I don't see a reason to add more complexity to something that is working fine for my needs. I don't have to change config often, maybe once a year or so.

" I don't see a reason to add more complexity to something that is working fine for my needs" valid point though.

I would do it due to: - keeping 'meantime to recovery' low due to having my configs in git -> fast recovery - using something like ansible for your small case to have it in git (instead of a shellscript) -> backup - perhaps a jenkins pipeline with testing the config before applying it automatically -> for quality - automatisation for having fun with it, seeing what is out there besides ssh and manuel editing

At the end of the day, i assume that this automatisated process is also less dependend from myself. So i'm not sure who is doing things when you are on holiday or sick.

I'm now having a small k8s cluster at home. I have never had anything which allows me to have my whole setup in git so easy with autohealing, domain management and high availability.

Their user case seems a bit weird to me. If a new application is deployed, can you not make changes to the nginx config locally and redeploy it? That way everyone has access and it'll be part of the usual merge request -> review -> merge flow.

If anything this tool makes editing easier and may lead to more misconfiguration.

IMHO, I might as well just use Vim. Maybe this has a use case, it's not for me. I literally need to type just one line and and press enter:

    sudo vi /etc/nginx/...

Generally speaking, a UI DOES have a use case - when you can't be bothered to learn the configuration language and its keys / values / nuances. The UI can help you create a sane and safe config, instead of having to scour the internet for - potentially outdated - information.

Mind you, I've had more trouble with that with Apache given how they changed their config files around on multiple occasions.

I'd argue that if you are neither willing nor able to learn nginx's config file format, you should not be configuring nginx. The default config has example blocks with comments anyway. If that's not enough, nginx maintains current documentation. But if you're configuring a web server (or anything, for that matter), you should take some time to learn how to configure it.

This. I never understood the "every idiot can do it gui server" thing, just because everybody can doesn't mean everybody should.

Have we already forgotten how Microsoft Exchange singlehandedly launched an entire spam industry?

Neat! Felt a little nostalgic seeing reading the title as it was a somewhat big emphasis as the "next thing to do" when I was part of the NGINX Amplify team.

In case you didn't know, the configuration parsing library we created for the NGINX Amplify agent is open source under Apache 2.0:

https://github.com/nginxinc/crossplane (credit to @aluttik who was the primary author)

It parses an NGINX configuration files into JSON and vice-versa.

From what i gather, this is a Deployment & editor software for nginx specifically. At work I've setup a pipeline using Azure Devops (also done it with Gitlab) that achieves the same thing. And I'm guessing it can be done with the other popular build & deploy tools such as Jenkins and . So i wonder, who is this for?

I'd rather track it in the repo and let the pipeline deploy it. No need to modify it by hand.

I just loved it, docker is a good choice but I would've love to have non-docker version as well.

Well, the Dockerfile says exactly how to start the software and how to install all the packages etc. locally, so why not use that? :)

What is wrong with the current config via CLI?

Edit file, reload... Voilà

how many cooks does one need in the kitchen, to continuously re-configure a single nginx server? His described use case seems like a strange setup.

And you'd think there'd be some automated pipeline that would deploy and reload nginx configs. That would be usable by all environments, from lab to prod, and would go through code review. A UI anyone can just go in and switch stuff for prod seems like a weird solution to the use case.

Nonetheless they had a problem, they fixed it and they shared the solution when they could've just kept it.

Reply on news.ycombinator.com