pc-bsd evolves into trueos (meetbsd california 2016)

MeetBSD 2016

PC-BSD Evolves into TrueOS

Kris [email protected]


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 changeAlphabet-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 changeImporting 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 devisedThe 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 promisingWe'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 promisingservice 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 imageThe 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


OK, so how does the Pico work? (Continued...)On the client side:- Fetch the image

- Decompress and 'dd'

- Plug and play


OK, so how does the Pico work? (Continued...)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
[email protected]

Click to edit the title text format

/

pc-bsd evolves into trueos (meetbsd california 2016)

Technology