OmniOS Community Edition r151038 Stable and LTS OmniOS Community Edition

The OmniOS Community Edition Association is proud to announce the general availability of the next stable and LTS version of OmniOS - r151038.

OmniOS is published according to a 6-month release cycle, with stable releases being supported for a year. However, as an LTS release, r151038 will be supported for three years, and the previous LTS release (r151030) now enters its last year of support.

The old stable r151034 release is now end-of-life and will receive no further updates; r151036 will be supported for a further six months.

Refer to the release schedule for further details and exact dates.

Release Notes and Upgrade Instructions

Direct upgrades to r151038 are supported from r151030, r151032, r151034 and r151036. Upgrades from earlier releases will need to be performed in stages as shown in the table on omnios.org/upgrade.

The highlights of this release include ZFS support for persistent layer 2 ARC, one-time boot environment activation, new pkg commands for managing removable packages and many improvements in the bhyve hypervisor.

There are many more changes and improvements in this release and those are detailed in the release notes, along with upgrade notes.

OmniOS Newsletter

Since the start of OmniOS Community Edition project, we have predominantly announced our new releases via twitter. 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 omnios.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 - omnios.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

Twitter Spaces, a few weeks in The Observation Deck

As a kid, I listened to a lot of talk radio. This was in the 80s, before the internet — and before the AM dial became fringe. I have fond memories of falling asleep to the likes of Bruce Williams who just gave damned good, level-headed advice. It was, at essence, both optimistic and temperate: a cool head to help people work through a tough spot.

Nothing really replaced the call-in show: talk radio devolved into poisonous echo chambers, while social networking gave people other outlets (too many!) to have conversations. But these online conversations — the written word — lack something: Twitter’s tight form gives us the hot take, blogs (ahem!) give us the longer form, but it both cases, the conversations that result seem to either lose their sizzle or go thermonuclear. Video is really great for some stuff (I have spoken about the rise of video and the preservation of oral tradition in software engineering) — but the discussion quality there is even worse. (When did YouTube comments become such a hellhole?!) And of course, TikTok has given us social, short-form video, which can be very entertaining, but isn’t really designed to induce any meaningful discussion.

And of course, I love podcasts, and one of the reasons I was excited to start a company was to get an excuse to make the podcast that we ourselves always wanted. Podcasts are particularly great because you can do something else while listening to them: they fill in that time when you’re doing the dishes or picking up the kids or whatever. But podcasts obviously miss the interactivity entirely. (Or mostly: let us not so quickly forget TWiV reading my letter on-air!)

Into all of this, enter Clubhouse and the rise of social audio. I had immediate Bruce Williams flashbacks, and was excited to participate. But my choice of device makes me unwelcome in Clubhouse’s eyes: their lack of an Android app is clearly not a mere temporary gap, but rather a deliberate deprioritization. (I certainly honor a young company’s need to focus, but how else can one describe an exceedingly well-capitalized company adding in-app payments before addressing 75% of the market?!) To me, the deprioritization of Android reflects Clubhouse’s deeper problem: it is fundamentally elitist and exclusionary. Avid Clubhouse users may claim that this was not always so, but it says it right there on the tin: it is, at the end of the day, a clubhouse — not a cafe or a town square. I personally have no interest in participating in venues that deliberately limit the participants: I want to engage with the broadest possible cross-section, not some subset that has been manicured by circumstance or technology choice. (For this same reason, I do not give talks unless the talk will be recorded and made freely available.)

