Instructions to pass to 66 v0.2.xxx version


Author : obarun | Tags : System, Generalpublied : 2019-07-21 13:17:00

66 packages v0.2.0.4 and its children


This explanation concerns essentially the transition between v0.1.x.x version and v0.2.x.x. The 66 documentation is now provided on html and manpages format and up to update. Refers on it to understand the following 66 command used in this thread.


We are talking about behaviour changes and what its need to be done to have an operational system.


Frontend files


A new @key field called @hiercopy on the [main] section, the ability to add a logger dependencies at longrun service and the new value called 'none' at @timestamp key were added.


Appart this new features, the most important changes concern the syntax of the environment variables to unexport the value. Previously:


[environment]
!key=value


where is now:


[environment]
key=!value


The exclamation mark '!' go now at the begin of the value instead of the key. This new format is expected by version of 66 higher than v0.2.0.0. If you, don't apply this change on your own service, the service will not be parsed correctly and will bring strange behaviour at running time. A double quoted can be used as:


[environment]
key=!"value"


Extra tools


New extra tools are here but be aware of the 66-envfile name changed to execl-envfile and it new interface. If you use it into your own scripts or service, please read the documentation of execl-envfile and change your service according with. Also, the old behaviour and name are kept. If a service contain 66-envfile a warning message about the changes is sends. Actually:


the 66-envfile is obsolescent, please use execl-envfile instead


Inner directories hierarchy


Due of the growing interest from other OS/Distro on 66, some adjustements was necessary to provide compatibility were:


Frontend service file previously installed by pacman at /etc/66/service goes now at /usr/lib/66/service. Let's call it 'upstream'. Frontend service file previously used by a administrator at /etc/66/sysadmin/service goes now at /etc/66/service. Let's call it 'sysadmin'.


Well, if you need to update an 'upstream' service make a copy of /usr/lib/66/service/ at /etc/66/service/. At the very first time, the parser will always give priority to this directory.


Configuration file of the daemon keep the same place meaning /etc/66/conf/.


Also, the heart of 66 rest at /var/lib/66.


If you have made personnal 'sysadmin' service, you need to place it at the new location to be able to use it.


To be general, configuration by administrator is expected at /etc/66. This directory is the well-know directory about configuration file.


/usr/lib/66 concern 'upstream' changes,... Any change on this directory will be overwritten at update time.


The heart of 66 at /var/lib/66 should be never touched by anyone. A change here can cause strange behaviour and an unstable system.


HOW TO: Beginning of the migration procedure


DO NOT UPDATE YOUR SYSTEM USING pacman -Syu.


Follow the exact intructions.


Make the instructions below on console


Be sure to have the following repositories enabled in your pacman.conf


[obcore-testing]
[obextra-testing]
[observice-testing]

(1) -> Synchronize the repositories using:


# pacman -Syy

(2) -> Update the 'skarnet' and oblibs package. A simple:


# pacman -Sy skalibs execline oblibs s6 s6-rc 


(3) -> Update all xxx-66serv package that you have e.g:


# pacman -S $(pacman -Qsq 66serv | grep -v "boot-66serv")


(4) -> We need to copy some files before updating the 66 and boot-66serv to be able to properly reboot the system at final update time. This will avoid to loose these files when the boot-66serv will be removed.


# mv /etc/66/stage2 /etc/66/stage2.bak
# mv /etc/66/stage2.tini /etc/66/stage2.tini.bak
# mv /etc/66/stage3 /etc/66/stage3.bak
# mv /etc/66/conf/boot /etc/66/conf/boot.bak
# mv /etc/66/66.conf /etc/66/66.conf.bak
# mv /etc/66/data /etc/66/data.bak
# mv /etc/66/sysadmin /etc/66/sysadmin.bak


(5) -> Uninstall boot-66serv. This need to be done before upgrading the 66 package.


# pacman -Rdd boot-66serv


(6) -> Install the new version of 66 (v0.2.0.4-1) and the new version of boot-66serv (v0.1.0.1-1):


# pacman -S 66 boot-66serv


(7) -> Create a temporary tree to store the new boot service set:


# 66-tree -n tmpboot


(8) -> Edit the /etc/66/init.conf to point the TREE variable to this temporary tree:


VERBOSITY=0
LIVE=/run/66
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin
TREE=tmpboot
RCINIT=/etc/66/rc.init
RCSHUTDOWN=/etc/66/rc.shutdown
UMASK=0022
RESCAN=0
ISHELL=/etc/66/ishell


This is really important here. If this variable is not set correctly you machine will not boot.


(9) -> Enable it:


# 66-enable -t tmpboot -C boot


