Freedom Environment
(F.E. = effie) Subsystems

One Install for Many Users


Poke me.
Poke off-image to change back.

FE Home page > FE Downloads page >

This One-Install-for-Many-FE-Users page

Background :

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

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

where the '$HOME/apps/bin' directory is used to hold some 'soft links' to start-up scripts of the several FE subsystems.

There is no 'yyyymmmdd' qualifier in the start-up script names --- so any references to these date-independent start-up scripts (such as desktop-icons OR command-aliases) do not need to be changed when a new release is installed.

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

    'feNautilusScripts' is an exception. The scripts for that system need to be under a different home subdirectory --- NOT 'apps' under '$HOME'.

    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 'tkGooies' because the scripts need to be accessed via the

    $HOME/.gnome2/nautilus-scripts

    directory of each user --- or via

    $HOME/.config/caja/scripts

    if users are using the MATE-Caja system instead of Gnome2-Nautilus.

    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'.


As was mentioned above, the '$HOME/apps/bin' directory is used to hold some 'soft-links' to the main startup scripts in the FE subsystem directories.

You can use those soft-link filenames to setup desktop-icons and command-aliases to run the start-up 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 alias files, after installation of a new release.


It is pointed out on the FE Downloads web 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/tkGooies
  • $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 --- to point to scripts in '$HOME/Applications' instead of '$HOME/apps'.

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, for the 'xpg', 'feAppMenus', and 'tkGooies' systems.


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/feXpg
$HOME/.freedomenv/feAppMenus
$HOME/.freedomenv/tkGooies

These FE user subdirectories are meant to contain two 'include' scripts

  • set_FEDIR.shi
  • set_feDIR.tki

where 'shi' is short for 'shell-include' and 'tki' is short for 'Tk-include'.

These two 'include-scripts' can be called in each of the 3 subsystems (feXpg, feAppMenus, tkGooies) --- in any of the 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.

    The content of the 'shell include' file 'set_FEDIR.shi' and the 'Tcl-Tk include' file 'set_feDIR.tki' is some rather elaborate shell and Tcl script code that is meant to be executed in a shell or Tcl-Tk script to determine the install directory of that particular FE system.

    It is left as an option to the installer to replace that code with a single statement that sets an 'FEDIR' or 'feDIR' variable to hold the install directory of the FE system.

    At one time, I considered using a common '$HOME/.freedomenv/common' directory to hold the two 'set_*DIR' include-scripts.

    But, even though the code could be the same for the three 'feXpg', 'feAppMenus', and 'tkGooies' systems, it seemed better to put copies in the 3 separate subdirectories of '$HOME/.freedomenv/'.

    The copies in separate directories allow for backup to each other.

    And, in case there is a logic problem in either of the two 'set_*DIR' include-scripts, the problem could be addressed in one FE subsystem without affecting the other two systems.

    Furthermore, three separate directories ---

    $HOME/.freedomenv/feXpg
    $HOME/.freedomenv/feAppMenus
    $HOME/.freedomenv/tkGooies

    --- allow for the fact that the three systems --- 'feXpg', 'feAppMenus', and 'tkGooies' --- could conceivably be installed in quite different install directories.

    And, if one wanted to hard-code the install directories in the 'set_*DIR' include-scripts, this could be done for the three different FE systems with 3 different 'parent' install directories.

Each of these 3 FE subsystems counts on being able to find the two 'include' scripts in their $HOME/.freedomenv subdirectory --- 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 'unequivocal' location that we can go to in order to get the appropriate install directory name.

The three '$HOME/.freedomenv' subdirectories

$HOME/.freedomenv/feXpg
$HOME/.freedomenv/feAppMenus
$HOME/.freedomenv/tkGooies

offer that 'unequivocal' location (for each user).

In the future, these subdirectories 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 --- other than the two 'set_*DIR' include-scripts.

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 file-server(s) 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 could use a directory, like '/apps', different from operating system directories, like '/usr', in order 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 'shared' workstation to use apps.

    In some 'classroom' scenarios like this, multiple users may be assigned to use the same userid on a workstation.


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 individual's 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 central '/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' :

/home/appadm/apps/feXpg_yyyymmmdd
to
/apps/feXpg_yyyymmmdd

/home/appadm/apps/feAppMenus_yyyymmmdd
to
/apps/feAppMenus_yyyymmmdd

/home/appadm/apps/tkGooies_yyyymmmdd
to
/apps/tkGooies_yyyymmmdd

/home/appadm/apps/bin
to
/apps/bin


    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 'appadm' (the owner of these apps directories).

    Then do 'soft-link' commands like the following --- to the startup scripts:

    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/tkGooies_yyyymmmdd/scripts/tkGooies_start.sh   \
    /apps/bin/tkGooies_start.sh

      NOTE:
      Each of the files on the left of these commands are shell scripts that startup the application. On the right are the new 'soft links'. The backslash indicates a continuation to the next line.

    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 pairs of 'include' files to users)