Given all of this, you can imagine my enthusiasm for Twitter Spaces: it captures the promise that I see in the medium — but addresses many of the problems with Clubhouse’s implementation. I have been participating in them for the past few weeks and (excitingly!) found last week that I have the ability to create Spaces. Here are my takeaways so far:

  • This is an even bigger deal than I thought it was. All of the strengths that I perceived in the medium seem to be even stronger than I thought they would be, and in particular — as with podcasts — I can have a conversation while I do something else. It is really nice to have social networking time after which one looks back at a clean kitchen or a prepared meal!

  • Spaces have broadened the people I follow. In every Space I have been in, I have come away following someone new. I find one of the most interesting aspects of Twitter to be able to be a part of conversations and social circles that broaden our perspectives (socially, technically, or otherwise) — and Spaces takes this to a new level: I find that I’m following people based on a comment that they make that I wouldn’t otherwise see in the din of my feed.

  • Spaces have felt very playful. In so many ways, this reminds me of early social networking circa 2003 — or of first getting online a decade prior. It just feels new, and fresh, and… fun! For example, I was in one space where a security researcher that I revere was with their crew, all trying to find ways to hack the captioning. (They made some interesting discoveries: because the captioning is done locally, they can actually reveal more about you than what you actually say!) I was more or less laughing the whole time; it was delightful.

  • The content is golden. If I have one complaint about Spaces, it’s that they aren’t publicly recorded — because there’s some great content here! I am hoping that this gets added over time (obviously, opt-in and clear to all participants!), because speaking personally, I want to go back and listen to an awesome Space that I might have missed — and I want others to be able to do the same with any Space that I host.

  • People have been really nice! Okay, this is a little one, but I think an essential one: in every Space I’ve been in, the people have just been incredibly friendly and welcoming. One of the challenges of the written word is that it’s too easy to be nasty: our mirror neurons don’t fire when our damage is inflicted at a distance. (Take it from the guy still trying to apologize for a Usenet comment from several decades ago!) While it’s still obviously very early for Twitter Spaces, being in a spoken conversation makes us much more predisposed to empathy — and I’m optimistic that the medium will retain the decency that we have lost elsewhere, allowing us a venue to listen to and learn from other perspectives. I also really like Twitter’s emphasis on safety — and I’m hopeful that the inevitable bad behavior that does crop up is taken care of pretty quickly.

  • Clubhouse is in trouble. I have been in a couple of Spaces where Clubhouse comes up (indeed, one of the Spaces I was in was a security researcher reporting how poorly Clubhouse handled a pretty serious safety issue that she had found), and in all of those conversations, the tenor is more or less the same: there was a brief moment last summer (especially, post George Floyd) when Clubhouse felt really important — profound, even — but their poor execution since has driven people away. In this regard, my early social networking metaphor may be apt in more ways than one: Clubhouse feels like Friendster. And just as Friendster hit on something huge (social networking!) for the wrong reasons (the founder’s desire to find dates!), Clubhouse’s focus on listening to famous people feels misplaced. (Speaking for myself, I am looking for conversations, not outtakes of Behind the Music.)

  • Hosting has been rewarding. So far, I have hosted one Space, convincing Adam to join me so I wouldn’t die alone. I think it’s fair to say that Adam was somewhat skeptical going in, but came out seeing promise in the medium. For example, one participant was dialing in from central Asia (where it was 4a!), and we ended up in a discussion on how insulated kids can become from the underlying mechanics of how computers actually work. He decribed that growing up needing to rely on second-hand computers was an essential part of his own technical education — that having less made him need to understand more. It was a moment that had everyone reflecting, and I’m honestly not sure how else that little interaction would have happened.

All in all, very positive and promising! Of course, there are still lots of things to stub your toe on; this is still new, after all, and lots of stuff doesn’t work quite right. And there’s also a lot to be figured out by those of us who will use the medium (reminder: retweets were invented by users, not by Twitter!). For my part from a hosting perspective, I am going to take some inspiration from talk radio and experiment with both regularity and time-bounds: Adam and I are going to host a Space again tomorrow (Monday) at 5p Pacific, keeping it again to about an hour. (We appear to be aided in our time bounds last week by a memory leak that caused my app to abort after about an hour!) So if you’re interested, drop on by — we’d love to hear what you have to say, which indeed is very much the whole point!

OpenIndiana Hipster 2021.04 is here openindiana

After another 6 months have passed we are proud to announce the release of our 2021.04 snapshot. The images are available at the usual place. As usual we have automatically received all updates that have been integrated into illumos-gate. This release’s most notably changes are

  • We have updated firefox and thunderbird to newer ESR versions (78.10.0 resp. 78.9.1). This was overdue and has been requested by many users.
  • Finally we have more than one NVIDIA driver version available with nvidia-390.141 being the default. Changing the driver to another version is documented at https://docs.openindiana.org/dev/graphics-stack/#Nvidia. At the moment we have the following versions in our repository:
    1. nvidia-460.67
    2. nvidia-390.141
    3. nvidia-340.108
  • Our gcc-7, gcc-8, gcc-9, and gcc-10 compilers have been patched to use the illumos libc SSP implementation for -fstack-protector
  • We have added openssl-1.1.1 and many packages have been updated to make use of the newer and supported version of openssl. Alas this process isn’t finished yet as many packages don’t use it out-of-the box and a few even don’t work with its new interface.
  • Work has been started to update our Python versions and the related packages. As a consequence we now have python-37 and python-39 packages. This is also an ongoing process that hasn’t been finished yet.

The following new packages have also been added:

  • fcron-3.3.0
  • libsigc++3 3.0.6
  • nodejs-16.0.0
  • re2c 2.0.3
  • wine 4.17

The following packages have been removed:

  • couchdb-21
  • libcouchbase
  • percona-server-56
  • php-70 and its extensions