A little explanation it needs. -C (new features) ask to 66 to overwrite the corresponding /etc/66/conf/ configuration file of the service. By default 66-enable will never touch these file if it not requested. We need this overwritten to apply the new syntax on environment files.


(10) -> Rebuild all your tree. The inner format was changed and 66 tools expect this new syntax to properly set the ecosystem. Well, by example:


# 66-tree -R root
# 66-tree -ncE root
# 66-enable -C tty@tty1 tty@tty2 dhcpcd


Adapt this example for your case and do not forget to use the -C option. Otherwise, the 'upstream' service will be updated but not key=value pair used inside.


Another example: Let's say you have a tree system with a sshd service


# 66-tree -R system
# 66-tree -ncE system
# 66-enable -C sshd


Let's repeat again: do not forget to use the -C option


Do not forget to make the exact same thing about your user service. So, destroy all user tree, make it again and enable again your service inside. Do not forget to use -C option with 66-enable command.


(11) -> Now rename all the previously moved files to the original name:


# mv /etc/66/stage2.bak /etc/66/stage2
# mv /etc/66/stage2.tini.bak /etc/66/stage2.tini
# mv /etc/66/stage3.bak /etc/66/stage3
# mv /etc/66/conf/boot.bak /etc/66/conf/boot
# mv /etc/66/66.conf.bak /etc/66/66.conf
# mv /etc/66/data.bak /etc/66/data


(12) -> We are almost ready to reboot. The last thing to do it's to take care about the contain of the /etc/66/boot.conf file. The file is the previously /etc/66/66.conf. Open it and edit it as you want to suit your needs. If you forgot to do it, the machine should boot anyway.


(13) -> Well, reboot:


# s6-svscanctl -6 /run/66/scandir/0


Use this command and only this command. Do not try to reboot with the classic reboot command. Your machine is currently running with the old system and the shutdown, reboot, poweroff have completely changed.


Congratulations, you are using the new version. But, to be clean, some command need to be done.


(14) -> Erase your previous boot tree, remake it, enable the new boot service set and finally remove the temporary one:


# 66-tree -R boot
# 66-tree -n boot
# 66-enable -t boot boot
# 66-tree -R tmpboot


(15) -> Edit your /etc/66/init.conf to change again the TREE variable and point it to the tree boot. Do not forget this step, if you do your next boot will go on trouble:


VERBOSITY=0
LIVE=/run/66
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin
TREE=boot
RCINIT=/etc/66/rc.init
RCSHUTDOWN=/etc/66/rc.shutdown
UMASK=0022
RESCAN=0
ISHELL=/etc/66/ishell


(16) -> Remove the old files:


# rm /etc/66/stage2
# rm /etc/66/stage2.tini
# rm /etc/66/stage3
# rm /etc/66/conf/boot.conf
# rm /etc/66/66.conf
# rm -r /etc/66/data


(17) -> Finally update your system entirely:


# pacman -Syu

What's new: to go futher


"Ok,i'm on the new one. All works as expected, and what? You ask my help to pass to your new version so i hope it bring up with improvements at least."


"Yeah, a lot my friend. Just to name a few: "


The most important and big change (excepting code improvement, bugs fix, compatibility addition, new features on existing tools, new tools,...) occurs for the boot and shutdown process.


The boot

The boot (stage1) is now made by a binary instead of a script bringing stability, reliability and security. If you take a look at /usr/bin/init file you will see:


66-boot


That's all for it. 66-boot take care of the boot procedure to create the scandir and launch the stage2 process. You can find a complete explanation of the process at 66-boot documentation. In case of crash of this stage (that should never happen) 66-boot will try to run a sulogin command to let you a chance to fix the things instead of directly going on kernel panic. At the current state of the machine we don't have a scandir running and so it's impossible to launch any service like tty. Sulogin was did for those special case.


The boot-66serv set of service was rewritten entirely to match a better integration of different policies decision and to be compatible with a large collection of divers OS. Also, encrypted device, zfs format is now provide at very first approach.


Shutdown process

Clear and safe! 66-hpr,66-shutdown and 66-shutdownd provide a really better integration of the shutdown procedure. Shutdown process can be now programmed at a specific time with 66-shutdown. Also, at the very end of the process a 66-umountall is launch to properly umount all your devices currently used on your machine.


Shutdown, reboot and poweroff safe wrappers are provided directly by 66. So 66 do not depend anymore of s6-linux-init API. This was the only purpose and presence of this API.


Scandir manipulation

Previous 66-scandir was splitted into two different API. 66-scanctl handles signal to send to the scandir where 66-scandir take care of the creation/remove of it.


Handle of classic service

On old 66 version, selection of classic service was launch synchronously. 66-svctl launch it now asynchronously. This feature is only present on 66 ecosystem and cannot be accomplish directly by s6-xxx tools.


