Show Notes/Links: https://www.bsdnow.tv/348

The post BSD Community Collections | BSD Now 348 first appeared on Jupiter Broadcasting.

Show Notes: techsnap.systems/427

The post Gigahertz Games | TechSNAP 427 first appeared on Jupiter Broadcasting.

Show Notes/Links: https://www.bsdnow.tv/343

The post FreeBSD, Corona: Fight! | BSD Now 343 first appeared on Jupiter Broadcasting.

Show Notes: chooselinux.show/27

The post GhostBSD + Freedom vs Pragmatism | Choose Linux 27 first appeared on Jupiter Broadcasting.

Show Notes/Links: https://www.bsdnow.tv/322

The post Happy Birthday, Unix | BSD Now 322 first appeared on Jupiter Broadcasting.

Episode Links:

linuxactionnews.com/78

The post Linux Action News 78 first appeared on Jupiter Broadcasting.

##Headlines
###OpenBSD 6.4 released

• See a detailed log of changes between the 6.3 and 6.4 releases.
• See the information on the FTP page for a list of mirror machines.
• Have a look at the 6.4 errata page for a list of bugs and workarounds.
• signify(1) pubkeys for this release:
• base: RWQq6XmS4eDAcQW4KsT5Ka0KwTQp2JMOP9V/DR4HTVOL5Bc0D7LeuPwA
• fw: RWRoBbjnosJ/39llpve1XaNIrrQND4knG+jSBeIUYU8x4WNkxz6a2K97
• pkg: RWRF5TTY+LoN/51QD5kM2hKDtMTzycQBBPmPYhyQEb1+4pff/H6fh/kA

###GhostBSD 18.10 RC2 Announced

This second release candidate of GhostBSD 18.10 is the second official release of GhostBSD with TrueOS under the hood. The official desktop of GhostBSD is MATE. However, in the future, there might be an XFCE community release, but for now, there is no community release yet.

• What has changed since RC1

• Removed drm-stable-kmod and we will let users installed the propper drm-*-kmod

• Douglas Joachin added libva-intel-driver libva-vdpau-driver to supports accelerated some video driver for Intel

• Issues that got fixed

• Bug #70 Cannot run Octopi, missing libgksu error.

• Bug #71 LibreOffice doesn’t start because of missing libcurl.so.4

• Bug #72 libarchive is a missing dependency

Again thanks to iXsystems, TrueOS, Joe Maloney, Kris Moore, Ken Moore, Martin Wilke, Neville Goddard, Vester “Vic” Thacker, Douglas Joachim, Alex Lyakhov, Yetkin Degirmenci and many more who helped to make the transition from FreeBSD to TrueOS smoother.

• Updating from RC1 to RC2:

• sudo pkg update -f

• sudo pkg install -f libarchive curl libgksu

• sudo pkg upgrade

• Where to download:

• All images checksum, hybrid ISO(DVD, USB) and torrent are available here: https://www.ghostbsd.org/download

• [ScreenShots]

• https://www.ghostbsd.org/sites/default/files/Screenshot_at_2018-10-20_13-22-41.png

• https://www.ghostbsd.org/sites/default/files/Screenshot_at_2018-10-20_13-27-26.png

###OpenSSH 7.9 has been released and it has support for OpenSSL 1.1

Changes since OpenSSH 7.8
=========================

This is primarily a bugfix release.

New Features
------------
 * ssh(1), sshd(8): allow most port numbers to be specified using
   service names from getservbyname(3) (typically /etc/services).
 * ssh(1): allow the IdentityAgent configuration directive to accept
   environment variable names. This supports the use of multiple
   agent sockets without needing to use fixed paths.
 * sshd(8): support signalling sessions via the SSH protocol.
   A limited subset of signals is supported and only for login or
   command sessions (i.e. not subsystems) that were not subject to
   a forced command via authorized_keys or sshd_config. bz#1424
 * ssh(1): support "ssh -Q sig" to list supported signature options.
   Also "ssh -Q help" to show the full set of supported queries.
 * ssh(1), sshd(8): add a CASignatureAlgorithms option for the
   client and server configs to allow control over which signature
   formats are allowed for CAs to sign certificates. For example,
   this allows banning CAs that sign certificates using the RSA-SHA1
   signature algorithm.
 * sshd(8), ssh-keygen(1): allow key revocation lists (KRLs) to
   revoke keys specified by SHA256 hash.
 * ssh-keygen(1): allow creation of key revocation lists directly
   from base64-encoded SHA256 fingerprints. This supports revoking
   keys using only the information contained in sshd(8)
   authentication log messages.

