Re: [Freeipmi-devel] one major bug, several minor issues

[Anand Babu]

I think best way is to handle IPCKEY creation at runtime.
ftok lookup should install one if missing.

If you think this is reasonable, let me know, I will go ahead and
implement it.

-ab
,----
| Hmmm, I can't remember the exact way to do this in automake, but we
| could perhaps make an option
| 
| make rpm-install
| 
| And it does everything just like make install, but doesn't install the
| ipckey??
| 
| Al
| 
| --
| Albert Chu
| address@hidden
| Lawrence Livermore National Laboratory
`----

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Thursday, April 1, 2004 5:24 pm
Subject: Re: [Freeipmi-devel] one major bug, several minor issues

> SYSV IPC uses 32-bit identifiers, called 'keys', to identify shared
> IPC objects. Generally, each application will have a key hard-coded in
> it, or will generate one at runtime based on the properties of a
> specific file. Unfortunately, there is no way to be absolutely sure
> that a SYSV IPC key is unique for your application.
> 
> The most commonly used method of generating an IPC key that is
> reasonably unique is to use the ftok() function.
> 
> Apart from system defined keys, having user configure / change it 
> is a
> must, though it is rarely required.
> 
> With ftok approach, if user wishes to change the key, he can simply
> # rm $IPCKEY, touch $RANDOM_NAME, mv $RANDOM_NAME $IPCKEY
> This will change the inode of the file and hence ftok result.
> 
> There are other cleaner ways to choose IPC KEY.
> 
> 1) predefined MACRO
>  #define IPCKEY_BASE_DEFAULT    36536
> 
> 2) configure --set-ipckey=[KEY]
> 
> 3) Environment Variable $IPC_KEY
> 
> 4) libfreeipmi config file.
> 
> I don't like Option 2) and 4). Because it lets user choose the IPCKEY
> and can result in non-unique keys. Correct policy is to let
> libfreeipmi enforce IPCKEY value and should be user-configurable too.
> 
> -ab
> 
> ,----
> | > Can you handle it in the RPM post install script?
> | > -ab
> | 
> | I could, but that leaves 2 issues:
> | 
> | 1) If the user isn't root, they can't build an rpm (make install 
> fails| when installing to /var/lib)
> | 
> | 2) You mkdir and install /var/lib/libfreeipmi/ipckey to a system 
> that| may not necessary want it.
> | 
> | Two is minor, but 1 is actually an issue.  I built rpms today, 
> and the
> | fix is very simple.  In the rpm spec file, I run
> | 
> | ./configure --enable-rpm-install
> | 
> | And this informs configure to install /var/lib/libfreeipmi/ipckey in
> | /var/tmp/foo/var/lib/libfreeipmi/ipckey instead.
> | 
> | Al
> | 
> | --
> | Albert Chu
> | address@hidden
> | Lawrence Livermore National Laboratory
> `----
> 
> ----- Original Message -----
> From: Anand Babu <address@hidden>
> Date: Thursday, April 1, 2004 2:30 pm
> Subject: Re: [Freeipmi-devel] one major bug, several minor issues
> 
> > Can you handle it in the RPM post install script?
> > -ab
> > ,----
> > | > This has to be a *fixed path*. 
> > | 
> > | Hmmm.  The problem is that when you build an rpm, the rpm build
> > | temporarily installs everything in some temporary directory like:
> > | 
> > | /var/tmp/libfreeipmi-0.0.0/var/lib/libfreeipmi
> > | 
> > | If the install of the ipckey is put into the real 
> > /var/lib/libfreeipmi| directory, it will be subsequently absent 
> > from the RPM.
> > | 
> > | Hmmmm.  I dunno.  I suppose the best thing to do would be to 
> > create an
> > | autoconf option "--rpm-install" or something, and this is just 
> a 
> > very| special case??
> > | 
> > | Al
> > `----
> > 
> > --
> > Albert Chu
> > address@hidden
> > Lawrence Livermore National Laboratory
> > 
> > ----- Original Message -----
> > From: Anand Babu <address@hidden>
> > Date: Wednesday, March 31, 2004 4:48 pm
> > Subject: Re: [Freeipmi-devel] one major bug, several minor issues
> > 
> > > ,----
> > > | Hey everyone,
> > > | 
> > > | 1) One major bug.  Files in:
> > > | 
> > > | /var/lock/*
> > > | 
> > > | are commonly removed on boot.  So 
> /var/lock/libfreeipmi/ipckey is
> > > | commonly removed by many bootup scripts, including the 
> default 
> > > redhat| one.  I am going to change to 
> > /var/lib/libfreeipmi/ipckey.  
> > > I think this
> > > | makes far more sense.
> > > `----
> > > Please go ahead and make that change. Even I didn't like 
> > /var/lock 
> > > path.FHS suggests only to keep only lock files there, while 
> > ipckey is
> > > handle.
> > > 
> > > ,----
> > > | 2) When I created the 
> > > | 
> > > | IPMI_DEFAULT_SDR_REPO_CACHE_FILENAME
> > > | 
> > > | macro.  I stupidly set the default path to
> > > | "/var/lib/fish/sdr-repo-cache".  It should instead by
> > > | /var/lib/libfreeipmi/sdr-repo-cache" ... 
> > > `----
> > > OK
> > > 
> > > ,----
> > > | 3) make install of /var/lock/libfreeipmi/ipckey (to be 
> renamed 
> > > soon),| doesn't install correctly when bulding RPMs.  I think 
> we 
> > > need to put
> > > | some prefix on the line:
> > > | 
> > > | Ipckeydir     = /var/lock/$(PACKAGE)
> > > | 
> > > | like
> > > | 
> > > | Ipckeydir     = ($FOO)/var/lock/$(PACKAGE)
> > > | 
> > > | I remember hitting this issue before, but I can't remember 
> what 
> > the> | variable prefix name is.  I'll figure it out.
> > > | 
> > > | After these changes, I'm going to tag as Alpha5-Qa1A.
> > > `----
> > > This has to be a *fixed path*. 
> > > 
> > > ftok uses inode of this file and 8 bits from PROJ_ID to make a 
> > unique> (somewhat) handle for IPC. All apps using libfreeipmi 
> > should refer to
> > > same IPCKEY in order to use the mutex device.
> > > 
> > > /var/lib/libfreeipmi/ipckey sounds better.
> > > 
> > > -- 
> > > _.|_ 
> > > (_||_)
> > > Free as in Freedom <www.gnu.org>
> > > 
> > 
> > 
> > 
> > -- 
> > _.|_ 
> > (_||_)
> > Free as in Freedom <www.gnu.org>
> > 
> 
> 
> -- 
> _.|_ 
> (_||_)
> Free as in Freedom <www.gnu.org>
> 



-- 
 _.|_ 
(_||_)
Free as in Freedom <www.gnu.org>