A couple of questions regarding FreeBSD vs. Linux

[herrbischoff]

Hi all,

I'm still quite new to FreeBSD. I have tinkered around with it and even set up my home server with it, then an internet server, then more. In the process I have made some observations that I like to reflect upon, possibly to gain deeper understanding and to be corrected where I may have strayed from the path of knowledge.

1. At first I was a little confused by the slim package that FreeBSD is. Apart from the system environment, there is practically no additional software installed. What initially struck me as weird, coming from different Linux distributions, soon made me rejoice about the far less opinionated way the system is set up out of the box. In fact, I have come to love The Handbook and learning about a mostly consistent set of commands. FreeBSD appears to relate to Unix in a way similar as Slackware to Linux. For the most part, you learn the system and not the distribution.
2. Speaking of distributions: I am thrilled that FreeBSD is a complete OS, not just a bundle of opinionated defaults. Whenever I had to deal with a new Linux distribution, I found dozens of pieces that wouldn't fit, exceptions and workarounds, bent rules and deep symlinks, a whole new approach to deal with things on one end, a fallback to ancient ones on the other. To be honest, Linux started to remind me more and more of the fragmented world that is (I shudder to think) Microsoft Windows. There are SO many moving pieces that even may change fundamentally from one release to the other with so many opinionated differences, it took the joy out of using the system. It felt like it was fighting me. Or me fighting it. This is high level critique of course. Linux is still light years ahead of any kind of Windows OS.
3. Simply put: to me, Linux feels like a box full of all kinds of components with a two years out-of-date manual translated from Mandarin Chinese to English. FreeBSD feels like a set of Lego pieces that contains just what you need to complete it, with instructions for alternate models and how to get more bricks that fit. Linux appears to be kind of a mess. A mess that works but is nonetheless a mess.

Am I correct in those observations? I don't want to solicit fanboy responses but rather ground myself properly.

What I have to come to wonder though is the approach you would take on FreeBSD for several scenarios and why certain things are the way they are.

1. Should I use pkg or portmaster exclusively to update the additional software or can they coexist without interfering with each other?
2. Is there a way to auto-install security patches without manual intervention? Also, is this recommended? I wonder about how running large-scale FreeBSD installations affects this.
3. Can I run a Linux guest in a jail — easily?
4. Is there a user-friendly way to manage jails?
5. What is the preferred method of virtualisation with FreeBSD as host OS? I'd like to be able to leverage FreeBSD functionality while running several Linux VMs (Debian/CentOS) as the software running in them is sadly not available for FreeBSD.

 

[SirDice]

Am I correct in those observations?

I'd say you're pretty much spot on.

Should I use pkg or portmaster exclusively to update the additional software or can they coexist without interfering with each other?

Don't install ports for the sake of installing ports. If you're going to stick to the defaults use the convenience of packages. Mixing non-default options and packages is going to lead to a lot of confusion and frustration. If you need to deviate from the default options I highly recommend using something like Synth or Poudriere to build your own packages.

Is there a way to auto-install security patches without manual intervention? Also, is this recommended? I wonder about how running large-scale FreeBSD installations affects this.

It can be automated but most of us prefer not to. Automatically installing them will inevitably lead to problems at some point in time, usually at the worst possible moment. Better to take more control and apply them when it's convenient.

Can I run a Linux guest in a jail — easily?

Yes, it's possible. It's not easy though and there are a lot of caveats.

Is there a user-friendly way to manage jails?

Two of the most popular ones are EZJail and IOCage. The latter is being rewritten so you might want to hold off on that one. EZJail should work but will, at the very least, generate a bunch of deprecation warnings as it's using an 'old' style to set up the jails.

What is the preferred method of virtualisation with FreeBSD as host OS? I'd like to be able to leverage FreeBSD functionality while running several Linux VMs (Debian/CentOS) as the software running in them is sadly not available for FreeBSD.

Bhyve of course https://wiki.freebsd.org/bhyve/ I can recommend sysutils/vm-bhyve, it makes it really easy to set up and use.

 

[herrbischoff]

Thanks for your response.

Bhyve of course https://wiki.freebsd.org/bhyve/ I can recommend sysutils/vm-bhyve, it makes it really easy to set up and use.

