{section: Background }
-In a cluster, Condor binaries and configuration files are placed on the head node. Worker nodes access these files via shared file system. Thus, drone rpm is designed to install on these worker nodes.
+In a cluster, HTCondor binaries and configuration files are placed on the head node. Worker nodes access these files via shared file system. Thus, drone rpm is designed to install on these worker nodes.
{section: Design }
-1: The head node will install Condor by using normal RPM with relocate option.
-2: The worker node will install drone rpm which is basically a bunch of scripts that will start Condor from shared file system.
+1: The head node will install HTCondor by using normal RPM with relocate option.
+2: The worker node will install drone rpm which is basically a bunch of scripts that will start HTCondor from shared file system.
3: Condor_master_wrapper is a python script that act like a master but it will copy the master binary to local file system before starting it. It will also update the master if there is change in the share folder.
4: Profile.d script is provided so that necessary environment variables are set (PATH, CONDOR_CONFIG). Manpath is not set because man will be able to find manpages by itself.
{section: Implementation }
{subsection: RPM Installation Behavior }
{subsubsection: pre (pre-install) }
-1: Add 'condor' user/group if not exists
+1: Add 'HTCondor' user/group if not exists
{subsubsection: postinst }
-1: Add Condor service (chkconfig --add)
+1: Add HTCondor service (chkconfig --add)
{subsubsection: preun }
-1: Call init script to stop Condor only if we are removing the last instance of Condor (not include upgrading). If the init script fails, abort the uninstall
-2: Remove Condor service (chkconfig --del)
+1: Call init script to stop HTCondor only if we are removing the last instance of HTCondor (not include upgrading). If the init script fails, abort the uninstall
+2: Remove HTCondor service (chkconfig --del)
{subsubsection: postun }
1: Do nothing