Make the '.freedomenv/feXpg' (or '.freedomenv/feAppMenus' or '.freedomenv/tkGooies') 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.)


USERID='abc'

mkdir /home/$USERID/.freedomenv
chown $USERID /home/$USERID/.freedomenv
chmod 755 /home/$USERID/.freedomenv     [if needed]

cp  /home/appadm/.freedomenv/feXpg/set_*  \
    /home/$USERID/.freedomenv/feXpg/

cp  /home/appadm/.freedomenv/feAppMenus/set_*  \
    /home/$USERID/.freedomenv/feAppMenus/

cp  /home/appadm/.freedomenv/tkGooies/set_*  \
    /home/$USERID/.freedomenv/tkGooies/

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.

    Let us use the two files in the 'feXpg' central installation as an example.

    Then for each user we can do commands like those shown above, but instead of the 'cp' (copy) command, use the following two 'soft-link' commands :

    ln   -s   /apps/feXpg_yyyymmmdd/includes_sh/set_FEDIR.shi   \
    /home/$USERID/.freedomenv/feXpg/set_FEDIR.shi

    ln   -s   /apps/feXpg_yyyymmmdd/includes_tk/set_feDIR.tki   \
    /home/$USERID/.freedomenv/feXpg/set_feDIR.tki

      NOTE2:
      It is around this step that we may need to have the '/apps' directory on a file-server mounted to the local workstations.

      That is generally done via an '/etc/fstab' file on the local workstation --- and using NFS (Network File System).

      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/tkGooies_start.sh

    (The '_start.sh' suffix was used for the tkGooies startup script to make it clear that the file is a startup shell script, and NOT a directory or a 'binary' executable.

    That probably should have been done for the other startup scripts, but, at the time, I was trying to use the minimal-file-naming that is typical in Unix/Linux systems.)

The instructions would vary depending on the desktop environment used --- Gnome, MATE, 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 'tkGooies'.

    NOTE:
    'tkGooies' in mid-2017 is/was a very preliminary release. Utilities such as some Tcl-Tk 'PlotQuik' utilities were still 'to-be-refined'. Hopefully, 'tkGooies' will be a much more 'mature' system by the 2022 to 2025 timeframe.

Note that there are significant advantages to having essentially all the files of an app under a single subdirectory of a top-level directory like '/apps' --- example: /apps/feXpg_yyyymmmdd --- 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 --- because you can't tell what the OS install might do to the entire 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', 'tkGooies').

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 the Nautilus file-manager program 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 the 'nautilus-scripts' sub-directory of directory '$HOME/.gnome2' is empty, remove it with 'rmdir' and re-create it as a 'soft-link' with the command

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

Alternatively, since there may be other Nautilus scripts to be put in the '$HOME/.gnome2/nautilus-scripts' directory, you might wish to keep the 'feNautilusScripts' in their own subdirectory --- so keep the 'nautilus-scripts' subdirectory and do

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


Let's go through the 'feNautilusScripts' install step by step.

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/appadm .

Here are the remaining steps, to make the 'feNautilusScripts' available to multiple users.


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

Now let us say that we have made the '/apps' directory, owned by 'appadm', as above at STEP 1 for the other FE systems.

Then we drag-and-drop '$HOME/.gnome2/nautilus-scripts' to '/apps'.

Or, if that GUI method is not available, we can use a command like

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

or

cp -R   $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

$HOME/.freedomenv/feNautilusScripts/set_DIR_NautilusScripts.shi

where $HOME = /home/appdam .

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   \
$HOME/.freedomenv/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 :


USERID='abc'

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 \
/home/$USERID/.freedomenv/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 located on his/her workstation disk (not on a 'central' file-server), we could execute the script remotely on each workstation, for the appropriate userid(s).

    NOTE:
    It is around this step that we may 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 --- and using NFS (Network File System).

    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.

One could provide some guidelines to the user in a 'handout'.

One could use some selected text from the FE download page for 'feNautilusScripts' to help make such a handout or online guide.


Conclusion:

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 move 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.


If one were dealing with the MATE desktop environment with the Caja file-manager (instead of the Gnome2 desktop environment with the Nautilus file-manager), one could adapt the above technique by noting that the 'feNautilusScripts' directories and files are to be in user directory

$HOME/.config/caja/scripts/

instead of user directory

$HOME/.gnome2/nautilus-scripts/

Bottom of this
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 history:

Page was created 2011 Aug 03.

Page was changed 2011 Aug 05.

Page was changed 2018 Aug 07.
(Added css and javascript to try to handle text-size for smartphones, esp. in portrait orientation.)

Page was changed 2019 Jun 13.
(Specified image widths in percents to size the images according to width of the browser window.)