The following packages have been updated or got security fixes:

  • Mate desktop related packages
    • atril 1.24.1
    • caja 1.24.1
    • eom 1.24.2
    • engrampa 1.24.2
    • marco 1.24.2
    • mate-calc 1.24.2
    • mate-control-center 1.24.2
    • mate-common 1.24.2
    • mage-panel 1.24.2
    • mate-power-manager 1.24.3
    • mate-session-manager 1.24.3
    • mate-settings-daemon 1.24.2
    • mate-system-monitor 1.24.2
    • mate-themes 3.22.22
    • mozo 1.24.1
    • pluma 1.24.2
  • Python related packages
    • python-37 3.7.10
    • python-39 3.9.4
    • argcomplete 1.12.2
    • atomicwrites 1.3.0
    • attrs 20.3.0
    • cffi 1.14.0
    • chardet 4.0.0
    • coverage 5.3.1
    • funcsigs 1.0.2
    • hypothesis 4.47.1
    • importlib-metadata 1.5.2
    • iniconfig 1.1.1
    • more-itertools 8.6.0
    • packaging 20.8
    • pathlib2 2.3.5
    • pip 20.3.3
    • pipdeptree 2.0.0
    • pluggy 0.13.1
    • py 1.8.2
    • pyparsing 2.4.0
    • pyro4 4.80
    • pytest 6.1.2
    • python-six 1.15.0
    • pytz 2020.5
    • pyxml 4.6.1
    • requests 2.22.0
    • scandir 1.10
    • setuptools 50.3.2
    • setuptools_scm 5.0.1
    • sortedcontainers 2.3.0
    • toml 0.10.2
    • wcwidth 0.2.5
    • zc.lockfile 2.0.0
    • zipp 1.2.0
    • zope-interface 5.2.0
  • Other packages
    • ansible 2.9.19
    • apr 1.7.0
    • apr-util 1.6.1
    • asciidoc 9.1.0
    • atk 2.36.0
    • autoconf-archive 2019.01.06
    • automake 1.16.3
    • babl 0.1.84
    • bacula 9.6.7
    • barman 2.12
    • bash-completion 2.11
    • bind 9.16.15
    • binutils 2.36
    • bluefish 2.2.12
    • borgbackup 1.1.16
    • djvulibre 3.5.28
    • citus 9.5.1
    • cmake 3.20.2
    • colorama 0.4.4
    • coreutils 8.32
    • cppunit 1.15.1
    • cpuid 1.7.6
    • cups 2.3.3
    • curl 7.76.1
    • czmq 4.2.1
    • diffstat 1.64
    • dnsmasq 2.85
    • doxygen 1.9.1
    • emacs 27.2
    • expat 2.3.0
    • findutils 3.8.0
    • fish 3.2.1
    • flac 1.3.3
    • fonttosfnt 1.2.1
    • fping 5.0
    • freerdp 2.3.2
    • gawk 5.1.0
    • geany 1.37.1
    • geany-plugins 1.37
    • gettext 0.21
    • gegl 0.4.30
    • gexiv2 0.12.2
    • git 2.31.1
    • gmp 6.2.1
    • gnu-grep 3.6
    • gnumeric 1.12.48
    • gnupg 2.2.27
    • gnutls 3.6.15
    • glib2 2.66.8
    • go 1.16.2
    • go 1.15.8
    • goaccess 1.4.3
    • goffice 0.10.49
    • gtar 1.34
    • gtk+3 3.24.24
    • haproxy 2.2.13
    • harfbuzz 2.7.4
    • htop 3.0.5
    • httping 2.5
    • idna 2.10
    • irssi 1.2.3
    • iso-codes 4.6.0
    • isync 1.4.1
    • jenkins-core-lts 2.277.3
    • jenkins-core-weekly 2.290
    • jetbrains-mono 2.225
    • lame 3.100
    • lcms2 2.12
    • libarchive 3.5.1
    • libass 0.15.0
    • libassuan 2.5.5
    • libebml 1.4.1
    • libepoxy 1.5.5
    • liberation-fonts 2.1.3
    • libexif 0.6.22
    • libexif-gtk 0.5.0
    • libgcrypt 1.9.2
    • libgee 0.20.4
    • libgpg-error 1.42
    • libidn 1.36
    • libmagick 5.40
    • libp11 0.4.11
    • libogg 1.3.4
    • libraw 0.18.13
    • libstatgrab 0.92
    • libtiff 4.2.0
    • libwebp 1.2.0
    • libwpg 0.3.3
    • libwps 0.4.12
    • links 1.22
    • logrotate 3.17.0
    • lsof 4.94.0
    • lzip 1.22
    • mc 4.8.26
    • mpfr 4.1.0
    • mrtg 2.17.7
    • mutt 2.0.6
    • nano 5.7
    • nginx 1.20.0
    • ninja 10.2
    • nodejs-10 10.24.1
    • nodejs-12 12.22.1
    • nodejs-14 14.16.1
    • nspr 4.30
    • ntp 4.2.8p15
    • openconnect 8.10
    • openldap 2.4.58
    • openssl-1.0.2 fixes for CVE-2021-23840 and CVE-2021-23841
    • openssl-1.1 1.1.1k
    • p11-kit 0.23.22
    • pango 1.48.0
    • percona-server-57 5.7.33.36
    • pigz 2.6
    • popt 1.18
    • postgresql 9.5.25
    • postgresql 9.6.21
    • postgresql 10.16
    • postgresql 11.11
    • postgresql 12.6
    • potrace 1.16
    • powerline 2.8.2
    • privoxy 3.0.22
    • qt5. 5.12.10
    • rbtools 1.0.3
    • rdiff-backup 2.0.5
    • rust 1.44.1
    • sbcl 2.1.3
    • scons 4.0.1
    • screen fix for CVE-2021-26937
    • shmux 1.0.3
    • slib 3b6
    • smartmontools 4.17
    • sqlite 3.35.5
    • squeak4 4.19.6
    • squeak5 5.0.2952
    • squeak5c 5.0.2954
    • stardict 3.0.6
    • sudo 1.9.6p1
    • terminus 4.49
    • texttable 1.6.3
    • tig 2.5.3
    • tmux 3.2
    • tor 0.4.5.7
    • tqdm 4.53.0
    • ts 1.0.1
    • unrar 6.0.4
    • valgrind 3.17.0
    • virtualbox 6.1.18
    • vlc 3.0.12
    • weechat 3.1
    • wget 1.21.1
    • x265 3.4
    • xdm 1.1.12
    • xkbcomp 1.4.4
    • xkeyboard-config 2.31
    • xmlsec 1.2.31
    • xorriso 1.5.4
    • xprop 1.2.5
    • xterm 367
    • youtube-dl 2021.01.08
    • zstd 1.4.9
    • zziplib 0.13.72

