A post in my ongoing saga to find a replacement operating system for CentOS8. These posts are primarily notes I am making for myself on why I consider an OS an acceptable replacement or something I personally cannot use to replace my CentOS8 servers. That are certainly not detailed posts or even fully evaluated recomendations for anyone else… I am not fully evaluating each OS but only focusing on what I need and whether the OS provides it.
OpenIndianna is a production ready operating system, and depending upon what you want to use your servers for this is an option that should be considered as an OS; but not as a drop in replacement for CentOS8 as Oracle Linux and Debian can be (as documented in my earlier posts).
From the requirements I need, which is puppet and docker the good news is that puppet is available in the standard repositories. The bad news is that as OpenIndianna does not use a ‘Linux kernel’ docker is not available for this operating system.
Despite docker not being available OpenIndianna does of course provide Solaris Zones for application isolation, although they are fairly heavyweight compared to docker containers and of course configured completely differently and not truely isolated as the easiest way of networking a zone is to give it a public ip on your network.
Openindianna is available from the OpenIndianna download page if you are interested in giving it a try.
Also you will need to learn a completely new set of packaging tools, and a new set of system management tools (svcadm/zonecfg/zfs/zpool etc.) For example instead of “systemctl status httpd”, “systemctl enable httpd”, “systemctl start httpd”, “systemctl status httpd” you would use the below.
root@openindiana:/etc/apache2/2.4# svcs -a | grep apache2 disabled 21:38:40 svc:/network/http:apache24 root@openindiana:/etc/apache2/2.4# svcs svc:/network/http:apache24 STATE STIME FMRI disabled 21:38:40 svc:/network/http:apache24 root@openindiana:/etc/apache2/2.4# svcadm enable svc:/network/http:apache24 root@openindiana:/etc/apache2/2.4# svcs svc:/network/http:apache24 STATE STIME FMRI online 22:32:15 svc:/network/http:apache24 root@openindiana:/etc/apache2/2.4#
However if you are used to creating service files for systemd you should have no trouble creating svc files for the OpenIndianna operating system.
Likewise the package management commands are different to CentOS, fortunately most are wrapped by the ‘pkg’ command. However
root@openindiana:/etc/apache2/2.4# pkg search php-pdo INDEX ACTION VALUE PACKAGE pkg.fmri set openindiana.org/web/php-56/extension/php-pdo pkg:/web/php-56/extension/php-pdo@5.6.35-2018.0.0.1 pkg.fmri set openindiana.org/web/php-54/extension/php-pdo pkg:/web/php-54/extension/php-pdo@5.4.45-2016.0.0.2 pkg.fmri set openindiana.org/web/php-55/extension/php-pdo pkg:/web/php-55/extension/php-pdo@5.5.38-2016.0.0.1 root@openindiana:/etc/apache2/2.4# pkg install php-pdo Creating Plan (Solver setup): - pkg install: No matching version of web/php-70/extension/php-pdo can be installed: Reject: pkg://openindiana.org/web/php-70/extension/php-pdo@7.0.33-2020.0.1.5 Reason: This version is excluded by installed incorporation consolidation/userland/userland-incorporation@0.5.11-2020.0.1.12901 root@openindiana:/etc/apache2/2.4#
It is a bit cleaner in a full package update in that it builds a new boot environment.
root@openindiana:/etc/apache2/2.4# pkg update
Packages to remove: 1
Packages to install: 10
Packages to update: 481
Create boot environment: Yes
Create backup boot environment: No
DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 492/492 16174/16174 408.9/408.9 219k/s
PHASE ITEMS
Removing old actions 6025/6025
Installing new actions 5528/5528
Updating modified actions 16031/16031
Updating package state database Done
Updating package cache 482/482
Updating image state Done
Creating fast lookup database Done
A clone of openindiana exists and has been updated and activated.
On the next boot the Boot Environment openindiana-2021:01:02 will be
mounted on '/'. Reboot when ready to switch to this updated BE.
It should be noted that after the full update the ‘pkg install php-pdo’ command shown above did actually work. However trying to install other packages I would need proved frustrating, the package management system seems to have no equivalent of the dnf/yum behaviour of simple selecting a match for what is already installed.
root@openindiana:~# pkg install php-opcache \
> php-intl \
> php-common \
> php-soap \
> php-mbstring \
> php-gd \
> php-json \
> php-fpm \
> php-xml \
> php \
> php-cli \
> php-mysqlnd \
> php-pecl-http \
> php-bz2 \
> php-zip \
> php-pclzip
pkg install: The following pattern(s) did not match any allowable packages. Try
using a different matching pattern, or refreshing publisher information:
php-pclzip
php
php-mysqlnd
php-pecl-http
php-xml
'php-common' matches multiple packages
pkg://openindiana.org/web/php-73/php-common
pkg://openindiana.org/web/php-70/php-common
'php-fpm' matches multiple packages
pkg://openindiana.org/web/php-73/php-fpm
pkg://openindiana.org/web/php-70/php-fpm
'php-cli' matches multiple packages
pkg://openindiana.org/web/php-73/php-cli
pkg://openindiana.org/web/php-70/php-cli
Please provide one of the package FMRIs listed above to the install command.
root@openindiana:~#
So you have to manually determine what is actually installed. Incidentally the ‘pkg update’ command upgraded everything to 70 so I could assume that the 73 is only partially implemented at this point or 73 would have been installed ?.
root@openindiana:~# pkg list | grep php web/php-70/extension/php-pdo 7.0.33-2020.0.1.5 i-- web/php-70/php-cli 7.0.33-2020.0.1.5 i-- web/php-70/php-common 7.0.33-2020.0.1.5 i-- root@openindiana:~#
Also it highlights that the packages I need to move my website to an OpenIndianna server may not exist making it even less likely it is a viable alternative for me.
You will also have seen that a full package update logged messages saying a new boot environment was created to boot from. So as well as learnming new package commands you must learn new OS management commands as a result of wanting to install packages. As a side note it is interesting that a new BE has a new copy of /var as I’m not aware of any OS configuration files that live under there so just retaining the existing /var with website pages, mysql/mariadb databases, logfiles etc. would seem to me to make more sense that replicating them all in a new boot environment. But then what do I know; and this post is not on how to use OpenIndianna but on why I would find it difficult to replace a CentOS server farm with OpenIndianna.
root@openindiana:~# beadm list BE Active Mountpoint Space Policy Created openindiana - - 7.65M static 2020-08-27 14:14 openindiana-2021:01:02 NR / 5.76G static 2021-01-02 03:35 root@openindiana:~# zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 9.90G 28.4G 33K /rpool rpool/ROOT 5.77G 28.4G 24K legacy rpool/ROOT/openindiana 7.65M 28.4G 2.43G / rpool/ROOT/openindiana-2021:01:02 5.76G 28.4G 2.52G / rpool/ROOT/openindiana-2021:01:02/var 1.94G 28.4G 910M /var rpool/ROOT/openindiana/var 2.49M 28.4G 956M /var rpool/dump 2.00G 28.4G 2.00G - rpool/export 77K 28.4G 24K /export rpool/export/home 53K 28.4G 24K /export/home rpool/export/home/mark 29K 28.4G 29K /export/home/mark rpool/swap 2.13G 30.5G 25.5M - root@openindiana:~#
On the firewall side OpenIndianna uses “IP Filter” as the firewall solution. As such users coming from a CentOS environment where iptables and NF tables have been used (either hidden from the user behind firewalld or used manually) will have to learn a new set of commands; and rewrite any customised automated firewall deployment and checking tools used.
It should also be noted that I did previously use solaris-x86 (back in the day when SUN still owned it) and OpenIndianna and found everything I needed as far as applications/packages go compiled with the GCC compiler quite happily from source so with a little bit of work everything needed is available… apart from Docker of course that needs a Linux kernel. I also found ZFS quotas extremely useful, athough I only played with zones as they provided no great benefit to me. It most certainly is a good solution if you are looking for a ‘all-in-one’ server for you applications, not so great if you are looking for application isolation or cloud deployment.
One thing that must be mentioned is that I have found it impossible to get OpenIndianna running under OpenStack (can do through the installation procedure and install, but not boot afterward). No ‘cloud images’ are available and the repositories do not seem to contain a ‘cloud-init’ package for it either (at least a ‘pkg search’ cannot find one). It does not support as much hardware as linux distributions do so you may run into issues, although it will run under linux KVM with the issue that on a reboot the KVM instance goes into a paused state and you must issue virst reset xxx and virsh resume xxx to let the reboot continue which makes it not the ideal candidate for an OS to run under KVM. This is also unlikely to ever be possible as this operating system is simply not designed for cloud use, it is a server operating system that runs best on native bare hardware.
For me personally I have been isolating applications I use (those that do not need access to the entire system anyway) into standard containers for docker and K8 use, so the inability to use docker prevents me from using this as a replacement for CentOS8; docker has become such a part of my application deployment I have even needed to run a local registry and moving applications from containers back to local server applications seems counter-intuative to me.
So for me it is not an option as a ‘quick’ replacement for CentOS8. For anyone setting up new server environments from scratch and no intention of using containers (although zones are available) it is a good option.
A note for desktop users; I have only ever used server installs so I do not know how it behaves as a desktop, however it is a good bet that if you rely on applications from rpmfusion, copr, or even snap packages you will probably find it wanting. I would consider it a ‘server’ OS.
