Obarun news

The [obcommunity] database is now signed

Eric Vidal — Sat, 30 May 2026 00:00:00 +0000

The [obcommunity] database is now signed

Dear Obarun Community,

The [obcommunity] repository is now signed: both its database and its packages can be cryptographically verified, just like the official Obarun repositories.

What changed

The pacman package has been updated so that signature verification for [obcommunity] is enforced by default. The global SigLevel is now Required (packages and database must be signed), and the [obcommunity] entry carries no DatabaseOptional override, so it inherits that full verification.

Action required

These new defaults are shipped with the pacman update as /etc/pacman.conf.pacnew; your existing /etc/pacman.conf is left untouched. To benefit from this security, you must merge pacman.conf.pacnew into your active configuration (for example with pacdiff). Without this merge, pacman keeps running with your previous settings and the signatures are not checked.

If you activated [obcommunity] following the older instructions, your block still contains:

[obcommunity] SigLevel = DatabaseNever Server = https://cloud.server.obarun.org/$repo/os/$arch

Remove the SigLevel = DatabaseNever line (or whatever defined) so the repository inherits the new global Required level and its signed database is actually verified:

[obcommunity] Server = https://cloud.server.obarun.org/$repo/os/$arch

Then resynchronise your databases:

pacman -Syy

A reminder: new packagers are always welcome

[obcommunity] is a community-managed repository, and it lives thanks to the people who contribute to it. Now that its packages and database are signed, this is a good moment to recall that new packagers are always welcome. If you have ever wanted to package software for Obarun, the path is now short and built on standard git operations — see the apkg tooling and the project skeleton to get started. Every new contribution helps [obcommunity] grow.

Thank you for your continued support of Obarun.

Eric Vidal: eric@obarun.org

XLibre packages move from [obcommunity] to [obextra]

Eric Vidal — Sun, 17 May 2026 00:00:00 +0000

XLibre packages move from [obcommunity] to [obextra]

Dear Obarun Community,

The xlibre-server, xlibre-input and xlibre-video packages have been moved from the [obcommunity] repository to the official [obextra] repository. This marks an important step in Obarun's transition away from Xorg.

A long road through [obcommunity]

XLibre has lived in [obcommunity] for a long time and has been tested in real conditions for many months. A heartfelt thank you to wat-now for the work carried out to bring and maintain these packages in [obcommunity] — without that groundwork, this promotion would not have been possible.

After this extended testing period, the packages are now mature enough to enter the official Obarun repositories.

What this means

xlibre-server, xlibre-input and xlibre-video are now part of [obextra]. The goal is clear: XLibre is intended to fully replace Xorg on Obarun.

Users are therefore encouraged to switch from xorg to xlibre. From now on, Xorg should be considered deprecated on Obarun. Existing Xorg installations will keep working, but new deployments and migrations should target XLibre.

What is coming next

The next Obarun ISOs (not yet ready) will ship with XLibre instead of Xorg as the default display server stack. The shift in the repositories is the first visible step of that transition; the ISO rebuilds will follow.

Thank you again to wat-now and to everyone who tested XLibre on Obarun during its time in [obcommunity]. Your feedback is what made this promotion possible.

Thank you for your continued support of Obarun.

Eric Vidal: eric@obarun.org

Introducing docs.obarun.org — automated, centralized documentation

Eric Vidal — Sat, 16 May 2026 00:00:00 +0000

Introducing docs.obarun.org — automated, centralized documentation

Dear Obarun Community,

Documentation for every Obarun program now lives under a single dedicated domain: docs.obarun.org. More importantly, it now updates itself.

Why this change

Until now, every documentation update required a manual change on the website side: each new software release meant editing the site, regenerating pages, and republishing — for every tag, on every project. That overhead delayed updates and made the published documentation chronically out of sync with the actual releases.

The new setup removes that step entirely. When a new tag is created on a software's repository, its documentation is built and published automatically to docs.obarun.org. No human intervention, no website edit, no manual deploy. The documentation you read on docs.obarun.org reflects the tags as they happen.

How it works

