我跑步有困难Solr 9.2在上面的虚拟机上（Azure 上的 Rhel9.1，图片来自 CIS）。
问题在于熵低，如下面的日志所示：
Started Apache Solr 9.
Java 17 detected. Enabled workaround for SOLR-16463
Warning: Available entropy is low. As a result, use of the UUIDField, SSL, or any other features that require
RNG might not work properly. To check for the amount of available entropy, use 'cat /proc/sys/kernel/random/entropy_avail'.
我已经尝试安装rng 工具和哈格德但问题仍然存在。 的输出仍然cat /proc/sys/kernel/random/entropy_avail是256。
以下是哈格德服务：
Started Entropy Daemon based on the HAVEGE algorithm.
haveged[14569]: haveged: command socket is listening at fd 3
haveged[14569]: haveged: fills: 1, generated: 512 K bytes, RNDADDENTROPY: 256
以及随机数生成器服务：
Started Hardware RNG Entropy Gatherer Daemon.
rngd[14506]: Disabling 7: PKCS11 Entropy generator (pkcs11)
rngd[14506]: Disabling 5: NIST Network Entropy Beacon (nist)
rngd[14506]: Disabling 9: Qrypt quantum entropy beacon (qrypt)
rngd[14506]: Initializing available sources
rngd[14506]: [hwrng ]: Initialization Failed
rngd[14506]: [rdrand]: Enabling RDSEED rng support
rngd[14506]: [rdrand]: Initialized
rngd[14506]: [jitter]: JITTER timeout set to 5 sec
rngd[14506]: [jitter]: Initializing AES buffer
我错过了什么？
答案1
Solr 有一个检查/proc/sys/kernel/random/entropy_avail < 300。版本控制和SOLR-10352 SOLR-10338建议在 Solr 7 左右添加该功能，以应对涉及加密的慢速测试。此检查在现代 Linux 上毫无用处，我认为开发人员应该将其删除。
我不太熟悉这个应用程序，不知道它最终从哪里获取随机位，例如在 /dev/random 或 /dev/urandom 中，或者 getrandom 系统调用上的哪些标志。Solr 从未使用过阻塞源来获取随机数量，但它过去可能因应用程序的意外或设计而阻塞过。
man 7 random将解释 Linux 随机驱动程序的存在是为了初始化加密安全 RNG (crng)。最近，源代码文档进行了一次迟来的更新，char/random.c6.3 总结：
* The high level overview is that there is one input pool, into which
* various pieces of data are hashed. Prior to initialization, some of that
* data is then "credited" as having a certain number of bits of entropy.
* When enough bits of entropy are available, the hash is finalized and
* handed as a key to a stream cipher that expands it indefinitely for
* various consumers. This key is periodically refreshed as the various
* entropy collectors, described below, add data to the input pool.
注意“无限扩展”。这里的算法足够好，阻塞池已被移除。
我认为 Linux 的阻塞池已经过时了。Linux 的 CRNG 生成的输出甚至足以用于密钥生成。阻塞池在任何物质方面都没有那么强大，而且维持它需要大量价值可疑的基础设施。
我测试了这种无阻塞情况，这是 CentOS Stream 9 从 /dev/random 读取 200 亿位。这是一个巨大的数量，因为 256 位足以为任何加密密钥提供种子。请注意，这只是一些空闲的测试虚拟机，我关闭了 rngd。尽管存在这些限制，但它在由 NIST 设计并由 rng-tools 维护者实施的测试套件中表现不错。
[root@novem ~]# pv < /dev/random | rngtest --blockcount=1000000
rngtest 6.16
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000000032 ]
rngtest: FIPS 140-2 successes: 999166
rngtest: FIPS 140-2 failures: 834
rngtest: FIPS 140-2(2001-10-10) Monobit: 110
rngtest: FIPS 140-2(2001-10-10) Poker: 104
rngtest: FIPS 140-2(2001-10-10) Runs: 314
rngtest: FIPS 140-2(2001-10-10) Long run: 310
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=38.767; avg=1393.782; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=21.052; avg=228.528; max=244.532)Mibits/s
rngtest: Program run time: 97270648 microseconds
2.33GiB 0:01:37 [24.5MiB/s] [ <=> ]
[root@novem ~]# uname -a
Linux novem 5.14.0-302.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 20 05:35:26 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
至于为什么在 EL 9 时代会触发警告，这是一个实现细节，因为池子这么小。它不会影响输出的质量。内核维护人员不会返回旧的 4096 位 LFSR 池。维护人员也对投入过多精力表示怀疑：“熵估计的一般概念从一开始就可能无法稳健地实现。”尽管如此，为了最大程度的透明度，并且不破坏用户程序假设，sysctl API 仍然存在。
您可以继续使用程序为其提供更多随机位。它们将与许多其他来源混合，并为 CRNG 提供更多输出。
进一步阅读：