You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several parameters which would be useful to enable configuring for each piece of information that the issuegen, motdgen, and profile scripts display.
The information which would have the configuration options:
SSH keys (currently in issuegen)
network interfaces from udev (currently in issuegen)
If there is a separate config file for each of the information above, one format could look like:
# /usr/lib/console-login-helper-messages/udev_if_snippetgen.conf
ISSUE_OUTPUT_DIR=/run/console-login-helper-messages/issue.d
ISSUE_ENABLE=true
# Example if we wanted to generate network interface information from udev to motd# as well as issue, and we wanted to drop the snippet in the "public" run/motd.d directory.
MOTD_OUTPUT_DIR=/run/motd.d
MOTD_ENABLE=true
A script called something like udev_if_snippetgen would be invoked by a udev rule (could be a systemd service or other, for other types of information). This script would source the above config file and look for each variable named *_OUTPUT_DIR and place a copy of the snippet in each of these files. In order to separate the scripts like this, this would likely require re-architecting issuegen to be a service that has an associated .path systemd unit, which triggers issuegen upon snippets being created in /run/console-login-helper-messages/issue.d (started in #43).
Prior to rearchitecting issuegen, the current issuegen could also work with the above config file by sourcing /usr/lib/console-login-helper-messages/udev_if_snippetgen.conf and look for ISSUE_OUTPUT_DIR to output the udev interface snippets to. If this variable is unset, then the path would be set to a default path (possibly chosen after checking the util-linux version on the system). Similar can be done for motdgen.
This setup does sound quite complicated for scripts that are sourcing simple pieces of information, but long term it'd ease development to have each type of information interface with issuegen, motdgen, and the profile.sh script in a common way - that way support for new types of information (e.g. #34) could be added without modifying the issuegen, etc. scripts. (E.g. the purpose of issuegen/motdgen/profile could be to only look for snippets that land in its input snippet directory /run/console-login-helper-messages/issue.d, in #43 ). It would also mean that issuegen doesn't operate on all the information it displays, if only one is modified (e.g. right now issuegen will regenerate the SSH key snippet, if a udev rule for the network interfaces was invoked).
That'd mean when packaging this, the default types of information (SSH keys, udev interfaces, etc) could be included in an optional subpackage like console-login-helper-messages-defaults, and users could further configure it if they wanted to turn off some of the defaults. issuegen, motdgen, etc. could still be used by custom snippet generators if the users wanted to. (Currently there hasn't been mention of a need for this, but it seems useful to have).
The text was updated successfully, but these errors were encountered:
There are several parameters which would be useful to enable configuring for each piece of information that the issuegen, motdgen, and profile scripts display.
The information which would have the configuration options:
This includes:
If there is a separate config file for each of the information above, one format could look like:
A script called something like
udev_if_snippetgen
would be invoked by a udev rule (could be a systemd service or other, for other types of information). This script would source the above config file and look for each variable named*_OUTPUT_DIR
and place a copy of the snippet in each of these files. In order to separate the scripts like this, this would likely require re-architectingissuegen
to be a service that has an associated.path
systemd unit, which triggersissuegen
upon snippets being created in/run/console-login-helper-messages/issue.d
(started in #43).Prior to rearchitecting
issuegen
, the currentissuegen
could also work with the above config file by sourcing/usr/lib/console-login-helper-messages/udev_if_snippetgen.conf
and look forISSUE_OUTPUT_DIR
to output the udev interface snippets to. If this variable is unset, then the path would be set to a default path (possibly chosen after checking theutil-linux
version on the system). Similar can be done formotdgen
.This setup does sound quite complicated for scripts that are sourcing simple pieces of information, but long term it'd ease development to have each type of information interface with
issuegen
,motdgen
, and theprofile.sh
script in a common way - that way support for new types of information (e.g. #34) could be added without modifying theissuegen
, etc. scripts. (E.g. the purpose of issuegen/motdgen/profile could be to only look for snippets that land in its input snippet directory/run/console-login-helper-messages/issue.d
, in #43 ). It would also mean thatissuegen
doesn't operate on all the information it displays, if only one is modified (e.g. right nowissuegen
will regenerate the SSH key snippet, if a udev rule for the network interfaces was invoked).That'd mean when packaging this, the default types of information (SSH keys, udev interfaces, etc) could be included in an optional subpackage like
console-login-helper-messages-defaults
, and users could further configure it if they wanted to turn off some of the defaults.issuegen
,motdgen
, etc. could still be used by custom snippet generators if the users wanted to. (Currently there hasn't been mention of a need for this, but it seems useful to have).The text was updated successfully, but these errors were encountered: