Difference: SystemdSchemaProposalv1 (1 vs. 9)

Revision 92014-08-19 - ascobie

Line: 1 to 1
 
META TOPICPARENT name="SL7PortHome"

LCFG systemd - a first stab

Line: 226 to 226
 

-- Main.ascobie - 2014-02-18 \ No newline at end of file

Added:
>
>
META TOPICMOVED by="ascobie" date="1408448910" from="LCFG.SystemdSchemaProposal" to="LCFG.SystemdSchemaProposalv1"

Revision 82014-05-21 - ascobie

Line: 1 to 1
 
META TOPICPARENT name="SL7PortHome"

LCFG systemd - a first stab

Line: 19 to 19
 
  • we have a bunch of links and config files
  • each can be either at top or within multiple wants directories
  • Note that following scheme won't allow a unit to be both in toplevel and in a wants - would you want this? Haven't seen this in practice in F19 nor F20.
Added:
>
>
  • Adding a new unit config file and triggering a systemd reload does not result in the new unit being started
 
  • For triggering reboots
    • can't see a way to say "I'm the last unit for a specific target"
    • we could have our own local "lcfg-multi-user.target" and "lcfg-graphical.target" which depend on the stock "multi-user.target" and "graphical.target" respectively. The default.target would be set to one of these local targets. The local targets will be provided by a OneStop unit which checks for any requested reboots (from earlier units) and reboots if necessary.

Revision 72014-05-21 - ascobie

Line: 1 to 1
 
META TOPICPARENT name="SL7PortHome"

LCFG systemd - a first stab

Line: 23 to 23
 
    • can't see a way to say "I'm the last unit for a specific target"
    • we could have our own local "lcfg-multi-user.target" and "lcfg-graphical.target" which depend on the stock "multi-user.target" and "graphical.target" respectively. The default.target would be set to one of these local targets. The local targets will be provided by a OneStop unit which checks for any requested reboots (from earlier units) and reboots if necessary.
  • Rather than having two structures - one for units at top level and one for units within *.wants directory -  have all units in one systemd.units list. An attribute of a unit is whether it should be in 0 or more *.wants directories (default would be top dir). 
Added:
>
>
  • How display component start up success/failure at boot time?
 

Some example resources


Revision 62014-05-20 - ascobie

Line: 1 to 1
 
META TOPICPARENT name="SL7PortHome"
Added:
>
>

LCFG systemd - a first stab

Thoughts

 
  • Do we maintain /etc/systemd or just /etc/systemd/system?
    • Initially the latter, but ultimately both
