How to install cjob on a separate linux computer
...that is, on a linux box which is not the ebpg console.
Back to the list of ebpg administration tips
Cjob, the ebpg exposure job editor, can be installed on a RHEL box which is not the e-beam console. This allows e-beam users to set up jobs on the same computer used for pattern conversion with Beamer. Students can have private accounts on the remote server, and can have the exposure jobs ready to run as soon as they arrive.
This installation procedure has been tested on RHEL servers only. The RHEL version does not have to match that of the ebpg console, but that would make it a little easier when trying to find the right library (.so) files. You can probably use other linux distros, but we have never tried it.
Let's use the name ebpg for the the ebpg console, and let's call the other linux box myserver. You should dream up better names for your own computers.
Cjob can run on a separate linux box, but it needs to access alignment mark definitions and beam archive files on the ebpg. It is possible to
mount the ebpg as a remote drive on the linux box, but that kind of setup is very unreliable, and the booting sequence is annoying. Instead, we will create an account "pg" on the linux box that will be synchronized daily with the "pg" account on the ebpg. Then cjob can look in the local /home/pg directory for all the stuff it needs.
The root user on myserver needs to log into the ebpg (daily) to synchronize the files. First we set up some encryption keys so that 'root' on myserver can automatically log into the ebpg's 'pg' account.
-
On myserver, log in as root, or type "su" to become root Open another terminal window. You will need to go back and forth
between pg@ebpg and root@myserver.
-
Let's see if pg@ebpg already has public/private keys. Pop over to the pg@ebpg terminal window, then
cd
cd .ssh
lsDo you see id.rsa and id_rsa.pub? If so, we can skip the next step.
-
Skip this if pg@ebpg already has keys (see step above). As the pg user on ebpg, generate keys:
cd
ssh-keygen
... (press [Enter] three times)
-
Let's see if root@myserver already has keys. Log onto myserver as root, then
cd
cd .ssh
lsDo you see id.rsa and id_rsa.pub? If so, we can skip the next step.
-
Skip this if root@myserver already has keys (see step above). As the root on myserver,
cd
ssh-keygen
... (press [Enter] three times)
-
Who needs which key file? This is so confusing. I always get this backwards, but I promise you this is the right way: Copy the the public key from root@myserver to pg@ebpg. As root@myserver,
cd
cd .ssh
scp id_rsa.pub pg@ebpg:.ssh/foo -
Go back to pg@ebpg and append this key (now in the file foo) to the list of authorized_keys. As pg@ebpg,
cd
cd .ssh
ls ... (you should see foo there)
cat foo >> authorized_keysThe >> bit is very important. It means 'append'.
If you type > instead, then you'll wipe out all other entries.
-
Download and unpack the ebpg funpak to find the folder "cjob_build", which contains the scripts needed for this installation. You can unpack the ebpg funpak with "tar xvf ebpg_funpak*.tar".
On myserver as root, use "cd" to move to the cjob_build folder, then execute
fix_ssh_permissions.sh
This script contains:
cd
find .ssh/ -type f -exec chmod 600 {} \;
find .ssh/ -type d -exec chmod 700 {} \;
find .ssh/ -type f -name "*.pub" -exec chmod 644 {} \; -
Run that same script (see previous step) as pg on ebpg
-
Check that root@myserver can ssh to pg@ebpg, by having root@myserver execute
ssh pg@ebpg
If you are asked for a password, then the key swap has failed. Drat. I always get this backwards. You might need to go back a few steps to make sure you sent the right key file to the right place. IF you do this key swap backwards, then pg@ebpg will be able to log in to root@myserver without a password. That's not good.
You have to get this right. If the login does not work without a password, then don't bother doing the rest!
Assuming that this step was successful, give yourself a pat on the back, because that was the hard part.
-
All of the files on ebpg under /home/beams should be owned by the user "beams". Sometimes the ownership gets goofed up if you install an update as root, so let's check the file ownership (as root@ebpg) using
cd /home/beams
ls -lThis list should show that the files are owned by "beams" in the group "raith", like this:
drwxr-x---. 27 beams raith 4096 Nov 18 2021 v09_14d
drwxr-x---. 27 beams raith 4096 Dec 30 2021 v09_14fIf the ownership is wrong, then fix it with
cd /home/beams
chown beams:raith * -R
cd /home/pg
chown pg:raith * -R -
root on myserver needs to define a crapload of symbols in /etc/bashrc. You probably already downloaded the ebpg funpak from here, and hopefully you extracted cjob_stuff.tar from the funpak. Naturally you must unpack cjob_stuff.tar with the command "tar xvf cjob_stuff.tar". Now is the time to append "append_this_to_bashrc" to /etc/bashrc. Move that file to the ebpg (you have to figure that out) then append it to /etc/bashrc like this:
su (become root@myserver) cd /home/pg (or wherever you put it) cat append_this_to_bashrc >> /etc/bashrc (>> is important!) gedit /etc/bashrc (you need to change a few lines) Search for the line containing "SYSADMIN" and change the email address to something appropriate. This person will get daily notices confirming that the server is updating itself.
Search for the line containing "PG_MACHID" and enter your own machine serial number. It appears twice, for some reason:
export PG_MACHID="A264" # change these
declare -x PG_MACHID="A264" -
Create the user "pg" on myserver and open up the file permissions:
useradd pg
chmod a+rw /home/pg
chmod a+rx /home/pg -R -
As root on myserver, put the synchronization script into /etc/cron.daily. The file sync_ebpg.sh is in the zip archive you downloaded. Note that "ebpg" will have to be replaced with your local name, eg ebpg.potluck.edu.
Copy sync_ebpg.sh and time_stamp.sh to /etc/cron.daily somehow, then edit the script, inserting the correct name of your ebpg. Make sure the script is executable:
cd /etc/cron.daily
chmod a+x *
gedit sync_ebpg.sh -
As root on myserver, run this script
cd /etc/cron.daily
./sync_ebpg.shThat worked - right? If it failed, you have to figure out why. This sync command will take a long time at first. Next time, it will be very fast because very few of the files will change. Notice that your server is now a handy backup for the ebpg.
-
Try running cjob by typing "cjob". First make sure the symbols are defined:
. /etc/bashrc # "dot space" means do this in the current window, not in a new shell which cjob # we hope these commands are in the PATH which gpftime Older versions of these instructions neglected to update the PATH, and so gpftime was missing. Gpftime allows cjob to estimate the exposure time.
Quite often we need some extra library files, because we did not really install cjob with a proper .rpm script. Someday Raith may give us a lovely installation file, but in the meantime we have to copy some down-level library files. These library files are found on the ebpg console computer. Well, you could install down-level packages, but it's easier to find the required files on the ebpg.
First try
cjob
If you get messages about missing libraries, then go to the ebpg and find them. Typically you will need
libpng12.so.*
libtiff.so.*On the ebpg, find the file you need with (for example)
locate libpng12
The full name is not necessary. The 'locate' command should tell you that the libpng12 "shared objects" are in
/usr/lib64/libpng12.so.0
/usr/lib64/libpng12.so.0.50.0Use "scp" to copy these to your server:
scp /usr/lib64/libpng12.so.* root@myserver:/usr/lib64/
Try running cjob again. If there are more missing library files, then go through this sequence again.
Even if you have all the required "so" files, cjob may not appear unless the XWindows graphics are rerouted to your local display. Try typing "gedit" to test the XWindows graphics. You might need to pop up a new terminal and log into the server with something like
ssh -Y user@myserver
If cjob crashes without any explanation, then this is usually due to a file permission problem. Cjob gives you no clues at all when it is having trouble opening the archive files. It just dies silently. You can enter
chmod a+rw /home/pg
chmod a+r /home/pg -Rand then try cjob again.
-
Now we have to test cjob as an ordinary user, not as root. We may find more file permission problems. Log into the server with a graphical desktop, then open a terminal window.
cd
which cjob
cjobIf this does not work, try setting the file permissions with
su
chmod a+rw /home/pg
chmod a+rx /home/pg -R
-
If cjob fires up then congratulations! Now you should test cjob to make sure it has a list of beam archives and markers.