Bertram wrote
Why is it needed now?
pulseaudio functionality is designed around systemd, by the same group, so its own versions are breaking dependencies and functionality as systemd changes. Otherwise either dbus or ck weren't running correctly. With alsa I've never had any problems or the need for dbus/ck/logind. Once it is set for a specific machine it is 100% reliable.
Moreover, I just typed
66-enable pulseaudio
omitting the suggested -t <user-tree>
and it seems to work nevertheless.
You can make 1000 trees, only one can be current. For an existing tree (root or user) the command:
66-tree -c treename
makes it current.
When you don't specify a tree 66-enable/disable commands are applied to the current tree.
But how is a user tree created, enabled, ....
on
http://wiki.obarun.org/doku.php?id=dbus_and_dm
Down the page I found
Create a user configuration tree as root, ...
# 66-tree -nE boot-user
I suppose that what's called a user configuration tree here is the
same as what higher up on the same page is just called a user tree ?
and that boot-user is the concrete name of the user tree to
be created?
A user tree and the boot-user tree are very separate terms. Any tree "created by the user" is referred to as a user tree.
For any user to enable trees and services as a user "root must create a tree commonly referred to in Obarun as a boot-user tree" and most importantly within this tree there is a service/module called boot-user@ , which can be configured especially for a particular user. In the past, before this became a module, there was a service called boot-user and it was the same for all users. Now it can be user specific. The names of the trees are arbitrary, you can name them differently once you understand their function.
For any "user" service to function a "user scandir" must be active, and this is handled by root by configuring the boot-user tree and services. If not, a user can create a tree but enabling and starting any services will fail.
Next comes
Do not forget the -E (Enable) option at tree creation to be able to start the tree at boot time.
# 66-enable -t boot-user boot-user@ oblive
Does that mean that the -E option above is a perequisite for running
successfully the 66-enable command, or is the 66-enable a substitute
for an ommitted -E option ?
Enabled in 66 means
for root: Once booting has completed (boot tree services complete) ALL trees that are enabled are "initiated" (# 66-intree -zg will show you different fields for enabled, initiated, default, etc.). Enable/disable is like an on/off switch, there is no middle. Either a tree is enabled or disabled. A tree that is disabled is there, ready to be started by root normally by issuing the < # 66-all -t treename up > command. Otherwise it is asleep.
for user: Once the user logs into the system, AND ONLY IF a scandir has been activated by root for that user (boot-tree --> boot-user@ username), then all "user trees" that ARE enabled, will be "initiated", meaning the services/modules active on those will attempt to start. User trees that are not-Enabled/Disabled remain asleep, till the user issues a <% 66-all -t usertreename up> command.
I believe most of what I am saying here is also covered in "intro to 66" in the wiki, 3-4 people contributed the creation of this document so it helps Obarun users in specific, to go past the state of confusion into the stage of experimentation with 66 tools.
The man page of 66-tree says that
with the -n option just an empty tree is created.
Now, what makes an empty tree into a user tree?
Simply if root creates a tree it is a root tree, if user oblive creates a tree it is oblive's tree (a user tree), the user does whatever she/he wants with it. The only thing root does for the user is create a scandir for user (ex: 1002 bob) to be able to start and stop service supervision (that is the boot-user tree created by root for the user and configured for the particular user by the boot-user@ bob module. If a scandir is not running for the user no tree, service, or module, can be supervised for the user.
Again I shouldn't copy/paste "intro to 66" here but there is a little confusion created here by the separation of Obarun and 66.
66 documentation is ONLY about 66 tools. Obarun documentation and wiki are about 66 implementation into obarun. 66 functionality is standard, but things like services, boot@ boot-user@ modules, etc. are all Obarun implementations. In Void or Antix if they officially adopt 66 the implementation may be slightly different. So not all questions about 66 can be answered by the wiki, if they are 66 specific. No questions about service files and modules can be answered by 66 documentation if they are Obarun implementations.
PLEASE suggest an alternative way that this discrepancy would be more understandable to new users.
user prompt %
% 66-tree -n newtree # a user tree is created named newtree
% 66-tree -E newtree # newtree is Enabled
% 66-tree -c newtree # newtree is set as current -- among other user trees
% 66-tree -D newtree # newtree is Disabled, will not start at login
% 66-tree -n othertree # a user tree is created named othertree
% 66-tree -cE othertree # othertree is Enabled and set as current -- newtree is no longer current, othertree is
% sudo 66-tree -ncE -S boot root2 # A ROOT tree is created, it is set a "c"urrent and is "E"nabled and will "-S"tart after boot tree completes.
% sudo 66-tree -D root # root tree is disabled
% sudo 66-tree -R root # root tree is deleted
% 66-intree -zg # will show you a summary of what "user" trees exist and what the status of trees and services is
% sudo 66-intree -zg # will show you a summary of what "root" trees exist and what the status of trees and services is
# 66-intree -zg
and
% sudo 66-intree -zg
are the same, attention to the prompt % or #
Is it the command
# 66-env -t boot-user -e nano boot-user@ oblive
which will create the file boot-user@ oblive ?
This command configures a module, both tree and an enabled module must be created in advance for this to execute.
If tree boot-user does not exist and/or boot-user@ oblive hasn't been enabled in that tree (boot-user), the command will fail.
66-env can not create any tree or service, or enable a service inside a particular tree. Both those tasks have to be done in advance for 66-env to work.
So you create boot-user tree, enable boot-user@ oblive module for user oblive, then use this command to configure the module.
It is called a module as the same basic service can be configured differently for different users.
Moreover, I have a tree named boot-user with my Obarun installations.
Is it the user tree? How do I know ?
Tree names can be anything, it can be zzz123 if you wanted. The proposed named convention through the Obarun live images and wiki documentation is that a boot-user is a "root" created tree to enable the boot-user@ oblive module and configure it.
If you run 66-intree in a root shell or using sudo in front, those are all root trees you see. If you run the same command as user you will only see user trees and services.
From the ...@ bf -- with bf my user name -- in its contents?
Or from the existence of the file boot-user@ bf ?
For the particular "obarun" module named boot-user@ -66serv for each user the root can create a different module named after the user. So in JWM -live iso it is boot-user@ oblive in a tree made by root named boot-user.
Give it a week or two and the more you play with them the more sense it will make. After a while it will be so crystal clear that you will wonder how do all those other Linux distros handle stuff like this. The answer is they don't and mostly they can't. In Obarun we can. So with this ability comes the complexity and a steep learning curve.
Finally, is there a difference between
66-enable pulseaudio
and
66-enable -t <user-tree> pulseaudio
or would -t <user-tree> just have added a default?
You can only learn by experimenting and once you mess up you can ask, and most of us do our best to share the light handed down by 66 god.
I think the answer is covered from above, but do this exercise, create 5 -n new trees. Enable some, see which one is current. Make one current. Enable a fake service in it, like make a service file in ~/.66/service/ls and have it show the contents of a directory or something dumb. A oneshot service.
If you don't specify which tree to be enabled, it automatically goes to the current one. If you have only 1 tree it is automatically current. By creating a new tree unless you specify -c to make it current, the first current remains as current.
Even if you wrote a failing service file and the service fails it will still show on user's tree as enabled, just not running. If it is a oneshot it will say up (meaning it was executed and done), down would have meant it wasnt' executed yet.
├─(up,Enabled,oneshot) mount-swap
This is from boot tree and it means that when boot tree was initiated at boot, service mount-swap was executed succesfully.
└─(931,Enabled,classic) dhclient@ eth0
This is dhclient@ eth0 a module-type of service configured for eth0 (interface) in a tree ... and this is running and currently supervised by 66, process # (pid) is 931.
66-intree -zg is your best friend in understanding all this, testing, and diagnosing what is wrong. The -z option for color helps as your eye will catch all the read that is failing. You want to see all green. Orange means they are asleep, waiting for you to start them.