Deemphasising FreeBSD?

[jgreco]

I think that's something that would go along very well with iocage. Having a base system is obviously useful, but minimizing the attack surface is always good.

One-size-fits-all solutions are more of a -fits-one thing, but even a write-up of the procedure for one of your examples would be very interesting. A lot of it would also translate over to Linux in concept, I imagine.

The devil is in the details. In theory, the procedure is approximately just

tar xvf somepackage.tar
cd somepackage
configure --prefix=/foojail
make install

but in practice, this just gets you part of the way. Each application has its own ins and outs, and there's dreary stuff like linkers and libc.

One of my primary goals has been to separate applications (the thing an OS is providing to the world) from the OS itself. This is basically a critical error that the major OS's make. If you want to set up a web server, SQL server, and DNS server on your FreeBSD host, classic strategy is that you install the packages and then twiddle with random files intermingled inside your OS. But ports has been ... ah ... "inconsistent" over the long haul, leaving systems with multiple configuration boogerfiles, and heaven help you if you run into a package that needs a newer OpenSSL major version and another package doesn't support it -- you get into the upgrade and things actually break. The smart thing is for each app to have its own SSL, and for that to have been validated to work. You can then separately update the apps.

And then there's the big one. Trying to figure out how a random Linux or FreeBSD box is doing its tricks, or what those tricks even are, can be an unpleasant experience. And let's not even talk about Apache with its nearly ten thousand lines of default configuration. How do you figure out what the differences between the default and the current configuration are, given that so many people hack on the default files?

So you compartmentalize that too. Compartmentalize all the Apache-carp over in /www/etc, where it wants to live, as part of the "defaults". But the actual webserver configuration for the thing being served is configured as an include, and lives over in /www/conf. That way the /www/etc stuff stays as untouched, and the deltas needed to make the webserver work are in /www/conf.

 

[diskdiddler]

"Top 10 reasons why sites write clickbait - Number 4 will SHOCK YOU!" seems like an accurate representation; controversy and arguments drive clicks.

One could make the same (poorly backed) argument that OpenZFS is "de-emphasizing Linux" by integrating with the FreeBSD stream. It's not a preference of one over another, it's becoming platform-agnostic, which is rarely if ever a bad thing.

And TrueNAS SCALE isn't going to target the same audience as the "storage-focused" TrueNAS; I don't see the former replacing the latter.

That is a little harsh, Serve The Home is definitely one of the better sites on the internet. Might be a slip up here, sure - but normally it's pretty great content.

 

[diskdiddler]

I'm happy about Linux support but aren't FreeBSD jails more secure than Docker containers? A few months ago I attempted using Docker for the first time, and I got all my containers working, but Kubernetes was super confusing to me. And it appeared Docker wasn't the best container solution, I saw podman being preferred, but there were less tutorials setting it up with Kubernetes. I just remember how frustrating it was recreating containers constantly getting testing the docker compose scripts I had. I could take a look at it again but I like the setup I have now with FreeNAS. I like how easy it is to manage the jails, and the security is a plus.

For mid skill users and lower, jails vs docker is no contest.
Docker is easier to use, more reliable, vastly more frequent updates and a massively huger library of software to work with.

I barely know what I'm doing and my Ubuntu VM (under FreeNAS) is running over 10 containers now, doing stuff and they get updated at most, within a week of the official package)

I found jails to be frankly, terrible. I suspect experienced FreeBSD and FreeNAS people to love them but docker support has really improved things for my purposes.

 

[danb35]

easier to use

Not that I've seen. Yes, there are lots of frontends that make it easier to use, but Docker itself doesn't seem any easier than iocage/FreeBSD.

more reliable

Really?

vastly more frequent updates and a massively huger library of software

This is nothing to do with Docker as such and all about the relative popularity of FreeBSD vs. Linux.

 

[ornias]

I learned to use, love and hate both to be honest.

I find docker compose including stack "workable", but I certainly don't like it.
I do however LOVE application containers, but indeed they often include unneeded crap and are not always up-to-date.

