On 4/6/23 17:56, Orion Poplawski wrote:
The nut package has a number of different systemd units:
/usr/lib/systemd/system/nut-driver-enumerator.path
/usr/lib/systemd/system/nut-driver-enumerator.service
'/usr/lib/systemd/system/nut-driver@.service'
/usr/lib/systemd/system/nut-driver.target
/usr/lib/systemd/system/nut-server.service
/usr/lib/systemd/system/nut.target
And I have a number of questions about how to handle them:
* I think we want a preset to automatically enable and start
nut-driver-enumerator.path. This monitors /etc/ups/ups.conf and runs
nut-driver-enumerator.service when it does. It also has:
[Install]
WantedBy=nut.target
Does that seem appropriate? Is is possible to start it immediately after
install in %post?
You don't want to start _anything_ until the user has done the rather extensive
editing required in the config files to tell the package what hardware to look
for and what to do.
* What is a user expected to do to enable and start "nut"? It seems like:
systemctl enable nut.target
systemctl start nut.target
The user needs to enable nut-driver-enumerator.service if there is any UPS
hardware monitored by this system (i.e., not needed if this is a "secondary"
system and some other "primary" system is actually monitoring the UPS).
Then, running "systemctl enable nut.target" will start the package on the
next boot. Include "--now", or run "systemctl start nut.target" to start it
immediately.
But all of that has to wait until the user has made the necessary edits in
the config scripts in /etc/ups.conf and edited the /usr/bin/upssched-cmd
script to set up any additional actions (e.g., notifications, etc) that are
wanted.
Would do the trick, but I don't think it's very intuitive - most users think
in terms of service units I think.
Overall, it's a pretty user-unfriendly package. Some things that used to
"Just Work" back in the days of CentOS 6 need manual configuration now.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