Added:
>
>
 
  • /etc/systemd/system/*.* - unit files. Files may be links to /lib/systemd
  • /etc/systemd/system/{unit}.wants - directory of unit files wanted by {unit}. Files may be links to /lib/systemd/
  • /etc/systemd/system/{unit}.d - directory of .conf override config files
Line: 17 to 22
 
  • For triggering reboots
    • can't see a way to say "I'm the last unit for a specific target"
    • we could have our own local "lcfg-multi-user.target" and "lcfg-graphical.target" which depend on the stock "multi-user.target" and "graphical.target" respectively. The default.target would be set to one of these local targets. The local targets will be provided by a OneStop unit which checks for any requested reboots (from earlier units) and reboots if necessary.
Added:
>
>
  • Rather than having two structures - one for units at top level and one for units within *.wants directory -  have all units in one systemd.units list. An attribute of a unit is whether it should be in 0 or more *.wants directories (default would be top dir). 
 
Changed:
<
<

Rather than having two structures - one for units at top level and one for units within *.wants directory -  have all units in one systemd.units list. An attribute of a unit is whether it should be in 0 or more *.wants directories (default would be top dir). 


>
>

Some example resources

 
systemd.libdir  /usr/lib/systemd/system

Line: 32 to 33
 

Added:
>
>
systemd.type_dbusbluez link
 systemd.realname_dbusbluez   dbus-org.bluez.service systemd.link_dbusbluez       bluetooth.service
Changed:
<
<
systemd.wantedby_dbusbluez   <UNDEFINED - implies at top level>
>
>
systemd.wantedby_dbusbluez  
 
Changed:
<
<
would create a softlink /etc/systemd/system/dbus-org.bluez.service -> /usr/lib/systemd/system/bluetooth.service
>
>
creates a softlink /etc/systemd/system/dbus-org.bluez.service -> /usr/lib/systemd/system/bluetooth.service

Note that an empty value for systemd.wantedby_{tag} indicates that the link should be created in the top-level directory.

 

Line: 46 to 50
 systemd.link_dbusfw          firewalld.service
Changed:
<
<
softlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service -> /usr/lib/systemd/system/firewalld.service
>
>
creates a softlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service -> /usr/lib/systemd/system/firewalld.service
 
Added:
>
>
(Note that systemd.type_{tag} defaults to link, so not defined above)
 
systemd.realname_default      default.target

Line: 55 to 60
 
Changed:
<
<
softlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target
>
>
Creates softlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target
 
!systemd.units mADD(sshd)
systemd.realname_sshd         sshd.service

Deleted:
<
<
systemd.link_sshd             sshd.service
 systemd.wantedby_sshd         multi-user.target
Changed:
<
<
softlink /etc/systemd/system/multi-user.target.wants/sshd.service -> /usr/lib/systemd/system/sshd.service
>
>
Creates a softlink /etc/systemd/system/multi-user.target.wants/sshd.service -> /usr/lib/systemd/system/sshd.service
 
Added:
>
>
Note that systemd.link_{tag} defaults to systemd.realname_{tag} if not defined.
 
Added:
>
>
 
!systemd.units                 mADD(sshdconfig)

Added:
>
>
systemd.type_sshdconfig file
 systemd.realname_sshdconfig sshd-local-config.service
Deleted:
<
<
systemd.link_sshdconfig        <UNDEFINED - implies create config file from resources>
 systemd.wantedby_sshdconfig sshd.service

systemd.description_sshdconfig   OpenSSH localconfig

Line: 82 to 88
 systemd.servicetype_sshdconfig   oneshot
Changed:
<
<
creates file /etc/systemd/system/sshd.service.wants/sshd-local-config.service with content :-
>
>
Creates a file /etc/systemd/system/sshd.service.wants/sshd-local-config.service with the content :-
 
[Unit]
Description=OpenSSH localconfig

Line: 94 to 100
 


Changed:
<
<
There are far too many options to support, so propose adding resources for most commonly used options and allowing additional lines using something like the following. Note that we'd need to specify, somehow, which section (ie [Unit], [Service]) each key/value pair applies to. (Do we need to worry about order?)
>
>
There are far too many unit options to support, so propose adding resources for most commonly used options and allowing additional lines using something like the following.

!systemd.units                 mADD(sshdconfig)
systemd.type_sshdconfig         file
systemd.realname_sshdconfig    sshd-local-config.service
systemd.wantedby_sshdconfig    sshd.service

systemd.description_sshdconfig   OpenSSH localconfig
systemd.unittype_sshdconfig      service  
systemd.before_sshdconfig        sshd.service  
systemd.conflicts_sshdconfig     sshd-nextgen    
systemd.genopts_sshdconfig       unneeded
systemd.genopt_sshdconfig_unneeded  StopWhenUnneeded=0
systemd.execstart_sshdconfig     /usr/local/bin/sshd-local-config
systemd.servicetype_sshdconfig   oneshot
systemd.specopts_sshdconfig         restart
systemd.specopt_sshdconfig_restart  Restart=on-failure

Creates a file /etc/systemd/system/sshd.service.wants/sshd-local-config with the following content :-

 

Changed:
<
<
systemd.lines_sshdconfig  1 2 3 4 5  systemd.line_sshdconfig_1 [Unit] systemd.line_sshdconfig_2 Description=OpenSSH local config systemd.line_sshdconfig_3 Before=sshd.service
>
>
[Unit] Description=OpenSSH localconfig Before=sshd.service Conflicts=sshd-nextgen StopWhenUnneeded=0

[Service] Type=oneshot ExecStart=/usr/local/bin/sshd-local-config Restart=on-failure

 
Added:
>
>
Note that the taglist systemd.genopts_{tag} is used for defining additional resources for the general [Unit] section, and the taglist systemd.specopts_{tag} is used for defining additional resources for the unit specific section (in this case [Service] as defined by systemd.unittype_{tag}).
 
.conf override files
Line: 123 to 158
 Execstart=/usr/local/bin/sshd -d
Added:
>
>

LCFG CPP macros

 
Added:
>
>
The macro below wraps up some of the above :-
#define LCFG_SYSTEMD_UNIT(TAG,RN,LINK,WANT) \
!systemd.units  mADD(TAG)¢\
systemd.realname_/**/TAG        RN¢\
systemd.link_/**/TAG    LINK¢\
!systemd.wantedby_/**/TAG       mADD(WANT)