Bugfixes
--------

 * ssh(1), ssh-keygen(1): avoid spurious "invalid format" errors when
   attempting to load PEM private keys while using an incorrect
   passphrase. bz#2901
 * sshd(8): when a channel closed message is received from a client,
   close the stderr file descriptor at the same time stdout is
   closed. This avoids stuck processes if they were waiting for
   stderr to close and were insensitive to stdin/out closing. bz#2863
 * ssh(1): allow ForwardX11Timeout=0 to disable the untrusted X11
   forwarding timeout and support X11 forwarding indefinitely.
   Previously the behaviour of ForwardX11Timeout=0 was undefined.
 * sshd(8): when compiled with GSSAPI support, cache supported method
   OIDs regardless of whether GSSAPI authentication is enabled in the
   main section of sshd_config. This avoids sandbox violations if
   GSSAPI authentication was later enabled in a Match block. bz#2107
 * sshd(8): do not fail closed when configured with a text key
   revocation list that contains a too-short key. bz#2897
 * ssh(1): treat connections with ProxyJump specified the same as
   ones with a ProxyCommand set with regards to hostname
   canonicalisation (i.e. don't try to canonicalise the hostname
   unless CanonicalizeHostname is set to 'always'). bz#2896
 * ssh(1): fix regression in OpenSSH 7.8 that could prevent public-
   key authentication using certificates hosted in a ssh-agent(1)
   or against sshd(8) from OpenSSH <7.8.

Portability
-----------

 * All: support building against the openssl-1.1 API (releases 1.1.0g
   and later). The openssl-1.0 API will remain supported at least
   until OpenSSL terminates security patch support for that API version.
 * sshd(8): allow the futex(2) syscall in the Linux seccomp sandbox;
   apparently required by some glibc/OpenSSL combinations.
 * sshd(8): handle getgrouplist(3) returning more than
   _SC_NGROUPS_MAX groups. Some platforms consider this limit more
   as a guideline.

##News Roundup

###MeetBSD 2018: The Ultimate Hallway Track

Founded in Poland in 2007 and first hosted in California in 2008, MeetBSD combines formal talks with UnConference activities to provide a level of interactivity not found at any other BSD conference. The character of each MeetBSD is determined largely by its venue, ranging from Hacker Dojo in 2010 to Intel’s Santa Clara headquarters this year. The Intel SC12 building provided a beautiful auditorium and sponsors’ room, plus a cafeteria for the Friday night social event and the Saturday night FreeBSD 25th Anniversary Celebration. The formal nature of the auditorium motivated the formation of MeetBSD’s first independent Program Committee and public Call for Participation. Together these resulted in a backbone of talks presented by speakers from the USA, Canada, and Poland, combined with UnConference activities tailored to the space.

• MeetBSD Day 0

Day Zero of MeetBSD was a FreeBSD Developer/Vendor Summit hosted in the same auditorium where the talks would take place. Like the conference itself, this event featured a mix of scheduled talks and interactive sessions. The scheduled talks were LWPMFS: LightWeight Persistent Memory Filesystem by Ravi Pokala, Evaluating GIT for FreeBSD by Ed Maste, and NUMA by Mark Johnston. Ed’s overview of the advantages and disadvantages of using Git for FreeBSD development was of the most interest to users and developers, and the discussion continued into the following two days.

• MeetBSD Day 1

The first official day of MeetBSD 2018 was kicked off with introductions led by emcee JT Pennington and a keynote, “Using TrueOS to boot-strap your FreeBSD-based project” by Kris Moore. Kris described a new JSON-based release infrastructure that he has exercised with FreeBSD, TrueOS, and FreeNAS. Kris’ talk was followed by “Intel & FreeBSD: Better Together” by Ben Widawsky, the FreeBSD program lead at Intel, who gave an overview of Intel’s past and current efforts supporting FreeBSD. Next came lunch, followed by Kamil Rytarowski’s “Bug detecting software in the NetBSD userland: MKSANITIZER”. This was followed by 5-Minute Lightning Talks, Andrew Fengler’s “FreeBSD: What to (Not) Monitor”, and an OpenZFS Panel Discussion featuring OpenZFS experts Michael W. Lucas, Allan Jude, Alexander Motin, Pawel Dawidek, and Dan Langille. Day one concluded with a social event at the Intel cafeteria where the discussions continued into the night.

• MeetBSD Day 2

Day Two of MeetBSD 2018 kicked off with a keynote by Michael W. Lucas entitled “Why BSD?”, where Michael detailed what makes the BSD community different and why it attracts us all. This was followed by Dr. Kirk McKusick’s “The Early Days of BSD” talk, which was followed by “DTrace/dwatch in Production” by Devin Teske. After lunch, we enjoyed “A Curmudgeon’s Language Selection Criteria: Why I Don’t Write Everything in Go, Rust, Elixir, etc” by G. Clifford Williams and, “Best practices of sandboxing applications with Capsicum” by Mariusz Zaborski. I then hosted a Virtualization Panel Discussion that featured eight developers from FreeBSD, OpenBSD, and NetBSD. We then split up for Breakout Sessions and the one on Bloomberg’s controversial article on backdoored Supermicro systems was fascinating given the experts present, all of whom were skeptical of the feasibility of the attack. The day wrapped up with a final talk, “Tales of a Daemontown Performance Peddler: Why ‘it depends’ and what you can do about it” by Nick Principe, followed by the FreeBSD 25th Anniversary Celebration.

• Putting the “meet” in MeetBSD

I confess the other organizers and I were nervous about how well one large auditorium would suit a BSD event but the flexible personal space it gave everyone allowed for countless meetings and heated hacking that often brought about immediate results. I watched people take ideas through several iterations with the help and input of obvious and unexpected experts, all of whom were within reach. Not having to pick up and leave for a talk in another room organically resulted in essentially a series of mini hackathons that none of us anticipated but were delighted to witness, taking the “hallway track” to a whole new level. The mix of formal and UnConference activities at MeetBSD is certain to evolve. Thank you to everyone who participated with questions, Lightning Talks, and Panel participation. A huge thanks to our sponsors, including Intel for both hosting and sponsoring MeetBSD California 2018, Western Digital, Supermicro, Verisign, Jupiter Broadcasting, the FreeBSD Foundation, Bank of America Merrill Lynch, the NetBSD Foundation, and the team at iXsystems.