The list of available software is still accessible from web.obarun.org/software. Selecting the documentation of a program now opens its dedicated section on docs.obarun.org, versioned per release. For example, the documentation of 66 for a given version is available at:

https://docs.obarun.org/66/<version>/

Every published version stays online at its own URL, so older releases remain referenceable.

Always reach the latest version

Each software exposes a latest shortcut that always points to the most recent published version of its documentation. No need to track version numbers — the link follows the tags automatically:

The same pattern applies to every Obarun program: docs.obarun.org/<software>/latest/.

Under the hood

All documentation is rendered with mkdocs-material, sharing the same theme, search, and navigation across projects. The publication pipeline is wired into each software's CI: a tag push triggers the build and deploy, and the new version (plus the latest/ shortcut) is live within minutes.

We hope this new layout makes the documentation easier to find, to trust, and to link to.

Thank you for being part of the Obarun journey!

Eric Vidal eric@obarun.org

apkg — new pipeline tooling for Obarun packages

Eric Vidal — Mon, 11 May 2026 00:00:00 +0000

apkg — new pipeline tooling for Obarun packages

Dear Obarun Community,

The build and deployment pipeline behind every Obarun package — [obcore], [obextra], [observice] and [obcommunity] — has been rebuilt from the ground up. The new tool is called apkg. It replaces the legacy apkg-*.sh bash scripts that have been quietly orchestrating Obarun package releases for more than 3 years. This post explains what changed, what it means for maintainers, and — most importantly — why contributing a package to [obcommunity] is now drastically easier than it used to be.

Why this matters

Until now, each package project carried a copy of a 12-script bash pipeline. Edge cases in version detection, signing, and tier promotion were handled inconsistently. Onboarding a new contributor involved a steep learning curve before they could understand how a package goes from a ‘PKGBUILD’ to the public repository.

apkg consolidates all of that into a single, tested Python application, packaged and shipped as obextra/apkg. The pipeline logic now lives in one place, behaves the same in every project, and is covered by an actual test suite.

Improvements

Several long-standing issues from the bash era are now properly handled:

Signing key isolation and Security — the Obarun signing key never leaves CI variables. Maintainers and operators do not hold it, even when publishing locally-built packages: the signature is added by a dedicated CI project after upload.
Epoch and split-package version comparison — a class of subtle bugs in the legacy pipeline that occasionally produced wrong or missed updates.
Concurrent repository operations — MinIO-backed locking with retry, replacing the old best-effort approach.
Cascading rebuilds — when a shared dependency bumps, downstream packages are now discovered, topologically sorted from .SRCINFO, and rebuilt in the correct order through a dedicated orchestrator, with parallel execution within independent topological waves.
Update detection — a single orchestrator job per repository detects upstream Arch bumps and dispatches the work, removing the need for per-package cron jobs.
Tier alignment — packages are promoted between staging, testing and stable automatically to match the tier where Arch currently has them, instead of relying on manual promotions in some cases.
Consistent exit codes and structured logging — every command follows the same convention (0 success, 111 failure) with a unified log format across the entire pipeline.

What changed under the hood

The legacy 12 bash scripts have been replaced by two binaries sharing a single library:

apkg — local administration: list, archive, delete, move, diff, audit packages stored in the Obarun repositories, plus optional helpers for the daily packaging workflow.
apkg-ci — CI engine: detects upstream Arch updates, builds, signs, deploys, promotes testing → stable, and runs dependency-aware cascading rebuilds.

All business logic lives in apkg.lib; the two binaries are thin frontends. The same code path runs whether a command is invoked locally on a maintainer's machine or inside a GitLab CI job.

What this means for package maintainers

The .gitlab-ci.yml of every package project is now a thin file that calls apkg-ci commands. There is nothing to copy, nothing to keep in sync between projects, and no bash internals to read in order to understand what the pipeline does. When the pipeline needs an improvement, the change happens once in apkg and propagates to every project on the next image rebuild.

For day-to-day work, apkg provides commands grouped by intent — build & publish, repo management, inspection, advanced — discoverable through apkg --help with full reference in docs/USAGE.md.

