OmniOS Community Edition r151028t, r151026at, r151022cr OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 18th of March 2019 are now available.

The following fixes are available for all supported releases:

In addition, for r151028 only:

  • A new system/network/cdp package is available that provides a service that uses Cisco Discovery Protocol to advertise the local host to neighbouring switches, and to maintain a table of neighbours that can be viewed via cdpadm show nei. This new service was contributed by Prominic.NET.

For further details, please see https://omniosce.org/releasenotes


Any problems or questions, please get in touch.

Tweaking the Tribblix installer The Trouble with Tribbles...

In the latest update to Tribblix, I've made a couple of minor tweaks to the installer.

The first is that compression (lz4) is now enabled on the root pool by default. It was possible in the past to give the -C flag to the installer, but now it's always on. There was a time in the past (the distant past) when enabling gzip compression could really hurt performance with some workloads, but the world has moved on, so enabling compression by default is a good thing.

The compression factor you see on something like the AWS image is:

NAME                 PROPERTY       VALUE  SOURCE
rpool                compressratio  1.92x  -
rpool/ROOT           compressratio  1.92x  -
rpool/ROOT/tribblix  compressratio  1.92x  -
rpool/export         compressratio  1.00x  -
rpool/export/home    compressratio  1.00x  -
rpool/swap           compressratio  2.04x  -

It's not bad, getting a factor of almost 2 essentially for free.

The second change is to partitioning. Traditionally, the root pool was created in a partition rather than the whole disk. You made the partition span the whole disk, but the disk was still partitioned in the traditional way.

As of m20.6, if you use -G instead of -B to the installer

./live_install.sh -G c1t0d0 [overlays...]

then it will create a whole disk pool with EFI System partition to support booting system with UEFI firmware. (As it says in the zpool man page.) Good for newer systems, but it brings another key capability.

For EC2 instances, this allows the rpool to be expanded. The base size is still 8G, but you can choose a different (larger) size for the EBS device when creating the instance:

When you initially log in, you still get the original size:

NAME    SIZE  ALLOC   FREE
rpool  7.50G   301M  7.21G

but you can use the following command:

zpool online -e rpool c2t0d0

and it magically expands to use the available space:

NAME    SIZE  ALLOC   FREE
rpool  11.5G   302M  11.2G

At the moment, this has to be done manually, but in future this expansion will happen automatically when the instance boots.

You can, of course, increase the size of an EBS volume while the instance is running. This takes a little while (the State is shown as "in-use - optimizing" while the expansion takes place). Unfortunately it appears at the moment that you need a reboot for the instance to rescan the devices so it knows there's more space.

OmniOS Community Edition r151028r, r151026ar, r151022cp OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 4th of March 2019 are now available. These are important system security updates which require a reboot.

The following fixes are available for all supported releases:

For further details, please see https://omniosce.org/releasenotes


Any problems or questions, please get in touch.

Apache 2.4 is 64-bit-only now openindiana

With merge of PR #4800 Apache 2.4 has become 64-bit-only.
This is a big breaking change, because we’ve reworked Apache directory layout and configuration to facilitate IPS switch to Python 3.5.
Python 3.5 is 64-bit-only, and we had an unpleasant choice either rewrite depot and sysrepo configuration to always use 64-bit Apache version or make Apache 2.4 64-bit-only.
Also to avoid ugliness which was necessary to allow users transparently switch from 32-bit or 64-bit version with existing configs to new 64-bit only version and possible incompatibilities, we decided to break current Apache 2.4 installations on upgrade, so that administrators could immediately see the issue.

