Freedom Environment
(F.E. = effie) Subsystems

One Install for Many Users

FE Home page > FE Downloads page > This One-Install-for-Many-Users page

Background :

If you have used any of the download pages for the FE subsystems, you will have noticed that each of the subsystems is installed, for a given user, in a subdirectory of $HOME/apps :

  • $HOME/apps/feXpg_yyyymmmdd
  • $HOME/apps/feAppMenus_yyyymmmdd
  • $HOME/apps/feHandyTools_yyyymmmdd
  • $HOME/apps/bin

    ('feNautilusScripts' is an exception. It ends up in a different home directory from '$HOME/apps'.)

This page describes how to move these files into a 'central' directory location so that one copy can serve many users.

    (The install technique for 'feNautilusScripts' [one-copy-for-many-users] is outlined in a section near the bottom of this page. The technique is different from the technique for 'xpg', 'feAppMenus', and 'feHandyTools' because the scripts need to be put in the '$HOME/.gnome2/nautilus-scripts' directory of each user.

    Rather than putting a physical copy of all the 'feNautilusScripts' files in the home directory of each user, one can make a link between a user directory and a 'central' copy of the scripts --- that is, make a link between '$HOME/.gnome2/nautilus-scripts' and a central copy of 'feNautilusScripts'. )

The '$HOME/apps/bin' directory is used to hold some 'soft-links' to the main startup scripts in the other three subsystem directories. You can use those soft-link filenames to setup desktop-icons and command-aliases to run the main scripts of the subsystems.

The fully-qualified filenames of the 'soft-links' do not contain the '_yyyymmmdd' release identifiers --- that is, the 'soft-link' full-filenames are the same for any release.

After installation of a new release, use of the 'soft-links' allows any desktop-icons or command-aliases to remain functional. That is, there is no need to change script names in icon Properties panels nor change names in command aliases, after installation of a new release.

