Created attachment 1061265 [details] Patch to add a rngd file to /etc/sysconfig Description of problem: rngd is run by systemd. But rngd.service currently does not allow to specify any commandline arguments for running rngd. In some cases it would make sense to e.g. be able to activate Intel DRNG as full entropy source or to pull in random data from another hardware rng whose driver is running in userspace and is offering it's numbers not on /dev/hwrandom. All this is possible with commandline options. But currently you have to patch rngd.service when you want to apply them. This conflicts with further updates of the rpm and complicates the task. So please add the file /etc/sysconfig/rngd to add parameters to rngd. Version-Release number of selected component (if applicable): rng-tools-5-5.fc22.x86_64 Attached is a patch which implements the necessary changes. Please apply or give feedback how it should be improved.
Yes please. I was going to file this exact bug for the same reasons. I want to run rngd from systemctl but set the source to something other than /dev/hwrandom.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Yes please. This used to work before this package was converted to systemd.
A simple patch to do this with systemd dropins instead of a file in /etc/sysconfig/rngd (we have too many of those already) below: $ git diff rngd.service diff --git a/rngd.service b/rngd.service index 33829f6..2f72d64 100644 --- a/rngd.service +++ b/rngd.service @@ -2,7 +2,7 @@ Description=Hardware RNG Entropy Gatherer Daemon [Service] -ExecStart=/sbin/rngd -f +ExecStart=/usr/sbin/rngd -f $OPTIONS SuccessExitStatus=66 [Install] That way you could do sudo systemctl edit rngd.service Add [Service] Environment="OPTIONS=--no-tpm=1" Jeff, ok to apply?
Using systemctl edit to set the options would work for me too.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Unfortunately this is still an issue with F31. rng-tools-6.7-3.fc31 still does not contain either my patch or Rubens $OPTIONS idea. Please consider applying either solution to rng-tools.
I've just bumped into this while trying to tweak rngd options. Still an issue in F32, rng-tools-6.9-3.fc32. Shall we start unresponsive maintainer procedure?
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still an issue on F34.
Looks like this was assigned to the wrong person.
hello, Gerd, Ruben, Dominik, thank you for reporting this. indeed, this bz was not assigned properly and has felt thru cracks. thank you for solutions suggested, while having no preferences, i've semi-randomly have chosen the systemctl-edit one to implement. if there are objections for this and suggestion that the etc-sysconfig one should be implemented instead, please, tell. could you please have a look at the suggested change: https://src.fedoraproject.org/fork/vladis/rpms/rng-tools/c/c0500dc591163e7428ee56d9793893e98f55d38c?branch=rawhide if you see i've missed something (except a release bump and a changelog), please, tell. you can try the following build for f34 if needed: https://koji.fedoraproject.org/koji/taskinfo?taskID=75788839 i'm planning to update rng-tools (again) soon, and i'll integrate this change if no objections/fixes.
The problem with this particular approach is that user (admin) changes will be blown away on package upgrades, because %attr(0644,root,root) %{_unitdir}/rngd.service.d/override.conf is missing the %config marker. Personally, I prefer the legacy /etc/sysconfig approach, but this works for me as well.
Hi Vladis, thanks for taking up this issue after this long time. Is there some agreement that systemd edit/override should be preferred over /etc/sysconfig for new options? I could at least not find anything in the packaging guidelines. I also prefer the /etc/sysconfig approach, because then you have all such changes to the system in one directory. Which makes it easier to find such changes when preparing for a migration to a new major distribution version or similar. But when the %config issue Dominik mentioned is addressed, the systemd edit/override solution would of course also work for me.
hello, Dominik, Gerd, thanks a ton for your thoughts, i also like the old-school etc-sysconfig approarch more. it has the %config marker, as you've mentioned, could you please, have a look? if anything else should be adjusted, i'll be glad to hear: https://src.fedoraproject.org/fork/vladis/rpms/rng-tools/c/a53ee4c0a916d11110dc58e4de2656119eed0295?branch=etc-sysconfig https://koji.fedoraproject.org/koji/taskinfo?taskID=75841876
One more thing. The "-f" option is required for the systemd service to work with Type=simple, so I wouldn't put that in the sysconfig file, e.g.: RNGD_ARGS="" ExecStart=/usr/sbin/rngd -f $RNGD_ARGS On the other hand, this makes it a little harder to override the complete command line. However, if you want to change the '-f', you also need to change 'Type=simple', so you'd be modifying or overriding the systemd unit file anyway. Also, there's an unecessary whitespace change in %attr(0644,root,root) %{_unitdir}/rngd.service line.
thanks, Dominik, adjusted: https://src.fedoraproject.org/fork/vladis/rpms/rng-tools/c/0c54b94f53c09dd3085aafcb409d37e8362ba23e?branch=etc-sysconfig i've added explicit 'Type=simple', a comment, disabled some entropy sources by default, and yes, i do not like 3 spaces in the "%{_unitdir}/rngd.service" line. let it be 4 spaces for no particular reason. a build: https://koji.fedoraproject.org/koji/taskinfo?taskID=75849046 could you please have a look if the change is acceptable now? thank you.
The sysconfig stuff looks all fine to me now. About disabling some of the random sources: - jitter I think there were some reports about problems with Raspberry Pis and the jitter rng in the past, but I think they have been solved upstream. But other than that I don't know why to disable it. On some older/embedded systems without RDRAND support in the CPU, this is one of the few random sources available. - pkcs11 I know that some smartcards are worn out by regularly using their random generator (flash/eeprom write cycle limit). So disabling this by default makes sense. It is easy for the admin to change it back on now. - rtlsdr Will usually not be connected. But when it is, I don't know why you would want to disable it. AFAIK it is quite a common mechanism and seems to be not easy to spoof from the outside since only some of the LSBs are used. - nist I think this is disabled by default and you don't want to use it. So explicitly disabling it is fine by me. So I would set RNGD_ARGS="-x pkcs11 -x nist" by default. If you think differently, I think it would be best to document somewhere why some of the mechanisms are disabled. That makes sure that for future changes this won't have to be discussed all again until some new facts are discovered.
hello, Gerd, thanks a ton, i'll follow your advise and make this change in a final commit. i was thinking to disable the jitter source because it consumes 100% of upto 4 CPU cores at startup for several seconds and i thought systems without RDRAND are really rare ones. Same way, I thought systems with rtl-sdr hw are exceptionally rare ones too. yep, the only place i can think of for these to be mentioned is in a fedora update. i know no one reads it mostly )).
FEDORA-2021-06fdbac213 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-06fdbac213
updates are posted: https://bodhi.fedoraproject.org/updates/?packages=rng-tools closing this bz for now, feel free to update if something.
FEDORA-2021-06fdbac213 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-06fdbac213` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-06fdbac213 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-06fdbac213 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.