See you at MeetBSD 2020!

###Setup DragonflyBSD with a desktop on real hardware ThinkPad T410
+Video Demo

Linux has become too mainstream and standard BSD is a common thing now? How about DragonflyBSD which was created as a fork of FreeBSD 4.8 in conflict over system internals. This tutorial will show how to install it and set up a user-oriented desktop. It should work with DragonflyBSD, FreeBSD and probably all BSDs.
Some background: BSD was is ultimately derived from UNIX back in the days. It is not Linux even though it is similar in many ways because Linux was designed to follow UNIX principles. Seeing is believing, so check out the video of the install!
I did try two BSD distros before called GhostBSD and TrueOS and you can check out my short reviews. DragonflyBSD comes like FreeBSD bare bones and requires some work to get a desktop running.

• Download image file and burn to USB drive or DVD

• First installation

• Setting up the system and installing a desktop

• Inside the desktop

• Install some more programs

• How to enable sound?

• Let’s play some free games

• Setup WiFi

• Power mode settings

• More to do?

You can check out this blog post if you want a much more detailed tutorial. If you don’t mind standard BSD, get the GhostBSD distro instead which comes with a ready-made desktop xcfe or mate and many functional presets.

• A small summary of what we got on the upside:

  • Free and open source operating system with a long history
  • Drivers worked fine including Ethernet, WiFi, video 2D & 3D, audio, etc
  • Hammer2 advanced file system
  • You are very unique if you use this OS fork

• Some downsides:

• Less driver and direct app support than Linux

• Installer and desktop have some traps and quirks and require work

###Porting Keybase to NetBSD

Keybase significantly simplifies the whole keypair/PGP thing and makes what is usually a confusing, difficult experience actually rather pleasant. At its heart is an open-source command line utility that does all of the heavy cryptographic lifting. But it’s also hooked up to the network of all other Keybase users, so you don’t have to work very hard to maintain big keychains. Pretty cool!
So, this evening, I tried to get it to all work on NetBSD.
The Keybase client code base is, in my opinion, not very well architected… there exist many different Keybase clients (command line apps, desktop apps, mobile apps) and for some reason the code for all of them are seemingly in this single repository, without even using Git submodules. Not sure what that’s about.
Anyway, “go build”-ing the command line program (it’s written in Go) failed immediately because there’s some platform-specific code that just does not seem to recognize that NetBSD exists (but they do for FreeBSD and OpenBSD). Looks like the Keybase developers maintain a Golang wrapper around struct proc, which of course is different from OS to OS. So I literally just copypasted the OpenBSD wrapper, renamed it to “NetBSD”, and the build basically succeeded from there! This is of course super janky and untrustworthy, but it seems to Mostly Just Work…
I forked the GitHub repo, you can see the diff on top of keybase 2.7.3 here: bccaaf3096a
Eventually I ended up with a ~/go/bin/keybase which launches just fine. Meaning, I can main() okay. But the moment you try to do anything interesting, it looks super scary:

charlotte@sakuracity:~/go/bin ./keybase login
▶ WARNING Running in devel mode
▶ INFO Forking background server with pid=12932
▶ ERROR unexpected error in Login: API network error: doRetry failed,
attempts: 1, timeout 5s, last err: Get
https://localhost:3000/_/api/1.0/merkle/path.json?last=3784314&load_deleted=1&load_reset_chain=1&poll=10&sig_hints_low=3&uid=38ae1dfa49cd6831ea2fdade5c5d0519:
dial tcp [::1]:3000: connect: connection refused

There’s a few things about this error message that stuck out to me:

• Forking a background server? What?
• It’s trying to connect to localhost? That must be the server that doesn’t work …

Unfortunately, this nonfunctional “background server” sticks around even when a command as simple as ‘login’ command just failed:

charlotte@sakuracity:~/go/bin ps 12932
  PID TTY STAT    TIME COMMAND
  12932 ?   Ssl  0:00.21 ./keybase --debug --log-file
  /home/charlotte/.cache/keybase.devel/keybase.service.log service --chdir
  /home/charlotte/.config/keybase.devel --auto-forked 

I’m not exactly sure what the intended purpose of the “background server” even is, but fortunately we can kill it and even tell the keybase command to not even spawn one:

charlotte@sakuracity:~/go/bin ./keybase help advanced | grep -- --standalone
   --standalone                         Use the client without any daemon support.

And then we can fix wanting to connect to localhost by specifying an expected Keybase API server – how about the one hosted at https://keybase.io?

charlotte@sakuracity:~/go/bin ./keybase help advanced | grep -- --server
   --server, -s                         Specify server API.

Basically, what I’m trying to say is that if you specify both of these options, the keybase command does what I expect on NetBSD:

charlotte@sakuracity:~/go/bin ./keybase --standalone -s https://keybase.io login
▶ WARNING Running in devel mode
Please enter the Keybase passphrase for dressupgeekout (6+ characters): 

