persistent device storage

[Kay Sievers]

On Fri, 2004-05-14 at 13:56 +0200, David Zeuthen wrote:
> On Fri, May 14, 2004 at 01:11:38PM +0200, Kay Sievers wrote:
> > On Sun, 2004-05-09 at 22:04 +0200, David Zeuthen wrote:
> > 
> > > On the topic of attributes for properties, maybe it would be useful to
> > > have owners/permissions? I thought about just having all properties read
> > > only for non-root and having the name space user.* be special in the
> > > sense it is per-user and writable. Maybe this is the easiest to do; I
> > > mean it's probably not useful to read other users properties?
> > 
> > Hi David,
> > what is the reason not to store the user properties in the home
> > directory which is mentioned in the TODO?
> > 
> 
> It's per-machine and NFS homedirs etc. etc.
> 
> > If you want per machine user data, hald can create a uuid for its own
> > store and look in the users home dir for a matching set?
> > 
> 
> Yeah that would make sense actually - what should the uuid be? Probably
> something more unique and persistent than the ip-address or hostname
> as this can change and it isn't really unique (on some sites, both IP and
> hostnames changes every time on bootup due to DHCP settings etc.).

thats from the libuuid inside the ext2fs-utils:

DESCRIPTION
       The uuid_generate function creates a new universally unique  identifier
       (UUID).   The  uuid  will be generated based on high-quality randomness
       from  /dev/urandom,  if  available.   If  it  is  not  available,  then
       uuid_generate  will use an alternative algorithm which uses the current
       time, the local ethernet MAC address (if available),  and  random  data
       generated using a pseudo-random generator.

       The uuid_generate_random function forces the use of the all-random UUID
       format,  even  if  a  high-quality  random  number   generator   (i.e.,
       /dev/urandom) is not available, in which case a pseudo-random generator
       will be subsituted.  Note that the use of a pseudo-random generator may
       compromise the uniqueness of UUID ..s generated in this fashion.

       The uuid_generate_time function forces the use of the alternative algo-
       rithm which uses the current time and the local  ethernet  MAC  address
       (if available).  This algorithm used to be the default one used to gen-
       erate UUID, but because of the use of the ethernet MAC address, it  can
       leak information about when and where the UUID was generated.  This can
       cause privacy problems in some applications, so the uuid_generate func-
       tion only uses this algorithm if a high-quality source of randomness is
       not available.

       The UUID is  16  bytes  (128  bits)  long,  which  gives  approximately
       3.4x10^38 unique values (there are approximately 10^80 elemntary parti-
       cles in the universe according to Carl Sagan ..s Cosmos).  The  new  UUID
       can  reasonably  be  considered  unique  among all UUIDs created on the
       local system, and among UUIDs created on other systems in the past  and
       in the future.


> Maybe an md5 of hostname / ip-address / time, generated the first time
> hald starts up would do? Or maybe we can just stash it in /var per
> machine as I originally had thought, but that leaves the problem of
> deleting it when the user is deleted. Hmmm..

What about hald creates at first startup its uuid and places it
in /var/lib/hal. Everytime hald inits the store, it reads its uuid from
there.
If a user connects through DBUS, hald reads/writes
$HOME/.hal/<uuid>/<udi>/<property> in the users home.
This should solve the dead properties and it gives the user total contol
over the stored data for multiple machines.

Kay


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal