As for all the license discussions, I just don’t want a company to pack my work and sell it as a commercial device or service. I’m open for a better license which covers that.

Unbound did not have this (nor any service I know) and you need extra care to handle your local devices registration

The fact that dnsmasq is the only service I know that manages dhcp records on dns makes me wonder if I am not doing something wrong.

Anyway, regardless, you can use dnsmasq with Unbound.

could you elaborate on that? How is the connection done?

You run an unbound server with a static IP, and point dnsmasq to said static IP.

OPs setup has this configured through Pi-hole. Look at the docker-compose file.

Edit: I just remembered Pi-hole has an official guide for this: https://docs.pi-hole.net/guides/dns/unbound/

You could also consider using zeroconf/avahi if you can. You don't even need a DHCP server for it (although you won't be able to connect to the internet etc).

It would be nice to add a note that this uses non-free software like wg-easy, though.

I'm not sure what exact issue you are having, but if you are trying to resolve mDNS .local across internal networks then you need to look up mDNS reflection. If you are trying to use .local for your own DNS records then pick something else (ideally using an actual registered TLD, so e.g. if you own foo.com then you could use lan.foo.com for your internal records).

Worked fine on windows but all the Apple devices in the house had a conniption when trying to connect. I ended up just using my personal domain replacing .local. Am currently investigating a wildecard DNS SSL cert to get HTTPS working on the LAN, but that's more out of curiosity than anything else

This is not always true as it’s a feature of the specific router and not part of the spec. To be fair, it’s a feature that’s now fairly common because of how handy it is.

Additionally; many flavours and types of operating systems transparently handle local discovery and resolution just not all of them.

For anyone looking to test this, open a terminal and ping the short domain. In the response it will show what domain it actually used. In my case ‘ping proxmox’ shows ‘proxmox..com’.

This is entirely pedantic but I think interesting if you have a mind for optimizing: The discovery/search does introduce some delay.

[0] https://www.icann.org/resources/board-material/resolutions-2...

https://datatracker.ietf.org/doc/html/rfc8375

You can add .home.arpa to you DNS search path (configurable with DHCP) so you don't have to type it, e.g. if you look up "nas" your computer will try "nas.home.arpa" too.

josephcsibleinternaldomain.com as a spitball

Hell to the no. They should have camped on less valuable real estate if they wanted it exclusively. I use .local for every host on my local network and I will never stop.

In debian 12 I just change this:

hosts: files resolve [!UNAVAIL=return] dns

to this:

hosts: files dns resolve [!UNAVAIL=return]

in /etc/nsswitch.conf, and everything acts just fine.

> ideally using an actual registered TLD

wat

Why do you even care what your local domain is? Set your search path correctly and you never even type it. .home.arpa is arguably a better choice anyway.

Definitely not an OSI approved license, but does look like they made an attempt in the spirit of GPL, no?

https://github.com/wg-easy/wg-easy/blob/master/LICENSE.md

> You may:

> - Use this software for yourself;

> - Use this software for a company;

> - Modify this software, as long as you:

> * Publish the changes on GitHub as an open-source & linked fork;

> * Don't remove any links to the original project or donation pages;

> You may not:

> - Use this software in a commercial product without a license from the original author;

I leaned not to attribute to malice what can be attributed to incompetence.

I believe you're also thoroughly misunderstanding the license terms that are present. The license says that you can utilize it for a commercial settings and in a commercial environment you just cannot resell the product.

This means that an Enterprise can openly use it within their Enterprise they just cannot sell it as a service that they offer.

While this is not the license that I would have chosen for a Greenfield project but at the moment I am at the mercy of the licenses in place for the projects that I am using. Once I replace the UI with a proprietary one everything will be fully open source the way it's intended

As an academic/non-profit researcher who frequently works through my personal devices, I presumably can't use wg-easy in any workplace setting, but presumably can't legally use your software at all.

> Once I replace the UI with a proprietary one everything will be fully open source the way it's intended

Huh? Proprietary is basically the opposite of open source.

It might not be ideal or my choice but the alternative of no choice at all would probably be more concerning.

“docker pull”, deploy, and one can move on to the next whatever. You can deploy this to a Synology NAS, a Raspberry Pi, or Heroku with a few clicks (or even an appropriately configured router that supports containers if you’re not running something providing this functionality natively).

