Generally speaking, any device (“server”) hosting a “service” NEEDS to be assigned a static IP. It simplifies routing significantly and avoids random break problems because DHCP is incredibly stupid at times…
Is there any specific reason you need DHCP to assign an IP to your main hosting server vs setting it all statically?
Moving it to it’s own system will not fix the routing problem. You can probably still leave it on the USG.
You should be able to set a fixed static IP on your server, and then also statically assign that same IP to your server in your USG DHCP config- as long as they both are “thinking about” the same IP I think routing should work correctly.
If that breaks, try just assigning the static IP only from the USG side or only from the server’s side. I’m 90% sure that even if the USG does not have your server machine in it’s client list, if it sends broadcast packets to an entered IP looking for the unifi server, and the unifi server is listening on that manually set IP, they should be able to talk.
disclaimer: i am high as shit right now and this may be bullshit
Is there any specific reason you need DHCP to assign an IP to your main hosting server vs setting it all statically?
I’ve done this. I think the real problem is if I ever change the server MAC or IP, as now the unifi server isn’t picked up by the USG, which means I can’t change the static address.
Unifi is specific about expecting the controller address to not change. You have several options: There’s the “override controller address” setting, which you can use to point the devices at a dns name, instead of an ip address. The dns can then track your controller. It doesn’t exactly solve your issue, though, as USG doesn’t assign dns names to dynamic allocations.
Another option is to give the controller a static IP allocation. This way, in case you reboot everything, USG will come up with the latest good config, then will (eventually) allocate the IP for controller, and adopt itself.
Finally, the most bulletproof option is to just have a static IP address on the controller. It’s a special case, so it’s reasonable to do so. Just like you can only send NetFlow to a specific address and have to keep your collector in one place, basically.
I’d advise against moving dhcp and dns off unifi unless you have a better reason to do so, because then you lose a good chunk of what unifi provides in terms of the network management. USG is surprisingly robust in that regard (unlike UDMs), and can even run a nextdns forwarding resolver locally.
So this is where I’m a little confused. The USG had the option to assign a static IP (which I’ve done), but if you ever need to CHANGE that IP… Chaos. From what I understand the USG needs to propagate that IP to all your devices, but it uses the controller to do that. Then you also run into issues with IP leases having to time out. Same problem occurs if I ever upgrade my server and change out the MAC address. Because now the IP is assigned to the old MAC.
I’m not sure if there’s any way around this. But it basically locks me in to keeping the controller (and thus my server) at a single, fixed IP, without any chance of changing it.
Here’s how it works: unifi devices need to communicate with the controller over tcp/8080 to maintain their provisioned state. By default, the controller adopts the device with http://controller-ip:8080/inform, which means that if you ever change the controller IP, you’ll must adopt your devices again.
There are several other ways to adopt the device, most notably using the DHCP option 43 and using DNS. Of those, setting up DNS is generally easier. You’d provision the DNS to point at your controller and then update the inform address on all your devices (including the USG).
Now, there’s still a problem of keeping your controller IP and DNS address in sync. Unifi, generally, doesn’t do DNS names for its DHCP leases, and devices can’t use mDNS, so you’ll have to figure a solution for that. Or, you can just cut it short and make sure the controller has a static IP―not a static DHCP lease, but literally, a static address. It allows your controller to function autonomously from USG, as long as your devices don’t reach to it across VLANs.
DHCP is a really stupid* service for the most part. Unless you are working with multiple subnets or have some very specific settings you need to pass to your clients, it’s probably not worth it to manage it yourself. I don’t want to discourage you though! Assigning static IP addresses by MAC can be extremely useful and is not always an option on routers. If you want static names and dynamic addresses, that is really where you need to manage both DNS and DHCP. It really depends on how and where you want names to be resolved and what you are trying to accomplish. (*stupid as in, it’s a really simple service. You want it simple because when DHCP breaks, you have other serious issues going on.)
Setting up your own DNS is worth its weight in gold. You can put it just about anywhere on your network (before your gateway, after, in China, whatever.) and your network won’t even know the difference if setup correctly. You can point BIND at the root servers and bypass your ISP completely if you want. ISP DNS services suck ass, so regardless of you resolve yourself, or forward all name queries to your anon DNS server of choice you have a really decent level of control on your network. It is the service to learn if you want to keep an eye on where your network wants to talk.
Your Unifi USG must play nice with your own server, by the laws of DNS. There may be some nuances when it comes to internal protocols like WINS, but other than that, it should be just fine.
I would setup a simple VM somewhere first, to answer your actual question. It’s good practice to keep core services isolated on their own, dedicated instances. This is to speed up recovery time and minimize down time. Even on your home network, DNS and DHCP are services you do not want going down. It’s always a pain when they do go down.
If only everyone was on IPv6, then everything could use SLAAC and worrying about IP assignment for client systems would be a thing of the past. IPv6 on a home LAN generally only uses DHCPv6 for configuring the DNS servers - client systems get IPs using SLAAC and learn their gateway using RAs (router advertisements).
Damn, I didn’t realize the amount of hate for DHCP. Ive used an already configured system with a DHCP/DNS server set up and it was super easy to manage. Want to change or add a static IP? Edit the text file, add the MAC, reload.
I didn’t know this wasn’t reflective of the overall experience.
Meh, I didn’t mean to hate on DHCP. It’s just a service I have learned to keep running all by itself somewhere in a dark corner of my network. DNS and DHCP are just services that I don’t like going down. Ever.
Because if you use relative bind mounts you can move a whole docker compose set of contaibera to a new host with docker compose stop then rsync it over then docker compose up -d.
It depends what I’m backing up and where it’s backing up to.
I do local/lan backups at a much higher rate because there’s more bandwidth to spare and effectively free storage. So for those as often as every 10 mins if there are changes to back up.
For less critical things and/or cloud backups I have a less frequent schedule as losing more time on those is less critical and it costs more to store on the cloud.
I use Kopia for backups on all my servers and desktop/laptop.
I’ve been very happy with it, it’s FOSS and it saved my ass when Windows Update corrupted my bitlocker disk and I lost everything. That was also the last straw that put me on Linux full-time.
Docker is a messy and not ideal but it was born out of a necessity, getting multiple services to coexist together outside of a container can be a nightmare, updating and moving configuration is a nightmare and removing things can leave stuff behind which gets messier and messier over time. Docker just standardises most of the configuration whilst requiring minimal effort from the developer
Also the ability to snapshot an image, goof around with changes, and if you don’t like them restore the snapshot makes it much easier to experiment than trying to unwind all the changes you make.
I had a lot of freezing when I was using immich on my RPi4. May be due to ram constraints. I moved to a 7 8 year old PC that I had lying around. It’s less finicky than a Pi4.
Thanks, HP it will be. When comparing Intel gens, there isn’t a massive difference between 4th and 8th gen, except the openvino detection which only works on 8th. But I can get a 4th gen for 25% of the price of a 8th gen.
I’d also highly recommend the proper PC, Immich can get pretty RAM-hungry if you use the ML functions, for me that has actually caused crashes before. Granted, that was while importing roughly 20k Assets (200GB) from a Google photos takeout, but it’s still probably better to be prepared.
Thanks for the insights. I’m planning to import about 1.2Tb of photos… So RAM is most important? What about Intel gen? I’ve compared 4th and 8th gen in terms of cpu speed and 4th still scores well. Depends of course on exact cpu. 4th gen can be bought here for about a 5th of the price of an 8th…
I’m a network guy, so everything in my labs use SNMP because it works with everything. Things that don’t support SNMP are usually replaced and yeeted off the nearest bridge.
For that I use librenms. Simple, open source, and I find it easy to use, for the most part. I put it on a different system than what I’m monitoring because if it shares fate with everything else, it’s not going to be very useful or give me any alerts if there’s a full outage of my main homelab cluster.
Of course, access from the internet to it, is forbidden, and any SNMP is filtered by my firewall. Nothing really gets through for it, so I’m unconcerned about it becoming a target. For the rest of my systems security is mostly reliant on a small set of reverse proxies and firewall rules to keep everything secure.
I use a couple of VPN systems to access the servers remotely, all running on odd ports (if they need port forwards at all). I have multiple to provide redundancy to my remote access, so if one VPN isn’t working due to a crash or something, I have others that should get me some measure of access.
selfhosted
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.