Environment variable handling

66-env let you handle/see /etc/66/conf file quickly by command line or by the editor predefine on your system.


Extra tools

execl-subuidgid (substitute uid gid) reacts with execline scripts and allow you to retrieve the uid,gid of a specific owner and substitute ${UID} ${GID} variable name into a script.


66-which reacts as same manner as which command but provide portability and compatibility where, for the most of the time, which is used as building command.


Interface of execl-envfile was clearly improved and permit to use absolute path as directory destination. Also, the -f options at the command line was removed but the feature is always there with a simplier manner to use it.


Frontend debugger

66-parser: the frontend debugger! This API use exactly the same parsing process as 66-enable command. This bring up a easy way to check if a frontend file is correctly set and to see the resulting file of the process without touching your current set of service before enable it.


X SESSION: How to configure with module service


66-mods.sh (a.k.a module service)


We are happy to announce you the very first approach of module service provided by 66-mods.sh script. This functionality is only available on Obarun system and not installed by default with the 66 package. We need to be clear here: the concept is clearely on development and need a lot of improvements. Otherwise, this tools works as expected and it will provide you a really easy way to properly e.g. start your X session by a complete set of service configured by an automatic way.


So, this is the introduction of new package suffix: xxx-66mod.


A module can be compared to an instancied service but applied on a complete set of service (a.k.a tree).


Let's take a concret example...


Configuring a system with login tracker (e.g consolekit) and Display Manager (e.g. sddm) with the conjuction of dbus can be a very tedious task. Understand the relationship between those elements is not so easy and needs compilation specification of dbus and consolekit, export of environment variable, creation of divers directory on the system, configuration of executable files (e.g. .xinitrc,.xession) and so on.


By chance we are under Obarun and on Obarun we have module service :).


You will find a new package at [observice-testing] repositories called boot-user-@-66mod. This package is a module that will configure a set of service and configuration file to start properly your X session with e.g sddm, consolekit and dbus. You will be able to start any Desktop session as JWM, Openbox, Plasma just applying three command.


Let's do it!


install the boot-user-@-66mod package:


# pacman -S boot-user-@-66mod


Now we need to first configure the modules for a specific user:


# 66-mods.sh boot-user-@oblive


This command will create a new set of service configured for oblive user. As you can see the syntax is exactly the same as an intancied service. If you want to apply the module for an another user just do:


# 66-mods.sh boot-user-@eric


Ok, now you have a to enable this module. You can enable a module on any tree because it just a set of service. However, the creation of a new tree can be a good idea to let you the time to appropriate the concept:


# 66-tree -cnE user
# 66-enable boot-user-oblive


Do not forget the -E option at tree creation to be able to start the tree at boot time.


That's it!


At your next boot a scandir for the oblive user will be created launched with good environment variable like DISPLAY, XDG_RUNTIME_DIR, DBUS_SESSION_BUS_ADDRESS and so on. That's mean that any daemon running under this scandir will inherit of those variables. The .xession and .xinitrc is configured and ready to be started. The /run/user/ is created and mounted correctly to accept any desktop daemon launched by dbus.


So, let repeat the command:

# 66-mods.sh boot-user-@oblive
# 66-tree -cnE user <- this is optional
# 66-enable boot-user-oblive


You can see exactly what do the module (name of service, file configured or installed on your system, ...) and how to enable it by doing:


# 66-mods -H boot-user-@


This will show you a great text explanation of the module.


To see the help of 66-mods.sh


# 66-mods -h


The module provide configuration and scandir but do not provide daemon like dbus, dbus-session-@, sddm, consolekit,... It a general set of service that need to be adaptable. For example you may want to start your X by startx instead of a DM.


Well, if you want to start your X session with e.g sddm follow this extra instructions. Those instruction to do concern the module itself and can be run after or before enabling the module.


Install the sddm, consolekit, dbus packages and services

# pacman -S sddm sddm-66serv consolekit2 dbus dbus-66serv


Note: do not enable consolekit service. Sddm will make it for you at the start of the X session. Sddm daemon enter in conflict with consolekit daemon if consolekit daemon is not launch by sddm itself.


So, enable the daemon for root:


# 66-enable sddm dbus


Enable dbus for normal user:


$ 66-enable dbus-session-@oblive


That's it, you can reboot. The sddm should appear and you can start your favorite desktop.


Note

A good advise is to read (again, and maybe again, and ...) the 66 documentation to be aware of all changes, improvements and new features provided by this 66 version.


Hope you will found this usefull for you.


If you have any questions or troubles, please do hesitate to make a reports.


Thanks for your attention.


eric.vidal@obarun.org

Latest posts