Also, this is amazing! No need for Debian Jails with bhyve. vm-bhyve is just perfect as well. This was the last major blocker for adopting FreeBSD on my client's servers. Truth be told, I've had it up to the neck having to deal with Ubuntu and that weird ZoL implementation. Freedom!

 

[ANOKNUSA]

Also, is [updating automatically] recommended?

It's possible to use pc-sysinstall(8) or write your own scripts to achieve this, but unless you put it through lots of testing then automated security and bug-fix updates are a very bad idea. Upgrading the system to a new version will always need to be done manually, since it requires merging all your own changes to configuration files with any changes to the defaults.

 

[Oko]

1. Should I use pkg or portmaster exclusively to update the additional software or can they coexist without interfering with each other?
2. Is there a way to auto-install security patches without manual intervention? Also, is this recommended? I wonder about how running large-scale FreeBSD installations affects this.
3. Can I run a Linux guest in a jail — easily?
4. Is there a user-friendly way to manage jails?
5. What is the preferred method of virtualisation with FreeBSD as host OS? I'd like to be able to leverage FreeBSD functionality while running several Linux VMs (Debian/CentOS) as the software running in them is sadly not available for FreeBSD.

1. A novice user has no business using ports so you should use binary packages i.e. pkg.
2. You should never auto-install security patches as some of them might require reboot. When you are running large-scale FreeBSD or any OS for that matter you are professional and typically you are using some kind infrastructure automation. In my lab we use Ansible because it is OS agnostic and easy to learn. Learn how to use beadm. The fact that it is shamefully stolen from Solaris doesn't change the fact that Linux has no equal.
3. No Jail is OS level virtualization technique and you can only run FreeBSD guests in jail. The good news is that you can run different version of OS than the host. I am not sure about different architecture but for short period of time I run 9.xxx in Jail on the top of 10.xxx to test something. Linux is a third rate OS when it comes to OS level virtualization. I would argue that Solaris+Containers is the top notch choice. FreeBSD is the poor man's choice. I am a poor man so I run it.
4. Yes and no. You can mange jails with tools like iocage, CBSD, Ezjail. Is it easier? Sure if you run tens of jails like me. User friendly not so sure. Warden infamous Jail manager of PC-BSD had a GUI. Warden was disbanded and PC-BSD is dead now too.
5. If you need full blown virtualization FreeBSD should not be your first choice. I would go with Linux and that is what I do at work. We use KVM on the top of Red Hat. KVM is Linux specific technology (I am ignorign any comments about SmartOS on this spot). I really like Xen which is also not available for FreeBSD (In my undertadning Dom0 is not production ready). I have never had lack with VirtualBox on FreeBSD but unless you need to run Internet Explorer to check your web application I would not use it anyway. I am not a big fun of true virtualization but my understanding if you are addicted to that kind stuff OpenStack and similar crap you will want to run Ubuntu. FreeBSD just got Bhyve. I am probably going to play with it little bit but I doubted any of the big virtualization users will be switching to FreeBSD from Linux anytime soon. By the way I really like virtualization on big frames like IBM but that is only available to huge corporations.

 

[freebuser]

Hi all,

I'm still quite new to FreeBSD. I have tinkered around with it and even set up my home server with it, then an internet server, then more. In the process I have made some observations that I like to reflect upon, possibly to gain deeper understanding and to be corrected where I may have strayed from the path of knowledge.

1. At first I was a little confused by the slim package that FreeBSD is. Apart from the system environment, there is practically no additional software installed. What initially struck me as weird, coming from different Linux distributions, soon made me rejoice about the far less opinionated way the system is set up out of the box. In fact, I have come to love The Handbook and learning about a mostly consistent set of commands. FreeBSD appears to relate to Unix in a way similar as Slackware to Linux. For the most part, you learn the system and not the distribution.
2. Speaking of distributions: I am thrilled that FreeBSD is a complete OS, not just a bundle of opinionated defaults. Whenever I had to deal with a new Linux distribution, I found dozens of pieces that wouldn't fit, exceptions and workarounds, bent rules and deep symlinks, a whole new approach to deal with things on one end, a fallback to ancient ones on the other. To be honest, Linux started to remind me more and more of the fragmented world that is (I shudder to think) Microsoft Windows. There are SO many moving pieces that even may change fundamentally from one release to the other with so many opinionated differences, it took the joy out of using the system. It felt like it was fighting me. Or me fighting it. This is high level critique of course. Linux is still light years ahead of any kind of Windows OS.
3. Simply put: to me, Linux feels like a box full of all kinds of components with a two years out-of-date manual translated from Mandarin Chinese to English. FreeBSD feels like a set of Lego pieces that contains just what you need to complete it, with instructions for alternate models and how to get more bricks that fit. Linux appears to be kind of a mess. A mess that works but is nonetheless a mess.

