# Presentation: 019334

## The F.R.E.N.C.H problem

## It’s all about the French !

- I meant, it’s all about Freeing Resources and Evading the Network Computing Hell.

- Thanks to Matt for helping me extend my limited vocabulary.

## Limitations of our current system (cont.)

- None of the clients can easily install software in the default Solaris / Linux / FreeBSD location.
- Even though we probably don’t want people to install to much locally, this should be enforced by access rights, not by a limitation.
- It is not stopping people to install stuff locally anyway.
- It forbids to easily install some project specific software on a few machine.

## /usr/local is considered to be the de facto standard for LOCALLY installed software

Steering away from standards can be dangerous. (Was OK for Linux and Solaris clients, it’s not anymore for FreeBSD clients.

Even if this technique is being used successfully out there, I don’t believe it fits our need.

Mounting /usr/local/ from a remote location can be confusing. Naming is so important.

- Steering away from standards can be dangerous. (Was OK for Linux and Solaris clients, it’s not anymore for FreeBSD clients.
- Even if this technique is being used successfully out there, I don’t believe it fits our need.
- Mounting /usr/**local**/ from a **remote** location can be confusing. Naming is so important.

- Limitations of our current system (cont.)

## The current system is not flexible and simple enough to satisfy our broad range of users need. Going from:

The simple user, who just wants to uses and depend on what is available from NFS.

The advanced user, who wants to benefit from the added value of the NFS server, but who also wants to be able to easily maintain a set of locally installed stuff (Through the port/pkg system for example.

The laptop user, who also wants to benefit from the nfs when on the network, but who still needs a bunch of core software in order to function when off the network.  

- The **simple user**, who just wants to uses and depend on what is available from NFS.
- The **advanced user**, who wants to benefit from the added value of the NFS server, but who also wants to be able to easily maintain a set of locally installed stuff (Through the port/pkg system for example.
- The **laptop user**, who also wants to benefit from the nfs when on the network, but who still needs a bunch of core software in order to function when off the network.

- Limitations of our current system (cont.)

## Finally, installing everything in one place (/usr/local or not), can be evil.

Conflicting Filenames.
Multiple versions of software.
Uninstallation of software.
Software distribution.
See /usr/local considered harmful:
 http://www.tinaa.com/rant/usrlocal.html

- Conflicting Filenames.
- Multiple versions of software.
- Uninstallation of software.
- Software distribution.
- See **/usr/local considered harmful:**
-  _[http://www.tinaa.com/rant/usrlocal.html](http://www.tinaa.com/rant/usrlocal.html)_

- Limitations of our current system (cont.)

## Do we want to mount software or not ?
Everything:
Using NFS for all our software (except a few exceptions)
Maybe not efficient. The clients are most likely not going to be unusable when the NFS is down.
Probably the easiest solution.

Nothing:
Using cfengine to keep a copy of all the software on each clients.
Disk space is a problem. Complex to put together and to maintain.
More efficient.

A bit of both:
Mounting most of the stuff
Using cfengine to maintain a core set of tools locally (bash, ssh, ..)
Complex to put together.
The best of two world.

- Everything:
- Using NFS for all our software (except a few exceptions)
- Maybe not efficient. The clients are most likely not going to be unusable when the NFS is down.
- Probably the easiest solution.
- Nothing:
- Using cfengine to keep a copy of all the software on each clients.
- Disk space is a problem. Complex to put together and to maintain.
- More efficient.
- A bit of both:
- Mounting most of the stuff
- Using cfengine to maintain a core set of tools locally (bash, ssh, ..)
- Complex to put together.
- The best of two world.

- Possible solutions / starting points

## Where do we mount or install software on clients and server ?

Need of consistency across clients and servers (The rpath problem). A good thing anyway

On all computers: Clients and servers:

/usr/dsd for site-installed and maintained software
/usr/local for locally-installed and maintained software

- Need of consistency across clients and servers (The rpath problem). A good thing anyway
- On all computers: Clients and servers:
- /usr/dsd for site-installed and maintained software
- /usr/local for locally-installed and maintained software

- Possible solutions / starting points

## Where do we install software ?
Everything in one place (Probably bad, but easy)

Using modules:
Install each software in 
/whatever/we/decided/sofware-name/software-version/
Harder, but so much better.
Only viable if we are consistent over all platforms
Modules everywhere / same name / same version ...

- Everything in one place (Probably bad, but easy)
- Using modules:
- Install each software in
- /whatever/we/decided/sofware-name/software-version/
- Harder, but so much better.
- Only viable if we are consistent over all platforms
- Modules everywhere / same name / same version ...

- Possible solutions/starting points (cont.)

## Where do we keep the source ?
For “Smart-enough” software (almost all):
/home/portnoy/shared/src/softwareName/softwareVersion/
Just keep the config.log for each platform as config.log.platformName.

For the few “not-so-smart” software:
/home/portnoy/platformName/src/softwareName/softwareVersion
Just keep the config.log

- For “Smart-enough” software (almost all):
*/home/portnoy/shared/src/softwareName/softwareVersion/*
- Just keep the config.log for each platform as config.log.platformName.
- For the few “not-so-smart” software:
*/home/portnoy/platformName/src/softwareName/softwareVersion*
- Just keep the config.log

- Possible solutions/starting points (cont.)

## Do we use a package system for the site-installed software ?

If yes:
No real control over versions installed
Not easy to install something in a specific place, and it’s dependencies in other specific places.
Probably too different across different platforms.

If no:
We have to maintain and install site software manually
Better control
Consistent
Probably the best solution

- If yes:
- No real control over versions installed
- Not easy to install something in a specific place, and it’s dependencies in other specific places.
- Probably too different across different platforms.
- If no:
- We have to maintain and install site software manually
- Better control
- Consistent
- Probably the best solution

- Possible solutions/starting points (cont.)

## Do we use a package system for the locally-installed software ?

If yes:
Leave this choice to the owner.
Now it’s easy, because it can use the default location /usr/local
Probably the best solution
If no:
Leave this choice to the owner.
The owner can install stuff manually

- If yes:
- Leave this choice to the owner.
- Now it’s easy, because it can use the default location /usr/local
- Probably the best solution
- If no:
- Leave this choice to the owner.
- The owner can install stuff manually

- Possible solutions/starting points (cont.)

## We tried to come up with solutions that would make the system more flexible and more robust.

We tried to solve some problems that are keeping some people from leveraging off of our system (laptop users, FreeBSD users, ...).

Only naming changes for the people who like the system the way it is.

Hopefully a consensus will be reached.

- We tried to solve some problems that are keeping some people from leveraging off of our system (laptop users, FreeBSD users, ...).
- Only naming changes for the people who like the system the way it is.
- Hopefully a consensus will be reached.

- Conclusion