OmniOS Community Edition r151030cy, r151034ay, r151036y OmniOS Community Edition

OmniOS weekly releases for w/c 19th of April 2021 are now available.

Security fixes for all releases

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


Any problems or questions, please get in touch.

OmniOS Community Edition r151030cx, r151034ax, r151036x OmniOS Community Edition

OmniOS weekly releases for w/c 12th of April 2021 are now available.

There are important fixes for r151030 and r151034 for users who use ZFS encryption and snapshot clones, some fixes for the mlxcx driver in r151034, a curl update to 7.76.1 in all releases and more.

All releases

  • curl updated to 7.76.1

r151034 and r151036

  • Changing the encryption key on a ZFS dataset with clones did not update the clones themselves, rendering them inaccessible.

r151036 only

  • SMB shares from an lofs mount would fail.

  • Reaping many process with shared mappings of files on ZFS was extremely slow.

  • In rare cases, a kernel panic could occur during system boot due to a race condition in the mlxcx driver.

  • The pkg depot server would periodically hang when accessed over low-latency connections.

  • The dma mailer could spin when trying to create a new local mailbox.

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


Any problems or questions, please get in touch.

Running Tribblix on Digital Ocean The Trouble with Tribbles...

A relatively recent feature offered by Digital Ocean is the ability to deploy your own custom image. So, can I deploy a Tribblix image to Digital Ocean?

Short answer: Yes!

For the process, read on.

I'm using Bhyve to create the image. This is a slight variation on the Installing Tribblix in Bhyve on Tribblix procedure.

The basic process looks like this:

  • Boot Tribblix in Bhyve
  • Install it
  • Tweak the installed image for Digital Ocea
  • Copy the ZFS volume to Digital Ocean

The first variation on the previous install is that I make the ZFS volume a bit smaller. We can resize it when it's deployed, so we don't need to make it too big. A 4G volume is fine; any smaller and there won't be any space for our swap partition. It doesn't actually matter too much, as we compress the image anyway

zap create-zone -t bhyve -z bhyve1 \
-x 192.168.0.236  \
-I /var/tmp/tribblix-0m24.1.iso \
-V 4G

Install as before,

./live_install.sh -G c1t0d0

remove the cdrom and reboot as before.

We now need to set up networking. We need to do this on a temporary basis, as we don't want any of these network configurations to carry over to the installed image. So I temporarily disable nwam, and manually bring up a working network. When the image boots on Digital Ocean, all this configuration will have been forgotten and it will bring up nwam as normal.

So run the following in the newly installed guest:

svcadm disable -t network/physical:nwam
ifconfig vioif0 plumb
ifconfig vioif0 up
ifconfig vioif0 inet 192.168.0.236/24
route add net default 192.168.0.1
echo "nameserver    8.8.8.8"  > /etc/resolv.conf

Now we need to tweak the image. At some later point this will all be integrated into the installer so it will just work. But for now, we'll start by applying any updates:

zap refresh
zap update-overlay -a

Now for the little tweak. I'm going to add a metadata service that will run at boot on Digital Ocean and do the sort of things that cloud-init would do. Fortunately, there's one for illumos, and it's packaged for Tribblix, so install it:

zap install TRIBmetadata-agent

If you look with svcs you'll see that it's offline. That's not a problem (it's because we've got a temporary manual network setup) - once we boot properly on Digital Ocean we'll have nwam running and the metadata service will run just fine.

We can tidy up and save a bit of space:

zap clean-cache -a