What this means for old/new contributors on Obcommunity

This is the part we care about most.

A contributor does not need to install or learn apkg to publish a package on Obcommunity. The CI pipeline runs on the GitLab side. From the contributor's machine, the entire packaging workflow comes down to standard git operations:

git add ... git commit -m "..." git push

That's it. Pushing the commit triggers the pipeline; the pipeline builds, signs, and deploys the package to the right tier of [obcommunity]. The contributor never touches apkg-ci, never holds the signing key, never logs into the repository server.

What needs to be respected is a minimal project skeleton, the same one used by every Obarun package. It looks like this:

mypackage/ ├── mypackage/ # git submodule → upstream PKGBUILD source │ └── .SRCINFO # generated with `makepkg --printsrcinfo > .SRCINFO` └── .gitlab-ci.yml # template — copy as-is, two stages: build, deploy

The .gitlab-ci.yml is a 30-line template provided in the apkg repository under templates/skeleton/. Copy it once, never touch it again. Every other file in the layout is either standard PKGBUILD packaging or strictly optional.

If a contributor wants extra control, the control/ directory provides simple text files to adjust per-package behaviour without changing the pipeline:

control/tier — force staging, testing or stable.
control/cascade — declare which packages must be rebuilt when this one bumps.(require apkg use)
control/frozen — temporarily exclude a package from the orchestrator.(require apkg use)
control/makeflags, control/makeopts — adjust the build for memory-hungry packages.

Each is a single-line text file. Add one, commit, push — done.

If you have ever considered packaging software for Obarun but found the existing tooling intimidating, now is the time to give it another look. The path from "I want to package X" to "X is in [obcommunity]" is now short, predictable, and built on top of standard tools you already use.

Documentation

User reference: docs/USAGE.md in the apkg repository.
Project skeleton: templates/skeleton/ in the same repository.
Patch authoring walkthrough: templates/HOWTO-patches.md.
Built-in help: apkg --help and apkg-ci --help, with subcommands grouped by intent.

Getting involved

If you would like to contribute a package, improve an existing one, or report an issue with the new pipeline, the Obarun Git repository is the place to start. Feedback from early users of apkg is especially welcome — every report helps us refine the tooling further.

Thank you for your continued support of Obarun.

Eric Vidal: eric@obarun.org

0.8.2.0 66 release

Eric Vidal — Sat, 31 May 2025 00:00:00 +0000

Obarun 66 Version 0.8.2.0 Released

Dear Obarun Community,

The release of 66 version 0.8.2.0 marks a significant step forward for the Obarun service management system. This update introduces powerful new features, critical bug fixes, and performance improvements designed to offer greater control, reliability, and ease of use for system administrators and users. Below is an overview of the key changes to help make the most of this release.

New Features

A new [Execute] section has been added, providing enhanced control over tasks executed just before a service’s start or stop processes. This section includes options like ChangeDirectory for setting the working directory, Nice for adjusting CPU scheduling priority, UMask for managing file creation permissions, BlockPrivileges for restricting privileges, LimitXXX for setting resource limits (e.g., LimitNICE, LimitNOFILE), and CapsBound and CapsAmbient for managing capabilities without additional dependencies. These tools allow for precise customization of service behavior.

Service dependency management has been improved with the Conflict key in the [Main] section, enabling specification of services that cannot run simultaneously, ensuring smoother operation.

Service configuration is now simpler, as Description, User, and Version fields are optional. If not provided, defaults are applied: Description uses the service name, User matches the process owner, and Version reflects the installed 66 version. This streamlines setup without sacrificing functionality.

Service trees can now be enabled at creation time, making it easier to set up and administrate trees in one step.

The project has transitioned to the Meson build system, offering improved cross-platform compatibility and build efficiency. The traditional configure and make system remains available during this transition, but testing Meson and sharing feedback is encouraged as the old build system can be consider as deprecated. Refer to INSTALL_MESON.md for setup instructions.

Enhancements

