[Fusioninventory-devel] Change in setup directories handling

[Guillaume Rousse]

Le 23/10/2010 19:40, Gonéri Le Bouder a écrit :
> On Wed, Oct 20, 2010 at 09:39:33PM +0200, Guillaume Rousse wrote:
>> Here is the issue with setup directory handling in the agent:
>> http://forge.fusioninventory.org/issues/273
>>
>> I just made some radical changes in my branch to fix this issue, and
>> enhance the situation:
>> - basevardir and share-dir options don't exist anymore
> --basevardir was useful for the case the user was not allowed to write
> on the default directory. How do you deal with this situation now?
Anyway, that's indeed a problem if you run an *installed* agent with a
different user that's the one than installed it, and you can't switch
back to the installing user to make the directory writable by the second
user. In that case, you'd better just run the agent from its extraction
directory, or reinstall it with the second user.

But is this scenario realistic enough to deserve a runtime option (by
opposition to an installation time one) ? Especially as we advice people
to run the agent as root users...

>> - config.pm doesn't have any hadrcoded list of directories to scan
>> - instead, the various executables (agent and win32-service)
>> automatically pass correct hardcoded values when instanciating the agent
> Yes, both changes make sence to me too.
> 
>> - in the git tree, those values match local tree, so it just works,
>> without the need for --devlib option
> How do you detect when you are in the git tree?
Because you run an unmodified executable.

>> - when installing, the 'make install' target automatically rewrite those
>> values to match installation location correctly
>> - those values can be altered by passing options to Makefile.PL:
>> perl Makefile.PL CONFDIR=/etc/fusioninventory
>> DATADIR=/usr/share/fusioninventory VARDIR=/var/lib/fusioninventory
> On Windows we set basvardir and config-file in the registry during the
> installation.
> I've the feeling it will be way more tortuous since we have to patch
> the fusioninventory-win32-server and fusioninventory-agent after the
> installation(?).
We have to do something anyway, not necessarily modifying the different
executables, to adapt the software to its installation.

Let's present the issue differently, starting with the variable
directories issue.

We have two directories (on Windows), and three (on Unix) whose exact
location are installation dependant:
- configuration directory
- read-only data directory
- writable data directory

I think we all agree than after installing the software, the user should
be able to run the agent without having to explicitely define any of
them himself: it should run correctly, with all features enabled, out of
the box. Which implies two tasks for the installation process:
- it should install read-only data, and eventually a default
configuration file, in those locations
- it should perform some kind of post-processing to make the programm
automatically look for the correct locations

Do we agree on that ?

The first task is quite easy to achieve, and is just a matter of using
makemaker hooks to performs additional file installation tasks.

The second task is more versatible, as they are various way to achieve
this goal:
- modify the N executables
- modify a single perl module, that would define those various values as
constant
- modify the configuration (but only for the two last directories)

I currently prefered the first one, just for sake of simplicity
(makemaker offers individual executable processing, not individual perl
modues processing), but I'm open to alternatives. For the record, the
second solution is actually used in sympa software, but it is
autotools-based, not Makemaker-based.

Indeed, they are two executable on Windows. And the actual installation
path occurs when running the installer, meaning this last one should
take care of the needed changes.

The second issue (--devlib option removal) was not my primary objective
when implementing the change, just an additional bonus. Given the
following statements:
- it's desirable to be able to run the software without installation
(development phase, and prebuilts)
- it's better if there is no specific option needed here, as it can't
work anyway without it
- such a specific option has no use once the software is installed

I just took advantage of the post-installation process needed for first
issue to implement this. And while just needing another substitution in
Makefile.PL, it also make the agent code simpler.
 --
BOFH excuse #273:

The cord jumped over and hit the power switch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4251 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/fusioninventory-devel/attachments/20101028/dbf509bd/attachment.bin>