PC-BSD Evolves into TrueOS (MeetBSD California 2016)

MeetBSD 2016MeetBSD 2016
PC-BSD Evolves into TrueOSPC-BSD Evolves into TrueOS
Kris MooreKris Moore
kris@ixsystems.comkris@ixsystems.com

PC-BSD Evolves into TrueOS
● After 10+ years of PC-BSD, the project team has taken an
important step and decided to re-brand
● Often asked questions include:
– Why?
 What has changed under the hood?
 Will PC-BSD users be able to upgrade?

● First, lets take a look at some of the reasoning behind the
name change
– Alphabet-soup
– The “PC” term doesn't properly reflect the capabilities
and vision of the project
– So much has changed internally and with release
process
–

● So what changed internally?
– The entire release model has undergone an overhaul
– Historically PC-BSD has closely mirrored FreeBSD's
release cycle, tracking -RELEASE
– In late 2015 PC-BSD began to release monthly
-CURRENT images, which quickly became the driving
factor in new user adoption and development
– TrueOS embraces -CURRENT fully, now a rolling
release updated typically bi-monthly
–

● Why the shift to a rolling-release model?
– Allows modern hardware to be used in a more timely
fashion
– Allows users and developers access to much more
cutting edge features
– Fills an important usability gap of -CURRENT for binary-
only users

● What changed to make a rolling-release possible?
– In mid~ 2016, we began to make the shift over to
package base
– freebsd-update, while great for -RELEASE was too
disruptive to the workflow for binary updating on
-CURRENT
– This coupled with our extensive use of ZFS for updating,
made it easy and safe to do so

● How does TrueOS use handle binary updating?
– PC-BSD originally started using ZFS + Boot-
Environments several years back
– These updates were performed as background tasks,
into a “new” BE
– TrueOS expands upon this idea with some important key
differences

● How does TrueOS updating differ from PC-BSD?
– In TrueOS updating has been broken down into stages
– Background updating involves downloading packages
only, verification of checksums before halting
– At shutdown time, 2nd
stage is kicked off (via init), creating
a new BE which doesn't lose changes to the parent

● Differences between PC-BSD & TrueOS Updating (contd)
– Update manager (pc-updatermanager) is self-updating
– UI now provides shutdown options to skip pending
updates if not convenient
– Should an update go sideways, the BE is never made
active and error log is kept

● What about dealing with ABI changes from -CURRENT?
– Some additional tooling and seat-belts had to be created
to deal with this challenge
– During the package update phase, incoming ABI
changes are monitored which triggers a full package
update (pkg update -f)
– When performing package installation, a sanity check
runs to ensure ABI on remote matches local

● How much has TrueOS diverged from FreeBSD?
– In some ways it has grown closer:
– Moved back to the BSD loader by default, replacing
GRUB
– Tracking -CURRENT gives more timely feedback to
FreeBSD developers who often no longer are running
-RELEASE builds
–

● In other ways TrueOS has embraced change
– Importing LibreSSL into base (Thanks to Barnard Spil!)
– Importing newer Xorg/DRM patches from upstream work
done by Matt Macy
– Different port defaults that make sense for a desktop
environment (Pulseaudio for example)
– Removed Clang / LLVM from base
–

● Why LibreSSL?
– Over the past decade of PC-BSD, we've also been bit be
some of the “worst offenders” for security updates
– OpenSSL has been a very high profile target
– OpenBSD does a good job “culling” old cruft, which has
resulted in a smaller security footprint
– TrueOS defaults to OpenNTP for similar reasons

● What about LibreSSL updates breaking ABI?
– The rolling nature of TrueOS makes this a non-issue for
our workflow
– This makes it easier to pull in newer versions, without
needing to backport specific security patches
–
–

● What are these new DRM/KMS changes?
– Matt Macy has done some amazing work to bulk lift
FreeBSD's kernel graphics stack and get caught up with
Linux
– Currently TrueOS uses Linux DRM 4.7, but (hopefully)
4.8 is around the corner
– This includes support for later Intel video chipsets, up to
and including Skylake