Am I correct in those observations? I don't want to solicit fanboy responses but rather ground myself properly.

What I have to come to wonder though is the approach you would take on FreeBSD for several scenarios and why certain things are the way they are.

1. Should I use pkg or portmaster exclusively to update the additional software or can they coexist without interfering with each other?
2. Is there a way to auto-install security patches without manual intervention? Also, is this recommended? I wonder about how running large-scale FreeBSD installations affects this.
3. Can I run a Linux guest in a jail — easily?
4. Is there a user-friendly way to manage jails?
5. What is the preferred method of virtualisation with FreeBSD as host OS? I'd like to be able to leverage FreeBSD functionality while running several Linux VMs (Debian/CentOS) as the software running in them is sadly not available for FreeBSD.

Given you have set up a web server (internet server?) I believe you are knowledgeable enough to use the ports, just be careful when you un-select the options during 'configure' to make sure you are not breaking any dependent ports.

I used (tried) to compile programs in RedHat and Debian but nothing comes closer to the way FreeBSD ports work. I would at least ask you to give it a try. Once you setup everything it is a piece of cake (art).

I am using ezjail for my jail management, but recently moved my config to /etc/jail.conf (this can be done during jails running and copying the configs from /var directory to /etc/jail.conf) and start and stop using the /etc/rc.d/jail command to comply with new requirements. This is in FreeBSD RELEASE 11.0.1.
Ezjail still gives me the flexibility to archive the jails which is great for me to back it up to LTO3.

From a server point of view (coming from Debian to) FreeBSD is a far more easy to manage things than any other OS. Everything is as just what you want in a server OS, all the configs are in the right place and you know exactly what to do and where to do when you need to tinker/ modify things to suit.

All the very best.

 

[herrbischoff]

It's possible to use pc-sysinstall(8) or write your own scripts to achieve this, but unless you put it through lots of testing then automated security and bug-fix updates are a very bad idea. Upgrading the system to a new version will always need to be done manually, since it requires merging all your own changes to configuration files with any changes to the defaults.

Thanks for your input. As I come from the Debian universe, where it is considered good practice to enable auto updates for security patches, this view first confused me. However, upon digging deeper into the system and thinking more about what I have already written above ("like a set of Lego pieces that contains just what you need to complete it"), this approach actually makes sense. However, my question was regarding security patches, not system upgrades. But as FreeBSD has a fundamentally different update strategy compared to Linux distros, system upgrades and patches appear to be the same thing.

A novice user has no business using ports so you should use binary packages i.e. pkg.

A little hostile, are we now? My question was regarding possible problems in using them together, not your opinion on whether I should be allowed to compile software from source, thank you very much.

Given you have set up a web server (internet server?) I believe you are knowledgeable enough to use the ports, just be careful when you un-select the options during 'configure' to make sure you are not breaking any dependent ports.

Thank you. It's a web server only in part and performs several other application-based functions. It runs beautifully with software installed via ports. I usually do not disable default settings unless I know exactly that I need to and what that will do to the system as a whole.

Everything is as just what you want in a server OS, all the configs are in the right place and you know exactly what to do and where to do when you need to tinker/ modify things to suit.

This is my experience as well. It just makes sense. On FreeBSD, I rarely have to hunt for certain files because they are usually exactly where I suspect they would be.

 

[Remington]

Thanks for your input. As I come from the Debian universe, where it is considered good practice to enable auto updates for security patches, this view first confused me. However, upon digging deeper into the system and thinking more about what I have already written above ("like a set of Lego pieces that contains just what you need to complete it"), this approach actually makes sense. However, my question was regarding security patches, not system upgrades. But as FreeBSD has a fundamentally different update strategy compared to Linux distros, system upgrades and patches appear to be the same thing.

Leaving a system unsupervised to do the automatic updates is generally a bad practice because what if the update fails and it disrupts the running system. Good administrators should be monitoring the updates in progress to be sure nothing breaks.