However, docker (by its design) gives me the certainty that (given the same config) an application is going to run like its developer designed it. Thats not always a good thing, but often is. Even if the developer didn't make the docker himself, there are often hunderds or thousands of users running precisely the same install, which makes it a lot easier to track down bugs.

Also things like integrated health checks are why I love to work with docker.
But: You still need to secure docker containers. period. (Putting behind things like a good auth proxy, limiting their access, seperate vlans, acl's etc)

To be fair: I haven't worked with kubernettes yet, but I will because I already reached some of the annoying bits of docker swarm-mode. So I understand why IX chooses k8s over swarmmode.

However:
I do prefer jails for custom setups that need to run rock solid. I find BSD in general to run a lot more solid for longer times than linux (containers).

 

[diskdiddler]

Not that I've seen. Yes, there are lots of frontends that make it easier to use, but Docker itself doesn't seem any easier than iocage/FreeBSD.

VASTLY easier, how you could even begin to debate this is beyond me.
I can figure this stuff out without needing to have a fundamental understanding of the operating system.
I barely know FreeBSD, I barely know linux, but I have a huge text file, chock full of docker commands that I figured out, how to put in and create a running container offering me a service, easily.

I have been using FreeNAS for 7 years and followed a plethora of guides on how to get guacamole going, how to get qbittorrent going. It's an absoloute nightmare getting some of these things working, updating.

Really?

The few jails I've got up, have broken several times out of the blue, only time I've had that on docker? ran out of disk space.

This is nothing to do with Docker as such and all about the relative popularity of FreeBSD vs. Linux.

So?
Who cares?
I have a bigger library, period - a massive library, more frequently being updated? This is vastly superior to me and more important than me, it's vastly more important to existing and future customers of the product(s) that IX are making.

ix may not be /directly/ competing with synology, but once they add docker support, they will be able to chip away at this for example.

Sorry, docker is so so much easier and better to add 'functions' to my device, in a huge way - even though it's under a VM![/QUOTE]

 

[ornias]

I barely know FreeBSD, I barely know linux,

Yet you basically continue judge both.... 'nuf said.

 

[diskdiddler]

Again, the discussion isn't about the OS it's about the ability to add features / plugins / containers to each.
You guys clearly protest too much and take it personally.

I'm telling you, after 7 years using FreeNAS, without question docker is simpler for adding stuff to my NAS, simple as that. that was the point of the discussion.

 

[jgreco]

Mod note: Pondering whether to peel off the Docker vs Jails into its own Cage Fight thread. It's distracting from the core topic here.

 

[diskdiddler]

It's fine I can drop it.

 

[jgreco]

without question docker is simpler for adding stuff to my NAS, simple as that. that was the point of the discussion.

And yet my users find adding a jail as easy as running an install script, and if I wrote containers they would find that to be the case as well, so "without question"

1) this is just your own experience
2) jails and containers are effectively equivalent technology
3) there will always be edge cases where no one has written a jail or container for some sort of ${thing} but that doesn't make the other technology a winner.

 

[Ericloewe]

My limited experience is that any management layer for jails or Linux containers has plenty of sharp edges to be at least mildly irritating. I haven't seen anything that really screams "this is so much better". Of course, Linux's popularity means there's a lot more stuff out there, but I don't think it's due to any inherent advantages.

 

[Tigersharke]

I think that's something that would go along very well with iocage. Having a base system is obviously useful, but minimizing the attack surface is always good.

One-size-fits-all solutions are more of a -fits-one thing, but even a write-up of the procedure for one of your examples would be very interesting. A lot of it would also translate over to Linux in concept, I imagine.

I agree. Although my primary use of jails is for the isolation in order to port software or test things without leaving unwanted bits all over the place, it would at the least be instructive for how things can be done better when real security is necessary. I think I will be working with Bastille as my attempts with iocage and numerous other "easy to use" jail management things were not quite, but I have yet to really test it out myself. I've been postponing a lot of things because I intend to swap the processor of my primary box.