charlotte@sakuracity:~/go/bin ./keybase --standalone -s https://keybase.io id dressupgeekout
▶ WARNING Running in devel mode
▶ INFO Identifying dressupgeekout
✔ public key fingerprint: 7873 DA50 A786 9A3F 1662 3A17 20BD 8739 E82C 7F2F
✔ "dressupgeekout" on github:
https://gist.github.com/0471c7918d254425835bf5e1b4bcda00 [cached 2018-10-11
20:55:21 PDT]
✔ "dressupgeekout" on reddit:
    
      My Keybase proof [reddit:dressupgeekout = keybase:dressupgeekout] (D4emf2X3JH5vi4R-FvelGoUUkPGg4oQCk5XvYpZy0F8) from      KeybaseProofs    
    
[cached 2018-10-11 20:55:21 PDT]

###Initial implementation of draft-ietf-6man-ipv6only-flag

This change defines the RA "6" (IPv6-Only) flag which routers
may advertise, kernel logic to check if all routers on a link
have the flag set and accordingly update a per-interface flag.

If all routers agree that it is an IPv6-only link, ether_output_frame(),
based on the interface flag, will filter out all ETHERTYPE_IP/ARP
frames, drop them, and return EAFNOSUPPORT to upper layers.

The change also updates ndp to show the "6" flag, ifconfig to
display the IPV6_ONLY nd6 flag if set, and rtadvd to allow
announcing the flag.

Further changes to tcpdump (contrib code) are availble and will
be upstreamed.

Tested the code (slightly earlier version) with 2 FreeBSD
IPv6 routers, a FreeBSD laptop on ethernet as well as wifi,
and with Win10 and OSX clients (which did not fall over with
the "6" flag set but not understood).

We may also want to (a) implement and RX filter, and (b) over
time enahnce user space to, say, stop dhclient from running
when the interface flag is set.  Also we might want to start
IPv6 before IPv4 in the future.

All the code is hidden under the EXPERIMENTAL option and not
compiled by default as the draft is a work-in-progress and
we cannot rely on the fact that IANA will assign the bits
as requested by the draft and hence they may change.

Dear 6man, you have running code.

Discussed with: Bob Hinden, Brian E Carpenter

##Beastie Bits

• Running FreeBSD on macOS via xhyve
• Auction Winners
• OpenSSH Principals
• OpenBSD Foundation gets a second Iridium donation from Handshake
• NetBSD machines at Open Source Conference 2018 Kagawa
• Absolute FreeBSD now shipping!
• NextCloud on OpenBSD
• FreeBSD 12.0-BETA2 Available
• DTrace on Windows ported from FreeBSD
• HELBUG fall 2018 meeting scheduled – Thursday the 15th of November
• 35C3 pre-sale has started
• Stockholm BSD User Meeting: Tuesday Nov 13, 18:00 – 21:30
• Polish BSD User Group: Thursday Nov 15, 18:30 – 21:00

##Feedback/Questions

• Greg – Interview suggestion for the show
• Nelson – Ghostscript vulnerabilities
• Allison – Ports and GCC

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

The post Ghostly Releases | BSD Now 270 first appeared on Jupiter Broadcasting.

##Headlines
###FreeBSD Foundation Update, September 2018

• MESSAGE FROM THE EXECUTIVE DIRECTOR

Dear FreeBSD Community Member, It is hard to believe that September is over. The Foundation team had a busy month promoting FreeBSD all over the globe, bug fixing in preparation for 12.0, and setting plans in motion to kick off our 4th quarter fundraising and advocacy efforts. Take a minute to see what we’ve been up to and please consider making a donation to help us continue our efforts supporting FreeBSD!

• September 2018 Development Projects Update

In preparation for the release of FreeBSD 12.0, I have been working on investigating and fixing a backlog of kernel bug reports. Of course, this kind of work is never finished, and we will continue to make progress after the release. In the past couple of months I have fixed a combination of long-standing issues and recent regressions. Of note are a pair of UNIX domain socket bugs which had been affecting various applications for years. In particular, Chromium tabs would frequently hang unless a workaround was manually applied to the system, and the bug had started affecting recent versions of Firefox as well. Fixing these issues gave me an opportunity to revisit and extend our regression testing for UNIX sockets, which, in turn, resulted in some related bugs being identified and fixed.
Of late I have also been investigating reports of issues with ZFS, particularly, those reported on FreeBSD 11.2. A number of regressions, including a kernel memory leak and issues with ARC reclamation, have already been fixed for 12.0; investigation of other reports is ongoing. Those who closely follow FreeBSD-CURRENT know that some exciting work to improve memory usage on NUMA systems is now enabled by default. As is usually the case when new code is deployed in a diverse array of systems and workloads, a number of problems since have been identified. We are working on resolving them as soon as possible to ensure the quality of the release.
I’m passionate about maintaining FreeBSD’s stability and dependability as it continues to expand and grow new features, and I’m grateful to the FreeBSD Foundation for sponsoring this work. We depend on users to report problems to the mailing lists and via the bug tracker, so please try running the 12.0 candidate builds and help us make 12.0 a great release.

• Fundraising Update: Supporting the Project