A little hostile, are we now? My question was regarding possible problems in using them together, not your opinion on whether I should be allowed to compile software from source, thank you very much.

Not at all. Ports and Packages works differently because they are not updated concurrently. Ports will usually get updated first then packages could be updated in a few days to a week. So mixing packages or ports with different versions or dependencies and that can break something. That's why mixing both of them should be avoided as much as possible. That's why I use ports-mgmt/poudriere to build packages from ports so I have my own repository. It's very easy to use ports-mgmt/synth or ports-mgmt/poudriere and it makes your job much easier by having your own packages with custom options and default settings.

 

[freebuser]

Thanks for your input. As I come from the Debian universe, where it is considered good practice to enable auto updates for security patches, this view first confused me. However, upon digging deeper into the system and thinking more about what I have already written above ("like a set of Lego pieces that contains just what you need to complete it"), this approach actually makes sense. However, my question was regarding security patches, not system upgrades. But as FreeBSD has a fundamentally different update strategy compared to Linux distros, system upgrades and patches appear to be the same thing.



A little hostile, are we now? My question was regarding possible problems in using them together, not your opinion on whether I should be allowed to compile software from source, thank you very much.



Thank you. It's a web server only in part and performs several other application-based functions. It runs beautifully with software installed via ports. I usually do not disable default settings unless I know exactly that I need to and what that will do to the system as a whole.



This is my experience as well. It just makes sense. On FreeBSD, I rarely have to hunt for certain files because they are usually exactly where I suspect they would be.

In regards to security FreeBSD has to different sections one base system and the other ports.
Both can be monitored for any security issues or updates.
For base system I subscribed to security mailing list and for Ports you can have a crontab to monitor and report any security issues via email.
I usually upgrade/update the system monthly and apply any patches during this (after a full backup).
Ports update is very easy and base updates/security advisories will generally have a section telling what to do to update the system.

I also used Poudriere and using synth now only because I have several jails running and to compile the ports in a faster PC under virtualbox.

 

[ANOKNUSA]

But as FreeBSD has a fundamentally different update strategy compared to Linux distros, system upgrades and patches appear to be the same thing.

No, I was referring to them as different things, and I think most of us think of them as different things. Upgrading from one version of the system to another (11.0 to 11.1, for example) should never be automated. Ever. When it comes to security and bug-fix updates then automation is something you can try to work with, but you can never be entirely certain whether an update will go smoothly or what the effects my be in the short term. And this just applies to -RELEASEs; if you're running -STABLE or -CURRENT (the FreeBSD equivalents to Debian Unstable and Debian Testing) then you shouldn't perform unattended updates at all, since the number and degree of changes with each update is variable.

This isn't necessarily a technical difference between FreeBSD and Debian, so much as a difference in outlook between the two communities and a consequence of design. FreeBSD folks tend to be much more conservative when it comes to messing around with something that works: if a system update is available, but it fixes a problem you can be sure doesn't affect you, then why mess with it? If you want or need to apply an update, best to know what's happening while its happening, and to know what has changed and when should a problem arise, rather than starting your day by wiping away coffee you spit all over your monitor after you're greeted with a nasty surprise.

This is even more applicable to port/package upgrades, since the ports tree and package repository run on a rolling-release model.

 

[kpa]

FreeBSD is fundamentally different compared to just about any Linux distro in one specific area, we have a solidly defined line between the operating system and third party software. The operating system comprises of the kernel and the what is called "the world" which is all of the userland binaries, libraries and configuration/data files that are part of the base distribution set. You'll also often see the term "base system" used for the operating system part. Updates to the base system are what the release engineers and the FreeBSD security team work on. Everything outside the base system, that is the ports and packages, is on a third party contributed software status and the FreeBSD security team takes no responsibility over those *), any updates, security or just general updates, to ports/packages are supposed to handled by the individual port maintainers with the help of committers who commit the changes to the repository.


*) The FreeBSD project does provide facilities for tracking problems in ports and packages, for example the VuXML database at http://www.vuxml.org/freebsd/. The security team however is not going to act on vulnerabilities on third party contributed software.

 

[rigoletto@]

Just to notice sysutils/qjail is quite similar to sysutils/ezjail but already fully support the current configuration mode.

