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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Fusioninventory-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/fusioninventory-devel