It’s officially Fall here at Foundation headquarters and we’re heading full-steam into our final fundraising campaign of the year. We couldn’t even have begun to reach our funding goal of $1.25 million dollars without the support from the companies who have partnered with us this year. Thank you to Verisign for becoming a Silver Partner. They now join a growing list of companies like Xiplink, NetApp, Microsoft, Tarsnap, VMware, and NeoSmart Technologies that are stepping up and showing their commitment to FreeBSD!
Funding from commercial users like these and individual users like yourself, help us continue our efforts of supporting critical areas of FreeBSD such as:

• Operating System Improvements: Providing staff to immediately respond to urgent problems and implement new features and functionality allowing for the innovation and stability you’ve come to rely on.
• Security: Providing engineering resources to bolster the capacity and responsiveness of the Security team providing your users with piece of mind when security issues arise.
• Release Engineering: Continue providing a full-time release engineer, resulting in timely and reliable releases you can plan around.
• Quality Assurance: Improving and increasing test coverage, continuous integration, and automated testing with a full-time software engineer to ensure you receive the highest quality, secure, and reliable operating system.
• New User Experience: Improving the process and documentation for getting new people involved with FreeBSD, and supporting those people as they become integrated into the FreeBSD Community providing the resources you may need to get new folks up to speed.
• Training: Supporting more FreeBSD training for undergraduates, graduates, and postgraduates. Growing the community means reaching people and catching their interest in systems software as early as possible and providing you with a bigger pool of candidates with the FreeBSD skills you’re looking for.
• Face-to-Face Opportunities: Facilitating collaboration among members of the community, and building connections throughout the industry to support a healthy and growing ecosystem and make it easier for you to find resources when questions emerge .

We can continue the above work, if we meet our goal this year!
If your company uses FreeBSD, please consider joining our growing list of 2018 partners. If you haven’t made your donation yet, please consider donating today. We are indebted to the individual donors, and companies listed above who have already shown their commitment to open source.
Thank you for supporting FreeBSD and the Foundation!

• September 2018 Release Engineering Update

The FreeBSD Release Engineering team continued working on the upcoming 12.0 RELEASE. At present, the 12.0 schedule had been adjusted by one week to allow for necessary works-in-progress to be completed.
Of note, one of the works-in-progress includes updating OpenSSL from 1.0.2 to 1.1.1, in order to avoid breaking the application binary interface (ABI) on an established stable branch.
Due to the level of non-trivial intrusiveness that had already been discovered and addressed in a project branch of the repository, it is possible (but not yet definite) that the schedule will need to be adjusted by another week to allow more time for larger and related updates for this particular update.
Should the 12.0-RELEASE schedule need to be adjusted at any time during the release cycle, the schedule on the FreeBSD project website will be updated accordingly. The current schedule is available at:
https://www.freebsd.org/releases/12.0R/schedule.html

• BSDCam 2018 Trip Report: Marie Helene Kvello-Aune

I’d like to start by thanking the FreeBSD Foundation for sponsoring my trip to BSDCam(bridge) 2018. I wouldn’t have managed to attend otherwise. I’ve used FreeBSD in both personal and professional deployments since the year 2000, and over the last few years I have become more involved with development and documentation.
I arrived in Gatwick, London at midnight. On Monday, August 13, I took the train to Cambridge, and decided to do some touristy activities as I walked from the train station to Churchill College. I ran into Allan outside the hotel right before the sky decided it was time for a heavy rainfall. Monday was mostly spent settling in, recouping after travel, and hanging out with Allan, Brad, Will and Andy later in the afternoon/evening. Read more…

• Continuous Integration Update

The FreeBSD Foundation has sponsored the development of the Project’s continuous integration system, available at https://ci.FreeBSD.org, since June. Over the summer, we improved both the software and hardware infrastructure, and also added some new jobs for extending test coverage of the -CURRENT and -STABLE branches. Following are some highlights.

• New Hardware

The Foundation purchased 4 new build machines for scaling up the computation power for the various test jobs. These newer, faster machines substantially speed up the time it takes to test amd64 builds, so that failing changes can be identified more quickly. Also, in August, we received a donation of 2 PINE A64-LTS boards from PINE64.org, which will be put in the hardware test lab as one part of the continuous tests.

• CI Staging Environment

We used hardware from a previous generation CI system to build a staging environment for the CI infrastructure, which is available at
https://ci-dev.freebsd.org. It executes the configurations and scripts from the “staging” branch of the FreeBSD-CI repository, and the development feature branches. We also use it to experiment with the new version of the jenkins server and plugins. Having a staging environment avoids affecting the production CI environment, reducing downtime.

• Mail Notification

In July, we turned on failure notification for all the kernel and world build jobs. Committers will receive email containing the build information and failure log to inform them of possible problems with their modification on certain architectures. For amd64 of the -CURRENT branch, we also enabled the notification on failing regression test cases. Currently mail is sent only to the individual committers, but with help from postmaster team, we have created a dev-ci mailing list and will soon be also sending notifications there.

• New Test Job

In August, we updated the embedded script of the virtual machine image. Originally it only executed pre-defined tests, but now this behavior can be modified by the data on the attached disk. This mechanism is used for adding new ZFS tests jobs. We are also working on analyzing and fixing the failing and skipped test cases.

