On Tue, Aug 02, 2022 at 12:14:23PM +0200, Karel Zak wrote: > On Sat, Jul 30, 2022 at 04:50:24PM +0200, Chris Hofstaedtler wrote: > > > > Debian sets up a uuidd user, for uuidd to run as. We also set the > > home directory for this user to /run/uuidd, which is on a tmpfs, so > > not ideal. > > > > I was wondering what other distributions do for the home directory? > > So it uses /var/lib/libuuid as a home directory. Per RFC 4222, the clock sequence *should* be incremented under various circumstances. Setting to to a random value (which would be required if you are using /run/uuidd) is *allowed*, but I would argue that this is not as good, and not as in keeping with the design spirt of UUID version 1: 4.1.5. Clock Sequence For UUID version 1, the clock sequence is used to help avoid duplicates that could arise when the clock is set backwards in time or if the node ID changes. If the clock is set backwards, or might have been set backwards (e.g., while the system was powered off), and the UUID generator can not be sure that no UUIDs were generated with timestamps larger than the value to which the clock was set, then the clock sequence has to be changed. If the previous value of the clock sequence is known, it can just be incremented; otherwise it should be set to a random or high-quality pseudo-random value. Similarly, if the node ID changes (e.g., because a network card has been moved between machines), setting the clock sequence to a random number minimizes the probability of a duplicate due to slight differences in the clock settings of the machines. If the value of clock sequence associated with the changed node ID were known, then the clock sequence could just be incremented, but that is unlikely. If system is using a read-only root, and doesn't want to maintain a /var partition, which some systemd installations do care about --- but for more traditional distributions, such as RHEL and Debian, my personal recommendation is to not try to use /run/uuidd and using a dynamic user for uuidd. Cheers, - Ted
