Random_seed File Locking on NFS File System Across Networks/Domains Hangs

[Charlie Salemi]

The 100+ servers only read the key.  Each user ID has a sub-directory under a generic location so there are no warnings printed by gpg when using the key to decrypt files.  Any operation that encrypts files imports the global key locally or uses User IDs that have the same key locally and uses it for the encrypting.

Again, the concern using the global keystore on the NAS is that it doesn’t cause issues if multiple servers are decrypting different files at the same time using the same key without using the random_seed file.  Using the —no-random-seed-file would eliminate the file locking issue, I believe.

________________________________
From: Gnupg-users <gnupg-users-bounces at gnupg.org> on behalf of Ángel <angel at pgp.16bits.net>
Sent: Sunday, April 25, 2021 7:51 PM
To: gnupg-users at gnupg.org
Subject: Re: Random_seed File Locking on NFS File System Across Networks/Domains Hangs

On 2021-04-25 at 13:11 +0000, Charlie Salemi via Gnupg-users wrote:
> 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?

No. Not using the random seed files means just, not using that file. It
isn't used for synchronization.
Although, you could face the same issue when they try to lock other
files. How are you handling the changes to that keystore? Are those 100
servers only reading the keys, or are they also *modifying* it (e.g.
importing new keys) ?



_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users&data=04%7C01%7C%7C9d89eb24058444eb94e008d908450ce8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637549914956463495%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SwbfvbDf97w%2F%2FOPExS57YixLJgD%2B3fdfKT94OgtXIvM%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210426/0cd8e2e8/attachment-0001.html>