The devil is in the details. In theory, the procedure is approximately just

tar xvf somepackage.tar
cd somepackage
configure --prefix=/foojail
make install

but in practice, this just gets you part of the way. Each application has its own ins and outs, and there's dreary stuff like linkers and libc.

One of my primary goals has been to separate applications (the thing an OS is providing to the world) from the OS itself. This is basically a critical error that the major OS's make. If you want to set up a web server, SQL server, and DNS server on your FreeBSD host, classic strategy is that you install the packages and then twiddle with random files intermingled inside your OS. But ports has been ... ah ... "inconsistent" over the long haul, leaving systems with multiple configuration boogerfiles, and heaven help you if you run into a package that needs a newer OpenSSL major version and another package doesn't support it -- you get into the upgrade and things actually break. The smart thing is for each app to have its own SSL, and for that to have been validated to work. You can then separately update the apps.

And then there's the big one. Trying to figure out how a random Linux or FreeBSD box is doing its tricks, or what those tricks even are, can be an unpleasant experience. And let's not even talk about Apache with its nearly ten thousand lines of default configuration. How do you figure out what the differences between the default and the current configuration are, given that so many people hack on the default files?

So you compartmentalize that too. Compartmentalize all the Apache-carp over in /www/etc, where it wants to live, as part of the "defaults". But the actual webserver configuration for the thing being served is configured as an include, and lives over in /www/conf. That way the /www/etc stuff stays as untouched, and the deltas needed to make the webserver work are in /www/conf.

I completely agree with the concept as a whole. I cannot count how many times something was updated or failed its update and various other things became broken or not installed themselves. An SSL for each thing than needs it would certainly solve that instance of breakage, and I am sure there are plenty of others that do not immediately spring to mind (python, rust, perhaps?).

 

[pechkin000]

Wow. Came in to five likes on that post just overnight. Makes me pleased to know that some people agree with me on some parts of that. Now leaves me wondering which parts. ;-)

I'm not sure, but is it worth asking this... is either iXsystems or the community interested in the possibility of this kind of thing being made available for FreeNAS? I haven't really looked too closely at this, but these jails are highly compartmentalized and self-contained, though they do their own jail management. Mmm.

I for one would be very interested in that. And I agree with the comment above me, even a writeup on how you do this would be an amazing read.

 

[Yorick]

Now leaves me wondering which parts

That running a wide-open SQL in docker or running everything as root in a jail is lazy. Getting rid of sh entirely sounds intriguing, but then, how do I configure and administrate the thing? Don’t answer that, rhetorical question. It can be done no doubt, it also sounds complex.

 

[jgreco]

That running a wide-open SQL in docker or running everything as root in a jail is lazy. Getting rid of sh entirely sounds intriguing, but then, how do I configure and administrate the thing? Don’t answer that, rhetorical question. It can be done no doubt, it also sounds complex.

It's not that bad. It helps if your build system bootstraps a configuration into the thing.

Many years ago, Sun said "the network is the computer" and this plays out pretty well if you actually embrace it. Lots of my stuff is built such that it can be run jailed or not jailed without more than a single setting change, and this is largely possible because when you're managing the thing over a TCP socket, all that really matters is that you can run the admin client and reach the socket.

Remember, what I'm talking about is getting rid of sh within the server's environment. This doesn't mean sh goes away in the administrator's environment. The thing that's a concern is what happens when some worm is crawling a well-known service port exploiting some sort of zero-day shell-gaining exploit. You want them to send their exploit payload and have it run off the end and try to exec("/bin/sh") into the happy abyss of not having one. Of course you also want them to be running into your ipfw of not being able to see the port in the first place; not having your pants down around your ankles on the public Internet is a really good bit of advice, belt and suspenders and all that.

Modern cloud, sadly, thrives on easy, which is how we end up with all these "found a wide open database on Amazon S3" problems.