66 Migration Instructions

Dear Obarun users, the Obarun testing repositories are ready to be used to migrate your 66 program to the new release.

This documentation serves as a general guide and may not cover all possible scenarios. It is based on a system freshly installed from the latest ISO, so you may need to adapt these instructions to your specific setup.

Before proceeding, carefully read all instructions below and ensure you understand each command. If you have any questions or concerns, don't hesitate to seek assistance on the Obarun forum.

If you notice any missing or incorrect information in these instructions, please open an issue on our news repository.

Please replace oblive with your actual user account name in these migration instructions when it's necessary.

Create Backup

First, create a directory to store backups:

$ mkdir -p ${HOME}/migration-backup/{etc,var/lib,usr/lib}/66
$ mkdir -p ${HOME}/migration-backup/user/oblive

Next, make a backups of the /etc/66, /var/lib/66 and /usr/lib/66 directories.

$ sudo -E cp -rT /etc/66 ${HOME}/migration-backup/etc/66
$ sudo -E cp -rT /var/lib/66 ${HOME}/migration-backup/var/lib/66
$ sudo -E cp -rT /usr/lib/66 ${HOME}/migration-backup/usr/lib/66

Also, backup the ${HOME}/.66 directories

$ cp -r ${HOME}/.66 ${HOME}/migration-backup/user/oblive/

Note

If you have multiple users, ensure to backup files for each user.

Make sure to have the current version of the following packages on your disk:

$ sudo pacman -Sw base skalibs execline s6 s6-rc s6-portable-utils s6-linux-utils s6-networking oblibs 66 66-tools oblog consolekit obsysusers

Repeat this process for all packages related to your services.

Note

To quickly obtain and save a list of your current services, execute the following commands:

$ 66-intree -o name,enabled,start,contents > ${HOME}/migration-backup/user-services.list
$ sudo -E 66-intree -o name,enabled,start,contents > ${HOME}/migration-backup/root-services.list

For example:

$ sudo pacman -Sw boot@-66serv boot-user@-66serv scandir@-66serv wpa_supplicant-66serv dbus-66serv consolekit-66serv scandir@-66serv openntpd-66serv connmand-66serv dhcpcd-66serv

Info

You can also find it on the Obarun archive site.

Warning

If you have sensitive services running, such as PostgreSQL, it's recommended to stop them before proceeding with the migration. Since the 66 ecosystem is not fully compatible between versions, services may not shut down correctly during the reboot procedure.

Now that we have necessary backups in place, let's proceed with the migration itself.

Update the 66 Ecosystem

Activate the [obcore-testing], [obextra-testing] and [observice-testing] repositories by editing your /etc/pacman.conf.

Remove the existing /var/lib/66, /etc/66 and ${HOME}/.66 directories:

$ sudo -E rm -rf /var/lib/66/ /etc/66 ${HOME}/.66

Danger

Do not reboot the machine from this point onward.

Synchronize pacman databases and install the necessary packages:

$ sudo pacman -Sy base skalibs execline s6 s6-linux-utils s6-portable-utils s6-networking oblibs 66 66-tools oblog consolekit obsysusers

Note

Pacman will prompt about conflicts between 66 and s6-rc and ask to remove s6-rc. Answer yes to proceed. Note that s6-rc has been dropped from 66.

Additionally, update your services using the list saved at ${HOME}/migration-backup/{root,user}-services.list:

$ sudo pacman -S boot@-66serv boot-user@-66serv scandir@-66serv wpa_supplicant-66serv dbus-66serv consolekit-66serv scandir@-66serv openntpd-66serv connmand-66serv dhcpcd-66serv

Configure the Services

Once you have updated the 66 ecosystem, it's time to configure the services according to your needs. Follow these steps:

Enable the boot@ service:

$ sudo 66 enable boot@system

Configure the boot@ service using your preferred editor (replace nano with your editor of choice):

$ sudo 66 configure -e nano boot@system

Apply the changes:

$ sudo 66 reconfigure boot@system

Enable all other services that you require. For example:

$ sudo 66 enable boot-user@oblive wpa_supplicant consolekit connmand openntpd

Enable user-specific services. For instance:

$ 66 enable dbus@oblive

Check the trees to ensure everything is correct:

$ sudo 66 -z tree status -g
Name        : boot
Current     : no
Enabled     : no
Allowed     : root
Groups      : boot
Depends     : \
              └─None