(DevOps/infra monkey before moving to infosec, embrace the container concept)

Provided you already turned off everything that can interfere with this stuff, including IPv6, any security like SELinux, grsecurity and friends, and you let it administer your netfilter firewall for you. Don't forget to check if you accidentally exposed some redis instance to the public Internet.

(And yes, I have embraced the concept and work daily with similar things, albeit in a larger scale. Let's just not kid ourselves it's easier than it is though. Just because an out of the box deploy goes sideways doesn't mean you are dumb.)

Not quite. My point was that the complexity of Docker is, in many cases, worth it because it hides a lot of the complexity of running software. Yes, you trade one problem for another, but the nice thing about Docker is, if you really go all in on it, the knowledge of how to use it transfers to pretty much any software you want to run.

For example, I wanted to run a JVM-based service the other day. Having never done this before, spinning it up with Docker took two minutes—I didn't have to figure out JDK vs runtime, which version I needed to install, etc. And yet, if I want to configure it past the defaults in the future, the image exposes several environment variables that make it easy.

No worries, just specify the previous version in my launch script, literally changing a couple of digits, and I'm back up and running in seconds.

I'm sure I could get it done using apt, but it was literally changing some numbers in a script and rerunning it.

As someone who just wants things to work, Docker has made things significantly better.

Makes trying new stuff a way less troublesome.

Give me raw source code or binaries and a configuration file in /etc or $HOME any day of the week.

If running an OS that supports docker...

I much prefer this over the old method of canned deployment where you ran a script and prayed it didn’t hose the host too badly.

My view is this:

There is a myriad of amazing toolage out there that the everyday person could greatly benefit from in their day-to-day life. A lot of that has a very high barrier to entry for technical knowledge. By simplifying this setup down to a simple Docker compose file I believe that I have allowed the lay person to play and experiment in the freedom of their own home with technology they may have otherwise been eyeing.

but the whole project here is to wrap up a bunch of other projects in a way that makes them easy to install and configure with minimal fuss. docker is perfect for that. if you want to be fussy and complain about the tools other people choose, then projects like this probably aren't much interest to you.

Earnestly interested in your take.

Yeah, you can easily pull and run things but you have no idea how or what it does and when things break whole idea is pull it again and run.

I have nothing against containers.. real system ones (LXC for example)

The concept of separating runtime (X or Y) from data storage is not unique to containers; it's a best practice in software design called separation of concerns. This separation makes applications more modular, easier to scale, and allows for better resource optimization.

The "pull it again and run" mentality is a simplification. While containers do promote immutability, where if something goes wrong you can restart from a known good state, it's not the only way to troubleshoot issues. The idea is to have a consistent environment, but it doesn't prevent you from debugging or understanding the internals.

Lastly, while there are differences between application containers (like Docker) and system containers (like LXC), they both leverage Linux kernel features to provide isolation. It's more about the use case and preference than one being "real" and the other not.

And by default logs are stored in a json format in a single file per container, grepping `docker logs` feels slower than grepping a file. And the option to read logs for n last hours is incredibly slow -- I think it reads file from the beginning until it reaches the desired timestamp

I've recently come across a talk related to running openstack in kubernetes. Which sounded like a crazy idea, openstack needs to do all kinds of things not allowed by default for containers, e.g. create network interfaces and insert kernel modules. But people still did it for some reason -- on of them was that it's easier to find someone with k8 experience than with openstack one. And they liked the self-healing properties of k8.

I don't know what the bottom line is

I’m by no means a docker evangelist, but it does work and it simplifies deployment and management quite a bit.

It's crazy to me that people push it so much given this issue, aren't VPNs even more common in corporate settings, especially with remote work nowadays?

I find it easier to just spin up a full VM than deal with docker's sensitivities, and it feels a bit ridiculous to run a VM and then setup docker within it instead of just having appropriate VM images.

While I can see it does at times make it more difficult to do certain things with the proper permissions, know how and set up there is nothing it cannot do.

I tried running a docker based setup for a year on my homeserver, thinking that using it for some time would help me get over my instinctive revulsion towards software that makes Docker the only way to use it, the way that forcing myself to use Python had helped me get over disdain for it back during the early days of the transition from 2 to 3. Didn't help at all, it was still a pita to rely on. Went back to proper installs, couldn't be happier.

Docker took off because there is no Linux. There are 50 different slightly incompatible OSes. So the best way to distribute software is to basically tar up the entire filesystem and distribute that. Dependency management has failed because there’s just too much sprawl.

One illustrative example: OpenSSL has divergent naming and versioning schemes across different versions of distributions that use the same Debian package manager. So you either build your packages at least four or five times, Dockerize, or statically link OpenSSL. That’s just for dpkg based distros too! Then there is RPM, APK, and several others I can’t recall right now.

BTW Windows has a bit of the same disease and being from one company has a lot less of an excuse. OS standardization and dependency standardization is very hard to get right, especially at scale.

Apple macOS is the only OS you can ship software for without statically linking or bundling everything and be reasonably sure it will work… as long as you are not going back more than two or three versions.

Yes, a dpkg is built for a distribution, and not only that but a specific version of a distribution. So they tend to get re-built a lot. But this is something buildhosts do. What you upload is the package source.

If you want to distribute a package to work on "Linux" in general, then you can't build it for a specific distribution. Then you bundle all the shared libraries and other dependencies. (Or make a static build, but for various reasons this is less common.) Do not try to rely on the naming scheme of openssl, or anything else really. This is what most games do, and the firefox tarball, and most other commercical software for Linux.

There are of course downsides to this. You have to build a new package if your openssl has a security issue, for example. But that's how most software is distributed on most other operating systems, including Windows. This is also how Docker images are built.

The alternative is to build packages for a specific distribution and release, and as stated above, that takes a bit of integration work.

There are issues with both alternatives, but they should not be confused.

That's not an accurate description of the main motivation for Docker. It's a nice secondary benefit, sure.

It was to solve the age old "it runs on my machine".

Open to being wrong but when docker hit the scene I remember that being touted left and right.

At a certain point you need to start defining the environment regardless of OS, and docker works as a tool that handles environment definition for literally any program (same thing works for ruby, java, python, etc). It handles more complex environment definition than packages, but is lighter than a VM. It's a middle ground, which is a great compromise for some cases and not for others.

Varying use cases and lots of flexibility is also the reason why linux is never going to just standardize the ecosystem and say "ok, there is only 1 openSSL package now." Some people see the ability to have a version of linux that is completely bonkers in versioning as a strength, akin to how some places have old windows 95 computers they still run because newer versions don't work properly. On linux, you could have old 1995 packages from a specific app, but the rest modern secure packages.

But the main use case was probably convenience. It's a very quick way for Mac and Windows users to get a small Linux VM up and running, and utilize the copious amount of software written for it.

These days it's mostly standard, for better or worse. There are a handful vendor independent ways to distribute software but this works with most cloud vendors. Is it good? Probably not, but few industry standards are.

Maybe, but that will never happen because the ecosystem got here by being open enough that people could be dissatisfied with existing stuff and make their own thing, and to a remarkable degree things are intercompatible. It's always been like this; just because there are 20 people working on distro A and 20 people working on distro B doesn't mean combining them would get 40 people working on distro AB. (In practice, attempting it would probably result in the creation of distros C-F as dissidents forked off.)

> Docker took off because there is no Linux. There are 50 different slightly incompatible OSes. So the best way to distribute software is to basically tar up the entire filesystem and distribute that. Dependency management has failed because there’s just too much sprawl.

I think I agree with you; part of the problem is that people treat "Linux" as an OS, when it's a piece that's used by many OSs that appear similar in some ways.

> Apple macOS is the only OS you can ship software for without statically linking or bundling everything and be reasonably sure it will work… as long as you are not going back more than two or three versions.

...but then by the same exact logic as the previous point, I think this falls apart; macOS isn't the only OS you can target as a stable system. In fact, I would argue that there are a lot of OSs where you can target version N and have your software work on N+1, N+2, and likely even more extreme removes. Last I looked, for example, Google's GCP SDK shipped a .deb that was built against Ubuntu 16.04 specifically because that let them build a single package that worked on everything from that version forward. I have personally transplanted programs from RHEL 5 to (CentOS) 7 and they just worked. Within a single OS, this is perfectly doable.

Over http? Pretty YOLO...

Otherwise anyone connected to WiFi can snoop on traffic.

Unfortunately my router, switches, AP and NAS don't support HTTPS either :'(

But of course, good security practices is never bad and using https whenever you can is always good.

No good reason, either. What is needed for support is already in place.