The development pipeline is now more robust, with the CI/CD system leveraging Meson and incorporating git support for reliable builds. A new boolean syntax for the BlockPrivileges key has been introduced, with updated documentation. The version comparison system has also been enhanced with new tests for greater reliability.

Bug Fixes

Several important issues have been resolved. A critical bug from version 0.8.0.0, which incorrectly set s6log logger ownership to root and removed runas information during migration, has been fixed. Services that crash now trigger clear error messages, improving system stability.

Compiler warnings for GCC and Clang have been eliminated, resulting in cleaner builds. The migration process has been improved to handle unknown logger directories, enhance Master resolve file processing. Performance enhancements include a corrected handling of uint64_t values, and proper log file display for logger of StdOut=file:/path type. A memory leak has been addressed, and minor fixes—such as corrected option names, removed unused files.

Upgrading to 0.8.2.0

To ensure a smooth transition, consider the following steps:

Verify Logger Settings: If upgrading from version 0.8.0.0 or 0.8.1.1, check s6log logger permissions to confirm they are set correctly. The migration process should take care of it for you. However, ensure that you have a correct permissions for the logger services directories if you get a down logger process after applying the migration. It should be set to s6log:s6log for the /var/log/66 and <username>:<username> for $HOME/.66/log and their sub-directories and files.

Community Engagement

Exploring the new features and testing the Meson build system is highly encouraged. Feedback is invaluable for refining 66 and ensuring it meets user needs. Thoughts or issues can be shared via the Obarun Git repository.

For a detailed changelog, refer to the 66-upgrade.md document.

Thank you for your continued support of Obarun.

Thanks for your attention.

Eric Vidal: eric@obarun.org

66 version 0.8.0.0 now in stable repos

Eric Vidal — Wed, 13 Nov 2024 00:00:00 +0000

66 version 0.8.0.0 now in stable repos

Dear Obarun users, all required packages for 66, updated for the new 0.8.0.0 release, have been moved from the testing repository to their respective stable counterparts. Archives of previous versions can be found in the [obarchive] repository on the packages page.

If you haven’t completed the migration yet, follow the instructions below.

66 Migration Instructions

The release includes a new upgrade process that is fully transparent to the user. Whether a migration involves changes to the resolve file or other components, 66 automatically detects version upgrades and makes the necessary adjustments, ensuring continuity with the new version. This process does not affect the state of running services, and an automatic snapshot is created during the migration to facilitate easy recovery if needed.

The release also includes a new snapshot command, offering a comprehensive backup solution for the 66 ecosystem. This feature guarantees that you can restore the exact state of the ecosystem before any changes. Importantly, using snapshots does not alter the state of running services.

Refer to the upgrade page for further information concerning new features and behavior changes.

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.

Migration

Note

Be sure to have the 66 and skalibs package in your /var/cache/pacman/pkg directory. It will be easier for you in case you need a rollback.

Just synchronize and update your system.

Now you just need to trigger the automatic migration process by invoking any 66 command, for instance, by using the new behavior of the 66 status command:

# 66 -v3 status

This will trigger the migration process for the root account.

Now, do the same for your regular user:

% 66 -v3 status

That's all!

You can also directly initiate a reboot, though this is not mandatory to use the new release. This will migrate your system before rebooting.

Warning

You need to trigger the migration for the root account first before triggering it for regular users.

Warning

The migration process should complete successfully. If you encounter any errors, restore your previous system by performing a rollback and post an issue on 66 with as much information as possible about the crash.

Rollback

As the automatic migration process take a snapshot before processing, you can restore your previous system easily if something goes wrong. To do so, run:

# 66 snapshot restore system@0.7.2.1

Then, do the same for your regular account:

% 66 snapshot restore system@0.7.2.1

Note

You can see the list of available snapshot with the command 66 snapshot list

Now you need to downgrade the package