eg :- LCFG_SYSTEMD_UNIT(default,default.target,multi-user.target,)

LCFG schema

@units type_$ realname_$ link_$ wantedby_$ requiredby_$ description_$ unittype_$ before_$ after_$ \
       conflicts_$ requires_$ execstart_$ execrestart_$ execreload_$ execstop_$ servicetype_$ \
       environmentfile_$ standardout_$ standarderr_$ busname_$ genopts_$ specopts_$
units
@type_$ %string(type): vENUM(link file)
type_$ link
realname_$
link_$
wantedby_$
requiredby_$
description_$
unittype_$
before_$
after_$
conflicts_$
requires_$
execstart_$
execrestart_$
execreload_$
execstop_$
servicetype_$
environmentfile_$
standardout_$
standarderr_$
busname_$

@genopts_$  genopt_$_$
genopts_$
genopt_$_$

@specopts_$ specopt_$_$
specopts_$
specopt_$_$

@extraconfigs extraunit_$ extralines_$
extraconfigs
extraunit_$
@extralines_$ extraline_$_$
extralines_$
extraline_$_$
 

Revision 52014-05-19 - ascobie

Line: 1 to 1
 
META TOPICPARENT name="SL7PortHome"
  • Do we maintain /etc/systemd or just /etc/systemd/system?
