So what is default?
# pacman -S dhcpcd dhcpcd-66serv
# 66-enable -S dhcpcd
this is the default and should works without any further configuration.
this is fixed now
How did you fixed it????
It is also a confusing benefit to have /etc/66/service when you say that pacman will not affect anything in it but a specific command by 66 will over-write the custom configuration. Why?
A file provided by upstream always try to be the portable and adaptable possible for every case. But it's not possible to reach every case. You need a design that's allow you the possibility to adapts for your needs.
So, dhcpcd come with a dhcpcd.conf by default. This configuration file can adapted for your system. dhcpcd-66serv come with a frontend by default. You need a way to adapt it to your system.
So let's compare this two packages :
dhcpcd binaries -> frontend service file
dhcpcd.conf -> /etc/66/conf/dhcpcd
You want to change the binary behavior -> change the configuration of the compilation and compile again. On upstream upgrade (meaning pacman -Sy dhcpcd) your own binary will be overwritten. You need to compile again.
You want to change the frontend behavior -> change the frontend file. On upstream update (meaning pacman -Sy dhcpcd-66serv) your change will be lost. Now, you
can avoid that just copying /usr/lib/66/service to /etc/66/service. Now at upgrade time when you do a pacman -Sy dhcpcd-66serv your change at /etc/66/service/dhcpcd is not overwritten because pacman install the original file at /usr/lib/66/service. Do you see the interest now?
You want to change the runtime behavior -> change the dhcpcd.conf file to suit your need. On upstream upgrade (meaning pacman -Sy dhcpcd) the configuration file /etc/dhcpcd.conf will be overwritten. By chance on Arch the file will be renamed at dhcpcd.conf.{pacnew,backup}. In this case you need to take a look of the change at dhcpcd.pacnew and apply the change to your dhcpcd.conf. But you don't loose your own configuration.
You want to change the runtime behavior of the daemon -> change the /etc/66/conf/dhcpcd file to suit your need. On upstream upgrade (66-enable -f dhcpcd) the file /etc/66/conf/dhcpcd will not be overwritten and ou keep your change. If you want to change it, you need to explicitly asking for it with 66-enable -f -C dhcpcd. In this case the configuration file is overwritten.
This example is very simple, we can go deeply in the process talking about the 66-enable -f -c option(lowercase instead of uppercase) but this will confuse people for the moment.
When we talk about service management we are targeting two diverse audience: user and administrator. The both can be one. By default the user should take care at only two command : 66-enable, 66-start. But an administrator need more than this two command. Administrator need a way to apply change that it need which the simple way as possible, so let's take a example (we talk about administrator):
Frontend behavior need to be changed :
- If we are on a bad design -> make the change at the original frontend file. At every upstream upgrade the administrator need to remake the works because the file original file is overwritten.
- if we are on good design -> 66 provide a way to administrator to avoid to remake the works at every upgrade. Copy /usr/lib/66/service/dhcpcd to /etc/66/service and administrator make the change on this file. He do it one time and no more. Now the administrator have a peace on mind on upstream update :), this file will never be touched by pacman.
Runtime behavior need to be changed:
- if we are on a bad design :
- if the administrator sucks -> he open the /usr/lib/66/service/dhcpcd frontend file, change the environment section and reenable the service. Now on upgrade, he need to remake the works.
- the administrator is a good one -> he need copy the frontend from /usr/lib/66/service/dhcpcd to /etc/66/service, open it and apply his change on environment section and reenable. Now on upgrade if the scrips itself was changed, he need to remake the works(cp,open,change,enable). - [*/]
- if we are on good design :
- if the administrator sucks -> he copy the frontend file from /usr/lib/66/service/dhcpcd to /etc/66/service, open it, make the change on the environment section,reenable it. Now on upgrade if the scrips itself was changed, he need to remake the works : open /etc/66/service/dhcpcd, make the change, reenable.
- it the administrator is a good one -> he open /etc/66/conf/dhcpcd , apply his change. Now on upgrade, if the scrips itself was changed, he don't need to make anything. the scripts will be updated and he keep the change for his environment section.
The /etc/66/service is NEVER touched by ANY 66 program. This is the secure place to have your own frontend file. 66 doesn't do anything into this directory by any command,option,whatever.
What's happen when you do a 66-enable dhcpcd ?
- - 66 search at /etc/66/service directory if the frontend file exist. if the file exist it parse it and write the result at /var/lib/66/...
- - the file was not found at /etc/66/service, it will search at /usr/lib/66/service, if the file exist it parse it and write the result at /var/lib/66/...
what's happen when you do a 66-enable -f dhcpcd?
the same process describe above is made but it overwrite the result of the parse at /var/lib/66
So -f doesn't mean : "overwrite the frontend file'
-f mean: "overwrite the result of the parsing process"
Too many options, too many variations, too many commands, too different from what we learned 2 months ago
The command that your learned two months ago doesn't change but the flexibility was improve and so new command are here.
From an user point of view:
- 66-enable -> nothing change
- 66-start -> nothing change
- 66-env -> "great i can change the command line of the daemon without the need to change the frontend file(dhcpcd -B become dhcpcd -B eh0)
- 66-shutdown -> "great i can now programs a shudown procedure at a specific time, my shutdown is now safe (unmount all volumes), i can force(if needed) a shutdown,.."
From an administrator point of view -
- 66-env -> "great my change is never touched if i don't ask for it"
- 66-parser -> "great i can now check the parsing result of the frontend file before trying to enable it, security was improved a lot..."
- 66-boot -> "great this is adaptable for every linux distro, i don't need to modify a complex script. I can configure my boot by a simple configuration file(etc/init.conf).
i can configure my stage2 by a simple configuration file (rc.init), i can configure my shutdown process by a simple configuration file(rc.shutdown). In case of crash i have now a secure sulogin opened before going directly on kernel panic"
- .....
- more extra tools -> "great this new tools allow me to write a scripts quicker and with more flexibility"
I see the transition from s6opts to 66-01 to 66-02 like learning to walk, learning to climb a stairway, now let's climb mt.Everest early Spring. You can't expect users to go from hand-gliding to flying at Mach3 at 65000ft.
That's doesn't mean that it's not possible :p. You have this opinion because you are an old user of Obarun and so, from the start of the projects a lot a things was changed (we comes from runit lol). Let's take a comparaison to a car(really stupid example). To drive a car you need, a steering wheel, an accelerator and a brake. Now you can add a warning but at the base you don't need to use the warning, this a feature, an extra, something that's you are not forced to use. But in some specific case it's better and safe to use.
That's the same thing with 66, we have simple tools to learn (66-tree,66-enable,66-start) and extra tools that's you are not forced to use. But in some specific case it's better and safe to use it.
Fungalnet, do you realize that you're learning a complete service manager??? it's not a simple thing. Have you tried to understand the rc BSD behavior and how to configure it?
You try to go deeply in the process and so you open your eyes about what we have behind the hood. Don't be afraid and take the time to learn and understand, ask what you want again and again and again.
We are on Obarun. Obarun is not a distro. I was always clear about that. Obarun is a build concept, so yes the audience is not the same. This doesn't mean that Obarun cannot be used by simple user, this means that in case of trouble you need to learn a bit because you have the full control of your system and nothing will make the thing for you...
Tree boot - existing and enabled by default -- For a custom design and booting ---> other options
That's the point. Erasing an existing boot set of service without asking anything at the user is a policy decision. This is really a bad design. I mean when you do fresh installation by the obarun-install(currently in preparation) the boot is installed by default. But at update time erasing/changing the behavior of the boot is not safe, is not a good manner to deal with user choice. I can change my boot as i want (making a new tree and apply my change into it) but this is not a thing that classic user will do.
That's why we have decide to not touch the boot when an upgrade is made.
But yeah, the discussion about that is not closed and we need to have reports from user to know what it can be accomplish or not.
For user tree de related tree would be part of obarun's plasma-template, xfce-template
that 's the purpose of 66-mods, you will see some JWM@ -66mod package coming soon to configure a JWM desktop by an automatic way. For example on my machine all service launched by jwm is under my control with service (compton, notification-daemon,gvfsd,.....). When i want to change the compton behavior, i change the configuration file ~/.config/compton.conf and i do 66-start -r compton. I can switch easily between configuration file, and so on...
Actually the boot-user-@ -66mod package allow you to properly configure a system to use any logger tracker(consolekit,elogind) with a DM without any extra efforts from user. Configure a system without systemd to properly start an X session without elogind is really a tedious task, the module do it for you :).
Well for the moment this is very first approach but a promising one.