It is pointed out on the FE downloads pages (and in the subsystem documentation help files and subsystem overview/description web pages --- and in various entries on this site's NEWS page) that each subsystem can be relocated (moved or renamed) to a directory other than '$HOME/apps'.

Hence if a user preferred using the name 'Applications', say, instead of 'apps', he/she could move the subsystems (actually, simply rename 'apps' to 'Applications'), resulting in :

  • $HOME/Applications/feXpg
  • $HOME/Applications/feAppMenus
  • $HOME/Applications/feHandyTools
  • $HOME/Applications/bin

The only change that may have to be made, underneath these directories, is to change the several 'soft-links' in the new '$HOME/Applications/bin' directory.

The only condition on each subsystem (for purposes of the move procedure described here) is that the subdirectory structure of each subsystem needs to be unchanged --- and the subdirectory names and file names need to be unchanged.

There is only one other directory, besides '$HOME/apps', in which FE subsystem files are installed :

  • $HOME/.freedomenv

The subdirectories of '$HOME/.freedomenv' are

  • $HOME/.freedomenv/common
  • $HOME/.freedomenv/feXpg
  • $HOME/.freedomenv/feAppMenus
  • $HOME/.freedomenv/feHandyTools

The main one of these FE user subdirectories is 'common'. It contains two 'include' scripts

  • set_FEDIR.shi
  • set_feDIR.tki

These two scripts are used by each of the 3 subsystems (feXpg, feAppMenus, feHandyTools) --- in any of the many shell-scripts and Tcl-Tk-scripts in these subsystems --- to determine the install directory in which the calling script lies. That install directory name can then be used to locate the various utility scripts that are used in the FE subsystem scripts.

Each of the FE subsystems counts on being able to find the two include scripts in $HOME/.freedomenv --- in order to use those include scripts to determine the install directory of the subsystem. Since we want to be able to move the FE install directories to a new location/name, we have to count on a 'constant' location that we can go to in order to get the appropriate install directory name. '$HOME/.freedomenv' is that 'constant' location. In particular, '$HOME/.freedomenv/common' is that location.

The other 3 directories

  • $HOME/.freedomenv/feXpg
  • $HOME/.freedomenv/feAppMenus
  • $HOME/.freedomenv/feHandyTools

are not really used by the subsystem programs. These 3 directories simply hold backup copies of the 2 include scripts. In the future, they could be used to hold 'subsystem-unique' code that might be needed by the corresponding subsystem. However, there is no apparent need at this time (mid 2011) to store 'subsystem-unique' code in these several subsystem subdirectories.

With this background, now we are ready to show how to make a single FE installation to serve multiple users (userids).

One FE copy for multiple users :

Given the introduction above, let us now say we want to move a copy of these FE subsystems to a single directory location to serve many users from one copy of the FE subsystem files.

Typically, in this case, there is a person with 'root' authority for the host computers involved. That person can set up appropriate directories on the servers and/or workstations involved.

There are a couple of typical scenarios :

  1. You have a central file server from which you serve out applications. You put the applications in a single directory --- say '/apps' --- and that directory is mounted to a multitude of workstations, typically using the same directory name --- '/apps'.

    The user home directories could be located on a central server --- under '/home' say --- and '/home' could be mounted to the multitude of workstations. Or the user home directories could be local to each workstation --- typically with one user (home directory) per workstation.

    Each user logs into his/her workstation to use apps.

    OR ...

  2. You have a workstation that is used by multiple people (multiple userids) --- for example, a classroom or a library with one workstation, and, at different times or different days, different users will use the workstation and the FE subsystems.

    There could even be simultaneous users of the workstation, logging in to the workstation via separate terminals, such as diskless terminals.

    You put some applications, such as the FE subsystem directories, in a single directory --- say /apps --- and that directory is located on disk storage at the workstation. (An administrator typically does this to protect the apps from being wiped out during an operating system upgrade.)

    On the workstation disk, there is a home directory for each userid that might use the workstation.

    Each user logs into the 'common' workstation to use apps.

    In many scenarios like this, multiple users may be assigned to use the same userid.

Now let us say the 'system administrator' or 'application administrator' has downloaded the several FE subsystems and installed them in his/her home directory. (It only takes a minute or two per subsystem.)

Let us say the administrator has a home directory, $HOME = '/home/appadm', where 'appadm' is the userid the administrator uses for these kinds of installation activities.

    NOTE1: The only times the app-administrator needs root authority is to make the '/apps' directory and any '/home' subdirectories needed --- and to set the ownership of those directories to 'appadm' or a user's userid.

    NOTE2: Using a generic userid such as 'appadm' is better than using an individual userid, like a userid based on initials of a individuals name. That way, if the app-admin gets hit by a bus, someone else can take over application administration without having to copy-rename-etc. lots of home directory files and change ownership of, typically, thousands of files and directories of applications.

Here is an outline of the steps, for the app-administrator to perform, from this point on.

Step 1 :       (make the /apps directories)

On the server (scenario 1) or workstation (scenario 2), the administrator, as 'root', makes a '/apps' directory if one did not already exist. Then make the owner of '/apps' the userid 'appadm'.

Then, as 'appadm', the FE subsystem directories are copied or moved (say, dragged-and-dropped in a GUI desktop environment) from '/home/appadm' to '/apps' :


      NOTE: Depending on how the 'soft-links' under $HOME/apps/bin were done, the 'soft-links' may have to be re-done. If necessary, remove the 'soft-links' from '/apps/bin' and, as user 'appsadm' (the owner of these apps directories), do 'soft-link' commands like the following:

        ln -s /apps/feXpg_yyyymmmdd/scripts/xpg         /apps/bin/xpg
        ln -s /apps/feXpg_yyyymmmdd/scripts/fefontsel   /apps/bin/fefontsel
        ln -s /apps/feXpg_yyyymmmdd/scripts/fecolorsel  /apps/bin/fecolorsel
        ln -s /apps/feAppMenus_yyyymmmdd/scripts/feAppMenus      /apps/bin/feAppMenus
        ln -s /apps/feHandyTools_yyyymmmdd/scripts/feHandyTools  /apps/bin/feHandyTools

      You could do some subset of these several commands (depending on which FE subsystems you are installing) --- and alter the following Step3 'finishing' instructions accordingly.

Step 2 :       (provide two include files to users)

Make the '.freedomenv/common' directory for each user and copy the two include scripts (mentioned above in the introduction) into each one.

    (Alternatively, give instructions to each user on how to do this. Or provide a script that the users can use to do this.)

If you do the copy for each user, here is an example of the several commands you, as 'root', could do for userid 'abc'. (Of course, you could put all this in a script.)

        mkdir /home/$USERID/.freedomenv
        chown $USERID /home/$USERID/.freedomenv
        chmod 755 /home/$USERID/.freedomenv     (if needed)
        mkdir /home/$USERID/.freedomenv/common
        chown $USERID /home/$USERID/.freedomenv/common
        chmod 755 /home/$USERID/.freedomenv/common     (if needed)
        cp  /home/appadm/.freedomenv/common/set_*   /home/$USERID/.freedomenv/common/

where, of course, $USERID represents the userid.

If the home directories were on a central server, you could put a list of userids in the script and add a 'for' loop to do these commands for each userid. Then you could execute the script just once and be done with this step.

    NOTE1: Rather than making physical copies of the two include files in each user's home directory, the administrator, as 'root', can make a link from a central copy of each of these two files. The '.shi' file is in an 'includes_sh' directory and the '.tki' file is in an 'includes_tk' directory, for each of the FE subsystems.

    Say we use the two files in the 'feXpg' central installation. Then for each user we can do the commands like those shown above, but in place of the 'cp' (copy) command, use the following two 'soft-link' commands :

     ln -s /apps/appadm/feXpg/includes_sh/set_FEDIR.shi  /home/$USERID/.freedomenv/common/set_FEDIR.shi
     ln -s /apps/appadm/feXpg/includes_tk/set_feDIR.tki  /home/$USERID/.freedomenv/common/set_feDIR.tki

    NOTE2: It is around this step that we will need to have the '/apps' directory on the server mounted to the local workstations. That is generally done via an '/etc/fstab' file on the local workstation. However, the mount technique is quite dependent on the flavor of Linux/Unix operating system. The experienced system administrator will know how to do this. In any case, consult the documentation, forums, wikis, distro web sites, etc. for your particular operating system(s).

Step 3 :       (provide a guide to users)

Give instructions to the users on how they can make desktop-icons (or command-aliases) for the main FE subsystem startup scripts, using one or more of the startup script names:

  • /apps/bin/xpg
  • /apps/bin/fefontsel
  • /apps/bin/fecolorsel
  • /apps/bin/feAppMenus
  • /apps/bin/feHandyTools

The instructions would vary depending on the desktop environment used --- Gnome, KDE, Xfe, LXDE, or whatever.

For a file manager like Nautilus, you could also give instructions to users on how to add a utility like 'xpg' to the 'Open with' options of the file manager. See the bottom of the 'xpg' download page for examples of such instructions.

You could paraphrase instructions that are outlined at the bottom of the FE download web pages, on this site, for each of the FE subsystems.

At this point, the users should be able to invoke the respective startup scripts with icons or aliases (or 'Open with' options) that they have defined.

So now we have our first 'central' installation of the FE subsystems 'xpg', 'feAppMenus', and 'feHandyTools'.

    NOTE: 'feHandyTools' in mid-2011 is a very preliminary release --- mainly to provide a few Tcl-Tk 'PlotQuik' utilities. It would be better to wait until a more complete release of 'feHandyTools' is available, say in late 2011, before making a 'central' installation out of 'feHandyTools'.

Note that there are significant advantages to having apps in a single subdirectory of a top-level directory like '/apps' --- the subdirectory being named according to the application, rather than having the files of an application scattered through system directories like /usr/bin, /usr/share, /usr/lib, /lib, and /var.

For example, you could have '/apps' in a disk partition separate from the root partition (or partitions) that contain the system directories like /bin, /boot, /dev, /etc, /lib, /sbin, /usr, and /var.

Then when the system administrator does an operating system upgrade, which typically wipes out and rebuilds the contents of directories like /usr and /etc, the '/apps' directories can be protected from being wiped out by the upgrade (say, by unmounting '/apps' before the upgrade --- just for good measure --- you can't tell what the OS install might do to the file system).

If the apps had been scattered through the system directories and subdirectories, it would have been almost impossible to avoid having to re-install the apps after the operating system upgrade. (The need to re-perform any local tailoring that was done to the apps is also avoided. Often those tailoring steps are not recorded by installers/maintainers, so it can be a time-consuming, painful-in-many-ways process to get the apps back to how they were.)

'Central' Install of 'feNautilusScripts' :

As was mentioned at the start of this page, the install technique for 'feNautilusScripts' [ one copy for many users ] is different from the technique for the other FE subsytems ('xpg', 'feAppMenus', 'feHandyTools'). The latter subsystems, by default, install in a subdirectory of the '$HOME/apps' directory.

The technique for 'feNautilusScripts' is different because the Nautilus scripts need to be available from the '$HOME/.gnome2/nautilus-scripts' directory of each user, rather than from a 'central' directory like '/apps'. This is because that is where Nautilus looks for the scripts --- at least, the 2.x versions of Nautilus look there.

The installer (the 'app administrator') could copy the 'feNautilusScripts' file structure to each user's '$HOME/.gnome2/nautilus-scripts' directory.

But the easier method (and more disk-space efficient method --- and a better method to facilitate easier updates or fixes or local-tailoring) is to make a link in each such user directory to a 'central' copy of the scripts. For example, after putting the 'feNautilusScripts' files in '/apps/feNautilusScripts' :

   If 'nautilus-scripts' of '$HOME/.gnome2' is empty, remove it with 'rmdir' and do

      ln  -s  /apps/feNautilusScripts  $HOME/.gnome2/nautilus-scripts

   Alternatively, do

      ln  -s  /apps/feNautilusScripts  $HOME/.gnome2/nautilus-scripts/feNautilusScripts

Here are the details of such a 'link-to-a-central-copy' install.

    In the following instructions, let's use 'we' instead of 'you'. I'm right there with you.

First, let us imagine being in a scenario like one of the two scenarios mentioned above --- (1) a central 'apps' server, or (2) a classroom-computer type of setting.

Next, let us say we are system or app administrator with permissions as described above.

Now let us say we have downloaded the 'feNautilusScripts' install file (a self-extracting script), and working under the userid 'appadm', say, we have installed 'feNautilusScripts', which is essentially just a click on the install file.

Now we have the 'feNautilusScripts' files installed under

       $HOME/.gnome2/nautilus-scripts   where   $HOME = /home/appsadm

Here are the remaining steps, corresponding to the several steps outlined above for the other FE subsystems.

STEP 1:       (provide the central '/apps' Nautilus scripts directory to users)

Now let us say that we have made the '/apps' directory, owned by 'appsadm', as above at STEP 1.

Then we drag-and-drop '$HOME/.gnome2/nautilus-scripts' to '/apps'. Or, if that method is not available, we can use a command like

      mv $HOME/.gnome2/nautilus-scripts /apps

Then, for clarity, we rename '/apps/nautilus-scripts' to '/apps/feNautilusScripts'. If necessary (if a rename via a GUI file manager is out of the question), we can use a command like

      mv /apps/nautilus-scripts /apps/feNautilusScripts

Now that the '/apps/feNautilusScripts' directory is in place, for each user, we can, as 'root', issue the command

      ln  -s  /apps/feNautilusScripts   $HOME/.gnome2/nautilus-scripts

                  if the 'nautilus-scripts' directory was non-existent or
                  empty and removed

   Alternatively, do

      ln  -s  /apps/feNautilusScripts  $HOME/.gnome2/nautilus-scripts/feNautilusScripts

where $HOME is '/home/abc' for user 'abc'. (In the app-server environment, this is easy to do if the home directories are located on the server.)

Of course, if we have a lot of users, we can prepare a script to do the 'ln -s' command for each user --- including commands to check existence of the 'natuilus-scripts' directory, etc. We have some choices as to how to do the logic here.

The script could have the above command(s) in the script for each user. OR, one could have a list of users in the script, and a 'for' loop to issue the command(s) for each userid.

STEP2 :       (provide the shell include file to users)

Now there is one more file we have to provide to each user. When we installed 'feNautilusScripts' as user 'appadm', there was a file created, outside of the '$HOME/.gnome2/nautilus-scripts' directory --- namely


We need to provide the same '.shi' (shell include file) to each user, in the user's home directory. So for each user, we have to make the '.freedomenv/feNautilusScripts' subdirectory (if it does not exist already) --- and we need to provide the users with the 'set_DIR_NautilusScripts.shi' file.

Rather than making a copy of the '.shi' file in each user's home directory, we can make a 'soft-link' from a central '.shi' file to the user's home directory.

There is a central copy of the '.shi' file that we can use. So for each user, after making the '.freedomenv/feNautilusScripts' subdirectory, we can perform the command

         ln -s /apps/feNautilusScripts/.set_DIR_NautilusScripts.shi  \

(NOTE: There is a dot (.) in front of the '.shi' filename in the central 'nautilus-scripts' directory. The purpose of the dot is described on the 'feNautilusScripts' download page.)

(The back-slash indicates the command line is continued on the next line. We could write the line this way in a script, such as in the following example.)

Of course, if there are a lot of users, we can make a script (to be run as 'root') which does commands like the following for each user :

        mkdir /home/$USERID/.freedomenv
        chown $USERID /home/$USERID/.freedomenv
        chmod 755 /home/$USERID/.freedomenv     (if needed)
        mkdir /home/$USERID/.freedomenv/feNautilusScripts
        chown $USERID /home/$USERID/.freedomenv/feNautilusScripts
        chmod 755 /home/$USERID/.freedomenv/feNautilusScripts     (if needed)
                     ln -s /apps/feNautilusScripts/.set_DIR_NautilusScripts.shi \

If the home directories were on a central server, we could put a list of userids in the script and add a 'for' loop to do these commands for each userid. Then we could execute the script just once and be done with this step.

If each user's home directory is mounted on his/her workstation, we could execute the script remotely on each workstation, for the appropriate userid(s).

    NOTE: It is around this step that we will need to have the '/apps' directory on the server mounted to the local workstations. That is generally done via an '/etc/fstab' file on the local workstation. However, the mount technique is quite dependent on the flavor of Linux/Unix operating system. The experienced system administrator will know how to do this. In any case, consult the documentation, forums, wikis, distro web sites, etc. for your particular operating system(s).

STEP3 :       (provide a guide to users)

At this point, the users should be able to navigate to any directory, using the Nautilus file manager, navigating the file system made available to them, and invoke the 'centrally installed' FE Nautilus scripts --- by right-clicking on a file in a directory and using the 'Scripts     >' option in the menu that pops up.

We could provide some guidelines to the user in a 'handout'. We could use some selected text from the FE download page for 'feNautilusScripts' to help make such a handout or online guide.

So now we have our first 'central' installation of 'feNautilusScripts'.

When a new release of 'feNautilusScripts' needs to be installed, we can use a technique similar to that described at the bottom of the 'feNautilusScripts' download page, on this site.

Namely, we can remove (or backup) the directories and files under '/apps/feNautilusScripts' and then just proceed through the steps above to install the new 'feNautilusScripts' in the home directory of the 'application administrator', and then move the files to the '/apps/feNautilusScripts' directory.

Bottom of the Freedom Environment Subsystems --- One Install for Many Users page.

To return to a previously visited web page location, click on the
Back button of your web browser a sufficient number of times.
OR, use the History-list option of your web browser.
OR ...

< Go to Top of Page, above. >
< Go to FE Home page. >

Page created 2011 Aug 03. Changed 2011 Aug 05.