Cheers!

 

[ANOKNUSA]

Just to notice sysutils/qjail is quite similar to sysutils/ezjail ...

https://lists.freebsd.org/pipermail/freebsd-jail//2013-March/002149.html

Just putting that out there. I can't say anything about the current state of Qjail, and as far as I know ezjail has not been abandoned by its creator and maintainer, so it'll probably be updated soon enough, according the creator's own standards.

 

[herrbischoff]

Upgrading from one version of the system to another (11.0 to 11.1, for example) should never be automated. Ever.

Absolutely. I would also never do an automated apt-get dist-upgrade on a Debian system.

FreeBSD folks tend to be much more conservative

It appears to be like that. This squarely flies in the face of other Linux distributions who consider Debian to be extremely conservative. Then again, there's RHEL and their even more conservative stance. However, having worked with several FreeBSD installations over the last couple of weeks, I very much prefer the way that the base system is seen as being separate from third-party software. This way, you can be as conservative as you like regarding the software you install. In fact, I am compiling and installing most software by hand on Debian systems anyway. The ports system is a welcome addition to this. Having tested synth, as suggested by SirDice, I'm sold. This is the way to do it.

FreeBSD is fundamentally different compared to just about any Linux distro in one specific area, we have a solidly defined line between the operating system and third party software. The operating system comprises of the kernel and the what is called "the world" which is all of the userland binaries, libraries and configuration/data files that are part of the base distribution set. You'll also often see the term "base system" used for the operating system part. Updates to the base system are what the release engineers and the FreeBSD security team work on. Everything outside the base system, that is the ports and packages, is on a third party contributed software status and the FreeBSD security team takes no responsibility over those *), any updates, security or just general updates, to ports/packages are supposed to handled by the individual port maintainers with the help of committers who commit the changes to the repository.

Thanks for driving that point home. It's also the logical conclusion from what I had written in the original post: "Linux appears to be kind of a mess. A mess that works but is nonetheless a mess." I love the separation of concerns in FreeBSD. This is now clear to me.

https://lists.freebsd.org/pipermail/freebsd-jail//2013-March/002149.html

Jeez, what a wrestling match... Anyhow, I think I'm going to stick with ezjail for now. I have already set up several jails and the more I use it, the more a system like Docker feels wrong to use except for truly distributed applications. They're different animals for different purposes, sure. For most routine tasks, running jails appears to be the better alternative.

The one thing I now wonder is about the best practice to give a jail access to a folder on the host file system. I have had success with a nullfs mount into the jails' folder. Is this fine or considered unstable?

 

[Remington]

The one thing I now wonder is about the best practice to give a jail access to a folder on the host file system. I have had success with a nullfs mount into the jails' folder. Is this fine or considered unstable?

It can be done by adding mount in /etc/fstab.<jailname> and don't use host's /etc/fstab. If you include the jail mount in host's /etc/fstab with missing folder or mistyped folder name then FreeBSD's boot-up will be disrupted until you fix the problem. Missing or mistyped folder name in /etc/fstab.<jailname> will only disrupt jail startup and that's easy to fix.

 

[herrbischoff]

It can be done by adding mount in /etc/fstab.<jailname> and don't use host's /etc/fstab.

Great suggestion, thanks. This should be part of the Handbook.

 

[Remington]

Great suggestion, thanks. This should be part of the Handbook.

You can use my /etc/jail.conf as a reference.

https://forums.freebsd.org/threads/49561/

 

[ANOKNUSA]

This should be part of the Handbook.

It's mentioned in jail(8). The Handbook can't contain everything. I believe you can actually place an fstab-style file anywhere an specify its location in jail.conf You can also just specify a single filesystem to mount in jail.conf if you don't want to create a separate, one-line file.

And yes, null mounts are a fine way to do it.

 

[Remington]

It's mentioned in jail(8). The Handbook can't contain everything. I believe you can actually place an fstab-style file anywhere an specify its location in jail.conf You can also just specify a single filesystem to mount in jail.conf if you don't want to create a separate, one-line file.

And yes, null mounts are a fine way to do it.

You made a valid point to keep things much cleaner so I'll include the mountpoint in the /etc/jail.conf instead of /etc/fstab.<jailname>. ezJail used to create multiple fstab files. I'll update the /etc/jail.conf example.