• Work in Progress

In August and September, we had two developer summits, one in Cambridge, UK and one in Bucharest, Romania. In these meetings, we discussed running special tests, such as ztest, which need a longer run time. We also planned the network testing for TCP/IP stack

###Daemonize – a Tiny C Library for Programming the UNIX Daemons

Whatever they say, writing System-V style UNIX daemons is hard. One has to follow many rules to make a daemon process behave correctly on diverse UNIX flavours. Moreover, debugging such a code might be somewhat tricky. On the other hand, the process of daemon initialisation is rigid and well defined so the corresponding code has to be written and debugged once and later can be reused countless number of times.
Developers of BSD UNIX were very aware of this, as there a C library function daemon() was available starting from version 4.4. The function, although non-standard, is present on many UNIXes. Unfortunately, it does not follow all the required steps to reliably run a process in the background on systems which follow System-V semantics (e.g. Linux). The details are available at the corresponding Linux man page. The main problem here, as I understand it, is that daemon() does not use the double-forking technique to avoid the situation when zombie processes appear.
Whenever I encounter a problem like this one, I know it is time to write a tiny C library which solves it. This is exactly how ‘daemonize’ was born (GitHub mirror). The library consists of only two files which are meant to be integrated into the source tree of your project. Recently I have updated the library and realised that it would be good to describe how to use it on this site.
If for some reason you want to make a Windows service, I have a battle tested template code for you as well.

• System-V Daemon Initialisation Procedure

To make discussion clear we shall quote the steps which have to be performed during a daemon initialisation (according to daemon(7) manual page on Linux). I do it to demonstrate that this task is more tricky than one might expect.

• So, here we go:

• Close all open file descriptors except standard input, output, and error (i.e. the first three file descriptors 0, 1, 2). This ensures that no accidentally passed file descriptor stays around in the daemon process. On Linux, this is best implemented by iterating through /proc/self/fd, with a fallback of iterating from file descriptor 3 to the value returned by getrlimit() for RLIMIT_NOFILE.

• Reset all signal handlers to their default. This is best done by iterating through the available signals up to the limit of _NSIG and resetting them to SIG_DFL.

• Reset the signal mask using sigprocmask().

• Sanitize the environment block, removing or resetting environment variables that might negatively impact daemon runtime.

• Call fork(), to create a background process.

• In the child, call setsid() to detach from any terminal and create an independent session.

• In the child, call fork() again, to ensure that the daemon can never re-acquire a terminal again.

• Call exit() in the first child, so that only the second child (the actual daemon process) stays around. This ensures that the daemon process is re-parented to init/PID 1, as all daemons should be.

• In the daemon process, connect /dev/null to standard input, output, and error.

• In the daemon process, reset the umask to 0, so that the file modes passed to open(), mkdir() and suchlike directly control the access mode of the created files and directories.

• In the daemon process, change the current directory to the root directory (/), in order to avoid that the daemon involuntarily blocks mount points from being unmounted.

• In the daemon process, write the daemon PID (as returned by getpid()) to a PID file, for example /run/foobar.pid (for a hypothetical daemon “foobar”) to ensure that the daemon cannot be started more than once. This must be implemented in race-free fashion so that the PID file is only updated when it is verified at the same time that the PID previously stored in the PID file no longer exists or belongs to a foreign process.

• In the daemon process, drop privileges, if possible and applicable.

• From the daemon process, notify the original process started that initialization is complete. This can be implemented via an unnamed pipe or similar communication channel that is created before the first fork() and hence available in both the original and the daemon process.

• Call exit() in the original process. The process that invoked the daemon must be able to rely on that this exit() happens after initialization is complete and all external communication channels are established and accessible.

The discussed library does most of the above-mentioned initialisation steps as it becomes immediately evident that implementation details for some of them heavily dependent on the internal logic of an application itself, so it is not possible to implement them in a universal library. I believe it is not a flaw, though, as the missed parts are safe to implement in an application code.

• The Library’s Application Programming Interface

The generic programming interface was loosely modelled after above-mentioned BSD’s daemon() function. The library provides two user available functions (one is, in fact, implemented on top of the other) as well as a set of flags to control a daemon creation behaviour.

• Conclusion

The objective of the library is to hide all the trickery of programming a daemon so you could concentrate on the more creative parts of your application. I hope it does this well.
If you are not only interested in writing a daemon, but also want to make yourself familiar with the techniques which are used to accomplish that, the source code is available. Moreover, I would advise anyone, who starts developing for a UNIX environment to do that, as it shows many intricacies of programming for these platforms.

##News Roundup
###EuroBSDCon 2018 travel report and obligatory pics

