| ▲ | freetime2 3 days ago | ||||||||||||||||
> I'd rather be running a Debian, with systemd, and boring regular utilities, than the bespoke environment openwrt has crafted together. I agree. I tried running OpenWrt as a wired router on an x86 mini PC, and found that it had some really powerful features and was certainly rock solid as a router. But there were some major annoyances, too. For example, their documentation includes a script for expanding the root filesystem [1] that left my system unable to boot. And while I didn't use it long enough to make it through an upgrade, their documentation on upgrades makes the process sound very brittle (it sounded like configs for installed packages don't carry over by default) and confusing. I thought about trying to set up an Ubuntu (or other popular distro) box as a router, which I think would be much easier to maintain over time. But my concern is that I might overlook some important config that is set by default in OpenWrt, and leave my machine vulnerable to attack. Having a web UI that I can log into and view/make config changes is also kind of nice. Are there any good out-of-the-box solutions or guides for doing this? (I know that OPNSense/PFSense are really popular among homelab users, but unfortunately the Marvell NICs in my mini PC are not supported in FreeBSD). [1] https://openwrt.org/docs/guide-user/installation/openwrt_x86... | |||||||||||||||||
| ▲ | c0wb0yc0d3r 3 days ago | parent [-] | ||||||||||||||||
> I tried running OpenWrt as a wired router on an x86 mini PC, and found that it had some really powerful features and was certainly rock solid as a router. But there were some major annoyances, too. For example, their documentation includes a script for expanding the root filesystem [1] that left my system unable to boot. I have been doing this myself recently. The docs around this are pretty out of date. The docs as they’re written only work for the ext4 images if I remember correctly. I got it to work with the squashfs version, but it was really janky. The problem is the OS just writes the to the empty space at the end of the squash partition without changing the partition table. I could only successfully get it working if resized the partition on first boot before the writable overlay is created. > And while I didn't use it long enough to make it through an upgrade, their documentation on upgrades makes the process sound very brittle (it sounded like configs for installed packages don't carry over by default) and confusing. I feel similarly about the process. There is either a command or a place on disk where you can put files to protect them across upgrades, but I can’t remember just now. I think it works that way because it’s targeted at embedded devices where I would think you typically bake everything you need into the root file system at compile time. I’m not an embedded engineer so maybe there are better ways of doing it. | |||||||||||||||||
| |||||||||||||||||