# cd /var/cache/pacman/pkg # pacman -U skalibs-2.14.2.0-1-x86_64.pkg.tar.xz execline-2.9.6.0-1-x86_64.pkg.tar.xz 66-0.7.2.1-2-x86_64.pkg.tar.xz 66-tools-0.1.0.2-3-x86_64.pkg.tar.xz oblibs-0.3.0.1-2-x86_64.pkg.tar.xz s6-2.13.0.0-1-x86_64.pkg.tar.xz s6-dns-2.3.7.2-1-x86_64.pkg.tar.xz s6-linux-utils-2.6.2.0-2-x86_64.pkg.tar.xz s6-networking-2.7.0.3-1-x86_64.pkg.tar.xz s6-portable-utils-2.3.0.3-2-x86_64.pkg.tar.xz oblog-0.1.1.0-6-x86_64.pkg.tar.xz obsysusers-0.1.2.1-5-x86_64.pkg.tar.xz

Also, downgrade your services packages.

Personal service

The migration process only deals with active services, meaning those that are running when you execute (as root or a regular user):

# 66 tree status

But you may have personal frontend files that are not active. To help with this, use the script below by running: ./migration_service.sh /path/to/my/<FrontendFile>

#!/bin/sh service="${1}" sed -e "s:\[main\]:\[Main\]:g" \ -e "s:@type:Type:g" \ -e "s:@description:Description:g" \ -e "s:@version:Version:g" \ -e "s:@depends:Depends:g" \ -e "s:@requiredby:RequiredBy:g" \ -e "s:@optsdepends:OptsDepends:g" \ -e "s:@options:Options:g" \ -e "s:@flags:Flags:g" \ -e "s:@notify:Notify:g" \ -e "s:@user:User:g" \ -e "s:@timeout-kill:TimeoutStart:g" \ -e "s:@timeout-up:TimeoutStart:g" \ -e "s:@timeout-finish:TimeoutStop:g" \ -e "s:@timeout-down:TimeoutStop:g" \ -e "s:@maxdeath:MaxDeath:g" \ -e "s:@down-signal:DownSignal:g" \ -e "s:@hiercopy:CopyFrom:g" \ -e "s:@intree:InTree:g" \ -e "s:\[start\]:\[Start\]:g" \ -e "s:@build:Build:g" \ -e "s:@runas:RunAs:g" \ -e "s:@execute:Execute:g" \ -e "s:\[stop\]:\[Stop\]:g" \ -e "s:\[logger\]:\[Logger\]:g" \ -e "s:@destination:Destination:g" \ -e "s:@backup:Backup:g" \ -e "s:@maxsize:MaxSize:g" \ -e "s:@timestamp:Timestamp:g" \ -e "s:\[environment\]:\[Environment\]:g" \ -e "s:\[regex\]:\[Regex\]:g" \ -e "s:@configure:Configure:g" \ -e "s:@directories:Directories:g" \ -e "s:@files:Files:g" \ -e "s:@infiles:InFiles:g" \ -i ${service}

See the Rosetta Stone for the list of keyword name changes.

Some Reasons

This release marks a major step towards the end of planned breaking changes for version 66. Version 0.7.0.0 introduced stability in the directory hierarchy of the 66 ecosystem, and version 0.8.0.0 solidified the stability of frontend file keys. While the implementation of events may happen in version 0.9.0.0, this can potentially occur without breaking existing 66 components(see roadmap).

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

Upgrading Obarun Site

Eric Vidal — Sun, 10 Nov 2024 00:00:00 +0000

Upgrading Obarun Site - Because We Deserve Better

Following our previous announcement, we’re pleased to officially present the new Obarun website! The old site, which had become outdated, unattractive, and buggy, no longer met our users' needs. This redesign brings improved clarity, accessibility, and efficiency, making it easier to navigate and offering a more welcoming experience.

What’s New?

Enhanced Package List: All packages are now available here, with full details for each package and the option to download directly—no more searching around!
Optimized Documentation: The documentation page of sotfware has been completely redesigned with a modern look and easier navigation, making it simpler to access information on each tool.

Source code remains accessible online, and contributions are always welcome! Whether you’re interested in enhancing the distribution or suggesting improvements, the community is open to anyone who shares our vision.

We hope this new site makes your experience even more enjoyable.

Thank you for being part of the Obarun journey!

Best regards,

Eric Vidal eric@obarun.org