This was my first big BSD conference. We also planned – planned might be a big word – thought about doing a devsummit on Friday. Since the people who were in charge of that had a change of plans, I was sure it’d go horribly wrong.
The day before the devsummit and still in the wrong country, I mentioned the hours and venue on the wiki, and booked a reservation for a restaurant.
It turns out that everything was totally fine, and since the devsummit was at the conference venue (that was having tutorials that day), they even had signs pointing at the room we were given. Thanks EuroBSDCon conference organizers!
At the devsummit, we spent some time hacking. A few people came with “travel laptops” without access to anything, like Riastradh, so I gave him access to my own laptop. This didn’t hold very long and I kinda forgot about it, but for a few moments he had access to a NetBSD source tree and an 8 thread, 16GB RAM machine with which to build things.
We had a short introduction and I suggested we take some pictures, so here’s the ones we got. A few people were concerned about privacy, so they’re not pictured. We had small team to hold the camera
At the actual conference days, I stayed at the speaker hotel with the other speakers. I’ve attempted to make conversation with some visibly FreeBSD/OpenBSD people, but didn’t have plans to talk about anything, so there was a lot of just following people silently.
Perhaps for the next conference I’ll prepare a list of questions to random BSD people and then very obviously grab a piece of paper and ask, “what was…”, read a bit from it, and say, “your latest kernel panic?”, I’m sure it’ll be a great conversation starter.
At the conference itself, was pretty cool to have folks like Kirk McKusick give first person accounts of some past events (Kirk gave a talk about governance at FreeBSD), or the second keynote by Ron Broersma.
My own talk was hastily prepared, it was difficult to bring the topic together into a coherent talk. Nevertheless, I managed to talk about stuff for a while 40 minutes, though usually I skip over so many details that I have trouble putting together a sufficiently long talk.
I mentioned some of my coolest bugs to solve (I should probably make a separate article about some!). A few people asked for the slides after the talk, so I guess it wasn’t totally incoherent.
It was really fun to meet some of my favourite NetBSD people. I got to show off my now fairly well working laptop (it took a lot of work by all of us!).
After the conference I came back with a conference cold, and it took a few days to recover from it. Hopefully I didn’t infect too many people on the way back.

###GhostBSD tested on real hardware T410 – better than TrueOS?

You might have heard about FreeBSD which is ultimately derived from UNIX back in the days. It is not Linux even though it is similar in many ways because Linux was designed to follow UNIX principles. Seeing is believing, so check out the video of the install and some apps as well!

Nowadays if you want some of that BSD on your personal desktop how to go about? Well there is a full package or distro called GhostBSD which is based on FreeBSD current with a Mate or XFCE desktop preconfigured. I did try another package called TrueOS before and you can check out my blog post as well.

Let’s give it a try on my Lenovo ThinkPad T410. You can download the latest version from ghostbsd.org. Creating a bootable USB drive was surprisingly difficult as rufus did not work and created a corrupted drive. You have to follow this procedure under Windows: download the 2.5GB .iso file and rename the extension to .img. Download Win32 Disk imager and burn the img file to an USB drive and boot from it. You will be able to start a live session and use the onboard setup to install GhostBSD unto a disk.

I did encounter some bugs or quirks along the way. The installer failed the first time for some unknown reason but worked on the second attempt. The first boot stopped upon initialization of the USB3 ports (the T410 does not have USB3) but I could use some ‘exit’ command line magic to continue. The second boot worked fine. Audio was only available through headphones, not speakers but that could partially be fixed using the command line again. Lot’s of installed apps did not show up in the start menu and on goes the quirks list.

Overall it is still better than TrueOS for me because drivers did work very well and I could address most of the existing bugs.

• On the upside:

• Free and open source FreeBSD package ready to go

• Mate or XFCE desktop (Mate is the only option for daily builds)

• Drivers work fine including LAN, WiFi, video 2D & 3D, audio, etc

• UFS or ZFS advanced file systems available

• Some downsides:

• Less driver and direct app support than Linux

• Installer and desktop have some quirks and bugs

• App-store is cumbersome, inferior to TrueOS

##Beastie Bits

• EuroBSDCon 2018 and NetBSD sanitizers
• New mandoc feature: -T html -O toc
• EuroBSDcon 2018
• Polish BSD User Group
• garbage[43]: What year is it?
• The Demo @ 50
• Microsoft ports DTrace from FreeBSD to Windows 10
• OpenBSD joins Twitter
• NetBSD curses ripoffline improvements
• FCP-0101: Deprecating most 10/100 Ethernet drivers
• Announcing the pkgsrc-2018Q3 release
• Debian on OpenBSD vmd (without qemu or another debian system)
• A BSD authentication module for duress passwords (Joshua Stein)
• Disk Price/Performance Analysis

##Feedback/Questions

• DJ – Zombie ZFS
• Josua – arm tier 1? how to approach it
• -Gamah – 5ghz

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

The post Tiny Daemon Lib | BSD Now 269 first appeared on Jupiter Broadcasting.

Coming up this week, we’ll be chatting with Lucas Holt, founder of MidnightBSD. It’s a slightly lesser-known fork of FreeBSD, with a focus on easy desktop use. We’ll find out what’s different about it and why it was created. Answers to your emails and all this week’s news, on BSD Now – the place to B.. SD.

Thanks to:

• Get Paid to Write for DigitalOcean

Direct Download:

Video | HD Video | MP3 Audio | OGG Audio | Torrent | YouTube

RSS Feeds:

MP3 Feed | OGG Feed | iTunes Feed | Video Feed | HD Vid Feed | HD Torrent Feed

– Show Notes: –

Headlines

Zocker, it’s like docker on FreeBSD

