For internal encrypting/decrypting operations we want to use a NFS location for the gpg keystore available to two (possibly more) user IDs across many servers. It was designed this way so we did not have to share the keystore to each server and updates to the keystore could be done in one location, not on several (100+) servers. When the servers and the NAS appliance are on the same network and domain, there is no issue calling the fcntl system call to lock the random_seed file. However, we are moving the servers to a new network and a new domain but not all at once. This is where the issue showed up. On servers already moved to the new network/domain any fctnl on the randon_seed file hangs. Servers still in the same network/domain as the NAS appliance work as before (no hang). We believe this is a firewall issue and are investigating a solution.
However, this leads to the following questions: what functionality does the random_seed file provide? We know it can be ignored with the --no-random-seed-file option, but there is the possibility of doing many encrypting/decrypting operations simultaneously from both user IDs executing on different servers. Would ignoring the file locking on the random_seed file with the --no-random-seed-file option cause issues with independent processes accessing the same keystore at the same time on different servers? If so, what are those issues, and can they be avoided/worked around?
However, this leads to the following questions: what functionality does the random_seed file provide? We know it can be ignored with the --no-random-seed-file option, but there is the possibility of doing many encrypting/decrypting operations simultaneously from both user IDs executing on different servers. Would ignoring the file locking on the random_seed file with the --no-random-seed-file option cause issues with independent processes accessing the same keystore at the same time on different servers? If so, what are those issues, and can they be avoided/worked around?