66 migration instructions

Eric Vidal — Wed, 16 Oct 2024 00:00:00 +0000

66 Migration Instructions

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

Refer to the upgrade page for further information concerning new features and behavior changes.

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.

Migration

Note

Be sure to have the 66 and skalibs package in your /var/cache/pacman/pkg directory. It will be easier for you in case you need a rollback.

Just synchronize and update your system by activating the [obcore-testing], [obextra-testing], and [observice-testing] repositories.

Now you just need to trigger the automatic migration process by invoking any 66 command, for instance, by using the new behavior of the 66 status command:

# 66 -v3 status

This will trigger the migration process for the root account.

Now, do the same for your regular user:

% 66 -v3 status

That's all!

You can also directly initiate a reboot, though this is not mandatory to use the new release. This will migrate your system before rebooting.

Warning

You need to trigger the migration for the root account first before triggering it for regular users.

Warning

Rollback

As the automatic migration process take a snapshot before processing, you can restore your previous system easily if something goes wrong. To do so, run:

# 66 snapshot restore system@0.7.2.1

Then, do the same for your regular account:

% 66 snapshot restore system@0.7.2.1

Note

You can see the list of available snapshot with the command 66 snapshot list

Now you need to downgrade the package

# cd /var/cache/pacman/pkg # pacman -U skalibs-2.14.2.0-1-x86_64.pkg.tar.xz execline-2.9.6.0-1-x86_64.pkg.tar.xz 66-0.7.2.1-2-x86_64.pkg.tar.xz 66-tools-0.1.0.2-3-x86_64.pkg.tar.xz oblibs-0.3.0.1-2-x86_64.pkg.tar.xz s6-2.13.0.0-1-x86_64.pkg.tar.xz s6-dns-2.3.7.2-1-x86_64.pkg.tar.xz s6-linux-utils-2.6.2.0-2-x86_64.pkg.tar.xz s6-networking-2.7.0.3-1-x86_64.pkg.tar.xz s6-portable-utils-2.3.0.3-2-x86_64.pkg.tar.xz oblog-0.1.1.0-6-x86_64.pkg.tar.xz obsysusers-0.1.2.1-5-x86_64.pkg.tar.xz

Also, downgrade your services packages.

Personal service

The migration process only deals with active services, meaning those that are running when you execute (as root or a regular user):

# 66 tree status

But you may have personal frontend files that are not active. To help with this, use the script below by running: ./migration_service.sh /path/to/my/<FrontendFile>

#!/bin/sh service="${1}" sed -e "s:\[main\]:\[Main\]:g" \ -e "s:@type:Type:g" \ -e "s:@description:Description:g" \ -e "s:@version:Version:g" \ -e "s:@depends:Depends:g" \ -e "s:@requiredby:RequiredBy:g" \ -e "s:@optsdepends:OptsDepends:g" \ -e "s:@options:Options:g" \ -e "s:@flags:Flags:g" \ -e "s:@notify:Notify:g" \ -e "s:@user:User:g" \ -e "s:@timeout-kill:TimeoutStart:g" \ -e "s:@timeout-up:TimeoutStart:g" \ -e "s:@timeout-finish:TimeoutStop:g" \ -e "s:@timeout-down:TimeoutStop:g" \ -e "s:@maxdeath:MaxDeath:g" \ -e "s:@down-signal:DownSignal:g" \ -e "s:@hiercopy:CopyFrom:g" \ -e "s:@intree:InTree:g" \ -e "s:\[start\]:\[Start\]:g" \ -e "s:@build:Build:g" \ -e "s:@runas:RunAs:g" \ -e "s:@execute:Execute:g" \ -e "s:\[stop\]:\[Stop\]:g" \ -e "s:\[logger\]:\[Logger\]:g" \ -e "s:@destination:Destination:g" \ -e "s:@backup:Backup:g" \ -e "s:@maxsize:MaxSize:g" \ -e "s:@timestamp:Timestamp:g" \ -e "s:\[environment\]:\[Environment\]:g" \ -e "s:\[regex\]:\[Regex\]:g" \ -e "s:@configure:Configure:g" \ -e "s:@directories:Directories:g" \ -e "s:@files:Files:g" \ -e "s:@infiles:InFiles:g" \ -i ${service}