• Containment is always a hot topic, and docker has gotten a lot of hype in Linux land in the last couple years – they’re working on native FreeBSD support at the moment
• This blog post is about a docker-like script, mainly for ease-of-use, that uses only jails and ZFS in the base system
• In total, it’s 1,500 lines of shell script
• The post goes through the process of using the tool, showing off all the subcommands and explaining the configuration
• In contrast to something like ezjail, Zocker utilizes the jail.conf system in the 10.x branch

Patrol Read in OpenBSD

• OpenBSD has recently imported some new code to support the Patrol Read function of some RAID controllers
• In a nutshell, Patrol Read is a function that lets you check the health of your drives in the background, similar to a zpool “scrub” operation
• The goal is to protect file integrity by detecting drive failures before they can damage your data
• It detects bad blocks and prevents silent data corruption, while marking any bad sectors it finds

HAMMER 2 improvements

• DragonFly BSD has been working on the second generation HAMMER FS
• It now uses LZ4 compression by default, which we’ve been big fans of in ZFS
• They’ve also switched to a faster CRC algorithm, further improving HAMMER’s performance, especially when using iSCSI

FreeBSD foundation May update

• The FreeBSD foundation has published another update newsletter, detailing some of the things they’ve been up to lately
• In it, you’ll find some development status updates: notably more ARM64 work and the addition of 64 bit Linux emulation
• Some improvements were also made to FreeBSD’s release building process for non-X86 architectures
• There’s also an AsiaBSDCon recap that covers some of the presentations and the dev events
• They also have an accompanying blog post where Glen Barber talks about more sysadmin and clusteradm work at NYI

Interview – Lucas Holt – questions@midnightbsd.org / @midnightbsd

MidnightBSD

News Roundup

The launchd on train is never coming

• Replacement of init systems has been quite controversial in the last few years
• Fortunately, the BSDs have avoided most of that conflict thus far, but there have been a few efforts made to port launchd from OS X
• This blog post details the author’s opinion on why he thinks we’re never going to have launchd in any of the BSDs
• Email us your thoughts on the matter

Native SSH comes to… Windows

• In what may be the first (and last) mention of Microsoft on BSD Now…
• They’ve just recently announced that PowerShell will get native SSH support in the near future
• It’s not based on the commercial SSH either, it’s the same one from OpenBSD that we already use everywhere
• Up until now, interacting between BSD and Windows has required something like PuTTY, WinSCP, FileZilla or Cygwin – most of which are based on really outdated versions
• The announcement also promises that they’ll be working with the OpenSSH community, so we’ll see how many Microsoft-submitted patches make it upstream (or how many donations they make)

Moving to FreeBSD

• This blog post describes a long-time Linux user’s first BSD switching experience
• The author first talks about his Linux journey, eventually coming to love the more customization-friendly systems, but the journey ended with systemd
• After doing a bit of research, he gave FreeBSD a try and ended up liking it – the rest of the post mostly covers why that is
• He also plans to write about his experience with other BSDs, and is writing some tutorials too – we’ll check in with him again later on

Feedback/Questions

• Adam writes in
• Dan writes in
• Ivan writes in
• Josh writes in

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
• There’s a new LibreSSL mailing list for discussion and announcements, subscribe if you’re interested
• Next week is a prerecorded episode since we’ll be at BSDCan
• If you’re interested in doing an interview at the conference, send us an email now and we can prepare some questions ahead of time

The post BSD After Midnight | BSD Now 92 first appeared on Jupiter Broadcasting.

This week we\’re at AsiaBSDCon, so it\’ll be a shorter episode. We\’ve got an interview with Eric Turgeon, founder of the desktop-focused GhostBSD project. Haven\’t heard of GhostBSD? Well stay tuned then. We\’ll be back next week with a normal episode.

Thanks to:

Direct Download:

Video | HD Video | MP3 Audio | OGG Audio | Torrent | YouTube

RSS Feeds:

MP3 Feed | OGG Feed | iTunes Feed | Video Feed | HD Vid Feed | HD Torrent Feed

– Show Notes: –

Interview – Eric Turgeon – ericturgeon@ghostbsd.org / @GhostBSD1

GhostBSD

Feedback/Questions

• Dave writes in
• Shane writes in
• Rob writes in
• Predrag writes in

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
• We especially want to hear some tutorial ideas that you guys would like to see
• If you have something you want to talk about on the show – anything cool involving BSD, whether you\’re a developer or not – we\’d be glad to interview you, just get in touch with us
• Watch live Wednesdays at 2:00PM Eastern (19:00 UTC)

The post Ghost of Partition | BSD 28 first appeared on Jupiter Broadcasting.

Anti-sec posts 1 million Apple UDIDs they claim to have stolen from the FBI, but what was the FBI doing with them in the first place?

More infrastructure switches vulnerabilities, and a great batch of audience questions and our answers!

All that and a lot more on this week’s TechSNAP!

Thanks to:

Use our codes TechSNAP10 to save 10% at checkout, or TechSNAP20 to save 20% on hosting!

SPECIAL OFFER! Save 20% off your order!
Code: go20off5

Pick your code and save:
techsnap7: $7.49 .com
techsnap10: 10% off
techsnap11: $1.99 hosting for the first 3 months
techsnap20: 20% off 1, 2, 3 year hosting plans
techsnap40: $10 off $40
techsnap25: 25% off new Virtual DataCenter plans
techsnapx: 20% off .xxx domains

 

Support the Show: