Changes

Issues to solve :

Issues to solve :

* SME vs upstream

* SME vs. upstream

* make unit files aware of service status in e-smith db configuration

* make unit files aware of service status in e-smith db configuration

* have our services boot in the right sequence

* have our services boot in the right sequence

systemctl daemon-reload has be run after each modification of a unit. Hence generated files by generators will be erase and generators rerun. <ref>https://www.freedesktop.org/software/systemd/man/systemctl.html#daemon-reload</ref>

systemctl daemon-reload has be run after each modification of a unit. Hence generated files by generators will be erase and generators rerun. <ref>https://www.freedesktop.org/software/systemd/man/systemctl.html#daemon-reload</ref>

==== Overide upstream vendor preset : templated unit files or not ? where ? ====

==== '''Overriding the upstream vendor preset : templated unit files, or not? And where?''' ====

Thinking of the example of a service unit provided by upstream vendor. Should we simply create a template and expand it over the unit.service in /lib/systemd/system/ or offer a different way to override upstream vendor settings ? Further more should we template our file to point to /lib/ or to /etc/. In other words, should we fight with admin space trying to overwrite changes in its dedicated space or should we fight with upstream vendors and overwrite their files or find a way to override them.

The reference is the example of a service unit provided by the upstream vendor.  

* Should we simply create a template and expand it over the unit.service in /lib/systemd/system/  

* Or offer a different way to override upstream vendor settings?

Furthermore should we template our file to point to /lib/ or to /etc/?

In other words, should we fight with admin space trying to overwrite changes in its dedicated space, or should we fight with upstream vendors and overwrite their files or find a way to override them?

* How : template or not

* How: overwrite or selective overriding

===== unit files created in /etc/systemd/system/ or in /lib/systemd/system/ =====

as a vendor we should work in /lib/systemd/system/, but as an admin helper we might want to play in /etc/systemd/system/ and rather offer a way to admin to use our template-custom or config db.

* Where: /etc or /lib/

* What: use a template or not

* How: overwrite, or selective overriding

==== template or not ====

===== '''Create unit files in /etc/systemd/system/ or in /lib/systemd/system/?''' =====

the first easy way to think to override ones service could be to simply template the file  /lib/systemd/system/servicename.service and expand it every time a reconfiguration or a boot occurs.

As a vendor we should work in /lib/systemd/system/, but as an admin helper we might want to play in /etc/systemd/system/ and rather offer a way to admin to use our template-custom or config db.

Going futher we could ensure the stability of the system by making this in /etc/systemd/system/servicename.service

 

Going further, we could ensure the stability of the system by setting this in  

 

/etc/systemd/system/servicename.service

===== unitname.d/file.conf versus overwrite uniname.service =====

===== unitname.d/file.conf versus overwrite uniname.service =====

dot d folder can be created both int etc and lib from readings and inspection in a few systems.

From reading and inspection of a few systems, a dot d folder could be created both in etc and lib .

 

 

First, copying the unit file from     <code>/usr/lib/systemd/system</code> to  <code>/etc/systemd/system</code> and modifying the chosen settings.  

There are two methods of overriding vendor settings in      unit files: copying the unit file from      <code>/usr/lib/systemd/system</code> to      <code>/etc/systemd/system</code> and modifying the      chosen settings. Alternatively, one can create a directory named     <code>''<code>unit</code>''.d/</code> within     <code>/etc/systemd/system</code> and place a drop-in     file <code>''<code>name</code>''.conf</code>     there that only changes the specific settings one is interested     in. Note that multiple such drop-in files are read if     present, processed in lexicographic order of their filename.

Second, one can create a directory named <code>''<code>unit</code>''.d/</code> within <code>/etc/systemd/system</code> and place a drop-in file <code>''<code>name</code>''.conf</code> there that only changes the specific settings one is interested in. Note that multiple such drop-in files are read if present, processed in lexicographic order of their filename.

The advantage of the first method is that one easily     overrides the complete unit, the vendor unit is not parsed at     all anymore. It has the disadvantage that improvements to the     unit file by the vendor are not automatically incorporated on     updates.

The advantage of the first method is that one easily overrides the complete unit, the vendor unit is not parsed at all anymore. It has the disadvantage that improvements to the unit file by the vendor are not automatically incorporated on updates.

The advantage of the second method is that one only     overrides the settings one specifically wants, where updates to     the unit by the vendor automatically apply. This has the     disadvantage that some future updates by the vendor might be     incompatible with the local changes. <ref>https://www.freedesktop.org/software/systemd/man/systemd.unit.html</ref>

The advantage of the second method is that one only overrides the settings one specifically wants, where updates to the unit by the vendor automatically apply. This has the disadvantage that some future updates by the vendor might be incompatible with the local changes.<ref>https://www.freedesktop.org/software/systemd/man/systemd.unit.html</ref>

==== uninstalling /masking unwanted/conflicting services: example of firewalld. ====

==== uninstalling /masking unwanted/conflicting services: example of firewalld. ====

we can plan to uninstall firewalld for example, but some packages will reinstall as a requirement. It might even be started, which could conflict with masq.

We can plan to uninstall firewalld for example, but some packages will reinstall as a requirement. It might even be started, which could conflict with masq.

=== Systemd current implementation ===

=== Systemd current implementation ===