See the Rosetta Stone for the list of keyword name changes.

Some Reasons

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

66 reach the obcore repository

Eric Vidal — Fri, 03 May 2024 00:00:00 +0000

66 reach the obcore repository

Dear Obarun users,

I'm pleased to announce that the 66 and skalibs packages have been moved from the [obcore-testing] repository to [obcore]. After three years of development, i'm happy to share the results of this work with you.

If you haven't completed the migration yet, here are the migration instructions from the previous post, removing the instructions for activating the Obarun testing repositories

66 Migration Instructions

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

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

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

$ 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.

Conclusion

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

66 migration instructions

Eric Vidal — Mon, 25 Mar 2024 00:00:00 +0000

66 Migration Instructions

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

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

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/.

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

Restoring Services

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

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

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

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.

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.

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

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

$ 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

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

$ 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

$ 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

$ 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

And with that, I'm done :).

Some Observations

$ 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

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

Changes to Obarun XMPP Chat Client

Eric Vidal — Mon, 11 Mar 2024 00:00:00 +0000

Changes to Obarun XMPP Chat Client

We regret to inform our users that Movim will no longer be supported as a client for the Obarun XMPP chat server. Despite our efforts, we have encountered persistent issues with Movim, including instability, broken updates, and discrepancies between Docker images and development tags.

As a result, the chat.obarun.org address is no longer valid.

We are pleased to introduce a new chat client as a replacement: Converse.js. This online hosting solution for Converse.js will ultimately become the official chat client for Obarun, integrated into our new website. Please note that while the solution is currently maintained by a third party, the XMPP server itself is still hosted on the Obarun server.

Instructions for connecting to the Obarun XMPP chat using Converse.js:

Visit the address Converse.js.

If you already have an account:

Enter your full username. For instance, if your username is eric, enter eric@xmpp.obarun.org.
Enter your password.

If you don't have an account:

Click on create an account at the bottom of the page.
Enter xmpp.obarun.org as the provider address.
Click fetch registration form.
Fill out the form and complete the captcha. If you encounter an error message during registration such as Malformed username or any others errors, refresh your page before trying again.

For new users, once logged in:

Click on the groupchats menu on the left and click the + icon.
Enter "obarun" as the groupchat name, choose your desired nickname, and click join.

Congratulations! You are now connected to the official Obarun chat.

Thank you for being part of the Obarun journey!

Best regards,

Eric Vidal eric@obarun.org

Testing repositories update

Eric Vidal — Sun, 03 Mar 2024 00:00:00 +0000

Testing Repositories update

We are currently in the process of updating packages in the [obcore-testing], [obextra-testing] and [observice-testing] repositories to provide the necessaries for the migration to the new release of 66.

During this transitional phase, we advise users against utilizing packages from these repositories. We will soon release a detailed news update outlining the migration procedure.

As we cannot provide all the necessary packages in one row, do not use the testing repositories until you see a news page with the complete procedure for the migration.

This will take a little time to accomplish, your patience and cooperation are appreciated.

Stay tuned for further updates.

Thank you for your continued support of Obarun.

Eric Vidal: eric@obarun.org

Bugs reporting update

Eric Vidal — Tue, 16 Jan 2024 00:00:00 +0000

Bug Reporting Update: Shifting to Gitlab

Dear Obarun Community,

We're rolling out an important update regarding bug reporting for package-related issues.

Going forward, we kindly ask our users to submit bug reports directly on our Gitlab instance, under the corresponding project for the package in question.

Why the Change?

In our ongoing efforts to streamline and centralize our bug tracking process, we've decided to consolidate all bug reports onto our Gitlab platform. This change allows for better organization, efficient tracking, and faster resolution of reported issues.

How to Report Bugs?

To report a bug related to a specific package, please follow these steps:

Visit our Gitlab Instance: Navigate to our Gitlab instance.

