[: Re: [Infrastructures] how to build an internal (local) file structure?]

[Ivan Popov]

Hi Rudy,

On Wed, Mar 30, 2005 at 02:42:25PM +0200, Rudy Gevaert wrote:
> I see it like this (or rather a way to do it would be):
> 
> company/
> `-- apps
>     |-- app1_v1
>     |   |-- bin.i386
>     |   |-- bin.sparc
>     |   |-- etc
>     |   |-- lib.i386
>     |   |-- lib.sparc
>     |   |-- sbin.i386
>     |   |-- sbin.sparc
>     |   |-- share
>     |   `-- src
>     |-- app1_v2
>     `-- app2_v1

as you wrote that, I think we have similar standpoints.
You may find it reasonable how we place software on /coda/konvalo.org

> I do have some questions:
> 
> - AFS seems a very good way to set up the fileserver put everything in
>   /afs/comanpy.com/  

Sure. I would definitely go AFS or Coda.

> - what with NFS?  It isn't good practice to mount NFS shares on top of
>   each other. It is clear that you can't keep /company on one machine
>   for ever.  

Of course, NFS does not scale.

> - do mount the whole /company on each machine?  With AFS you can set
>   up the right rights.  But NFS is trickier.

You can imitate a global file name space with NFS, but it will
need a lot of care, while you get it almost for granted with AFS
(unless you destroy that yourself, with shortcuts in /afs ...)

> - how do implement the symlink farm?  CFengine seems good to me.  

One side of the problems - trivial symlink farms do not really scale.
You will face other issues, like [maintaining different versions of]
shared libraries and others.

> /bin/app1 -> /company/apps/app1_v2/bin.i386/app1
> /etc/app1/ -> /company/apps/app1_v2/etc/

You don't need/want these links. Seriously.

Then, you do not need cfengine either as soon as you have a global
filesystem view.
You will be able to create the necessary objects (including symlink trees)
via one machine and they will be equally valid for all hosts at once.

Regards,
--
Ivan