Slashdot Mirror
Ask Slashdot: Migrating a Router From Linux To *BSD?
An anonymous reader writes I'm in the camp that doesn't trust systemd. You can discuss the technical merits of all init solutions all you want, but if I wanted to run Windows NT I'd run Windows NT, not Linux. So I've decided to migrate my homebrew router/firewall/samba server to one of the BSDs. Question one is: which BSD? Question two: where's some good documentation regarding setting up a home router/firewall on your favorite BSD?
It's fine if the documentation is highly technical, I've written linux kernel drivers before :) (Got a question? You can Ask Slashdot, too.)
It's fine if the documentation is highly technical, I've written linux kernel drivers before :) (Got a question? You can Ask Slashdot, too.)
subject says it all.
runs from very small disk (I use a 4gb m-sata ssd) and has a great ui, is a superb firewall and is bsd based. used to be the old openwall code.
--
"It is now safe to switch off your computer."
http://www.bsdnow.tv/tutorials/openbsd-router
He said he's written drivers. He didn't say they compiled or worked.
The three distros in the Subject line do not use systemd, though Gentoo does offer it. They may well be the dig-in-the-heels distros that will stay that way, driven by people like you. Moving to one of those distros is a smaller/easier move for you, and doesn't preclude moving to a BSD in the future.
Years back I thought about moving my server to OpenBSD, based on reputation. However after some thinking I realized that potentially the safest server is the one you know best how to administer. I was probably better off knowing how to administer Linux well across my home cluster than to divide my efforts. I know OpenBSD is supposed to be "secure by default", but don't know how I might accidentally mess that up by mis-applying Linux knowledge to it.
The living have better things to do than to continue hating the dead.
1) Don't run your fileserver on your router/firewall. You're asking for problems.
2) Not all Linuxes run Systemd (Yay Slackware). I have nothing against the BSDs and they are probably better for networking anyway.
Personally I have Tomato on my firewall/router and use Slackware for my server needs. Serves me pretty well.
The comparison to Windows NT is because systemd insists on binary logs, takes over vast chunks of functionality that it has no business touching, and makes it basically impossible to debug problems. It makes the experience of administering the server much more like administering Windows than administering Linux should be.
Aside from pFsense, another great alternative is TrueOS.
Like BSD, Gentoo is a source-based. So, if you're familiar with Linux, you might find Gentoo a sort of gentle introduction to a more BSD-like distro.
I've been using Gentoo for a while, and it has done what I expected most distros to do: It offers two init systems: OpenRC (the default), and systemd. OpenRC is actually Gentoo's own. It's sysvinit-like, with a few nice enhancements. If you're familiar with Sysvinit, you don't find it hard to switch: OpenRC is lightweight, and converting a syvinit-style startup script to an OpenRC one usually requires only a few modifications. OpenRC it lets you specify dependencies and runlevels by name, rather than having to manage a bunch of symlinks and numbers by hand.
Gentoo is not as user-friendly as, say, Ubuntu. There's no GUI installer. Instead, the Gentoo Handbook walks you through how to partition and format your disk, etc. I initially picked Gentoo because I wanted to learn more about Linux. Whenever I've gotten stuck, I have also found the online Gentoo community (wiki, forums,etc.) to be quite friendly and helpful.
Another option is the grandaddy of all the BSD based appliances, m0n0wall. It is still very lean and very solid.
IMO the comparison comes about because the philosophies of the two (systemd and windows) are more related to one another than they are to Unix. Unix favors a collection of interacting tools that each do something (ideally, doing that something well). Windows is a giant monolithic shroud covering a multitude of interacting moving parts that you can't see, touch, or understand unless you spend the necessary years becoming an insider. Systemd seems to be leaning in that direction, hence the comparison. It's a big collection of "stuff" that refuses to be broken up into component functional bits.
It certainly doesn't help that the systemd authors seem to think so highly of themselves, that I feel no need to add to their aggrandizement by thinking highly of them myself.
I'm the original AC who asked the question. Or someone pretending to be him, you have no way of knowing.
1. Not trusting systemd.
Because it can't be troubleshooted if all you have is something to read text files with. When all you have is a single user shell, for example. Or you've put the hard drive in a different system, which is whatever you had on hand and could even be Windows with an ext3 plugin.
Because it comes from the author of PulseAudio, who is world renowned for the stability of his products. And low CPU consumption, when they work.
Because it contradicts the Unix philosophy of having a lot of little utilities that each do one thing. It may not be a big deal for a full time sysadmin, but if your main job isn't that it's a lot easier to just read about the small parts that interest you and disable the rest.
2. If he can write Linux kernel drivers, why does he need to ask Slashdot, or why doesn't he google it?
Because I don't know anything about BSD, and I'm not looking for "learn BSD in 10 easy mouse clicks". Although the signal to noise ratio on here sometimes approaches zero, there is the occasional informed opinion, and with a bit of luck, there will be some pointer to some actual pertinent information.
3. Use pfSense
If i use pfSense I won't learn anything. I've installed it before, it took about zero BSD knowledge. Also, I want the file serving part, see 4.
4. Move your Samba server to another machine for security reasons.
The router doesn't have any important files on it. It has the usual torrents, and it runs a private http server. I update the http server's pages through samba because it's the most convenient. It's not worth running this on a separate machine as there's nothing on there that I can't afford to lose. The real data is on other machines, and backed up properly.
Looking forward to the next batch of flame posts now :)
systemd insists on binary logs
My understanding is that SystemD makes binary logs for its own purposes, and that the binary features include indexes so it can very quickly answer queries like "what were the last ten things logged by Apache?"
However, SystemD permits continuing to run a time-tested conventional log daemon. The current recommended way to get network logging is to run rsyslog.
Some hard-core SystemD haters are still not happy, because the log events flow through SystemD on their way to the conventional log daemon.[1]
takes over vast chunks of functionality that it has no business touching
I'm not certain this really is the case. SystemD is a collection of services, and each one has a specific area of concern. The actual technical analyses I have read suggest that the basic design of SystemD is sound, and that it is doing things that people want to be done. For example, SystemD allows the graphics system (X.org) to run as a non-root user.
One criticism of SystemD that may have some validity: that the only documentation is whatever the source code contains this week. SystemD is being developed at a rapid pace and documentation may be suffering. This is one reason I am glad for projects like UselessD... they will force the SystemD interface to settle down a bit and be documented a bit better.
But I'll say it again: from what I have read (in technical analyses) the basic design of SystemD seems to be sound. The Debian technical committee that evaluated the situation concluded that SystemD was the best choice for Debian. (Then the politics blew up but that's another story.) Do you think that the Debian technical committee spent months evaluating SystemD and were just wrong about it? (That's not to say that SystemD is perfect. But something can be imperfect and still be the best choice for the future.)
makes it basically impossible to debug problems
I will not comment on this because I have no experience with SystemD yet. I have seen comments like this multiple times.
Perhaps, even if SystemD is the future, it should be adopted slowly and carefully in the present. Debian "jessie" has SystemD as optional which seems like a very good thing to me.
[1] I think that's probably an overreaction... if Red Hat can't get SystemD to reliably pass through log events, that would imply a level of brokenness that would preclude the widespread adoption that seems to be taking place.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I don't understand the blatent systemd pushing. Reasons for disliking it vary but don't really matter, because its adoption will force a *lot* of people who don't want it to either suffer through it or suffer through migration to another OS. That is reason enough not to adopt it. Trying to discredit people's reasons for disliking it is presumptuous, pointless, and rather stupid.
Below is a great explanation as to why systemd is like windows.
From "SystemD Abomination"
Subject Vested interest in control. RedHat and SystemD
Date Mon, 17 Nov 2014 04:40:08 +0100
by beaverdownunder:
It should be obvious to anyone that RedHat has a vested interest in making the vast majority of Linux distributions dependent on technology it controls. Linux is its bread-and-butter.
It appears RedHat has realised that, through systemd, it can readily provide preferential support for its own projects, and place roadblocks up for projects it does not control, thus extending its influence broadly and quickly. By using tenuous dependencies amongst its own projects it can speed adoption even faster.
Once it has significant influence, and the maintainers of competing projects have drifted away either out of frustration or because they are starved of oxygen, RedHat knows that they can effectively take Linux closed-source by restricting access to documentation and fighting changes that are not in their own best interests.
At this point, they can market themselves as the only rational choice for corporate Linux support -- and this would be perfectly reasonable because they would have effective control of the ecosystem.
Linux (as in a full OS implementation) is an extremely complex beast and you can't just "fork it" and start your own 'distro' from scratch anymore -- you would have to leverage a small army to do it, then keep that army to maintain it. It's just not practical.
At the same time, Linux has matured to the point of attaining some measure of corporate credibility, and from RedHat's point of view, it no longer needs its 'open source' roots to remain viable. RedHat also, understandably, fears potential competition.
Through systemd and subsequent takeovers of other ecosystem components, RedHat can leverage its own position while stifling potential competition -- this is a best-case scenario for any corporation. It will have an advantage in the marketplace, potential customers will recognize that advantage, and buy its products and support contracts.
I hope you can understand why many see this as an extremely compelling case. Arguing that RedHat has 'ethics' and would 'never do such a thing' is immature and silly -- RedHat is a corporation, it exists to profit from its opportunities, just like any other company. To attempt to argue that it would not do so is contrary to what we can assume is its default state.
It's no 'conspiracy theory' to assume that a corporation will behave like a corporation; arguing that it is just makes one look like a naive child. systemd is one large step toward RedHat gaining the ability to reap what it has sewn -- for its benefit and not necessarily ours.