Search for the Package: Use the search bar to find the project corresponding to the package you're encountering issues with. For example, if you're experiencing problems with the cronie package, locate the cronie project.
Open an Issue: Once you've found the project, open a new issue detailing the bug you've encountered. Be sure to provide as much relevant information as possible, including steps to reproduce the issue, system details, and any error messages.

Benefits of Using Gitlab for Bug Reporting:

Centralized Platform: All bug reports are now centralized on our Gitlab instance, making it easier for our developers to track and manage issues.
Improved Collaboration: Gitlab's collaborative features allow for better communication and collaboration between users and developers, leading to quicker bug resolutions.
Transparent Process: By reporting bugs on Gitlab, users can track the progress of their reported issues and stay informed about any updates or resolutions.

We believe this transition will enhance the bug reporting experience for our community and enable us to provide more efficient support.

Thank you for your cooperation and continued support as we strive to improve the Obarun experience together.

Best regards,

Eric Vidal eric@obarun.org

Upgrading Obarun News

Eric Vidal — Tue, 16 Jan 2024 00:00:00 +0000

Upgrading Obarun News - Because We Deserve Better

Dear Obarun Community,

We're excited to announce a significant upgrade to our news delivery system, and we want to share the reasons behind this change.

Why the Change?

Tedious Formatting: Writing news on the old platform was like navigating a maze of HTML tags, making the process long and cumbersome.
Internal Chaos: The organization of news internally resembled a digital battleground, making it challenging to maintain order.
Failed Archiving: Our attempts at archiving were, unfortunately, less successful than a cat trying to catch its tail.
Eye-Piercing Formatting: The text formatting was, to be blunt, visually offensive and a hazard to your ocular health.

The Turning Point: Release of 66

With the imminent release of 66 (after three years of hard work), we seized the opportunity to revamp not only our news delivery but also the overall face of Obarun.

The Game Plan: rm -rf site/

This year is earmarked for a complete overhaul of the Obarun website. If you've noticed the recent transformation of forum, you'll understand our commitment to improvement.

What to Expect?

Incremental Transformation: Over the coming months, you'll witness a gradual transformation of the Obarun website, brick by brick.
Next on the List: The documentation pages and package-related sections are on our radar for a makeover. Yes, we acknowledge the eyesore that is the current package table, and let's not even mention the perplexing DNS structure at cloud.server.obarun.org/browse.

We believe Obarun deserves a sleek, user-friendly, and efficient online presence, and we're committed to making it happen.

Thank you for being part of the Obarun journey!

Best regards,

Eric Vidal eric@obarun.org

66 preprod tag

Eric Vidal — Mon, 01 Jan 2024 00:00:00 +0000

66 preprod tag is out

We would like to inform you about the preprod release of 66. This release marks the completion of code development for the upcoming production release, with the focus shifting primarily to bug fixes from this point onward.

The dev branch was also merged to the master branch.

You can find the release note here

A milestone centralizes issues.

Thank you for your continued support of Obarun.

Thanks for your attention

Eric Vidal: eric@obarun.org ...

Activating obcommunity repository

Eric Vidal — Mon, 25 Dec 2023 00:00:00 +0000

Activating obcommunity repository

To enable the [obcommunity] repository and start benefiting from packages signed by obcommunity, follow these steps:

Look for the new package obcommunity-keyring in the[obcommunity] repository. You must install this package to take advantage of the signatures on packages from this repository.

Edit the /etc/pacman.conf file, uncomment the lines related to the [obcommunity] repository and modify the SigLevel field as below.

[obcommunity] SigLevel = Never Server = https://cloud.server.obarun.org/$repo/os/$arch/

Install the obcommunity-keyring package:

pacman -Sy obcommunity-keyring.

Edit the /etc/pacman.conf file again and change again the SigLevel field.

[obcommunity] SigLevel = DatabaseOptional Server = https://cloud.server.obarun.org/$repo/os/$arch/

Following these steps should allow you to install packages from the [obcommunity] repository and utilize their package signatures.

Thanks for your attention

Eric Vidal: eric@obarun.org