Now you know, your apache server is broken. What should you do?

  • Don’t panic.
  • Read apache24(1m).
  • If you’ve changed /etc/apache2/2.4/httpd.conf, /etc/apache2/2.4/httpd.conf.new will contain new version necessary for updated Apache2.4 to work correctly. So, merge two files manually, preserving your local changes. As you can see, /etc/apache2/2.4/conf.d/modules-*.load files have gone, and you have to include LoadModule directives either in /etc/apache2/2.4/conf.d/*.conf files or in /etc/apache2/2.4/httpd.conf directly
  • mpm_event module is used by default (if you don’t overwrite it in svc:/network/http:apache24 instance httpd/MPM property). So, fix your configuration files to avoid relying on IfModule prefork.c.
  • 64bit is not set now, so fix configuration files relying on it

Happy updating!

OmniOS Community Edition r151028q, r151026aq, r151022co OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 26th of February 2019 are now available. These are all non-reboot updates.

In all releases, The openssl and curl packages have been updated to address a security vulnerability. In r151028, there is also an update to the vim text editor.

For further details, please see https://omniosce.org/releasenotes


Any problems or questions, please get in touch.

Building illumos-gate on AWS (2019 version) The Trouble with Tribbles...

I've covered building illumos on AWS before, but the instructions there are a bit out of date. Of course, these will become outdated too, in time, but should still be useful.

First spin up an EC2 instance, the AMI you want to use for this is "Tribblix-m20.5", ami-7cf2181b in London. (If you want to use a different region, then you'll have to copy the AMI.)

For instance size, try an m4.2xlarge - a t2.micro really won't cut it, you won't even be able to install the packages. With an m4.2xlarge you're looking at 30-45 minutes to build illumos, depending on whether debug is enabled.

Add an external EBS device of at least 8G, there isn't enough space on the AMI's root partition to handle the build. When you add it, attach it at /dev/sdf (there's no real reason for this, but that will match the zpool create below).

Once it's booted up (I assume you know about security groups and keypairs, so you can ssh in as root), then the first thing you need to do is update the image:

zap refresh
zap update-overlay -a

Install the illumos-build overlay and tweak the install

zap install-overlay illumos-build
rm -f /usr/bin/cpp
cd /usr/bin ; ln -s ../gnu/bin/xgettext gxgettext

Create a user and a storage pool for them to use

zpool create -O compression=lz4 illumos c2t5d0
useradd -g staff -d /illumos -s /bin/bash illumos
chown illumos /illumos
passwd illumos

Log in as illumos, and clone the gate. What I do here is have a reference copy of the gate, and then I can clone that very quickly locally every time I want to do a build.

mkdir ${HOME}/Illumos-reference
cd ${HOME}/Illumos-reference
git clone https://github.com/illumos/illumos-gate

If you want to create omnitribblix too

git clone https://github.com/omniosorg/illumos-omnios

Clone the relevant Tribblix repo

mkdir ${HOME}/Tribblix
cd ${HOME}/Tribblix
git clone https://github.com/tribblix/tribblix-build

The scripts need to know where the Tribblix repo(s) are checked out

export THOME=${HOME}/Tribblix
Create a build area with the gate checked out

mkdir ${HOME}/Illumos
cd ${HOME}/Illumos
git clone ${HOME}/Illumos-reference/illumos-gate

and if you want to build omnitribblix too

git clone ${HOME}/Illumos-reference/illumos-omnios omnitribblix

You need the closed tarballs

wget -c \
  https://download.joyent.com/pub/build/illumos/on-closed-bins.i386.tar.bz2 \
  https://download.joyent.com/pub/build/illumos/on-closed-bins-nd.i386.tar.bz2

Right, you're now ready to do a build.

cd illumos-gate

For a release build:

${THOME}/tribblix-build/illumos/releasebuild m20.6

For a debug build with a gcc7 shadow

${THOME}/tribblix-build/illumos/debugbuild

For a debug build without the gcc7 shadow

${THOME}/tribblix-build/illumos/debugbuild -q
For omnitribblix, which assumes (and requires) that you've done a vanilla gate build first

cd ${HOME}/Illumos/omnitribblix
${THOME}/tribblix-build/illumos/omnibuild m20lx.6
And there you have it, you should have a beautiful cleanly built gate.

This differs from my previous recipe in a couple of key ways:
  1. I no longer require you to build in a zone, although I would still recommend doing so if you want to use the system for other things. But as this is an AWS instance, we can dedicate it to gate building
  2. It's far more scripted. If you want to see what it's really doing, look inside the releasebuild, debugbuild, and omnibuild scripts.
 Next time, I'll cover how the files from the build are converted into packages.

Modifying boot files with SmartOS under Loader Staring at the C

With the advent of newboot in SmartOS/Triton, newly-installed systems will use loader as the bootloader, replacing grub. See RFD 156 for some technical background on the motivation of the switch.

It's often the case that people want to make some modification to an /etc file in subsequent SmartOS boots. As we boot from ramdisk, we can't just directly modify the files. As originally described on Keith's blog the way to get around this problem involves specifying specific files to over-ride the default.

Obviously this has changed under loader. Let's presume we want to over-ride /etc/system to set kmem_flags. First, let's take a copy of our file and edit it:


# sdc-usbkey mount
/mnt/usbkey
# mkdir -p /mnt/usbkey/etc
# cp /etc/system /mnt/usbkey/etc/ # or /mnt/usbkey/kernel/drv/dtrace.conf etc.
# echo "set kmem_flags=0xf" >>/mnt/usbkey/etc/system
Now we want loader to prepare this file as a bootfs module. In grub, we used something like "module /os/bootfs/etc/system type=file name=etc/system". For loader, it's similar:

# cd /mnt/usbkey/boot
# echo etc_system_load=YES >>loader.conf.local
# echo etc_system_type=file >>loader.conf.local
# echo etc_system_name=/etc/system >>loader.conf.local
The prefix (etc_system_) is fairly arbitrary, though often named after the module. For each file you want, you'd want a _load, _type, and _name entry specified.

Note that loader is a little more restrictive than grub: we need the path to match exactly (so no /os/bootfs sub-directory). If this all worked OK, then we should see during boot something like:


Loading /os/20190207T125627Z/platform/i86pc/kernel/amd64/unix...
Loading /os/20190207T125627Z/platform/i86pc/amd64/boot_archive...
Loading /os/20190207T125627Z/platform/i86pc/amd64/boot_archive.hash...
Loading /etc/system...
Booting...
SunOS Release 5.11 Version joyent_20190209T105033Z 64-bit
Copyright (c) 2010-2019, Joyent Inc. All rights reserved.
WARNING: High-overhead kmem debugging features enabled (kmem_flags = 0xf)...
And we should find a copy of our modified file here:

# tail /system/boot/os/etc/system
* Use hires tick to improve some scheduling latency issues
set hires_tick=1

*
* The "buildstamp" module contains information about the git sources used to
* build the operating system image. Once loaded, the driver will refuse to
* detach. We load it early to ensure it is in a crash dump wherever possible.
*
forceload: drv/buildstamp
set kmem_flags=0xf

OmniOS Community Edition r151028o, r151026ao, r151022cm OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 11th of February 2019 are now available. These are all non-reboot updates.

In all releases, The mercurial and curl packages have been updated to address security vulnerabilities. There is also an additional change to fix a problem where some pkg operations could take up to two minutes longer than necessary.

For further details, please see https://omniosce.org/releasenotes


Any problems or questions, please get in touch.

Reflecting on The Soul of a New Machine The Observation Deck

Long ago as an undergraduate, I found myself back home on a break from school, bored and with eyes wandering idly across a family bookshelf. At school, I had started to find a calling in computing systems, and now in the den, an old book suddenly caught my eye: Tracy Kidder’s The Soul of a New Machine. Taking it off the shelf, the book grabbed me from its first descriptions of Tom West, captivating me with the epic tale of the development of the Eagle at Data General. I — like so many before and after me — found the book to be life changing: by telling the stories of the people behind the machine, the book showed the creative passion among engineers that might otherwise appear anodyne, inspiring me to chart a course that might one day allow me to make a similar mark.

Since reading it over two decades ago, I have recommended The Soul of a Machine at essentially every opportunity, believing that it is a part of computing’s literary foundation — that it should be considered our Odyssey. Recently, I suggested it as beach reading to Jess Frazelle, and apparently with perfect timing: when I saw the book at the top of her vacation pile, I knew a fuse had been lit. I was delighted (though not at all surprised) to see Jess livetweet her admiration of the book, starting with the compelling prose, the lucid technical explanations and the visceral anecdotes — but then moving on to the deeper technical inspiration she found in the book. And as she reached the book’s crescendo, Jess felt its full power, causing her to reflect on the nature of engineering motivation.

Excited to see the effect of the book on Jess, I experienced a kind of reflected recommendation: I was inspired to (re-)read my own recommendation! Shortly after I started reading, I began to realize that (contrary to what I had been telling myself over the years!) I had not re-read the book in full since that first reading so many years ago. Rather, over the years I had merely revisited those sections that I remembered fondly. On the one hand, these sections are singular: the saga of engineers debugging a nasty I-cache data corruption issue; the young engineer who implements the simulator in an impossibly short amount of time because no one wanted to tell him that he was being impossibly ambitious; the engineer who, frustrated with a nanosecond-scale timing problem in the ALU that he designed, moved to a commune in Vermont, claiming a desire to deal with “no unit of time shorter than a season”. But by limiting myself to these passages, I was succumbing to the selection bias of my much younger self; re-reading the book now from start to finish has given new parts depth and meaning. Aspects that were more abstract to me as an undergraduate — from the organizational rivalries and absurdities of the industry to the complexities of West’s character and the tribulations of the team down the stretch — are now deeply evocative of concrete episodes of my own career.

As a particularly visceral example: early in the book, a feud between two rival projects boils over in an argument at a Howard Johnson’s that becomes known among the Data General engineers as “the big shoot-out at HoJo’s.” Kidder has little more to say about it (the organizational civil war serves merely as a backdrop for Eagle), and I don’t recall this having any effect on me when I first read it — but reading it now, it resonates with a grim familiarity. In any engineering career of sufficient length, a beloved project will at some point be shelved or killed — and the moment will be sufficiently traumatic to be seared into collective memory and memorialized in local lore. So if you haven’t yet had your own shoot-out at HoJo’s, it is regrettably coming; may your career be blessed with few such firefights!

Another example of a passage with new relevance pertains to Tom West developing his leadership style on Eagle:

That fall West had put a new term in his vocabulary. It was trust. “Trust is risk, and risk avoidance is the name of the game in business,” West said once, in praise of trust. He would bind his team with mutual trust, he had decided. When a person signed up to do a job for him, he would in turn trust that person to accomplish it; he wouldn’t break it down into little pieces and make the task small, easy and dull.

I can’t imagine that this paragraph really affected me much as an undergraduate, but reading it now I view it as a one-paragraph crash-course in engineering leadership; those who deeply internalize it will find themselves blessed with high-functioning, innovative engineering teams. And lest it seem obvious, it is in fact more subtle than it looks: West is right that trust is risk — and risk-averse organizations can really struggle to foster mutual trust, despite its obvious advantages.

This passage also serves as a concrete example of the deeper currents that the book captures: it is not merely about the specific people or the machine they built, but about why we build things — especially things that so ardently resist being built. Kidder doesn’t offer a pat answer, though the engineers in the book repeatedly emphasize that their motivations are not so simple as ego or money. In my experience, engineers take on problems for lots of reasons: the opportunity to advance the state of the art; the potential to innovate; the promise of making a difference in everyday lives; the opportunity to learn about new technologies. Over the course of the book, each of these can be seen at times among the Eagle team. But, in my experience (and reflected in Kidder’s retelling of Eagle), when the problem is challenging and success uncertain, the endurance of engineers cannot be explained by these factors alone; regardless of why they start, engineers persist because they are bonded by a shared mission. In this regard, engineers endure not just for themselves, but for one another; tackling thorny problems is very much a team sport!

More than anything, my re-read of the book leaves me with the feeling that on teams that have a shared mission, mutual trust and ample grit, incredible things become possible. Over my career, I have had the pleasure of experiencing this several times, and they form my fondest memories: teams in which individuals banded together to build something larger than the sum of themselves. So The Soul of a New Machine serves to remind us that the soul of what we build is, above all, shared — that we do not endeavor alone but rather with a group of like-minded individuals.

Thanks to Jess for inspiring my own re-read of this classic — and may your read (or re-read!) of the book be as invigorating!

Thoughts on SPARC support in illumos The Trouble with Tribbles...

One interesting property of illumos is that its legacy stretches back decades - there is truly ancient code rubbing shoulders with the very modern.

An area where we have really old code is on SPARC, where illumos has support in the codebase for a large variety of Sun desktops and servers.

There's a reasonable chance that quite a bit of this code is currently broken. Not because it's fundamentally poor code (although it's probably fair to say that the code quality is of its time, and a lot of it is really old), but it lives within an evolving codebase and hasn't been touched in the lifetime of illumos, and likely much longer. Not only that, but it's probably making more assumptions about being built with the old Studio toolchain rather than with gcc.

What of this code is useful and worth keeping and fixing, and what should be dropped?

A first step in this was that I have recently removed support for starfire - the venerable Sun E10K. It seems extremely unlikely that anyone is running illumos on such a machine. Or indeed that anyone has them running at all - they're museum pieces at this point.

A similar, if rather newer, class of system is the starcat, the Sun F15K and variants. Again, it's big, expensive, requires dedicated controller hardware, and is unlikely to be the kind of thing anyone's going to have lying about. (And, if you're a business, there's no real point in trying to make such a system work - you would be much better off, both operationally and financially, in getting a current SPARC system.)

And if nobody has such a system, then not only is the code useless, it's also untestable.

The domained systems, like starfire and starcat, are also good candidates for removal because of the relative complexity and uniqueness of their code. And it's not as if the design specs for this hardware are out there to study.

What else might we consider removing (with starfire done and starcat a given)?

  1. The serengeti, Sun-Fire E2900-E6800. Another big blob of complex code.
  2. The lw8 (lightweight 8), aka the V-1280. This is basically some serengeti boards in a volume server chassis.
  3. Anything using Sbus. That would be the Ultra-2, and the E3000-E6000 (sunfire). There's also the socal, sf, and bpp drivers. One snag  with removing the Ultra-2 is that it's used as the base platfrom for the newer US-II desktops, which link back to it.
  4. The olympus platform. That's anything from Fujitsu. One slight snag here is that the M3000 was quite a useful box and is readily available on eBay, and quite affordable too.
  5. Netra systems. (Specifically NetraCT - there's a US-IIi NetraCT, and two US-IIe systems, the NetraCT-40 and the NetraCT-60. Code names montecarlo and makaha (something about Tonga too). Also CP2300 aka snowbird.
  6. Server blade. I'm talking the old B100s blade here.
  7. Binary compatibility with SunOS 4 - this is kernel support for a.out, and libbc.
I'm not saying at this point that all of this code and platform support will go, just that it lists the potential candidates. For example, I regard support for M3000 as useful, and definitely worth thinking about keeping.

What does that leave as supported? Most of the US-II and US-III desktops, most of the V-series servers, and pretty much all the early sun4v (T1 through T3 chips) systems. In other words, the sort of thing that you can pick up second hand fairly easily at this point.

Getting rid of code that we can never use has a number of benefits:

  • We end up with a smaller body of code, that is thus easier to manage.
  • We end up with less code that needs to be updated, for example to make it gcc7 clean, or to fix problems found by smatch, or to enable illumos to adopt newer toolchains.
  • We can concentrate on the code that we have left, and improve its quality.
If we put those together into a single strategy, the overall aim is to take illumos for SPARC from a large body of unknown, untested, and unsupportable code to a smaller body of properly maintained, testable, and supportable code. Reduce quantity to improve quality, if you like.

As part of this project, I've looked through much of the SPARC codebase. And it's not particularly pretty. One reason for attacking starfire was that I was able to convince myself relatively quickly that I could come up with a removal plan that was well-bounded - it was possible to take all of it out without accidentally affecting anything else. Some of the other platforms need bit more analysis to tease out all the dependencies and complexity - bits of code are shared between platforms in a variety of non-obvious ways.

The above represents my thoughts on what would be a reasonable strategy for supporting SPARC in illumos. I would naturally be interested in the views of others, and specifically if anyone is actually using illumos on any of the platforms potentially on the chopping block.

SPARC and tod modules on illumos The Trouble with Tribbles...

Following up from removing starfire support from illumos, I've been browsing through the codebase to identify more legacy code that shouldn't be there any more.

Along the way, I discovered a little tidbit about how the tod (time of day) modules - the interface to the hardware clock - work on SPARC.

If you look, there are a whole bunch of tod modules, and it's not at all obvious how they fit together - they all appear to be candidates for loading, and it's not obvious how the correct one for a platform is chosen.

The mechanism is actually pretty simple, if a little odd.

There's a global variable in the kernel named:

tod_module_name

This can be set in several ways - for some platforms, it's hard-coded in that platform's platmod. Or it could be extracted from the firmware (OBP). That tells the system which tod module should be used.

And the way this works is that each tod module has _init code that looks like

if (tod_module_name is myself) {
   initialize the driver
} else {
   do nothing
}

so at boot all the tod modules get loaded, but only the one that matches the name set by the platform actually initializes itself.

Later in boot, there's an attempt to unload all modules. Similarly the _fini for each driver essentially does

if (tod_module_name is myself) {
   I'm busy and can't be unloaded
} else {
   yeah, unload me
}

So, when the system finishes booting, you end up with only one tod module loaded and functional, and it's the right one.

Returning to the original question, can any of the tod modules be safely removed because no platform uses them? To be honest, I don't know. Some have names that match the platform they're for. It's pretty obvious, for example, that todstarfire goes with the starfire platform, so it was safe to take that out. But I don't know the module names returned by every possible piece of SPARC hardware, so it isn't really safe to remove some of the others. (And, as a further problem, I know that at least one is only referenced in closed source, binary only, platform modules.)

OmniOS Community Edition r151028l, r151026al, r151022cj OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 21st of January 2019 are now available. These are all non-reboot updates.

In all releases, The openssh packages have been updated to mitigate four separate CVEs in the scp command. In r151026 and r151028, there is also an updated ntpsec package fixing several CVEs.

For further details, please see https://omniosce.org/releasenotes


Any problems or questions, please get in touch.

OmniOS Community Edition r151028j, r151026aj, r151022ch OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 7th of January 2019 are now available. These are reboot updates for r151028 only.

In all releases:


The following information relates to release r151028 only

Updates (r151028 only)

  • Fix for ZFS performance degredation with some pools due frequent metaslab unload and re-load - OS-7151

  • bhyve updates including disk performance improvements.

  • Performance improvement in zone resource tracking on machines with many CPUs - illumos 9936

Fixes (r151028 only)

  • Workarounds for some hard disks and SSDs with buggy firmware relating to power conditions.

  • LX: fix to openat() in order to support newer systemd - see #331

  • bhyve/kvm brands did not support more than one disk when configured via zonecfg

Features (r151028 only)

  • Added library/security/openssl/preview to allow installation and testing of OpenSSL 1.1.1 - see blog post

For more details, see https://omniosce.org/releasenotes

Any problems or questions, please get in touch.

Previewing OpenSSL 1.1.1 on OmniOS r151028 OmniOS Community Edition

We’ve had a number of requests for updating the OpenSSL package in OmniOS r151028 to version 1.1.1, which have led to the creation of a new library/security/openssl/preview package. This allows updating to openssl 1.1.1 on r151028 ahead of the r151030 release (scheduled for May). We’re using this package on our own servers to enable TLS/1.3 for various services.

Installation

In order to make the switch, first ensure that you are on the latest version of the library/security/openssl package. It should be dated 20181214 or later.

omnios$ pkg list -v openssl
FMRI                                                                       IFO
pkg://omnios/library/security/openssl@1.1.0.10-151028.0:20181214T120225Z   i--

Then install the new preview package:

omnios$ openssl version
OpenSSL 1.1.0j  20 Nov 2018

omnios$ pfexec pkg install openssl/preview

omnios$ openssl version
OpenSSL 1.1.1a  20 Nov 2018

Reverting

Due to the way the packages are structured, reverting to version 1.1.0 requires an additional step over just removing the preview package:

omnios$ pfexec pkg uninstall openssl/preview

omnios$ pfexec pkg revert --tagged openssl-preview

omnios$ openssl version
OpenSSL 1.1.0j  20 Nov 2018

OmniOS Community Edition r151028f, r151026af, r151022cd OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 10th of December 2018 are now available. These are reboot updates if you have the system/bhyve package installed and not otherwise.

NSS has been updated in all supported releases to version 3.41 fixing CVE-2018-12404 and bringing in the latest set of CA certificates.

bhyve has been updated in r151026 and r151028 to fix CVE-2018-17160. Thanks to Joyent for providing a rapid fix.


For more details, see https://omniosce.org/releasenotes

Any problems or questions, please get in touch.

OmniOS Community Edition r151028e, r151026ae, r151022cc OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 3rd of December 2018 are now available. These are non-reboot updates.

Perl has been updated in all releases to fix a number of CVEs. Refer to the release notes for your particular OmniOS version for more details.

Mozilla nss and nspr are now at versions 3.40.1 and 4.20, fixing CVE-2018-12404 and bringing the latest set of CA certificates to all releases.


For more details, see https://omniosce.org/releasenotes

Any problems or questions, please get in touch.

OmniOS Community Edition r151028 OmniOS Community Edition

The OmniOS Community Edition Association is proud to announce the general availability of OmniOSce - r151028.

OmniOSce is published according to a 6-month release cycle, r151028 takes over from r151026, published in May 2018; the next LTS release is scheduled for May 2019. The old stable r151024 release is now end-of-lifed and will no longer receive updates. See the release schedule for further details.

This is only a small selection of the new features, and bug fixes in the new release; review the release notes for full details.

New Features

The OmniOSce team and the illumos community have been very active in creating new features and improving existing ones over the last 6 months. Highlights of this new release include:

  • Production-ready Bhyve hypervisor. For years, OmniOS has provided a linux kvm based hypervisor. With this release, we are adding a second option. The bhyve hypervisor from the BSD world has been made a first class illumos component through the combined efforts of Pluribus networks and Joyent with extra help from the FreeBSD community. It provides massively faster disk and network io than the kvm hypervisor as it does not rely on qemu emulation for these services but comes with a super optimised native driver implementation.

  • Branded zones for bhyve and KVM virtual machines. Running a virtual machine inside a zone provides an additional layer of security as any success in breaking out of the virtual machine container will only result in access to the branded zone which itself guarantees strong isolation from the global zone. On top of added security, zones also provide protection against hyper-threading attacks such as L1TF and Portsmash, and allow strict resource controls for cpu, disk and network access. Our website contains documentation on how to make use of these new zone types.

  • ZFS support for mounting filesystems in parallel. This significantly improves boot time for systems with many filesystems.

  • All userland tools are now compiled with gcc7 and several 32-bit only packages have been moved to 64-bit only.

  • Many packages have been updated to newer releases like Python 3.5, Perl 5.28, OpenSSL 1.1. And developers can now start using gcc 8 on OmniOS.

New Hardware Support

  • Emulex 31000/32000-based Fibrechannel cards.
  • ATTO Celerity FC-162E Gen 5 and Celerity FC-162P Gen 6 Fibrechannel cards.
  • QLogic 16Gb/s Gen5/6 fibrechannel cards.
  • QLogic QL41000/45000 series devices.
  • NVMe 1.3 devices.
  • SMB access to some HP scanner models.

Release Notes and Upgrade Instructions

This is only a small selection of the new features, and bug fixes in the new release; review the release notes for full details and find upgrade instructions at omniosce.org/upgrade

OmniOSce Newsletter

Since the start of OmniOS Community Edition project, we have predominantly announced our new releases via twitter. With r151028 we are now also offering a newsletter with announcements of updates, bug fixes and new releases. You can subscribe here.

Commercial Support

Have you ever wondered how OmniOS development gets financed? You may have noticed that there is no big company bankrolling it all. The way we keep afloat is by the companies who rely on OmniOS powered servers taking out support contracts for their hardware. How about you? Visit omniosce.org/support for more details and to generate a quote. If you aren’t in a position to take a support contract, please consider becoming an OmniOS patron to help secure its future - omniosce.org/patron.

About OmniOS Community Edition Association - this Swiss Association is responsible for the ongoing development and maintenance of OmniOS, having been established in Summer 2017 after OmniTI announced their withdrawal from the project.

OmniOSce Association Aarweg 17, 4600 Olten, Switzerland

OmniOS Community Edition r151028b OmniOS Community Edition

OmniOS Community Edition release r151028b is now available.

r151028b (2018-11-12)

Weekly release for w/c 12th of November 2018.

This is a non-reboot update.

Updates

  • ipmitool updated to fix crash when doing AES encryption with lanplus;
  • Updated illumos-gate build templates in developer/build/onbld;
  • developer/illumos-tools updated to include python-35 and gcc7;
  • Installer updated to set default route without requiring an additional reboot.

New installation media have been prepared for this release and can be found at https://omniosce.org/download

For more details, see https://omniosce.org/releasenotes

Any problems or questions, please get in touch.

OmniOS Community Edition r151028d OmniOS Community Edition

OmniOS Community Edition weekly release for w/c 26th of November 2018 is now available. This is a non-reboot update.

In r151028:

  • git has been updated to the latest release (2.19.2) fixing CVE-2018-19486

For more details, see https://omniosce.org/releasenotes

Any problems or questions, please get in touch.

OmniOS Community Edition r151026aa, r151022by OmniOS Community Edition

OmniOS Community Edition releases r151026aa & r151022by are now available.

Weekly releases for w/c 5th of November 2018.

For more details, see https://omniosce.org/releasenotes

Any problems or questions, please get in touch via the lobby or #omnios on Freenode

OmniOS Community Edition r151028c, r151026ac, r151022ca OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 19th of November 2018 are now available. These are non-reboot updates.

In all releases:

  • openssl has been updated to the latest release (1.0.2q in all and 1.1.0j in r151028), fixing two low severity CVEs.
  • openjdk has been updated to 1.7.0_201-b00

In r151026 and r151028, pkg has been updated to fix a problem that could occur when removing a package if auto-be-naming is enabled.

r151028 has also received an update to the openssh package to work around a bug in VMware that could cause SSH traffic to be dropped, and a small update to system/header to add a file that was missing.

This week also sees a backport to screen in r151022 so that it is built against the more extensive ncurses library, enabling support for more terminal types.


For more details, see https://omniosce.org/releasenotes

Any problems or questions, please get in touch.

IFR Alternate Minimums Josef "Jeff" Sipek

As some of you already know, I’ve been working on my instrument rating over the past 5–6 months. As part of it, I had to figure out and understand the regulations governing when an alternate airport is needed and the required weather at the destination and alternate airports.

The first part is answered by 91.169(a) and 91.169(b). To give you taste of the regulations, here is (b):

(b) Paragraph (a)(2) of this section does not apply if:

(1) Part 97 of this chapter prescribes a standard instrument approach procedure to, or a special instrument approach procedure has been issued by the Administrator to the operator for, the first airport of intended landing; and

(2) Appropriate weather reports or weather forecasts, or a combination of them, indicate the following:

(i) For aircraft other than helicopters. For at least 1 hour before and for 1 hour after the estimated time of arrival, the ceiling will be at least 2,000 feet above the airport elevation and the visibility will be at least 3 statute miles.

(ii) For helicopters. At the estimated time of arrival and for 1 hour after the estimated time of arrival, the ceiling will be at least 1,000 feet above the airport elevation, or at least 400 feet above the lowest applicable approach minima, whichever is higher, and the visibility will be at least 2 statute miles.

Clear as mud, isn’t it?

The second question (the required weather at the destination and alternate airports) is answered by 91.169(c). Don’t worry, I won’t quote it here.

Since the text of the regulation is not easy to read, I decided that the best way to understand it is to make a flowchart. As I fly airplanes, I’ve ignored any part of the regulations that is about aircraft other than airplanes.

The result:

Clearer? I certainly think so!

The one big thing to keep in mind about this flowchart is that not every approach can be used during planning. This is a semi-large topic of its own.

In short, any approach that you aren’t authorized for, the plane isn’t equipped for, or that has a NOTAM saying that it isn’t available, effectively doesn’t exist. As far as GPS approaches are concerned, if you have a TSO 129 or 196 GPS, then you have another restriction—you cannot plan on using GPS approaches at both your destination and your alternate.

I found it useful to write this down and in the process truly understand the rules. Hopefully, you’ve found this useful as well. Needless to say, you should not rely on this flowchart without verifying that it is correct. Regulations sometimes change, and people sometimes make mistakes when making flowcharts to visualize said regulations. (If you find a problem, let me know!)

One final thought: just because the regulations don’t require an alternate airport doesn’t mean that you shouldn’t have one anyway. Weather often seems to have a mind of its own and a propensity to prove forecasters wrong.

My awesome download manager Staring at the C

Since Liferea in more recent versions requires a download manager (it does not attempt to deal with the constant "new" podcast downloads on broken RSS feeds), I tried a few different different ones. None of them worked. The best of a bad bunch was uGet, but that still often got stuck on a busy loop, forgot where to download, failed to handle duplicates etc.

I realised that in fact the best option was this marvellous piece of engineering:


$ cat bin/download
#!/bin/bash

url="$1"

readonly LOG_FILE="/var/tmp/download.log"
touch $LOG_FILE
exec 1>>$LOG_FILE
exec 2>&1

#set -x

if grep "$1" ~/.downloaded >/dev/null; then
echo "$(date): skipping $1"
exit 0
fi

echo "$(date): downloading $1"

echo "$1" >>~/.downloaded

cd $my_download_dir

curl -RksSLJO "$1"
Not exactly stunning but it works.

wodim under Ubuntu Staring at the C

wodim/k3b are unusable on Ubuntu: after making sure you're in the cdrom group, you need to add to /etc/security/limits.conf:

@cdrom - memlock unlimited
(Or some limit, I suppose, if you're bothered.)

OmniOS Community Edition r151028l, r151026al, r151022cj OmniOS Community Edition

OmniOS Community Edition weekly releases for w/c 21st of January 2019 are now available. These are all non-reboot updates.

In all releases, The openssh packages have been updated to mitigate four separate CVEs in the scp command. In r151026 and r151028, there is also an updated ntpsec package fixing several CVEs.

For further details, please see https://omniosce.org/releasenotes


Any problems or questions, please get in touch.