Required by : \
              └─None
Contents    : \
              ├─boot@system:system-hostname (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-run (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-tmp (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-proc (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-sysctl (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:udevd-log (pid=0, state=Enabled, type=classic, tree=boot)
              ├─boot@system:tty-earlier@tty12 (pid=0, state=Enabled, type=classic, tree=boot)
              ├─boot@system (pid=unitialized, state=Enabled, type=module, tree=boot)
              ├─boot@system:populate-run (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:populate-tmp (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-sys (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:populate-sys (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-dev (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-pts (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-shm (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:populate-dev (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-cgroups (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-branch (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-hwclock (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:modules-kernel (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-random (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:modules-system (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:udevd (pid=0, state=Enabled, type=classic, tree=boot)
              ├─boot@system:udevadm (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-fontnkey (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-fsck (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-fstab (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:system-branch (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-rw (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-loop (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-sethostname (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-time (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-tmpfiles (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-authfiles (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:mount-netfs (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-dmesg (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:local-branch (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:runtime-branch (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:canopy (pid=unitialized, state=Enabled, type=oneshot, tree=boot)
              ├─boot@system:tty-rc@tty2 (pid=0, state=Enabled, type=classic, tree=boot)
              └─boot@system:tty-rc@tty1 (pid=0, state=Enabled, type=classic, tree=boot)

Name        : global
Current     : no
Enabled     : yes
Allowed     : root
Groups      : admin
Depends     : \
              └─None
Required by : \
              └─session (Enabled)
Contents    : \
              ├─wpa_supplicant-log (pid=0, state=Enabled, type=classic, tree=global)
              ├─dbus-log (pid=0, state=Enabled, type=classic, tree=global)
              ├─consolekit-log (pid=0, state=Enabled, type=classic, tree=global)
              ├─connmand-log (pid=0, state=Enabled, type=classic, tree=global)
              ├─openntpd-log (pid=0, state=Enabled, type=classic, tree=global)
              ├─wpa_supplicant (pid=0, state=Enabled, type=classic, tree=global)
              ├─dbus (pid=0, state=Enabled, type=classic, tree=global)
              ├─openntpd (pid=668, state=Enabled, type=classic, tree=global)
              ├─consolekit (pid=0, state=Enabled, type=classic, tree=global)
              └─connmand (pid=0, state=Enabled, type=classic, tree=global)

Name        : session
Current     : no
Enabled     : yes
Allowed     : root
Groups      : admin
Depends     : \
              └─global (Enabled)
Required by : \
              └─None
Contents    : \
              ├─scandir@oblive:setenv@oblive (pid=unitialized, state=Enabled, type=oneshot, tree=session)
              ├─scandir@oblive:svscan@oblive-log (pid=0, state=Enabled, type=classic, tree=session)
              ├─scandir@oblive (pid=unitialized, state=Enabled, type=module, tree=session)
              ├─boot-user@oblive:mount-run@oblive (pid=unitialized, state=Enabled, type=oneshot, tree=session)
              ├─scandir@oblive:svscan@oblive (pid=0, state=Enabled, type=classic, tree=session)
              └─boot-user@oblive (pid=unitialized, state=Enabled, type=module, tree=session)

Check for user-specific services as well:

$ 66 -z tree status -g
Name        : global
Current     : no
Enabled     : yes
Allowed     : oblive
Groups      : user
Depends     : \
              └─None
Required by : \
              └─None
Contents    : \
              ├─dbus@oblive-log (pid=0, state=Enabled, type=classic, tree=global)
              └─dbus@oblive (pid=0, state=Enabled, type=classic, tree=global)

All services should be marked as pid=uninitialized or pid=0, but their state should be state=Enabled. Services that you want to be brought up at startup should also be marked as Enabled: yes.

Once everything is configured correctly, you can reboot:

$ sudo 66-shutdown -r now

Post migration

Deactivate the [obcore-testing], [obextra-testing], and [observice-testing] repositories by editing your /etc/pacman.conf.

If you use personal ns rules files, remember to install them from your ${HOME}/migration-backup/usr/lib/66/script/ns directory to /usr/share/66/script/ns.

Similarly, copy your personal /usr/lib/66/script directory to /usr/share/66/script/.

If you had personal service frontend files previously installed at /etc/66/service, copy them from your ${HOME}/migration-backup/etc/66/service directory to /etc/66/service. Also, don't forget to do the same for user services located at ${HOME}/.66/service by copying them from your ${HOME}/migration-backup/user/oblive/.66/service directory.

Please refer to the explanation below Using your own service.

Rollback

If you encounter any issues or wish to revert to a previous version of 66, follow these rollback instructions:

Remove the existing /usr/lib/66, /var/lib/66, /etc/66, and ${HOME}/.66 directories:

$ sudo -E rm -rf /usr/lib/66 /var/lib/66/ /etc/66 ${HOME}/.66

Restore the backed-up configuration files:

$ sudo -E cp -r ${HOME}/migration-backup/etc/66 /etc
$ sudo -E cp -r ${HOME}/migration-backup/var/lib/66 /var/lib

Additionally, restore user files:

$ cp -r ${HOME}/migration-backup/user/oblive/.66 ${HOME}/

Note for Coexistence of Services Versions

Services from versions 0.7.0.0 and 0.6.2.0 of 66 can coexist on the system because the new version of 66 does not recognize the /usr/lib/66 directory and instead uses the /usr/share/66 directory.

Restoring Services

Restoring the frontend service from ${HOME}/migration-backup/usr/lib/66 will bring back the service. However, pacman will not recognize the changes and conflicts during the installation of service packages. Therefore, we need to reinstall the services through pacman instead of restoring them by copying the ${HOME}/migration-backup/usr/lib/66 directory.

Without Internet Access

$ cd /var/cache/pacman/pkg
$ sudo pacman -Udd base-3-3-any.pkg.tar.xz skalibs-2.11.2.0-1-x86_64.pkg.tar.xz execline-2.8.3.0-1-x86_64.pkg.tar.xz s6-2.11.1.0-1-x86_64.pkg.tar.xz s6-rc-0.5.3.1-1-x86_64.pkg.tar.xz s6-linux-utils-2.5.1.7-1-x86_64.pkg.tar.xz s6-portable-utils-2.2.4.0-1-x86_64.pkg.tar.xz s6-networking-2.5.1.0-1-x86_64.pkg.tar.xz oblibs-0.1.4.0-2-x86_64.pkg.tar.xz 66-0.6.2.0-2-x86_64.pkg.tar.xz 66-tools-0.0.8.0-2-x86_64.pkg.tar.xz obsysusers-0.1.2.0-2-x86_64.pkg.tar.xz oblog-0.1.1.0-2-x86_64.pkg.tar.xz consolekit2-1.2.6-2-x86_64.pkg.tar.xz boot@-66serv-2.4.1-2-x86_64.pkg.tar.xz boot-user@-66serv-0.4.3-1-x86_64.pkg.tar.xz scandir@-66serv-0.3.1-1-x86_64.pkg.tar.xz

$ pacman -U wpa_supplicant-66serv-0.2.0-1-x86_64.pkg.tar.xz consolekit-66serv-0.2.0-1-x86_64.pkg.tar.xz dbus-66serv-0.2.1-1-x86_64.pkg.tar.xz openntpd-66serv-0.2.1-3-x86_64.pkg.tar.xz connmand-66serv-0.2.0-1-x86_64.pkg.tar.xz dhcpcd-66serv-0.2.0-1-x86_64.pkg.tar.xz

With Internet Access

Note

Be sure to have deactivated Obarun testing repositories in your pacman configuration file.

$ sudo pacman -Sydd base skalibs execline s6 s6-rc s6-portable-utils s6-linux-utils s6-networking oblibs 66 66-tools oblog consolekit obsysusers

$ sudo pacman -S boot@-66serv boot-user@-66serv scandir@-66serv wpa_supplicant-66serv dbus-66serv consolekit-66serv openntpd-66serv connmand-66serv dhcpcd-66serv

Once you have reinstalled the necessary packages, you can reboot the system:

$ sudo 66-shutdown -r now

Using Your Own Service

If you are using your own frontend service files, please be aware of the following points to ensure compatibility with the new version of 66:

Deprecation of longrun Type: The longrun type is deprecated and will be automatically converted to classic type during the parse process. However, it's essential to note that 66 does not modify the frontend file itself. To avoid issues with future updates of 66, it's recommended to change the longrun type of your service to classic type.
Deprecation of @shebang Key: The @shebang key is deprecated and will be removed in the next 66 release. Ensure that the shebang of your custom service is defined at the beginning of the @execute field. For detailed instructions, refer to the A word about the @execute key section.
Changes to module Type: The module type has undergone significant changes in its inner structure. You will need to recreate it from scratch. Refer to the explanation of the module directory structure on this page for detailed guidance.

You can find comprehensive information about the complete changes to frontend files on the upgrade documentation page.

Additionally, for assistance in converting service frontend files from version 0.6.2.0 to version 0.7.0.0, refer to the converting service frontend file page.

Common Command and Command Comparison

This description below is not attempted to replace the 66 documentation. Consult it if you have any doubts and to find out about all the new features and behavioural changes.

You can find a complete explanation of comparison between old and new 66 UI interface by reading the Rosetta Stone.

However, i'll provide translations between old and new 66 UI interface for the most common commands.

First at all, you can find help of 66 UI interfaces doing the following

$ 66 -h

This will display the general help of 66. You can have the help of any command doing for example:

$ 66 start -h

This will display the help of the start command. This behavior is true for every 66 command or subcommand for example

$ 66 tree create -h

This will give you help of the create subcommand from the 66 tree command.

Service manipulation

Start

In previous versions, a service had to be enabled before it could be started. However, in the current version, you can start a service without enabling it first. This means that the service will not be brought up at the next reboot unless it has been explicitly enabled.

To start a service, simply execute the following command, replacing dockerd with the name of your desired service:

$ sudo 66 start dockerd

By default the dockerd service will be parsed (if not already the case) and started at tree global. If the service was never parsed you can specify the tree to use with:

$ sudo 66 -t virtual start dockerd

Note

If the tree virtual doesn't exist yet, 66 will create it automatically. You don't need to specifically create any tree before associating a service within it. The tree is create with default configuration. Refer to the basic creation configuration documentation page for more information.

Enable

If the service was already enabled, the above command will not switch the service dockerd to the tree virtual. To do so, use:

$ sudo 66 -t virtual enable dockerd

It was accomplish with the old version by 66-enable -t virtual dockerd command.

Now, the dockerd service is a part of the virtual tree. You can also refers to the associated service to a tree documentation page.

You can also enable and start a service in one pass:

$ sudo 66 enable -S dockerd

The previous command to do the same was 66-enable -S dockerd.

Convenient Command

Some convenient command was introduce to reload, restart, and reconfigure a service.

To reload or restart a service, you previously used the command 66-start [-r|R] dockerd. With the new interface to reload a service, do

$ sudo 66 reload dockerd

To restart it, do

$ sudo 66 restart dockerd

Let's say you have modified something at the frontend file of the service and you want to apply the change, use:

$ sudo 66 reconfigure dockerd

This will stop, parse again the service, and bring up it again. The previous command to accomplish the same was 66-enable -F dockerd.

You may need to deal with configuration file of the service. The previous command used was 66-env -e nano dockerd, you can accomplish the same with

$ sudo 66 configure -e nano dockerd

Once you're done with your changes, apply it with the following command

$ sudo 66 reload dockerd

Note

In case of module type use sudo 66 reconfigure <service>. The reload command send a SIGHUP signal to the service which the traditionnal way on linux to make the daemon reloading it configuration file. In case of module the service need to be parsed again which what exactly do the reconfigure command.

Remove and Freed

You can remove a service like you did with 66-disable -R command. To do so with the new interface:

$ sudo 66 remove dockerd

You may want to free the ressources used by a service when you no longer need it running. Previously, you would use the command 66-stop -u dockerd. Now, you can achieve the same with:

$ sudo 66 free dockerd

Get Information

The command previously used to see service information was 66-inservice. This command is replaced by 66 status. So, to see a service status do:

$ sudo 66 status dockerd

You can combine options used in the previous 66 release with 66-inservice:

$ sudo 66 status -go name,status,logfile dockerd

Tree Manipulation

As we saw before, tree are created automatically if it doesn't exist yet with the invocation of the -t option of the 66 main command. But, you may want to configure it to suit your needs.

With the new version of 66, trees react similarly to services regarding interdependencies. A tree can depend on another tree. For example, if the session tree declares global as a dependency, the global tree will be brought up before the session tree. This means that all services associated AND enabled to the global tree will be started first before any services associated with the session tree.

However, a service can depend on another service even if the services are not associated with the same tree. For instance, the consolekit service is associated with the global tree, and dbus is associated with the session tree. consolekit depends on dbus. Even though the global tree will be started first when handling consolekit, 66 will attempt to start dbus first because consolekit depends on dbus. Then, when it's the turn of the session tree to start, 66 found dbus as already marked up, and continue to deal with the rest of the services associated to tree session.

In the new version of 66, a service can depend on any other service, regardless of the tree associated with the service. This marks a significant difference from the previous version of 66 and this the reason of the drop of the @extdepends field at frontend file. This flexibility also enables the ability to start a service without the need to enable it first. This feature is made possible by the removal of s6-rc.

Create, Enable, Remove a Tree

Previously, to create a tree you used 66-tree -n mytree. To do so with the new interface:

$ sudo 66 tree create mytree

This will create the tree named mytree with basic configuration.

The previous command to enable a tree 66-tree -E mytree can now be accomplish with:

$ sudo 66 tree enable mytree

You may want to control it dependencies, do it using the tree subcommand admin:

$ sudo 66 tree admin -o depends=global session

This tree subcommand replace the 66-tree -S. In this example the tree session will depends on tree global.

Note

You can create and manage the configuration of the tree in one pass with the tree create subcommand. The following command create and handle dependencies of the tree

$ sudo 66 tree create -o depends=global session

You can remove a tree with the command 66 tree remove previously made by the command 66-tree -R:

$ sudo 66 tree remove mytree

Marking the tree as the current one is straightforward:

$ sudo 66 tree current mytree

Get Information

The Command previously used was 66-intree. Use 66 tree status with the new 66 version:

$ sudo 66 tree status

This will display information of all trees.

You can also use previous option like:

$ sudo 66 tree status -g

Or to get information from a specific tree:

$ sudo 66 tree status -g global

Red line or keeping the old to the new

First of all, the inner directory structure of 66 underwent a revamp (thanks to the drop of s6-rc) and significant simplification. This inevitably breaks compatibility with previous versions.

To establish a solid foundation with the new version, it's advisable to take a somewhat drastic approach and clean all main 66 directories. Therefore, the backup to the Update the 66 Ecosystem procedure needs to be applied in any case.

Let's examine a complete example from an existing services system:

$ sudo 66-intree > intree_root.file
$ cat intree_root.file
Name         : boot
Initialized  : yes
Enabled      : no
Starts after : None
Current      : no
Allowed      : root
Symlinks     : svc->backup db->backup
Contents     : tty-earlier@tty12 mount-proc mount-sys system-hostname mount-run populate-run mount-tmp
               populate-tmp populate-sys mount-dev mount-pts mount-shm populate-dev mount-cgroups 00
               all-Mount modules-kernel udevd-log udevd udevadm system-fontnkey system-fsck mount-fstab
               system-hwclock system-random modules-system system-sysctl all-System mount-rw mount-netfs
               local-loop local-sethostname local-time local-tmpfiles local-authfiles local-dmesg all-Local
               all-Runtime All tty-rc@tty1 tty-rc@tty2 boot@system

Name         : virtual
Initialized  : yes
Enabled      : no
Starts after : None
Current      : no
Allowed      : root
Symlinks     : svc->backup db->backup
Contents     : dockerd-log dockerd virtlockd-socket virtlockd-log virtlockd virtlogd-log virtlogd
               libvirtd-log libvirtd

Name         : root
Initialized  : yes
Enabled      : yes
Starts after : None
Current      : yes
Allowed      : root
Symlinks     : svc->source db->source
Contents     : openntpd-log openntpd wpa_supplicant-log wpa_supplicant dbus-log dbus connmand-log connmand
               consolekit-log consolekit

Name         : boot-user
Initialized  : yes
Enabled      : yes
Starts after : root
Current      : no
Allowed      : root
Symlinks     : svc->source db->source
Contents     : setenv@oblive svscan@oblive-log svscan@oblive scandir@oblive mount-run@oblive boot-user@oblive

Name         : tty
Initialized  : yes
Enabled      : yes
Starts after : root boot-user
Current      : no
Allowed      : root
Symlinks     : svc->source db->source
Contents     : tty@tty5-log tty@tty5 tty@tty6-log tty@tty6

Similarly, for the user:

$ 66-intree > intree_user.file
$ cat intree_user.file
Name         : base
Initialized  : yes
Enabled      : yes
Starts after : None
Current      : yes
Allowed      : oblive
Symlinks     : svc->source db->source
Contents     : dbus-session@oblive-log dbus-session@oblive xdg-user-dirs

Now, let's review the configuration service files:

$ su
# for i in $(66-intree -no contents);do r=$(66-inservice -no envat $i); if [[ ${r} == "None" ]]; then continue ; fi ; v=${r##*/} ;  echo "$i:$v" >> service_root.file ;done
$ sort service_root.file | uniq -d
all-Runtime:2.4.1
boot-user@oblive:0.4.3
boot@system:2.4.1
connmand:0.2.0
consolekit:0.2.0
dbus:0.2.1
dockerd:0.2.0
local-authfiles:2.4.1
local-dmesg:2.4.1
local-sethostname:2.4.1
local-time:2.4.1
local-tmpfiles:2.4.1
modules-system:2.4.1
mount-dev:2.4.1
mount-proc:2.4.1
mount-pts:2.4.1
mount-run:2.4.1
mount-rw:2.4.1
mount-shm:2.4.1
mount-sys:2.4.1
mount-tmp:2.4.1
openntpd:0.2.1
scandir@oblive:0.3.1
svscan@oblive:0.3.1
system-fontnkey:2.4.1
system-fsck:2.4.1
system-hostname:2.4.1
system-hwclock:2.4.1
tty-earlier@tty12:2.4.1
tty-rc@tty1:2.4.1
tty-rc@tty2:2.4.1
virtlockd-socket:0.2.0
wpa_supplicant:0.2.0

For the user:

$ for i in $(66-intree -no contents);do r=$(66-inservice -no envat $i); if [[ ${r} == "None" ]]; then continue ; fi ; v=${r##*/} ;  echo "$i:$v" >> service_user.file ;done
$ cat service_user.file
dbus-session@oblive:0.2.1

After completing the steps outlined in the backup procedure up to the Update the 66 Ecosystem procedure, I can proceed by creating the necessary trees.

Trees

Boot Tree

The boot tree will be automatically created when invoking the 66 enable boot@system command. However, for the sake of demonstration, I will create it from scratch.

$ sudo 66 tree create -o groups=boot:allow=root boot

I can configure the tree during creation using the -o options:

The groups=boot indicates to 66 that the boot tree belongs to the boot group. This is a fairly new features. Associating the boot tree with the boot group prevents users from enabling the boot tree.
The allow=root option behaves the same as in the previous version.

Root Tree

With the new version, a default tree called global is provided and enabled by default. As for the root tree, it should be populated with services mainly used by other services or essential services required at every boot, such as sysadmin administration. There's nothing to configure for this tree as 66 handles it directly.

Virtual Tree

This tree requires no particular configuration. It was not enabled and has no dependencies. A simple creation will suffice:

$ sudo 66 tree create virtual

TTY Tree

This tree needs to start after the root and boot-user trees. Therefore, for us, it depends on global and boot-user. Again, in one pass, I create and configure the tree. The following command is self-explanatory:

$ sudo 66 tree create -o depends=global,boot-user tty

If you really enjoy typing 66 commands, you can split it into two steps, with the first being the creation and the second the administration of the tree:

$ sudo 66 tree create tty
$ sudo 66 tree admin -o depends=global,boot-user tty

It's also enabled straightforwardly:

$ sudo 66 tree enable tty

Boot-User Tree

The boot-user@ service is already created by the tty tree creation process. Since I invoked depends=global,boot-user in the create command and 66 didn't find the boot-user tree, it created it with a sensible default configuration. Any invocation of a non-existing tree by any related tree options with any 66 command will trigger its creation.

However, it needs to be configured slightly to depend on global as it is dependent on root:

$ sudo 66 tree admin -o depends=global boot-user

Now, I'm done with the tree configurations.

Services

Boot@system

Starting with the boot service:

$ sudo 66 enable boot@system

A brief explanation of what happens behind this 66 enable command: I didn't specify the name of the tree, but 66 associates the boot@system service with the boot@ tree. This is because a seed is provided with the boot@ service, and the service frontend file has the @intree=boot field defined. So, 66 knows where to enable the boot@system service and how to create the necessary tree. Since the boot tree was previously created, 66 left it as is.

I import my previous configuration file to the new one by copying the old version (service_root.file) from the backup to the configuration directory. Then, I invoke the configure command to import the old version to the new one, and finally, I reconfigure the boot@system service to apply the changes:

$ sudo -E cp -r ${HOME}/migration-backup/etc/66/conf/boot@system/2.4.1 /etc/66/conf/boot@system/2.4.1
$ sudo 66 configure -i 2.4.1,3.7.0 boot@system
$ sudo 66 reconfigure boot@system

Note

To know the current version of the service:

$ sudo 66 configure -V boot@system

I may double-check to ensure everything is good:

$ sudo 66 configure -L boot@system

Warning

Name of variable at [environment] section may have changed between versions. You should always check your configuration file manually with the configure command above.

To Global

Transitioning from the previous root tree (intree_root.file), I need to enable the following services:

$ sudo 66 enable openntpd wpa_supplicant dbus connmand consolekit

Again, I don't need to specify the name of the tree. As @intree is not defined on these services and no trees are marked as the current one, 66 will use the global default tree. You can obviously force it if you really want with the -t option:

$ sudo 66 -t global enable openntpd wpa_supplicant dbus connmand consolekit

Or I can mark the tree as the current one:

$ sudo 66 tree current global
$ sudo 66 enable openntpd wpa_supplicant dbus connmand consolekit

All these commands yield the same result, with my services associated with the global tree.

I can apply the same method i used before for importing the old configuration to the new one:

$ sudo -E cp -r ${HOME}/migration-backup/etc/66/conf/openntpd/0.2.1 /etc/66/conf/openntpd/0.2.1
$ sudo 66 configure -i 0.2.1,0.7.0 openntpd

I don't need to use the 66 reconfigure command as the frontend itself was not modified, and it's not a module service type.

To summarize, I've applied the same process for all my global services.

To Virtual

Let's proceed quickly:

$ sudo 66 -t virtual enable dockerd libvirtd

The services are now associated with the virtual tree. I've applied my configuration importation process, and I'm done with these services.

To TTY

I think you understand the point by now:

$ sudo 66 -t tty enable tty@tty5 tty@tty6

I have no configuration files to import for these ones.

To Boot-User

The boot-user@ service is by default associated with a tree named session and provides the necessary seed file to configure that tree. It might be beneficial to switch to this new configuration, but the decision is yours. So, I force the use of the specified tree with the -t option:

$ sudo 66 -t boot-user enable boot-user@oblive

Applying the same configuration file importation process should now be straightforward for you. Additionally, I execute:

$ sudo 66 reconfigure boot-user@oblive

Since it's a module type, it needs to be reconfigured from scratch to apply the changes from my imported configuration files. As you may have noticed, there's no need to specify the tree here; 66 is smart enough to do what it needs to do.

And with that, I'm done :).

Some Observations

To maintain compatibility with previous practices of managing trees and services, I began by creating the trees. However, with the new version, you can take a shorter route, as 66 automatically creates trees when they don't exist on the system simply by enabling services and then administering the tree afterward:

$ sudo 66 enable boot@system # This creates the boot tree and also administers it through the seed configuration file
$ sudo 66 enable openntpd wpa_supplicant dbus connmand consolekit # Default to the global tree
$ sudo 66 -t virtual enable libvirtd dockerd # The tree doesn't exist yet, but 66 will create it
$ sudo 66 -t boot-user enable boot-user@oblive # Same here regarding the tree
$ sudo 66 -t tty enable tty@tty5 tty@tty6 # Another one
$ sudo 66 tree admin -o depends=global,boot-user tty # I administer the tty tree to make it depend on global and boot-user
$ sudo 66 tree enable tty # Self-explanatory
$ sudo 66 tree admin -o depends=global boot-user # Set global as a dependency for boot-user

Now, I can proceed with my configuration file importation process and finally reconfigure the boot@system and boot-user@oblive services.

User Services

The exact same process can be applied to user services. Since a global tree exists for the root user, a global tree for users also exists and behaves in the same manner. Therefore:

$ sudo 66 enable dbus@oblive xdg-user-dirs

Again, I can now import my configuration files if desired. As you may have noticed, the dbus-session@ service was renamed to dbus@. However, this is the exact same service and performs the same functions as before.

Obarun Notable Changes

The new 66 version provide a default tree called global. This tree is always present on your system. If you remove it, this tree will be automatically recreated at any 66 command invocation. By default, any service started/enabled will be associated to that tree. This tree is also enabled by default, that mean that 66 will try to start any enabled service on it right after the finish of the boot tree. So, in fact it react as same as the previously tree called root.
The directory /usr/lib/66 is only used to store library of 66. All others compoments find on that directory can be find now at /usr/share/66
User services must be installed at ${HOME}/.66/service, /etc/66/service/user or /usr/share/66/service/user in that order of precedence. This allows us to make a quick visual distinction between system and user services. It also enables us to have the exact same name for a service that can be used by both root and regular users. A perfect example is dbus-66serv. In the previous version, this package installed the dbus and dbus-session@ frontend files. With the new version, the dbus-session@ frontend file was replaced by dbus@ and installed at /usr/share/66/service/user/dbus. Therefore, you can start the service using a regular account with the 66 start dbus@oblive command.
The boot-user@ service is now installed by default at tree named session. This tree is automatically created by 66 with sane default configuration at boot-user@ configuration.

Some Reasons

I am aware that the new version requires many changes and adaptations for the use of the new interfaces. I had two choices: either I continued and dragged old issues in the code with s6-rc, or I completely rethought 66 as an independent service manager by abandoning s6-rc.

Don't get me wrong, s6-rc is very good software but too static for the use and needs of machine infrastructures mostly for desktop use. S6-rc guarantees service startup sequences as immutable, which is great but complicates the use and configuration of the services ecosystem.

The new version of 66 also guarantees service startup sequences but does so in a much more flexible way, allowing the end user to build complex service structures without needing to have an overview of the entire system's services.

Using trees in the previous version of 66 was difficult to manage because a service could not depend on another if it was not in the same tree. The new version of 66 solves this problem. In fact, the user should not even have to deal with manipulating trees anymore, as 66 is intelligent enough to build and manage the service dependency graph for the entire system.

Additionally, the introduction of seed files and the @intree field allows distributors to configure the 66 ecosystem from the start without any intervention required from the user.

I am also aware that the skalibs packages have been stuck at a specific version for a long time. To be honest, I tried to optimize the little time I had to dedicate to the different components of Obarun. 66 was my priority but I didn't see the point of wasting time adapting 66 which was going to be obsolete anyway. After all, if 66 is built with static libraries, skalibs components can be updated on the system and do not prevent the use of the latest skalibs tools.

The interface of the tools also needed changes. The proliferation of tool names such as 66-start, 66-enable, made usage as difficult for users as it was for scripting. We now have a single interface 66 followed by specific commands. This design is much closer to interfaces used by tools such as Git, for example, and is more intuitive to use.

This should also allow for easier integration of 66 into tools that manipulate services. Many web-based tools are being developed today, especially to meet the needs in the cloud domain. Most of these tools use commands such as systemctl start/reload/restart <service> to manage the services they need. The new version of 66 allows, for example:

# ln -sf /usr/bin/66 /usr/bin/systemctl

This obviously greatly simplifies the integration of 66 for cloud tools, without the need for explicit code modification for service management. However, 66 does not cover all systemctl commands and I must be clear here: 66 was not, is not, and will not be a little chick following its mother. Providing compatibilities when possible is a good thing and avoids being part of the problem. All software development should be done with awareness and consideration of the professional or personal production environment around us whether we like it or not. But that's where it stops. 66 does not have the same objective as systemd; 66 works on mechanisms, not on policies. 66 deals with service management, nothing more, nothing less.

Increasing the flexibility of relationships between services was also necessary. This change will allow for easier development of event-reactive service integrations as well as easier integration of 66 into tools such as dbus-broker. This is brought about by the ability to start a service without the need for it to be "enabled". We are talking here about external tools. 66 has nothing to do with dbus or seatd. Here again, market reality forces us to use tools for which we currently have no real alternative (I am thinking in particular of eudev).

The abandonment of s6-rc inevitably leads to deep changes in the 66 infrastructure code, which is either a very good thing. The number of lines of code remains around 30 thousand lines with increased flexibility, more features, better program execution quality, and increased optimization of certain algorithms, for example, the parser takes three times shorter to accomplish the same task as with the previous version.

The work is certainly not finished and a small roadmap has started to be published and which will, I hope, allow you to have a clearer vision of the future developments of 66.

I hope this new version will satisfy you and that you will appreciate the changes made.

Thank you for your continued support of Obarun.

Thanks for your attention

Eric Vidal: eric@obarun.org