● Why was Clang removed?
– Having a compiler in the base system (while sometimes
handy), just isn't required for the largest % of users
– This saves us quite a few MB from a default install, and
most users don't notice
– Developers will be prompted to install llvm38 from
packages if they try to compile

● What sort of port defaults does TrueOS use?
– Going through the list would be tedious, but you can
check it out: (http://bit.ly/2fn6arC)
– Some of the highlights include PULSE support
(More on that later), options to enable LibreSSL, and
Features (Such as NONECIPHER for openssh-portable)
–
–

● Most of these changes take place behind the scenes, what
has changed for Desktop users?
– Defaults to its own home-grown Lumina Desktop
Environment
– Also includes its own PCDM login manager, which
includes specific features required for other projects.
– PC-BSD control panel has been retired in favor of
SysAdm

● Why have you switched to Lumina?
– For many years, PC-BSD had tried to remain “Desktop
Agnostic”. While this was popular, it simply became too
costly to maintain
– Many of the various $DESKTOP FreeBSD porting teams
are burning lots of cycles just trying to keep up with
upstream
– Lumina on the other-hand, was born on PC-BSD and
allowed us to spend less time patching and more time
developing features we care about

● Why have you switched to Lumina? (Continued...)
– Since we've switched, we've been able to focus our
limited development hours on adding new features such
as:
● Update Manager Support
● Integration with ZFS
● Proper utilities for display, sound, and network
management on a native FreeBSD environment.

● What is PCDM and how has it changed for TrueOS?
– PCDM (PC-BSD Desktop Manager – Time for a name
change?) is our home-grow replacement for Login
Managers such as GDM / KDM, SLIM and others
– On PC-BSD it added features for GELI / PEFS home
directory encryption
– On TrueOS it grows features such as HiDPI, and support
for the upcoming TrueOS “Pico” client logins

● What is this “SysAdm” utility?
– Historically we've grouped various management UI's
together into the PC-BSD Control Panel
– This has been overhauled with a single “SysAdm” utility
– It is made up of a couple components, including a server
backend that provides a REST and WebSockets API
– The Qt based client can be used to “Remote control”
other systems, including headless servers

● What other things can SysAdm do?
– Can control multiple systems from a single application
– Communication over Secure WebSockets (wss://)
– UI's for Task Management, System Updates, Packages,
Boot-Environments and much more
– Able to import/export configuration (Encrypted on disk)

● What other things can SysAdm do? (Continued)
– Notification manager for system monitoring
– Multi-Platform (Currently TrueOS, OSX and Windows)
–

● How about upgrades for existing PC-BSD users?
– Due to the nature of the upgrade, we decided against
offering a standard “binary” update
– We realize that wiping the disk is normally not an ideal
situation as well, so another method was devised
The TrueOS installation media now provides a
mechanism we call “Non-Destructive Fresh Installation”

● How does a non-destructive fresh install work?
– Due to PC-BSD's exclusive use of ZFS for many years
now, TrueOS was able to leverage this in a unique way.
– The installer (pc-sysinstall) and Qt front-end now will
detect the presence of an existing zpool with Boot-
Environments.
– If detected, an option to install into a new BE is
presented.

● How does a non-destructive fresh install work? (Continued)
– Datasets such as /usr/home aren't included in a BE,
allowing them to “float” between different BEs
– This never touches the disk / partitioning, if the user
wants to re-partition or change boot-loaders, that will still
require a destructive installation
– Post-install the user can run the “beadm” command to
mount and copy data from an old BE.

● How does a non-destructive fresh install work? (Continued)
– This enables the user to do a “try before you buy”
approach, testing out upgrades for functionality
– Until the old BE is destroyed, you can revert at any time

● These are features in TrueOS *Right Now*. What do you
have cooking in the lab?
– We currently have a couple different things about to
emerge from the workshop:
● A replacement init system (Well rc anyway)
● TrueOS Pico

● ZOMG, a new init system? Its not systemd is it???
– NO
– After evaluating many options, we felt the best way
forward was OpenRC

● First up, why a new Init / RC system?
– Init systems have been something under a lot of
discussion in recent years
– From the PC-BSD perspective, we've found the legacy
init to be a bit limiting and cumbersome at times
– In particular with Laptop usage (especially without
suspend/resume) a boot time of 60+ seconds really
bums us out
–

● Why OpenRC?
– Two clause BSD license
– Still in active development
– Originates from a NetBSD developer (Roy Marples)
– Doesn't require re-inventing the wheel
– Also doesn't requiring replace /sbin/init as PID 1

● So far the results have been promising
– We've integrated it directly into our FreeBSD base tree
(Replacing all their gmake ← yuck)
– Boot times show dramatic improvement
– Able to use updated wpa_supplicant, dhcpcd and others
from ports
– Work is ongoing to provide openrc service scripts via our
ports/packages
–
–

● So far the results have been promising
– “service” command has nearly identical usage
– Should be available in next round of package updates
– Joe Maloney is spearheading the effort, and will most
likely give some talks about it in 2017
– That 60-80 second boot-time is closer to 20 seconds
now.
–
–

● OK, so what is this “TrueOS Pico” you've mentioned?
– Short Version – ARM version of TrueOS, specifically
designed to operate as a “Thin Client” extension.
– Long Version – I've been struggling to find a good use for
several of these RPI2 devices sitting on my desk

● How does the Pico work?
It's split into two parts, the Pico Server (TrueOS
Desktop/Server) and the ARM image
– The server operates as a MDNS advertiser, and clients
use MDNS to search for a server
– Once a server is located, the client and server perform
some REST chatter, SSH keys are created and
exchanged and a SSH X11 forwarding session is started

● OK, so how does the Pico work? (Continued...)
– On the server side:
● # pkg install picoserver
● # service picoserver onestart

– On the client side:
● - Fetch the image
● - Decompress and 'dd'
● - Plug and play

– On the server side, all configuration knobs can be tuned
in /usr/local/etc/picoserver.ini
– The client is a zero-config setup
– After making changes on the server side, you can “kick”
clients to force a reboot of the client, which will perform a
re-configuration of the session
–

● What sort of features are supported?
– At the moment we support the following optional
features:
● - SSH Tuning options (Cipher, compression levels)
● - Enable/Disable Audio (PulseAudio)
● - Enable/Disable VirtualGL

● Why would I want a Pico thin-client?
– Inexpensive
– Less systems to manage
– Can login to any user-account from any client
– (I have lots of kids – All these appeal to me!)

● How's the performance of the RPI2?
– Boarder-line – Acceptable for “lite” desktop computing.
– Basic email, web-browsing, that kind of thing
– Where the system struggles is with lots of changing
pixels
– This is partly due to CPU usage of the “scfb” driver, also
partly due to the USB 100Mbps NIC

● So what can be done to improve it?
– Moving to a faster platform – The RPI3 looks attractive,
but still may run out of gas with full-screen workloads
– The Banana-Pi-M3(?) might be another good reference
device, with a dedicated 1Gbps nic
– Better video driver – Maybe porting over fbturbo?

● With so much going on, where do you guys need help?
– Everywhere!
– In particular:
● - Kernel / Device Drivers
● - Patching ports for -CURRENT
● - Testing or better yet, bug-fixing
–

● Enough of the arranged questions. What about my
question?
– - Ask away!

Thank You!
Kris Moore
kris@ixsystems.com

PC-BSD Evolves into TrueOS (MeetBSD California 2016)

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (18)

Plus de iXsystems

Plus de iXsystems (7)

Dernier

Dernier (20)

PC-BSD Evolves into TrueOS (MeetBSD California 2016)