Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Friday August 12 2016, @11:16AM   Printer-friendly
from the all-it-takes-is-time-and-money dept.

Arthur T Knackerbracket has found the following story:

The developers of FreeBSD have announced they'll change the way they go about their business, after users queried why known vulnerabilities weren't being communicated to users.

This story starts with an anonymous GitHub post detailing some vulnerabilities in the OS, specifically in freebsd-update, libarchive, bspatch and portsnap. Some of the problems in that post were verified and the FreeBSD devs started working on repairs.

But over on the FreeBSD security list, threads like this started asking why users weren't being told much about the bugs or remediation efforts. That's a fair question because updating FreeBSD could in some circumstances actually expose users to the problem.

Now the FreeBSD team has answered those questions by saying “As a general rule, the FreeBSD Security Officer does not announce vulnerabilities for which there is no released patch.”

The operating system's developers and security team are now “reviewing this policy for cases where a proof-of-concept or working exploit is already public.”

That post also explains that the team is considering more detailed security advisories. There's also an admission that the proposed patch may have broken other things in the OS.

The post concludes by saying that the FreeBSB core and security teams are working with all due haste to fix things and will let those subscribed to its mailing lists know when patches are ready and the danger is past.

[The majority of SoylentNews.org's servers run Ubuntu 14.04 LTS (Long Term Stable version). Upgrading to version 16.04 LTS would expose our systems to systemd and there has been some discussion among staff about our options. One option under consideration would be FreeBSD. Are there any Soylentils who run FreeBSD? What has your experience been? Any surprises to share with the community? --martyb]


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Interesting) by Unixnut on Friday August 12 2016, @01:02PM

    by Unixnut (5779) on Friday August 12 2016, @01:02PM (#386990)

    I have to say in my experience, I disagree with you. I found adopting to FreeBSD was much easier than SystemD, especially debugging problems with it. The fact it has reached a point where it is easier to either "Turn it off and on again", or "reinstall Linux" than actually delve into the OS and debug/fix/alter the system, means that it is becoming more like Windows, for many of the same reasons I moved from Windows more than a decade ago.

    If systemD works, it is tolerable, but if (like me) your job involves administration/maintenance and debugging of the systems, you quickly learn how much of a major PITA systemD is.

    I switched to Devuan (https://devuan.org/) for my Linux desktops, as they are systemD free. I started moving to FreeBSD for the servers. The biggest thing to get used to was the default shell is not bash. A lot of the commands for core things like disk detection, adding/removing users are different (BSD stack rather than GNU stack), but nothing that a bit of internet research cannot fix. The ports system is a bit like Gentoo's portage, just a little more manual.

    ZFS itself is awesome, but required quite a bit of fettling and magic incantations to wring out the best performance.

    FreeBSD is a bit tricker to set up (if you want to really fine tune things). In fact it reminds me a bit of Linux up until 2.6. Generally very powerful and flexible, but steep learning curve. Getting the system to be exactly how you want can take a while, but once set up it runs like a champ till the end of time.

    If you want it to "Just work", or only use the defaults, or don't care about the OS as long as it runs your apps, then stick to Linux. I can foresee a time when Linux becomes more like Windows, easy to install/use, inflexible, but pretty UI and apps exist for it. While FreeBSD does the heavy lifting/Server side. Either way, it would be better than Windows, as both are OSS, and you can hack into them if you really need to.

    Starting Score:    1  point
    Moderation   +3  
       Interesting=2, Informative=1, Total=3
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by Beige on Friday August 12 2016, @07:26PM

    by Beige (3989) on Friday August 12 2016, @07:26PM (#387139) Homepage

    It appears I touched a raw nerve with the previous posting and I'm sorry for that - however, in my personal experience learning systemtd didn't take much time and it has worked fine since. Most day-to-day stuff you can handle with just systemctl and chkconfig and these seem to work fine at least on CentOS. As far as potential secuirty issues go, systemd should be the least of your worries anyway. Personally I've used FreeBSD since version 2 and I've generally been happy with it so I wouldn't arue against its merits. However, it sounds like the SoylentNews staff are happy and comfortable with Ubuntu 14 and assuming that's the case then adapting to systemd shouldn't be much of a problem for anyone with half a clue.

    • (Score: 3, Insightful) by The Mighty Buzzard on Saturday August 13 2016, @02:33AM

      by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Saturday August 13 2016, @02:33AM (#387332) Homepage Journal

      Adapting to systemd almost certainly isn't going to happen for SN. Allow me to enlighten everyone as to why:
      You do not put a beta init system on a production server. Period.

      --
      My rights don't end where your fear begins.
    • (Score: 3, Informative) by Unixnut on Saturday August 13 2016, @10:02AM

      by Unixnut (5779) on Saturday August 13 2016, @10:02AM (#387443)

      Yeah, sorry. My company has started switching to CentOS/RHEL7 , and we are doing the initial testing/rollout. I spent the last 2 weeks trying to work out why systemD would randomly hang, or work fine one moment, then on reboot drop into "Emergency Mode", or the binary logs getting corrupted, and the general pain of having no choice but to interact with things like logs using their tools.

      You can't bypass their tools and use one of the standard ones, or your own. Back when it was all separate programs and scripts, it was easy to "step through" each stage until you hit a problem, then debug it. SystemD either works, or it doesn't. I can't easily step through it, or replace subsystems, because it is all so heavily integrated. All it usually tells you is the equivalent of "Oops, something happened. Here is the emergency mode", without really telling me anything useful, or even showing where in the stage it broke.

      And yes, we had a clean installed CentOS7 machine that would just boot randomly into emergency mode on reboot. In the end it was faster and easier to just wipe it and reinstall, after which it worked. No idea why, and no idea why it didn't work. This kind of obscure "Sometimes works, sometimes doesn't" might be standard acceptance for Windows Admins, but it used to infuriate me, because I hate black boxes, where I have no idea why something is broken, or why it suddenly started working. It is why I switched to Linux and Unix systems back in the early 00's. You could rip a Linux system apart completely, and it was all small programs interconnected loosely. It was wonderful, so powerful and flexible, but it demands effort and the pursuit of knowledge to be any good with it.

      As for SystemD. IMO it has a serious architectural/design flaw, which is that it is trying to be yet another tightly-integrated abstraction layer between the kernel and the apps. A bit like svchost on Windows. The more abstraction layers you have, the more complexity, and the more opportunity for flaws to creep up due to the interaction of different parts. Not to mention being slower (latency wise) and more prone to security flaws (I have some power over higher parts of the stack, but the kernel/systemD is not easy to just rip out and replace in case of a security flaw).

      However I suspect this is on purpose. I think RedHat is seeing the next major growth will be on stateless machines, like Openstack. You don't care about debugging the OS or its init system. If the machine cocks up, just terminate and spawn a new one. The apps are stateless, the data is in "the cloud", so minimal downtime. That is why for systemD boot times were so important. On a server nobody cares if it takes 30 mins to comeback, as you reboot so often. However in a dynamic "Virtual Cloud" setup, you want to spin machines up quickly.

      For that kind of setup, I actually think systemD is perfect. You have a "black box" OS, you have your apps running on it (perhaps in docker), and if one segment fails, just respawn and carry on.

      However that means that it is ill suited for traditional systems. While I can imagine in future the majority of compute could be cloud based, there will still be traditional hardware machines out there, and for them I believe in future the BSDs will dominate, along with Linux where required due to tie-in (e.g docker can only run on Linux, so you need a Linux host for it). However I am sticking to Linux on my desktops. Far more apps, better graphics support, there are systemD free alternatives, and I am still more familiar with it.