and shut down the zone (and the newly installed instance of Tribblix):

zoneadm -z bhyve1 halt

What we want is a raw image. So all we do is dd the ZFS volume to a file.

dd if=/dev/zvol/rdsk/rpool/bhyve1_bhvol0 \
of=/var/tmp/tribblix-do-m24.1.img bs=1048576

That's a 4G file, the size of the volume. As it's stored on ZFS, and ZFS compression is on, it will actually consume a lot less space as the image is mostly empty. But what we don't want to do is upload 4G of empty space. So we can compress it:

gzip -9 /var/tmp/tribblix-do-m24.1.img

(it ends up as about 300M), or you could use bzip2, I think.

There are two options when you upload the image to Digital Ocean - you can either do a direct upload through the browser, or you can give it a URL where the image can be found and get Digital Ocean to pull it from there. I found it much easier to scp the image up to an existing webserver and get Digital Ocean to grab it, as I don't trust browsers to behave well.

Log in to Digital Ocean.

Select 'Images' from the left hand menu
Tab to 'Custom Images'
Import via URL
[Insert the URL where you've stashed the file]

You then get a dialog

Name - tribblix-do-m24.1.img.gz
Distribution - unknown (it's not on the list)
Region - London

Obviously, for me, London is conveniently local. You get warned there will be a charge, and it shows as pending for a few minutes.

Then it pops up 'your image is ready to use'.

To the right of the image in the list is a 'More' dropdown menu from which you can start a droplet. So off we go.

It selects a pretty hefty instance type by default. Reset that to the very cheapest. Choose the ssh key you're going to use, pick a useful (and shorter) hostname, and Create Droplet.

Don't bother with block storage. That's exposed by virtio-scsi, which illumos doesn't yet support.

It'll take a few moments to create the droplet, and once it's ready you'll see the IP address.

At this point, if everything has worked, you should be able to ssh in as root with the ssh key you chose. Chances are that doesn't quite work yet. If it doesn't, simply ssh in as jack, from where you can su to root.

(Remember, jack is on the live ISO, and we haven't deleted it. During experiments I tend not to, to give myself a way in if things don't work right. A proper production image would have the jack user removed and password login for root disabled.)

If the metadata service hasn't run properly (it will resize the ZFS pool, change the hostname, and add the correct key to ssh in as root) then you can restart the metadata service:

svcadm restart metadata

Now ssh to root works, the hostname is set, and the zfs pool has been expanded to the full size.

None of the above is excessively specific to Tribblix, the same general process will work for any of the illumos distributions. (Although you may have to build and install the metadata service yourself.)

Installing Tribblix in Bhyve on Tribblix The Trouble with Tribbles...

One of the big new features recently added to illumos is the Bhyve hypervisor. Rather that the shared-kernel application-level virtualization offered by zones, think of something like VirtualBox, KVM, or Qemu.

One of the things that I am using Bhyve for is to test the Tribblix ISO images and the installer. This allowed me to shrink the installer footprint slightly in recent releases (and showed that one of the tricks I tried wasn't going to work).

Using Bhyve requires a fairly modern system (my own is a little old, and has an Intel Core i7, and works fine). The instructions here also need you to be running current Tribblix, m24.1 or newer.

So, how do I install Tribblix in Bhyve on Tribblix? Most of the following needs to be done as root.

First, make sure that you have the software installed:

zap install-overlay bhyve

I'm doing this on my desktop, so I'm using VNC to connect.

zap install-overlay retro-desktop

You need the current ISO. Again, this has to be m24.1 or newer. Correct the path below to match wherever you've downloaded it to.

While you don't actually have to run bhyve in a zone, that's the standard and most convenient way. So, I use zap to create a zone:

zap create-zone -t bhyve -z bhyve1 \
-x 192.168.0.236  \
-I /var/tmp/tribblix-0m24.1.iso \
-V 8G

Let's run through these. The -t flag says to create a bhyve zone, -z gives it a name, -x gives it an (exclusive) IP address, -I tells it where the ISO image is, and -V tells it to create a ZFS volume of the given size. The other argument that may be of interest is -m, which allows you to set the amount of memory allocated; it defaults to 1024M which is fine for Tribblix.

Then you need to be able to connect to the instance. I'm going to use VNC to connect to the console. We use socat to wire up the bhyve socket in the zone to a network port in the global zone that we can connect to.

socat TCP-LISTEN:5905,reuseaddr,fork UNIX-CONNECT:/export/zones/bhyve1/root/tmp/vm.vnc

You may need to modify the zone name in the path, and you can choose the TCP port (for VNC, it's offset by 5900, so the 5905 is :5 in VNC-speak).



 

 

 

Then, as yourself, you can start a VNC client

vncviewer :5

If that can't connect, then one possibility is that bhyve can't start because it doesn't have enough memory. One little trick to make sure there's enough headroom is to create a file in /tmp and then delete it immediately.

mkfile 1200m /tmp/1200m ; rm /tmp/1200m

You can then log in to the live environment. And do an install like so:

./live_install.sh -G c1t0d0


 

 

 

 

and the install will carry on

 




 

 

 

 

If you want to run this, you have to avoid booting off the CD. The way to do this is to remove the cdrom from the zone specification before you reboot the guest, like so:

zonecfg -z bhyve1 remove attr name=cdrom
zonecfg -z bhyve1 remove fs dir=/var/tmp/tribblix-0m24.1.iso special=/var/tmp/tribblix-0m24.1.iso
zoneadm -z bhyve1 reboot

Obviously, adjusted for the zone name and the ISO file name. I need to teach zap how to do this properly. And then start socat again (if you stopped it) and reconnect using VNC.

You may need to fiddle the networking in the installed guest. The exclusive-ip setting here will force the guest to use the given address. That's unlikely to work terribly well, as the chances of allocating the same address that DHCP would hand out are pretty remote. So to get it on the network you may have to fiddle in the guest by hand.

svcadm disable network/physical:nwam
echo "192.168.0.236/24" > /etc/hostname.vioif0
echo "192.168.0.1" > /etc/defaultrouter
svcadm enable network/physical:default

and populate /etc/resolv.conf with something relevant so that dns works

echo "nameserver 8.8.8.8" > /etc/resolv.conf



 

 

 

 

 

 

Once you're done, you can destroy the zone with

zap destroy-zone -z bhyve1

which will also destroy the ZFS volume it was using.

While the above refers to installing Tribblix inside Bhyve, the same general procedure ought to work to install other illumos distributions.




Compensation as a reflection of values The Observation Deck

Compensation: the word alone is enough to trigger a fight-or-flight reaction in many. But we in technology have the good fortune of being in a well-compensated domain, so why does this issue induce such anxiety when our basic needs are clearly covered? If it needs to be said, it’s because compensation isn’t merely about the currency we redeem in exchange for our labors, but rather it is a proxy for how we are valued in a larger organization. This, in turn, brings us to our largest possible questions for ourselves, around things like meaning and self-worth.

So when we started Oxide — as in any new endeavor — compensation was an issue we had to deal with directly. First, there was the thorny issue of how we founders would compensate ourselves. Then, of course, came the team we wished to hire: hybrid local and remote, largely experienced to start (on account of Oxide’s outrageously ambitious mission), and coming from a diverse set of backgrounds and experiences. How would we pay people in different geographies? How could we responsibly recruit experienced folks, many of whom have families and other financial obligations that can’t be addressed with stock options? How could we avoid bringing people’s compensation history — often a reflection of race, gender, class, and other factors rather than capability — with them?

We decided to do something outlandishly simple: take the salary that Steve, Jess, and I were going to pay ourselves, and pay that to everyone. The three of us live in the San Francisco Bay Area, and Steve and I each have three kids; we knew that the dollar figure that would allow us to live without financial distress — which we put at $175,000 a year — would be at least universally adequate for the team we wanted to build. And we mean everyone literally: as of this writing we have 23 employees, and that’s what we all make.

Now, because compensation is the hottest of all hot buttons, it can be fairly expected that many people will have a reaction to this. Assuming you’ve made it to this sentence it means you are not already lighting us up in your local comments section (thank you!), and I want to promise in return that we know some likely objections, and we’ll address those. But before we do, we want to talk about the benefits of transparent uniform compensation, because they are, in a word, profound.

Broadly, our compensation model embodies our mission, principles, and values. First and foremost, we believe that our compensation model reflects our principles of honesty, integrity, and decency. To flip it around: sadly, we have seen extant comp structures in the industry become breeding grounds for dishonesty, deceit, and indecency. Beyond our principles, our comp model is a tangible expression of several of our values in particular:

  • It has set the tone with respect to teamwork. In my experience, the need to “quantify” one’s performance in exchange for justifying changes to individual compensation are at the root of much of what’s wrong in the tech industry. Instead of incentivizing people to achieve together as a team, they are incentivized to advance themselves — usually with sophisticated-sounding jargon like OKRs or MBOs, or perhaps reasonable-sounding (but ultimately misguided) mantras like “measure everything.” Even at their very best, these individual incentives represent a drag on a team, as their infrequent calibration can prevent a team from a necessary change in its direction. And at worst, they leave individuals perversely incentivized and operating in direct opposition to the team’s best interest. When comp is taken out of the picture, everyone can just focus on what we need to focus on: getting this outlandish thing built, and loving and serving the customers who are taking a chance on it.

  • It is an expression of our empathy. Our approach to compensation reflects our belief in treating other people the way that we ourselves want to be treated. There are several different dimensions for this, but one is particularly visceral: because we have not talked about this publicly, candidates who have applied to Oxide have done so assuming that we have a traditional comp model, and have braced themselves for the combat of a salary negotiation. But we have spoken about it relatively upfront with candidates (before they talk to the team, for example), and (as the one who has often had this discussion) the relief is often palpable. As one recent candidate phrased it to me: “if I had known about this earlier, I wouldn’t have wasted time stressing out about it!”

  • It is (obviously?) proof-positive of our transparency. Transparency is essential for building trust, itself one of the most important elements of doing something bold together. One of the interesting pieces of advice we got early on from someone who has had outsized, repeated success: modulo private personnel meetings, make sure that every meeting is open to everyone. For those accustomed to more opaque environments, our level of transparency can be refreshing: for example, new Oxide employees have been pleasantly surprised that we always go through our board decks with everyone — but we can’t imagine doing it any other way. Transparent compensation takes this to an unusual (but not unprecedented) extreme, and we have found it to underscore how seriously we take transparency in general.

  • It has allowed whole new levels of candor. When everyone can talk about their salary, other things become easier to discuss directly. This candor is in all directions; without comp to worry about, we can all be candid with respect to our own struggles — which in turn allows us to address them directly. And we can be candid too when giving public positive feedback; we don’t need to be afraid that by calling attention to someone’s progress, someone else will feel shorted.

These are (some of!) the overwhelming positives; what about those objections?

  • Some will say that this salary is too low. While cash compensation gets exaggerated all of the time, it’s unquestionable that salaries in our privileged domain have gotten much higher than our $175,000 (and indeed, many at Oxide have taken a cut in pay to work here). But it’s also true that $175,000 per year puts us each in the top 5% of US individual earners — and it certainly puts a roof over our families’ heads and food in their bellies. Put more viscerally: this is enough to not fret when your kids toss the organic raspberries into the shopping cart — or when they devour them before you’ve managed to get the grocery bags out of the car! And speaking of those families: nothing is more anxiety-producing than having a healthcare issue compounded by financial distress due to inadequate insurance; Oxide not only offers the best healthcare plans we could find, but we also pay 100% of monthly premiums — a significant benefit for those with dependents.

  • Some will say that we should be paying people differently based on different geographical locations. I know there are thoughtful people who pay folks differently based on their zip code, but (respectfully), we disagree with this approach. Companies spin this by explaining they are merely paying people based on their cost of living, but this is absurd: do we increase someone’s salary when their spouse loses their job or when their kid goes to college? Do we slash it when they inherit money from their deceased parent or move in with someone? The answer to all of these is no, of course not: we pay people based on their work, not their costs. The truth is that companies pay people less in other geographies for a simple reason: because they can. We at Oxide just don’t agree with this; we pay people the same regardless of where they pick up their mail.

  • Some will say that this doesn’t scale. This is, at some level, surely correct: it’s hard to envision a multi-thousand employee Oxide where everyone makes the same salary — but it has also been (rightly) said that startups should do things that don’t scale. And while it seems true that the uniformity won’t necessarily scale, we believe that the values behind it very much will!

  • Some will say that this makes us unlikely to hire folks just starting out in their career. There is truth to this too, but the nature of our problem at Oxide (namely, technically very broad and very deep), the size of our team (very small), and the stage of our company (still pretty early!) already means that engineers at the earliest stages of their career are unlikely to be a fit for us right now. That said, we don’t think this is impossible; and if we felt that we had someone much earlier in their career who was a fit — that is, if we saw them contributing to the company as much as anyone else — why wouldn’t we reflect that by paying them the same as everyone else?

  • Some will say that this narrows the kind of roles that we can hire for. In particular, different roles can have very different comp models (sales often has a significant commission component in exchange for a lower base, for example). There is truth to this too — but for the moment we’re going to put this in the “but-this-can’t-scale” bucket.

  • Some will say that this doesn’t offer a career ladder. Uniform compensation causes us to ask some deeper questions: namely, what is a career ladder, anyway? To me, the true objective for all of us should be to always be taking on new challenges — to be unafraid to learn and develop. I have found traditional ladders to not serve these ends particularly well, because they focus us on competition rather than collaboration. By eliminating the rung of compensation, we can put the focus on career development where it belongs: on supporting one another in our self-improvement, and working together to do things that are beyond any one of us.

  • Some will say that we should be talking about equity, not cash compensation. While it’s true that startup equity is important, it’s also true that startup equity doesn’t pay the orthodontist’s bill or get the basement repainted. We believe that every employee should have equity to give them a stake in the company’s future (and that an outsized return for investors should also be an outsized return for employees), but we also believe that the presence of equity can’t be used as an excuse for unsustainably low cash compensation. As for how equity is determined, it really deserves its own in-depth treatment, but in short, equity compensates for risk — and in a startup, risk reduces over time: the first employee takes much more risk than the hundredth.

Of these objections, several are of the ilk that this cannot endure at arbitrary scale. This may be true — our compensation may well not be uniform in perpetuity — but we believe wholeheartedly that our values will endure. So if and when the uniformity of our compensation needs to change, we fully expect that it will remain transparent — and that we as a team will discuss it candidly and empathetically. In this regard, we take inspiration from companies that have pioneered transparent compensation. It is very interesting to, for example, look at how Buffer’s compensation has changed over the years. Their approach is different from ours in the specifics, but they are a kindred spirit with respect to underlying values — and their success with transparent compensation gives us confidence that, whatever changes must come with time, we will be able to accommodate them without sacrificing what is important to us!

Finally, a modest correction. The $175,000 isn’t quite true — or at least not anymore. I had forgotten that when we did our initial planning, we had budgeted modest comp increases after the first year, so it turns out, we all got a raise to $180,250 in December! I didn’t know it was coming (and nor did anyone else); Steve just announced it in the All Hands: no three-hundred-and-sixty degree reviews, no stack ranking, no OKRs, no skip-levels, no numerical grades — just a few more organic raspberries in everyone’s shopping basket. Never has a change in compensation felt so universally positive!

OmniOS Community Edition r151030cv, r151034av, r151036v OmniOS Community Edition

OmniOS weekly releases for w/c 29th of March 2021 are now available.

Security Fixes for all releases

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


Any problems or questions, please get in touch.

Using the 'zadm' utility to create a bhyve VM from an image OmniOS Community Edition

Creating an OmniOS bhyve VM is quick and easy with the provided images. This example shows creating a VM running the rolling bloody release on r151034.


zadm is open source and hosted on Github. Feedback and pull requests are welcome.

Any questions, please get in touch!

OmniOS Community Edition r151030cu, r151034au, r151036u OmniOS Community Edition

OmniOS weekly releases for w/c 22th of March 2021 are now available.

Security Fixes for all releases

Additionally for r151034 and r151036

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


Any problems or questions, please get in touch.

Setting up a virtual machine in Azure OmniOS Community Edition

With the release of OmniOS r151038, a hard disk image suitable for uploading to Microsoft Azure is available. This image is pre-configured to run in Azure and can be provisioned directly from the command line, using the Azure CLI, as shown below.

This article assumes you already have the Azure CLI installed and working and that you have authenticated to Azure using the az login command.

The image is provided as a compressed virtual hard disk (vhd) file on the OmniOS download site. In the following example, the image related to the rolling “bloody” release is used.

First, download the image to the local machine, and uncompress it:

        $ cd /tmp
$ curl -O https://downloads.omnios.org/media/bloody/azure-151037.vhd.zst
$ zstd -d azure-151037.vhd.zst

Create a resource group to hold the rest of the resources. If you already have a resource group configured in Azure, you can skip this step. In this example, the resource group is called web and it is being created in the ukwest region.

        $ az group create --name web --location ukwest

Create a storage account to hold the disk image - again, if you already have a storage account configured, you can skip this step.

        $ az storage account create --resource-group web --location ukwest \
    --name webstorage --kind Storage --sku Standard_LRS

Obtain the key needed to access this new storage account. This can also be obtained using the Azure web portal. Setting the two environment variables shown makes the following commands shorter as these parameters can then be omitted.

        $ key=`az storage account keys list \
    --resource-group web --account-name webstorage \
    | jq -r 'first | .value'`

$ export AZURE_STORAGE_ACCOUNT=webstorage
$ export AZURE_STORAGE_KEY=$key

Create a container within the storage account. This is where the disk image will be uploaded:

        $ az storage container create --name omniosdisk

Now the image can be uploaded, this will take a few minutes and you will see a progress bar.

        $ az storage blob upload --container-name omniosdisk --type page \
    --file /tmp/azure-151037.vhd --name azure-151037.vhd

Once that is uploaded, it is time to create the virtual machine. In the following example, an admin user is also being created with the username boho. This account will be granted permission to use sudo and will be configured with the provided public SSH key in its authorized_keys file.

        $ az vm create --resource-group web --location ukwest \
    --name web01 --storage-account webstorage --os-type linux \
    --admin-username boho --ssh-key-value ~/.ssh/id_rsa.pub \
    --size Standard_B1s --boot-diagnostics-storage=webstorage \
    --use-unmanaged-disk --image \
    https://webstorage.blob.core.windows.net/omniosdisk/azure-151037.vhd

Once this is complete, a JSON object will be displayed which includes the assigned public IP address for the VM:

        {
  "location": "ukwest",
  "powerState": "VM running",
  "publicIpAddress": "51.140.2xx.1xx"
}

If all went well, you should be able to SSH straight in using the provided admin username and SSH key:

        $ ssh boho@51.140.2xx.1xx
The authenticity of host '51.140.2xx.1xx (51.140.2xx.1xx)' can't be established.
ECDSA key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
OmniOS r151037  omnios-master-0401360920        March 2021
boho@web01:~$
boho@web01:~$
boho@web01:~$ sudo -s
root@web01:/home/boho#

You can then proceed to add additional data disks to the machine as required using the standard Azure CLI or web interface.