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
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.
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.
Peter N. M. Hansteen's PF tutorial and books are recommended reads, Peter remains involved with the developers and the information stays relevant and useful. He also ensures that readers using other BSD systems, especially with older versions of pf, can learn just as much from it.
* The Book of PF, 3rd Edition, 2014 - ISBN: 978-1593275891
* http://home.nuug.no/~peter/pf/
Michael W Lucas is another author that writes books for both the BSD and sysadmin communities, similarly, he works closely with developers and users to release these short, yet all-encompassing tomes of information, covering a wide variety of topics.
https://www.michaelwlucas.com/...
* Absolute OpenBSD, 2nd Edition, 2013 - ISBN: 978-1593274764
* SSH Mastery, 2012 - ISBN: 978-1470069711
* Sudo Master, 2013 - ISBN: 978-1493626205
And of course, official documentation is great. The effort of many people working to improve, Jason McIntyre improving readability and overall quality, Ingo Schwarze's amazing work on mandoc(1) tools. OpenBSD's FAQ, which is usually the first step people take to learn more about the system, is maintained by Nick Holland.
http://www.openbsd.org/faq/
http://www.openbsd.org/cgi-bin...
Another option is the grandaddy of all the BSD based appliances, m0n0wall. It is still very lean and very solid.
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
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.
I'm in a similar boat. I recently (a few months ago) migrated from Gentoo to FreeBSD.
The problem with systemd, and probably why so many people are running from it, is that it's not as simple as just not using systemd, or even not using a distro with systemd as a default.
A lot of packages are gaining direct or indirect dependencies on systemd, and it is becoming a huge pain to run a systemd free system. I found myself having to use portage's blacklist for the first time because simply specifying -systemd as a use flag wasn't enough. I also had to uninstall a bunch of packages and fix the associated breakage. I don't use gnome, but enough gnome packages ended up installed as dependencies of various things that it was a real headache. Slackware has straight up dropped gnome because it's too hard to have it without systemd. And of course you have systemd as an indirect requirement for gimp. Yes friends, when a graphics editing tool depends on a specific init system, it's time to get the hell out of there!
Systemd isn't the only factor, but it's certainly a major one and I think it's pushing a lot of people (like myself) who have kinda been disillusioned with Linux for some time over the edge. At some point mainstream adoption became the big goal, and this mindset where it was better to have a less flexible but easier to use system started destroying a lot of what drew us to Linux in the first place. Linux is basically morphing into a more open version of Windows for the sake of mass appeal, which may be great for humanity, but it's not why I got interested in Linux.