Workgroups were added to Fermi Linux to address the problem that "a single install style" does not fit in an environment with many different groups each with their own needs. The workgroup modifications allow for customization of the install in the areas of
I have included a few examples of things that have been requested in the past and are NOT available because they violate these rules. If we find that you are trying to include items which violate the following rules you will be contacted so that you can remove them from your workgroup. These items include files, RPMS, tar files. The reason we have these rules is because the install area and cdroms of the release are open to the world. So the items available have to live within these rules.
Some definitions and conventions used in this documentation
All of the directories and files indicated below are copied automatically to /etc/<workgroup> < name=""> during the install. The tree structure below is preserved. This allows for your "workgroup custom install shell script" to be able to access these files if needed. The following describes the contents of the CVS Fermi workgroup area. See the CVS for Workgroups document for information on using this area. This area is also available via ftp from ftp://linux.fnal.gov/linux/lts304/i386/sites/Fermi/workgroups/ . There is one directory for each workgroup and within this directory are directories and files. These are descibed below. The example links below point to the "Farms" workgroup.
What is this directory used for?
Locations for RPMS that are specific to the workgroup.
When are these rpms installed?
These RPMS are installed at the end of the installation during the "Post Install " phase. This is after the installation has installed all of the RPMS that were selected based on your workgroup entry in "/SL/base/comps.xml" and created all of the installations configuration files. It is also before the scripts are run that are located in "scripts/".
What rpm options are used to install these rpms?
When these RPMS are installed they are installed with the rpm option "--force". It is up to the workgroup maintainer that these RPMS work as desired. If depedencies are needed then the workgroup maintainers has to make sure that those depedencies are met.
How must the RPMS files be named?
The RPMS must have a suffix of ".rpm".
What hardware architecture do these rpms have to be?
These need to be RPMS for the architeture that is appropropriate for your hardware. The most common is i386. This architecture works for all x86 Intel and AMD x86 architectures.
Where do these RPMS come from?
These RPMS are provided by you. They should NOT be RPMS located in " /SL/RPMS " as those RPMS are installed via the "comps" file. So if you want one of the RPMS from "/SL/RPMS" then put it in your "comps" file. Occasionally I will make RPMS available that are useful for a specific purpose. Beware of dependencies when you get rpms from other sources. You should also note that not all versions of RPM are compatible with each other. There are many cases where a RPMS that is created with a newer version of RPM cannot be installed with a lower version of RPM. Test and test and test some more. You should first test on a normal system and make sure the rpm works first. Then move it to your workgroup area.
Some places to get RPMS are
Scientific Linux contrib RPMS
Dag Wiers Repository
Are there any limitations about the RPM size(s)?
Large RPMS can cause problems because of a shortage of space on the install cdroms. If cdrom space becomes a issue I reserve the right to not put these RPMS on the cdroms. They are still available for network installs. Note that network installs are only available on-site at Fermi.
Does yum use this directory?
Yum searches for RPMS that exist in this directory. They are installed if they have not been installed or are a newer version than one that already exists. Of course this is only successful if yum does run, and hasn't been turned off.
What is this directory used for?
You can put whatever you want in here as long as they obey the above rules. A common use for this area is to hold config files which you can then reference in your workgroup shell script's.
Are there any limitations about the size of this area?
The Fermi Linux maintainers reserve the right to remove large items from the cdrom if space gets tight. They will remain on the install server.
What is this directory used for?
If a file called before.rpms.sh, or after.rpms.sh exists and is executable in this directory it will be executed during the install or upgrade.
If a file called before.rpms.yum.sh, or after.rpms.yum.sh exists and is executable in this directory it will be executed during a "yum install" or "yum update".
When is it run?
before.rpms.sh: Before all of the RPMS in /RPMS/ have been installed. This occurs during the "post install" part of the installation or upgrade.
after.rpms.sh: After all of the RPMS in /RPMS/ have been installed. This occurs during the "post install" part of the installation or upgrade.
before.rpms.yum.sh: Before all of the RPMS in /RPMS/ have been installed. This occurs during the %post part of the yum install or update.
after.rpms.yum.sh: After all of the RPMS in /RPMS/ have been installed. This occurs during the %post part of the yum install or update.
How is it run?
This script is run "chrooted" to the new install area. It is good practice to specify full path names for executables as the $PATH variable may not be set as expected. This must be a "bash" script. It has access to the new installed area. It does NOT have access to the cdrom. It does NOT have access to the NFS install area. It is NOT interactive so it cannot ask questions. Please test on a normal system as much as possible as it is alot easier testing then.
Any Other things run from here?
If a file called "after.rpms.nochroot.sh" exists and is "executable" in this directory it will be run during the install after all of the RPMS in /RPMS/ have been installed. This script is run in the context of the installer. The install medium location is available in $SOURCE. The new install area is in $CHROOT. This should not be needed much. It was originally provided as a method to access the cdrom during the install. It must be a bash script.
How do I test these scripts?
It is best to test them on a already installed system vs during the install as it is much easier to test. To test during a install you can go to alt-f2 to get to a shell. You have to do this after you see the "Post Installation message" otherwise your files will not have been copied yet. You will be in the non chrooted area. The newly installed area is mounted on /mnt/sysimage . You can chroot to this area and will this be in the same environement as the "after.rpms.sh" script is in. If your do not chroot it the environment of the "after.rpms.nochroot.sh" script. In /mnt/sysimage/ or / depending on if you are chrooted nor not your will see "/etc/workgroups". This file contains the name of your workgroup. You can cd to "/etc/<workgroup> to get to your workgroup files that were copied over during the install during the "post install" time. You can test from here. Your scripts are in scripts/, your RPMS are in RPMS/. Depending on when you are looking your scripts should have already been executed and your RPMS installed. There are some log files in /tmp and in /etc/<workgroup> that can be used to help with debugging.
What is this directory used for?
This is an area where workgroup maintainers may document their workgroup. Documentation is not mandatory, but it is useful.
Is there anything important about the workgroup.html web page?
This is the page that the main workgroup documentation points to. As a maintainer you may edit this file as much as you want, but we would appreciate it if you do not remove the file or the link pointing to it will be broken.
What is this directory used for?
It holds files used by CVS. Please do not change the files in here as it may cause CVS to not work properly.
This file defines what "Groups and RPM packages" are installed during the Scientific Linux packages installation time. This file is the workgroup portion of the "/SL/base/comps.xml" file which is used during the install select what RPMS are installed from the RPMS available in "/SL/RPMS/". Since this file is a subset of the file that is really used it has to be merged with the other "comps.xml" files from the other workgroups and with the Scientific Linux defined portion. The merging of these "comps.xml" files will be done manually by the linux-workgroups@fnal.gov mailing list owners. The mailing list owners will be notified by the standard CVS change mail when this file is modified. Because this is a manual process it will not be done when you receive this mail. You will get mail from one of the linux-workgroups@fnal.gov mailing list owners that it has been incorporated. We are using a manual process for this as this is a key file and if there are errors it could cause all installs to fail.
Starting with Fermi Linux 9.0.1, the comps file was changed to an XML format. Because of that change we have split the documentation for editing the Comps file into two sections.
Comps.xml file for Fermi Linux, versions 9.0.x and above
Kerberos
You will need to double check to make sure the group fermi-kerberos is in your group area.
AFS
If you include openafs-client in your group area (not just the package area) then you should get everything needed for openafs.
UPS/UPD bootstrap
There are 2 parts needed for the UPS/UPD bootstrap. First you need to include "upsupdbootstrap" in your " comps" file. This RPM places the ups/upd tar files into /var/tmp. Then you need to get either "upsupdbootstrap-local*.rpm" or "upsupdbootstrap-generic*.rpm" from "/RedHat/RPMS/" and place it in your workgroups " RPMS/" directory. These RPMS install the tar file in /var/tmp which the upsupdbootstrap RPMS just installed. The "local" version places the UPS/UPD bootstrap software in "/local" and the "generic" version puts it in "/fnal".