Changed:
<
<
>
>
    • Initially the latter, but ultimately both
 
  • /etc/systemd/system/*.* - unit files. Files may be links to /lib/systemd
  • /etc/systemd/system/{unit}.wants - directory of unit files wanted by {unit}. Files may be links to /lib/systemd/
  • /etc/systemd/system/{unit}.d - directory of .conf override config files
Line: 14 to 14
 
  • we have a bunch of links and config files
  • each can be either at top or within multiple wants directories
  • Note that following scheme won't allow a unit to be both in toplevel and in a wants - would you want this? Haven't seen this in practice in F19 nor F20.
Added:
>
>
  • For triggering reboots
    • can't see a way to say "I'm the last unit for a specific target"
    • we could have our own local "lcfg-multi-user.target" and "lcfg-graphical.target" which depend on the stock "multi-user.target" and "graphical.target" respectively. The default.target would be set to one of these local targets. The local targets will be provided by a OneStop unit which checks for any requested reboots (from earlier units) and reboots if necessary.
 

Rather than having two structures - one for units at top level and one for units within *.wants directory - 

Revision 42014-02-19 - ascobie

Line: 1 to 1
 
META TOPICPARENT name="SL7PortHome"
  • Do we maintain /etc/systemd or just /etc/systemd/system?
Line: 58 to 58
 systemd.units mADD(sshd) systemd.realname_sshd         sshd.service systemd.link_sshd             sshd.service
Changed:
<
<
systemd.wantedby_sshd         multi-user.target.wants ... [others?]
>
>
systemd.wantedby_sshd         multi-user.target
 

Revision 32014-02-19 - ascobie

Line: 1 to 1
 
META TOPICPARENT name="SL7PortHome"
  • Do we maintain /etc/systemd or just /etc/systemd/system?
Line: 75 to 75
 systemd.unittype_sshdconfig      service systemd.before_sshdconfig        sshd.service systemd.execstart_sshdconfig     /usr/local/bin/sshd-local-config
Changed:
<
<
systemd.type_sshdconfig          oneshot
>
>
systemd.servicetype_sshdconfig   oneshot
 

creates file /etc/systemd/system/sshd.service.wants/sshd-local-config.service with content :-

Revision 22014-02-18 - ascobie

Line: 1 to 1
 
META TOPICPARENT name="SL7PortHome"
Added:
>
>
  • Do we maintain /etc/systemd or just /etc/systemd/system?

  • /etc/systemd/system/*.* - unit files. Files may be links to /lib/systemd
  • /etc/systemd/system/{unit}.wants - directory of unit files wanted by {unit}. Files may be links to /lib/systemd/
  • /etc/systemd/system/{unit}.d - directory of .conf override config files

  • can have both an nfs.service and an nfs.socket
  • might have a .wants directory, but no unit file
  • a unit file can be a conf file (which we wish to generate) or a link to /usr/lib/systemd/system
  • a unit can be under multiple .wants directories (but presumably must link to same file?)

  • we have a bunch of links and config files
  • each can be either at top or within multiple wants directories
  • Note that following scheme won't allow a unit to be both in toplevel and in a wants - would you want this? Haven't seen this in practice in F19 nor F20.

Rather than having two structures - one for units at top level and one for units within *.wants directory -  have all units in one systemd.units list. An attribute of a unit is whether it should be in 0 or more *.wants directories (default would be top dir). 


systemd.libdir  /usr/lib/systemd/system

systemd.units dbusbluez dbusfw dbusavahi dbusmodem dbusnetworkmgr dbusnmdispat default displaymanager syslog


systemd.realname_dbusbluez   dbus-org.bluez.service
systemd.link_dbusbluez       bluetooth.service
systemd.wantedby_dbusbluez   <UNDEFINED - implies at top level>

would create a softlink /etc/systemd/system/dbus-org.bluez.service -> /usr/lib/systemd/system/bluetooth.service


systemd.realname_dbusfw      dbus-org.fedoraproject.FirewallD1.service
systemd.link_dbusfw          firewalld.service

softlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service -> /usr/lib/systemd/system/firewalld.service


systemd.realname_default      default.target
systemd.link_default          graphical.target

softlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target


!systemd.units mADD(sshd)
systemd.realname_sshd         sshd.service
systemd.link_sshd             sshd.service
systemd.wantedby_sshd         multi-user.target.wants ... [others?]

softlink /etc/systemd/system/multi-user.target.wants/sshd.service -> /usr/lib/systemd/system/sshd.service


!systemd.units                 mADD(sshdconfig)
systemd.realname_sshdconfig    sshd-local-config.service
systemd.link_sshdconfig        <UNDEFINED - implies create config file from resources>
systemd.wantedby_sshdconfig    sshd.service

systemd.description_sshdconfig   OpenSSH localconfig
systemd.unittype_sshdconfig      service
systemd.before_sshdconfig        sshd.service
systemd.execstart_sshdconfig     /usr/local/bin/sshd-local-config
systemd.type_sshdconfig          oneshot

creates file /etc/systemd/system/sshd.service.wants/sshd-local-config.service with content :-

[Unit]
Description=OpenSSH localconfig
Before=sshd.service

[Service]
ExecStart=/usr/local/bin/sshd-local-config
Type=oneshot


There are far too many options to support, so propose adding resources for most commonly used options and allowing additional lines using something like the following. Note that we'd need to specify, somehow, which section (ie [Unit], [Service]) each key/value pair applies to. (Do we need to worry about order?)

systemd.lines_sshdconfig  1 2 3 4 5 
systemd.line_sshdconfig_1 [Unit]
systemd.line_sshdconfig_2 Description=OpenSSH local config
systemd.line_sshdconfig_3 Before=sshd.service


.conf override files
 

Changed:
<
<

  • Do we maintain /etc/systemd or just /etc/systemd/system?
  • /etc/systemd/system/*.* - unit files. Files may be links to /lib/systemd
  • /etc/systemd/system/{unit}.wants - directory of unit files wanted by {unit}. Files may be links to /lib/systemd/
  • /etc/systemd/system/{unit}.d - directory of .conf override config files
  • can have both an nfs.service and an nfs.socket
  • might have a .wants directory, but no unit file
  • a unit file can be a conf file (which we wish to generate) or a link to /usr/lib/systemd/system
  • a unit can be under multiple .wants directories (but presumably must link to same file?)
  • we have a bunch of links and config files
  • each can be either at top or within multiple wants directories
  • Note that following scheme won't allow a unit to be both in toplevel and in a wants - would you want this? Haven't seen this in practice in F19 nor F20.

Rather than having two structures - one for units at top level and one for units within *.wants directory -
Have all units in one systemd.units list. An attribute of a unit is whether it should be in 0 or more *.wants directories (default would be top dir).

systemd.libdir /usr/lib/systemd/system

systemd.units dbusbluez dbusfw dbusavahi dbusmodem dbusnetworkmgr dbusnmdispat default displaymanager \
syslog

systemd.realname_dbusbluez dbus-org.bluez.service
systemd.link_dbusbluez bluetooth.service
systemd.wantedby_dbusbluez <UNDEFINED - implies at top level>

# would create a softlink /etc/systemd/system/dbus-org.bluez.service to /usr/lib/systemd/system/bluetooth.service

systemd.realname_dbusfw dbus-org.fedoraproject.FirewallD1.service
systemd.link_dbusfw firewalld.service

# softlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service -> /usr/lib/systemd/system/firewalld.service

systemd.realname_default default.target
systemd.link_default graphical.target

# softlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

!systemd.units mADD(sshd)
systemd.realname_sshd sshd.service
systemd.link_sshd sshd.service
systemd.wantedby_sshd multi-user.target.wants ... [others?]

# softlink /etc/systemd/system/multi-user.target.wants/sshd.service -> /usr/lib/systemd/system/sshd.service

!systemd.units mADD(sshdconfig)
systemd.realname_sshdconfig sshd-local-config.service
systemd.link_sshdconfig <UNDEFINED - implies create config file from resources>
systemd.wantedby_sshdconfig sshd.service

systemd.description_sshdconfig OpenSSH localconfig
systemd.unittype_sshdconfig service
systemd.before_sshdconfig sshd.service
systemd.execstart_sshdconfig /usr/local/bin/sshd-local-config
systemd.type_sshdconfig oneshot

# creates file /etc/systemd/system/sshd.service.wants/sshd-local-config.service

with content

[Unit]
Description=OpenSSH localconfig
Before=sshd.service

[Service]
ExecStart=/usr/local/bin/sshd-local-config
Type=oneshot

There are far too many options to support, so propose adding resources for most commonly used options and allowing additional lines using something like the following. Note that we'd need to specify, somehow, which section (ie [Unit], [Service]) each key/value pair applies to. (Do we need to worry about order?)


systemd.lines_sshdconfig 1 2 3 4 5
systemd.line_sshdconfig_1 [Unit]
systemd.line_sshdconfig_2 Description=OpenSSH local config
systemd.line_sshdconfig_3 Before=sshd.service


.conf override files

systemd.overrides sshdexec
systemd.configunit_sshdexec sshd.service
systemd.lines_sshdexec 1 2 3
systemd.line_sshdexec_1 [Service]
systemd.line_sshdexec_2 Execstart=
systemd.line_sshdexec_3 Execstart=/usr/local/bin/sshd -d

Would create /etc/systemd/system/sshd.service.d/sshdexec.conf with contents :-

[Service]
Execstart=
Execstart=/usr/local/bin/sshd -d










>
>
systemd.overrides            sshdexec systemd.configunit_sshdexec  sshd.service systemd.lines_sshdexec       1 2 3  systemd.line_sshdexec_1     [Service] systemd.line_sshdexec_2      Execstart= systemd.line_sshdexec_3      Execstart=/usr/local/bin/sshd -d
 
Added:
>
>
Would create /etc/systemd/system/sshd.service.d/sshdexec.conf with contents :-

[Service]
Execstart=
Execstart=/usr/local/bin/sshd -d

 -- Main.ascobie - 2014-02-18 \ No newline at end of file

Revision 12014-02-18 - ascobie

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="SL7PortHome"


  • Do we maintain /etc/systemd or just /etc/systemd/system?
  • /etc/systemd/system/*.* - unit files. Files may be links to /lib/systemd
  • /etc/systemd/system/{unit}.wants - directory of unit files wanted by {unit}. Files may be links to /lib/systemd/
  • /etc/systemd/system/{unit}.d - directory of .conf override config files
  • can have both an nfs.service and an nfs.socket
  • might have a .wants directory, but no unit file
  • a unit file can be a conf file (which we wish to generate) or a link to /usr/lib/systemd/system
  • a unit can be under multiple .wants directories (but presumably must link to same file?)
  • we have a bunch of links and config files
  • each can be either at top or within multiple wants directories
  • Note that following scheme won't allow a unit to be both in toplevel and in a wants - would you want this? Haven't seen this in practice in F19 nor F20.

Rather than having two structures - one for units at top level and one for units within *.wants directory -
Have all units in one systemd.units list. An attribute of a unit is whether it should be in 0 or more *.wants directories (default would be top dir).

systemd.libdir /usr/lib/systemd/system

systemd.units dbusbluez dbusfw dbusavahi dbusmodem dbusnetworkmgr dbusnmdispat default displaymanager \
syslog

systemd.realname_dbusbluez dbus-org.bluez.service
systemd.link_dbusbluez bluetooth.service
systemd.wantedby_dbusbluez <UNDEFINED - implies at top level>

# would create a softlink /etc/systemd/system/dbus-org.bluez.service to /usr/lib/systemd/system/bluetooth.service

systemd.realname_dbusfw dbus-org.fedoraproject.FirewallD1.service
systemd.link_dbusfw firewalld.service

# softlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service -> /usr/lib/systemd/system/firewalld.service

systemd.realname_default default.target
systemd.link_default graphical.target

# softlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

!systemd.units mADD(sshd)
systemd.realname_sshd sshd.service
systemd.link_sshd sshd.service
systemd.wantedby_sshd multi-user.target.wants ... [others?]

# softlink /etc/systemd/system/multi-user.target.wants/sshd.service -> /usr/lib/systemd/system/sshd.service

!systemd.units mADD(sshdconfig)
systemd.realname_sshdconfig sshd-local-config.service
systemd.link_sshdconfig <UNDEFINED - implies create config file from resources>
systemd.wantedby_sshdconfig sshd.service

systemd.description_sshdconfig OpenSSH localconfig
systemd.unittype_sshdconfig service
systemd.before_sshdconfig sshd.service
systemd.execstart_sshdconfig /usr/local/bin/sshd-local-config
systemd.type_sshdconfig oneshot

# creates file /etc/systemd/system/sshd.service.wants/sshd-local-config.service

with content

[Unit]
Description=OpenSSH localconfig
Before=sshd.service

[Service]
ExecStart=/usr/local/bin/sshd-local-config
Type=oneshot

There are far too many options to support, so propose adding resources for most commonly used options and allowing additional lines using something like the following. Note that we'd need to specify, somehow, which section (ie [Unit], [Service]) each key/value pair applies to. (Do we need to worry about order?)


systemd.lines_sshdconfig 1 2 3 4 5
systemd.line_sshdconfig_1 [Unit]
systemd.line_sshdconfig_2 Description=OpenSSH local config
systemd.line_sshdconfig_3 Before=sshd.service


.conf override files

systemd.overrides sshdexec
systemd.configunit_sshdexec sshd.service
systemd.lines_sshdexec 1 2 3
systemd.line_sshdexec_1 [Service]
systemd.line_sshdexec_2 Execstart=
systemd.line_sshdexec_3 Execstart=/usr/local/bin/sshd -d

Would create /etc/systemd/system/sshd.service.d/sshdexec.conf with contents :-

[Service]
Execstart=
Execstart=/usr/local/bin/sshd -d










-- Main.ascobie - 2014-02-18

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback