Operations E-log System

Guidelines For The Use Of This Document

This document provides a general description of the Operations E-log system.

Background

The Operations E-log system (sometimes called the "MCC E-log") runs on the mccelog Linux (formerly Solaris) system. It is also dependent on the Oracle MCCO instance since E-log entries and supporting information are stored in the elog_owner schema of this Oracle instance. An outage of either mccelog or the Oracle MCCO instance will cause an outage of the Operations E-log system. Previously the periodic MCCO Oracle password change required actions that resulted in an outage of this system but this is no longer the case since now the Oracle Wallet facility is used (and code changes to specify the Operations E-log system new Oracle passwords are no longer necessary).

There are two Operations E-log interfaces for making and displaying entries: (1) the web interface, and (2) the "Tcl/Tk" E-log interface. The web interface is now almost exclusively used: Operations E-log Main Web Page. The "Tcl/Tk" E-log interface may be invoked by running the command "runElog" on a machine such as slcsun1.

All development and most E-log administrator actions are performed on mccelog using the "cddev" account. Rare actions such as restarting the Apache web server on mccelog require sudo privilege for an individual account.

Required System Components

The Operations E-log system requires an Apache web server to be running. This web server may be restarted as follows:

  1. Log on to mccelog as yourself and obtain sudo access with a command such as "sudo tcsh".
  2. cd /etc/init.d
  3. ./httpd stop
  4. ./httpd start

The Apache web server includes access to "https" (SSL) security. SCCS annually renewals the SSL security certificate.

SCCS has installed Kerberos 5 libraries for Unix (AFS) username/password authentication.

Oracle client software is required to access the MCCO Oracle instance. Currently this is version 11.1 (/afs/slac.stanford.edu/package/oracle/f/11.1.0/amd64_linux26/11.1.0).

The web interface primarily uses PHP. The PHP module OCI8 is required for PHP to access Oracle.

Besides PHP, Perl is also a key component of the system. Perl must be built with the DBI module to access Oracle.

Oracle Accounts

There are three Operations E-log Oracle accounts: elog_owner, elog_reader, and elog_writer. The elog_owner account owns all of the Operations E-log system Oracle objects. The password for this account is restricted to the E-log administrator. The administrator runs scripts using this account to modify the contents of E-log Oracle tables to perform activities such as adding new E-log users and making new logbooks. Occassionally the administrator uses this account to add new Oracle objects (e.g., tables) in order to support new E-log subsystems created by developers.

The elog_reader and elog_writer Oracle accounts are used by E-log software to obtain access to Oracle objects and perhaps modify their contents (e.g., updating entries or adding table rows). The elog_reader account is restricted to only allow read access to E-log Oracle objects while the elog_writer account also allows modification to Oracle objects.

Operations E-log Oracle Password Change (obsolete)

The "Operations E-log Password Change Procedure" section of the Oracle Password Change document described the procedure that used to be needed to change Oracle passwords for the Operations E-log system. As described in the introductory "Background" section of this document this procedure is no longer needed due to the use of the Oracle Wallet facility.

Web Interface

The Operations E-log system web interface uses PHP, Perl, and some JavaScript. The main location of the production code on mccelog is /www/htdocs/elog/wbin. The E-log entry Unix (AFS) username/password authentication production code is located in /www/htdocs/elog/wsbin.

There are two directories containing php scripts named wbin and wsbin that should be placed in your web server’s document root where they can be accessible via http and https respectively.

The wbin directory contains all scripts necessary for browsing and searching the elog. The wsbin directory contains the scripts for actions requiring authentication such as making/updating an entry or OPS-PR.

Some important PHP files are:

The main development area web interface code is located in /www/htdocs/elog/dev. Developers have their own testing areas in subdirectories of this area (e.g., /www/htdocs/elog/dev/mgibbs). A developer may make changes and perform testing in his/her own development area. When a developer would like to release changes to production the E-log administrator is contacted to make the release. First, the administrator checks the differences for each changed file between the developer's area and the main developmenent area. Small code changes or merges may be required to the changed files in the main development area after the administrator copies the changed files from the developer's area to the main development area. Then the administrator tests changes in the main development area. Next backup copies are made of files to be changed in the production area and the changes are copied to the production area with the file extension "new". Some string replacement changes are usually made to these "new" extension files (usually removing references to "dev_", the prefix of most files in the development area). Finally after requesting permission from the EOIC to make the web interface changes, the administrator copies the "new" extension changed files to the production version and final testing is done by the developer and the administrator. The saved backup copies of the changed files can be restored as the production versions in case the changes need to be backed out.

Important URLs related to development:

Matt Gibb's development area - https://mccelog.slac.stanford.edu/elog/dev/mgibbs/dev_elog.php

Development area -  https://mccelog.slac.stanford.edu/elog/dev/dev_elog.php

The list of logbooks is hard-coded in just two places:

/var/www/htdocs/elog/wbin/create_elog.php

/var/www/htdocs/elog/wbin/elog_create_quick_entry.php. 

The web interface supports the creation of new E-log entries. After a request to make a new E-log entry has been validated, the Perl script logXml.cgi located in /www/htdocs/elog/wbin creates a XML file describing the contents of the new entry (perhaps referencing attachments) by invoking the /mccelog/logxml/bin/modules/logXml_perl_module_src/Jlab/logXml/logXml.pm Perl module. Occassionally this Perl module needs to be modified to recognize new XML tags required to support new features. This Perl module creates the XML file in the /nfs/slac/g/cd/mccelog/logxml/new directory as well as copying any associated attachments to this area.

Processing New E-log Entries

The /mccelog/logxml/bin/elog_loader script is started during the boot process and runs continually (sleeping one second between processing loops) to process new E-log entry files created in the /nfs/slac/g/cd/mccelog/logxml/new directory. It moves new E-log entry XML files and any associated attachment files to the /nfs/slac/g/cd/mccelog/logxml/unproccessed directory. Then the script invokes the /mccelog/logxml/bin/new_elog_1.9.pl Perl script to parse each new E-log entry XML file, validate it, and load the parsed information and any attachments for a successfully processed file into the E-log Oracle schema. A successfully processed file and any associated attachments are also moved into the /nfs/slac/g/cd/mccelog/logxml/processed directory. If a new E-log entry XML file is not successfully processed, it and any associated attachments are moved to the /nfs/slac/g/cd/mccelog/logxml/review directory and the reason for the processing failure is stored in an error file put in the /nfs/slac/g/cd/mccelog/logxml/exception directory. The E-log administrator checks this directory almost daily via the web interface (Other Actions => Pending entries) for cleanup or (rarely) possible action.

E-log Print Queue Mechanism

The Operations E-log print queue mechanism is usually used to create an E-log attachment file (in PNG format) from an image file (usually a Postscript file) in the E-log pool attachments area, /nfs/slac/g/cd/mccelog/logxml/incomplete. Thumbnails of these E-log attachment files in the E-log pool attachments area are displayed on the web interface "make entry" web page for possible inclusion when a user is making an E-log entry.

There are many E-log print queues that may be used to create an E-log attachment file in the E-log pool attachment area: elog_accl, elog_pep, elog_mcc, elog_spps, elog_nlcta, elog_pack, elog_lband, elog_rf, elog_lband, elog_rf, elog_bic, elog_amrf, elog_pcdpse, elog_swlog, elog_tlog, elog_lcls, elog_facet, and elog_spear3. They all perform the same purpose and the only advantage to having many different print queues is that the name of the print queue (without the "elog_" prefix) appears in the name of the thumbnail in the E-log pool attachments area, making it easier to find E-log attachment files. There is also a special elog_rotate print queue which can be used if there is a desire to rotate an E-log attachment file image by 90 degrees.

There are also E-log print queues that may be used to directly make entries in selected logbooks. These E-log print queues and their associated logbooks are: mcc_ent (mcc), lcls_ent (lcls), tlog_ent (tlog), spear3_ent (spear3), and facet_ent (facet). There are also E-log print queues that are similar but rotate attachments by 90 degrees: mcc_entrot, lcls_entrot, tlog_entrot, spear3_entrot, and facet_entrot.

To add an Operations E-log print queue edit the st.make_elog_printq and st.elog_pipe scripts in /mccelog/logxml/bin and then reboot the mccelog system.

All E-log print queues use a similar mechanism. Each E-log print queue has an associated Unix named pipe that is located in the /mccelog/logxml/var directory and print output is directed towards this pipe rather than a printer for a conventional print queue. This Unix pipe and print queue setup can be seen in the script /mccelog/logxml/bin/make_elog_printq.pl, which is invoked by st.make_elog_printq for each E-log print queue. There is an associated process (a Perl script) for each of these Unix named pipes and associated print queues that listens for input from its pipe and processes this input. This includes converting the input (usually a Postscript file) to a PNG format file using the ImageMagick "convert" utility. These E-log print queue Unix named pipe processing processes are started by the /mccelog/logxml/bin/st.elog_pipe script when the mccelog system is booted.

Cronjobs on MCCELOG

There are three cron jobs running under the "cddev" account on the mccelog system: elog_notifier, monitor_elog_loader.pl, and elog_attachment_cleanup_one_day.

The elog_notifier cron job runs every five minutes. The /mccelog/logxml/bin/elog_notifier Bourne shell script invokes the /mccelog/logxml/bin/elog_email_notify.pl Perl script. The purpose of the elog_notifier cron job is to send email notification of a new E-log entry to all email addresses specified in the notification dialog box in the "make entry" E-log web page. It accomplishes this by scanning an E-log Oracle table containing information for recent entries that require email notification. This information was stored during the elog_loader processing of E-log entry XML files.

The monitor_elog_loader.pl cron job also runs every five minutes. This /mccelog/logxml/bin/monitor_elog_loader.pl Perl script checks whether the elog_loader process is running and starts this process if it is not running.

The elog_attachment_cleanup_one_day cron job runs three times per day at eight hour intervals (2 AM, 10 AM, and 6 PM). The /mccelog/logxml/bin/elog_attachment_cleanup_one_day Bash script moves files in the E-log pool attachments area /nfs/slac/g/cd/mccelog/logxml/incomplete that are older than two days to the /nfs/slac/g/cd/mccelog/logxml/save_incomplete area. This action removes thumbnail images of E-log pool attachments from the E-log "make entry" web page that are older than two days to limit the images shown to relatively recent ones. It is extremely rare than a user would take longer than two days to make an E-log entry that uses an E-log pool attachment. If this does occur, a user can contact the E-log administrator to move E-log attachment files from the /nfs/slac/g/cd/mccelog/logxml/save_incomplete area back to the E-log pool attachments area (/nfs/slac/g/cd/mccelog/logxml/incomplete) so that they can be used in making a new entry. This script also removes files in the /nfs/slac/g/cd/mccelog/logxml/save_incomplete area that are older than ten days in order to conserve disk space.

CVS Repository

Modified or new Operations E-log files are committed in the old "SLAC-Controls-Software" CVS repository, where other old "Unix Development Environment" files are stored. That is, where the environment variable CVSROOT is set to /afs/slac/g/cd/soft/cvs. Web interface files are stored in the package/elog/webapp area. Other Operations E-log files (e.g., files in the /mccelog/logxml subdirectories) are stored in the package/elog/script area. The contents of these areas may be viewd by first accessing the SLAC-Controls-Software CVS area URL and then successively select the "package" and "elog" links (and then either the "webapp" or "script" link).

Periodic Cleanup of Review, Exception, New, and Unprocessed Directories

Periodically (e.g., perhaps once or twice per week) the Operations E-log review and exception directories should be checked and files in these directories should then be subsequently deleted. The XML files in the review directory represent Operations E-log entries that were submitted but not processed due to a processing problem. The corresponding files in the exception directory describe the problem encountered during processing. Usually these will be due to either a syntax problem or an attempt to supersede an entry more than once. More rarely there may be files in the new and unprocessed directories that need to be deleted. These files may indicate run-time Oracle row insertion problems. There may also be sqlnet files in these directories created by an Oracle maintenance activity.

To determine whether there are files are in the exception, new, and unprocessed directories which may need to be deleted select "Other Actions => Pending entries" from Operations E-log Main Web Page.

 

If the message "There are no pending entries in the NEW, UNPROCESSED, or EXCEPTION directories" appears on the resulting preview.php web page, no files need to be examined and deleted. If a different message appears, files do need to be examined and deleted.

The most common message besides the "no pending entries" message is one indicating one or more files in the exception area. Below this message are file links indicating the reason for the entry processing problem. However, there also may be messages indicating that there are files in the new and/or unprocessed directories. It is normal that files are put into those directories temporarily during processing but any file in these directories that is older than a couple of minutes should be eventually manually deleted.

/nfs/slac/g/cd/mccelog/logxml/proccessed directory -

After an xml file is successfully committed to database, elog_loader script moves it under "processed" directory, intact and unaltered.

When the logbook was designed to use the database as its back-end storage, there was no experience in the group with using Oracle and a lot of people were concerned about reliability.  Keeping the files available in processed was meant to reassure them.  If the database was unavailable, it would still be possible to read log entries from a web page that pulled them from the processed directory.  But after several years experience where the database never crashed and never lost data people lost that fear and the files in processed really don't serve much purpose.  Sometimes they are useful to look at it if a users believes their log entry didn't go into the database correctly -- you can go look at the original source and debug. 

/nfs/slac/g/cd/mccelog/logxml/new directory -

Programs dump new xml files under $LOADER_DIR/new directory.

/nfs/slac/g/cd/mccelog/logxml/unproccessed directory -

elog_loader moves all files from new into $LOADER_DIR/unprocessed and from there feeds them to new_elog.pl one at a time.

The review, exception, new, and unprocessed directories are:

When you logon to the url and create a quick elog entry, normally you will see following type of processes -

nobody 19185 16252 1 11:48:39 ? 0:00 /usr/perl5/perl-5.16.1/perl /var/www/htdocs/elog/wbin/logXml.cgi

nobody 6843 0.0 0.1 1712 1304 ? S 11:15:15 0:00 sh -c /www/htdocs/elog/bin/afs.pl divekar
cddev 11079 0.1 0.1 4784 3240 ? O 11:15:59 0:00 /usr/perl5/perl-5.16.1/perl /mccelog/logxml/bin/new_elog_1.9.pl --file=20120919

To examine and subsequently delete these files the Operations E-log administrator typically logs onto the mccelog machine using the cddev account:

The Operations E-log administrator should examine files in the above directories before deleting them to monitor the reason for processing problems. These are almost always due to user error in making entries. Therefore almost always these files should be simply deleted after examination.

Weekly Conversion of Physics E-log System Entries to Operations E-log System Entries

This section describes the procedure for the weekly task of converting the previous week's ACCEL, FACET, and LCLS Physics E-log logbook entries to entries in their corresponding Operations E-log logbooks. Physics E-log logbook entries are stored in week directories (1 through 52 or 53) for each year and these week directories are the processing granularity used by the entry conversion Perl script. The week period in these directories is from a Monday through a Sunday. Therefore, the best time to process the previous week's entries is on a Monday morning so that the previous week's entries are converted as soon as possible. However, this may be done later if necessary (e.g., the Operations E-log administrator is on vacation).

The conversion procedure is as follows:

  1. Logon to the physics-elog machine as yourself.
  2. Change directory to a logbook's current year directory. For example if the accelog directory is chosen and the year is 2012:
  3. List the week directories by issing a simple "ls" command.
  4. Note the previous week's week number. It should be one less than the highest consecutive week numbers. For example, if the directory numbers were "01 02 03 52", the previous week's week number would be "02".
  5. Change directory to the NFS destination directory for the accelog logbook and the current year. For example, if the year is 2012:
  6. Copy the desired week directory (usually the previous week's directory) and contents from the accelog logbook's data directory to the corresponding NFS destination directory. For example, if the year is 2012 and the desired week directory is "02":
  7. Peform similar action's for the desired week directory for the facelog and lclselog logbooks. For example, if the year is 2012 and the desired week directory is "02":
    1. cd /nfs/slac/g/esd/archiver/desy_elog/facetelog/data/2012
    2. cp -r /var/www/facetelog/data/2012/02 .
    3. cd /nfs/slac/g/esd/archiver/desy_elog/lclselog/data/2012
    4. cp -r /var/www/lclselog/data/2012/02 .
  8. Logoff the physics-elog machine and logon to the mccelog machine using the "cddev" account.
  9. cd /mccelog/logxml/bin
  10. source ./client9i
  11. Run the Perl Physics E-log system to Operations E-log system conversion script for the ACCEL, FACET, and LCLS logbooks. The time required to process the ACCEL logbook entries should be short. The time required to process the FACET logbook entries should also be short if FACET is not running. For example, if the year is 2012 and the desired week directory is "02" (note that if the week is less than 10 there is no leading '0'):
    1. ./prod_desy_to_jlab_xml.pl accel 2012 2 2012 2
    2. ./prod_desy_to_jlab_xml.pl facet 2012 2 2012 2
    3. ./prod_desy_to_jlab_xml.pl lcls 2012 2 2012 2
    The first two numbers are the starting year and week number and the last two numbers are the ending year and week number used for processing. Normally they would be the same, indicating only one week of data entries will be processed (e.g., year 2012, week 2).

Adding a New E-log User

In order for a user to be able to create new E-log entries the E-log administrator must have previously added information about the user in the E-log Oracle schema. After the administrator has done this the user becomes an "authorized E-log user" and his/her name can be added to the list of authorized E-log users that may be accessed from the E-log login web page.

Before proceeding with adding information for a prospective new authorized E-log user to the E-log Oracle schema the E-log administrator must verify that the user has a SCCS Unix account. This is due to the need to enter the user's Unix account name into the Oracle E-log schema as well as his/her first and last name. The user's Unix account name in the Oracle E-log schema is used in the E-log login username/password authentication process required previously in a user's browser session before a user can create an E-log entry.

Note - There are two exceptions - physics and fphysics accounts.

To verify that a prospective new authorized E-log user has a SCCS Unix account and determine the account name the E-log administrator may enter a Unix command of the following form:

where "search_string" is typically all or part of the user's first or last name. If the output of the command includes a line containing the user's first and last name then the user has a SCCS Unix account and the account name is the first field in the line. If the output of the command does not include a line containing the user's first and last name then the administrator must contact the user and request that he/she contact SCCS to request the creation of a Unix account. In this case the user must contact the administrator after the Unix account has been created so that the administrator can proceed with the process of making the user an authorized E-log user.

After determining the user's Unix account name the administrator needs to determine whether the user will need to make entries into one of the restricted logbooks. E-log entries in a restricted logbook can only be made by restricted number of users authorized to make entries into the logbook. There are currently three restricted logbooks:

  1. MCC
  2. SPEAR3
  3. SSRL-BLDO

 

There have been no cases where a user needs access to more than one restricted logbook. If a user requests to be able to make E-log entries into a restricted logbook, there are one or more "gatekeepers" for each restricted logbook that the E-log administrator may contact to verify whether the user should be granted privilege to make entries into the logbook:

  1. MCC - Mike Stanek or Peter Schuh
  2. SPEAR3 - Ed Guerra
  3. SSRL-BLDO - Bart Johnson

Most authorized E-log users are not allowed to make entries into a restricted logbook. However, new Controls Software employees are given privilege to make entries into the MCC logbook. Requests for other users to be given access to the MCC logbook typically come from the MCC logbook gatekeepers: Mike Staneck and Peter Schuh. All requests for new users to be granted permission to make entries into SPEAR3 or SSRL-BLDO have come from the respective restricted logbook gatekeepers.

After the new E-log authorized user's information has been obtained (Unix account name, first name, and last name) and their possible need to make an entry into a restricted logbook has been determined, the follow procedure may be followed by the E-log administrator to create a new authorized E-log user:

  1. Logon to an AFS access machine such a lcls-dev2 using the "laci" account.
  2. cd /nfs/slac/g/archiver/operations_elog_admin
  3. export TWO_TASK=MCCO
  4. sqlplus elog_owner
  5. Enter the current elog_owner password.
  6. Enter a command of the form: where "user_last_name" is the last name of the prospective new authorized E-log user. The result should be "no rows selected" or other users with the same last name of the prospective new authorized E-log user. This step is done to verify that the prospective new authorized E-log user is not already in the list of authorized E-log users.
  7. select * from elog_users order by user_id;
  8. Note the last user_id number displayed. In this procedure what is referred to the "next user_id number" is one more than the last user_id number displayed. For example, if the last user_id number displayed was 1391, the "next user_id number" would be 1392.
  9. exit
  10. Determine the name of the SQL file to be edited (under /nfs/slac/g/archiver/operations_elog_admin  directory), in order to add the new authorized E-log user:
  11. Edit the appropriate SQL file by performing the following steps:
    1. Replace ALL occurences of the exiting user_id number in this file by the previously determined next user_id number. For example, if the first line of the file was:
      • insert into elog_users values (1391, 'abc', 'John', 'Smith', null, null);
      The existing user_id number is the first number in this line (e.g., 1391). To replace ALL occurences of the exiting user_id number 1391 by the next user_id number 1392 using the VI editor, one could enter the command "%s/1391/1392/g".
    2. Edit the first line of the file by replacing the next three fields by the new authorized user's Unix account name, first name, and last name. For example, if the next user_id number is 1392, the user's Unix account name is "jdoe", and the user's name is "Jane Doe" the new edited first line would be:
      • insert into elog_users values (1392, 'jdoe', 'Jane', 'Doe', null, null);
    3. Exit the editor while writing the edited changes.
  12. sqlplus elog_owner
  13. Enter the current elog_owner password.
  14. Invoke the previously edited SQL file to insert a new row into the Oracle E-log elog_users table and many new rows into the logbook_users table. For example, if the edited file was insert_new_elog_user.sql:
  15. exit
  16. cd /afs/slac/g/cd/soft/html/elog/users
  17. cp elog_authorized_users.html elog_authorized_users.html.prev
  18. Edit elog_authorized_users.html (whose information can be accessed from the E-log login web page) to add the new authorized E-log user. There are four sections in this file with each section containing HTML list entries of user names in alphabetical order (lastname first). The four sections are:
    1. MCC logbook authorized users
    2. SPEAR3 logbook authorized users
    3. SSRL-BLDO logbook authorized users
    4. General authorized users
    If a user was given privilege to make entries in a restricted logbook, add an entry to the associated restricted logbook section. In any case, also add an entry in the general authorized users section.
  19. Send email to the user notifying him/her that he/she has been added to the list of authorized E-log users.

Real life example - Adding New Elog User fphysics.

divekar@mcclogin $ ssh mccelog -l laci

-bash-3.00$ uname -a
SunOS mccelog 5.10 Generic_147440-12 sun4u sparc SUNW,Sun-Fire-V240

-bash-3.00$ id
uid=8412(laci) gid=1006(cd)

-bash-3.00$ cd /nfs/slac/g/archiver/operations_elog_admin
-bash-3.00$ pwd
/nfs/slac/g/archiver/operations_elog_admin

-bash-3.00$ export TWO_TASK=MCCO
-bash-3.00$ sqlplus elog_owner

SQL> select * from ELOG_USERS order by user_id;
...

USER_ID USERNAME FIRSTNAME
---------- ---------- ------------------------------
LASTNAME EMAIL A
------------------------------ ------------------------------ -
1390 divekar Shashi
Divekar

1391 ohickman Oliver
Hickman

SQL> exit

In the above step we identified that last user_id is 1391. Fow new uer we will use user_id 1392.

Edit /nfs/slac/g/archiver/operations_elog_admin/insert_new_elog_user.sql.

Use the new user_id by replacing old user_id.

Use new user name by replaving old user name.

-bash-3.00$ cat insert_new_elog_user.sql
insert into elog_users values (1392, 'fphysics', null, 'Fphysics', null, null);

insert into logbook_users values (120, 1392);
insert into logbook_users values (121, 1392);
insert into logbook_users values (123, 1392);
insert into logbook_users values (124, 1392);
insert into logbook_users values (126, 1392);
insert into logbook_users values (129, 1392);
insert into logbook_users values (130, 1392);
insert into logbook_users values (140, 1392);
insert into logbook_users values (150, 1392);
insert into logbook_users values (160, 1392);
insert into logbook_users values (170, 1392);
insert into logbook_users values (180, 1392);
insert into logbook_users values (185, 1392);
insert into logbook_users values (188, 1392);
insert into logbook_users values (190, 1392);
insert into logbook_users values (195, 1392);
insert into logbook_users values (197, 1392);
insert into logbook_users values (198, 1392);
insert into logbook_users values (200, 1392);
insert into logbook_users values (300, 1392);
insert into logbook_users values (305, 1392);
insert into logbook_users values (310, 1392);
insert into logbook_users values (1000, 1392);

commit;

After editing the file again invole sqlplus.

-bash-3.00$ export TWO_TASK=MCCO
-bash-3.00$ sqlplus elog_owner

SQL> @insert_new_elog_user

SQL> select * from ELOG_USERS order by user_id;

..

....

USER_ID USERNAME FIRSTNAME
---------- ---------- ------------------------------
LASTNAME EMAIL A
------------------------------ ------------------------------ -
1390 divekar Shashi
Divekar

1391 ohickman Oliver
Hickman

1392 fphysics
Fphysics

393 rows selected.

Existing Logbooks -

SQL> select LOGBOOK_ID, Name from logbooks;

LOGBOOK_ID NAME
---------- ------------------------------
300 LCLS
188 SPEAR-SE
123 NLCTA
120 ACCELERATOR
121 PEP
122 MCC
1000 TLOG
140 RF
160 BIC
180 SPPS
200 SW_LOG

LOGBOOK_ID NAME
---------- ------------------------------
190 AMRF
195 PCD-PEE
198 PEM
170 ASTA
150 XFD
185 ITF
130 LBAND-SNS
187 SPEAR3
305 LCLS-LASER
129 LBAND-MARX
124 NLCTA-LASER

LOGBOOK_ID NAME
---------- ------------------------------
189 SSRL-BLDO
126 XTA
197 PEM-FT
310 FACET

26 rows selected.

 

Adding a New Logbook

Adding a new logbook requires small web interface code changes and changes to the contents of some Oracle E-log tables.

When a user group requests a new logbook the user should specify the name of the logbook. Unless the requestor specifically requests the creation of a restricted logbook (logbooks for which only a group of requestor authorized users can make entries), an unrestricted logbook should be created. If a user requests a restricted logbook it is a good idea to question the user as to whether a restricted logbook is really needed and to explain that there is increased setup and maintenance cost for restricted logbooks.

The creation of a new logbook requires a software request and test plan. CATER 97899 (job 1), which describes the addition of the Operations E-log system XTA logbook, is an example of this.

A decision needs to be made regarding where to put the logbook name in the list of logbooks displayed on the main E-log web page. For instance, a decision was made to put the XTA logbook close to the NLCTA logbooks since there is an organizational relationship. After this decision has been made the choice of the logbook_id for the new logbook can be made. The logbook names are displayed on the main E-log web page are displayed in order of their logbook_id in the Oracle E-log logbook table. To see the logbook_id numbers and other information for each logbook:

  1. Logon to an AFS access machine such a lcls-dev2 using the "laci" account.
  2. export TWO_TASK=MCCO
  3. sqlplus elog_owner
  4. Enter the current elog_owner password.
  5. select * from logbooks order by logbook_id;
For the XTA logbook it was decided to put its logbook name between the NLCTA-LASER logbook name (logbook_id 124) and the LBAND-MARX logbook name (logbook_id 129). Therefore a logbook_id between 124 and 129 was chosen: 126.

While in sqlplus under the elog_owner account, also issue the following command:

Note this maximum user id number.

After the new logbook name, the new logbook_id, and the maximum user id number have been determined, the following procedure may be followed to prepare for the release to add a new logbook:

  1. Logon to an AFS access machine such a lcls-dev2 using the "laci" account.
  2. cd /nfs/slac/g/archiver/operations_elog_admin
  3. Edit the file insert_logbooks.sql by replacing the new logbook_id in place of the existing number and the new logbook name everywhere there is another logbook name in the first line of the file. For example if the new logbook_id was 126 and the new logbook name was XTA, the new first line in the logbook would be:
  4. If the new logbook is an unrestricted logbook (the usual case), edit the file insert_users_for_new_logbook.pl in two places:
    1. On the "logbook_id :=" line replace the existing number by the new logbook_id. For example, if the new logbook_id number is 126, the completed edited line would be
      logbook_id := 126;
    2. On the "end_user_id :=" line replace the existing number by the maximum user id number. For example, if the new maximum user id number is 1391, the completed edited line would be
      end_user_id := 1391;
  5. If the new logbook is an unrestricted logbook (the usual case), edit each of the "insert_new*_elog_user.sql" files:
    1. insert_new_elog_user.sql
    2. insert_new_mcc_elog_user.sql
    3. insert_new_spear3_elog_user.sql
    4. insert_new_ssrl_bldo_elog_user.sql
    For each file add a new "insert into logbook_users values" line for the new logbook_id number. These lines are in increasing order by logbook_id number (currently 120 through 1000). For example, if the new logbook_id number is 126 and the second number in each "insert into logbook_users values" line is 1372 (a user_id number), the new line would be
    insert into logbook_users values (126, 1372);
    This editing is done so that when any new authorized E-log user is later added this person is permitted to make entries into the new unrestricted logbook.
  6. If the new logbook is a restricted logbook (NOT the usual case), create a new ""insert_new*_elog_user.sql" file where "*" is replaced by the new logbook name. Suppose the new logbook name was "abc". First, create a new template file. For example: Then edit the new file (e.g., "insert_new_abc_elog_user.sql") to add a new "insert into logbook_users values" line for the new logbook_id number as explained in the previous step for unrestricted logbooks. This new file creation and editing is done so that when a new authorized E-log user is later added who has been authorized to create entries into the new restricted logbook this person is permitted to make entries into this new logbook and all unrestricted logbooks.
  7. Logon to the mccelog machine using the "cddev" account.
  8. cd /www/htdocs/elog/dev
  9. Save the current versions of the files to be changed. Although the changes to be made are simple, it is always a good idea to save the current versions of the files to be changed in this main development area in case the changes need to be backed out. Two files in the main development area to be changed are dev_create_elog.php and dev_elog_create_quick_entry.php so saving the current versions of these files is accomplished by:
  10. Edit the file dev_create_elog.php by adding a new line in the "$logbook_choices" array initialization statement (search for the first occurrance of the string "logbook_choices") for the new logbook name. There is a line in this array initialization statement for each logbook and the logbook name order corresponds to the order the names appear in the "Make New Entry" list of logbooks to select. It is good practice to add the new logbook name after the same logbook name that the new logbook name follows on the main elog web page. For example when the line was added it followed the existing line
  11. Edit the file dev_elog_create_quick_entry.php to add a new line for the logbook name in a similar manner as was done for the editing of dev_create_elog.php.
  12. cd /www/htdocs/elog/wbin
  13. cp create_elog.php create_elog.php.prev
  14. cp elog_create_quick_entry.php elog_create_quick_entry.php.prev
  15. cp /www/htdocs/elog/dev/dev_create_elog.php create_elog.php.new
  16. cp /www/htdocs/elog/dev/dev_elog_create_quick_entry.php elog_create_quick_entry.php.new
  17. Edit create_elog.php.new to remove all "dev_" substrings.
  18. Edit elog_create_quick_entry.php.new to remove all "dev_" substrings.

After obtaining permission from the EOIC to perform the software release for the previously approved test plan to make a new logbook, perform the release as follows:

  1. Logon to an AFS access machine such a lcls-dev2 using the "laci" account.
  2. export TWO_TASK=MCCO
  3. cd /nfs/slac/g/archiver/operations_elog_admin
  4. sqlplus elog_owner
  5. Enter the current elog_owner password.
  6. @insert_logbooks
  7. If the new logbook is an unrestricted logbook (the usual case) perform the following to permit all authorized E-log users to make entries into the new logbook: This will cause an exit from sqlplus.
  8. If the new logbook is a restricted logbook (NOT the usual case), allow each person authorized to make entries into the new logbook to make entries into this logbook. For each such person:
    1. Determine their user id by a sqlplus command such as:
      select user_id from elog_users where lastname = 'user_lastname';
      where "user_lastname" is the person's last name.
    2. Insert a row into the logbook_users table for the person's user id and the logbook_id for the new logbook with a command of the following form:
      insert into logbook_users values (logbook_id, user_id);
      where "logbook_id" is the logbook_id for the new logbook and "user_id" is the person's user id determined from the preceeding step.
    Perform these two steps to authorize yourself (the E-log administator) temporarily to make entries into the new restricted logbook so that you will be able to test whether entries can be made in this new logbook (as described later during verification testing).
  9. Logon to the mccelog machine using the "cddev" account.
  10. cd /www/htdocs/elog/wbin
  11. cp /www/htdocs/elog/dev/dev_create_elog.php.new create_elog.php
  12. cp /www/htdocs/elog/dev/dev_elog_create_quick_entry.php.new elog_create_quick_entry.php

Verify that the release was successful:

  1. Bring up a browser and set the URL to the Operations E-log Main Web Page.
  2. Verify that the new logbook name appears in the desired place in the list of logbooks (and associated checkboxes) on the main E-log web page.
  3. Verify that the new logbook name appears in the list of logbook names when the "Jump To Logbook" link is selected on the main E-log web page. It may be necessary to clear the browser cache before being able to see the new logbook name. Please use a search engine to determine how to clear the browser cache for the browser you are using.
  4. Create a new E-log entry into the new logbook using the "New Entry" button on the main E-log web page. The new logbook name should appear in the list of selectable logbook names on the "Make New Entry" E-log web page. Verify that the new entry appears in the new logbook.
  5. Create a new E-log entry into the new logbook using the "Quick Entry" button on the main E-log web page. The new logbook name should appear in the drop-down list of logbooks that appears afther the "Quick Entry" button is selected. Verify that the new entry appears in the new logbook.

There is one last step after successfully verifying the release was successful if the new logbook is a restricted logbook. In this case, the following file should be edited to add a new section listing the people who are authorized to make entries in the new restricted logbook:

How to filter logbooks appearing on the Operations Elog URL  under "Logbook:" section ?

This was done under dev area just for doing test. In this test we made the three logbooks - ACCEL, LCLS and FACET, not to appear on the dev URL - https://mccelog.slac.stanford.edu/elog/dev/dev_elog.php

Procedure -

Logged onto mccelog - ssh mccelog -l cddev

# cp  /mccelog/www/dev/dev_elog_new_filter_form.php /mccelog/www/dev/dev_elog_new_filter_form.php.05212012

# vi   /mccelog/www/dev/dev_elog_new_filter_form.php

# diff /mccelog/www/dev/dev_elog_new_filter_form.php /mccelog/www/dev/dev_elog_new_filter_form.php.05212012
39c39
< if ($results['ABBREVIATION'] != 'SPPS' && $results['ABBREVIATION'] != 'FACET' && $results['ABBREVIATION'] != 'LCLS' && $results['ABBREVIATION'] != 'ACCEL')
---
> if ($results['ABBREVIATION'] != 'SPPS')

General useful information -

For testing the general web server functionality -

http://mccelog.slac.stanford.edu/cgi-bin/first.cgi

http://mccelog.slac.stanford.edu

http://mccelog.slac.stanford.edu:80

https://mccelog.slac.stanford.edu/elog/wbin/elog.php

https://mccelog.slac.stanford.edu/elog/dev/dev_elog.php

http://mccelog/server-status?refresh=30

http://mccelog/server-status?auto

SW_LOG elog and sw-log unix account -

sw-log unix account is a special account. Emails sent to sw-log@slac.stanford.edu gets formatted and put in to Operations Log.

It has a local mainbox, forwarding capability and uses procmail.

 

 

divekar@mcclogin $ pwd

/afs/slac.stanford.edu/u/cd/sw-log

 

divekar@mcclogin $ ls -la .forward

-rw-r--r-- 1 sw-log cd 64 Jun 25  2004 .forward

 

divekar@mcclogin $ ls -la | grep proc

drwxr-xr-x 2 sw-log cd    2048 Mar 26  2010 .procmail/

-rw-r--r-- 1 sw-log cd     429 Jul  8  2009 .procmailrc

 

For testing do this from mcclogin and then check SW_LOG logbook -

[divekar@mcclogin technical]$ echo "test email to swlog" | mailx -s "test email to swlog" sw-log

 

Apache httpd and php -

The libphp.so is loaded into apache httpd process when you run it in satandard SAPI mode.  If you were to run PHP in CGI mode, then the web server would call /bin/php and you could see php processes executing on the server if you happened to do a ps -ef at the right time. 

 

If you enable apache mod_status and set ExtendedStatus On, you can see detailed information about each httpd process by going to /server-status on your server. See http://httpd.apache.org/docs/current/mod/core.html#extendedstatus

 

Problems, Issues and Solutions -

mccelog webpage was showing following warnings on and off -

Warning: ociplogon(): ORA-01017: invalid username/password; logon denied in /var/www/html/elog/wbin/ora_functions.php on line 38

Warning: ociplogon(): ORA-01017: invalid username/password; logon denied in /var/www/html/elog/wbin/ora_functions.php on line 72

Solution -

Note: Do not set Oracle environment variables in PHP scripts with putenv(). The web server may load Oracle libraries and initialize Oracle data structures before running your script. Using putenv() causes hard to track errors as the behavior is not consistent for all variables, web servers, operating systems, or OCI8 functions. Variables should be set prior to Apache starting

 

We already ORACLE_HOME and PATH declared in /etc/sysconfig/httpd . Also included TNS_ADMIN, restarted httpd and that fixed our problem.

PATH=/mccelog/package/php/php-5.4.7/bin:/mccelog/package/perl/perl-5.16.1/bin:$PATH

export PATH

ORACLE_HOME=/afs/slac.stanford.edu/package/oracle/f/11.1.0/amd64_linux26/11.1.0

export ORACLE_HOME

TNS_ADMIN=/afs/slac/g/lcls/tools/oracle/wallets/elog_writer

export TNS_ADMIN

Symptoms when Oracle Backend Server is down –

http://mccelog webpage will show following when Oracle is not available.

Warning: ociplogon(): ORA-12532: TNS:invalid argument in /var/www/html/elog/wbin/ora_functions.php on line 38

Warning: ociplogon(): ORA-12532: TNS:invalid argument in /var/www/html/elog/wbin/ora_functions.php on line 72

Warning: ociparse() expects parameter 1 to be resource, integer given in /var/www/html/elog/wbin/ora_functions.php on line 110

Date range not valid

Error

 

User Issues -

Cannot logon to elog to put entry.

Ensure that user can logon to flora machine. If user's unix password is expired tell him to get it reset by SCCS. Email is account-services

Checking print pipes -

lpr -P elog_spear3 <some file>

Following commands were issued from mcclogin and then checked from web interface that it created entries under tlog

xwd -display localhost:49.0 | xwdtopnm | pnmdepth 255 | pnmtops -width 8.5 -height 11 -scale 1 -center | lpr -P elog_tlog_ent
xwd -display localhost:49.0 | xwdtopnm | pnmdepth 255 | pnmtops -width 8.5 -height 11 -scale 1 -center | lpr -P elog_tlog_entrot

Note this command will expect an input. Just click left key of mouse and then you will see following two lines -

xwdtopnm: writing PPM file
pnmtops: generating color Postscript program.

 

xwd - dump an image of an X window
xwdtopnm - convert an X11 or X10 window dump file to a PNM image
pnmdepth - change the maxval in a PNM image
pnmtops - convert PNM image to PostScript

This is how tlog printers are configured on mcclogin -

divekar@mcclogin $ lpstat -t | grep -i tlog | grep -vi facet
device for elog_tlog_ent: ipp://lcls-prod01.slac.stanford.edu:631/printers/elog_tlog_ent
device for elog_tlog_entrot: ipp://lcls-prod01.slac.stanford.edu:631/printers/elog_tlog_entrot
elog_tlog_ent accepting requests since Thu 16 Aug 2012 11:10:19 AM PDT
elog_tlog_entrot accepting requests since Thu 16 Aug 2012 11:10:20 AM PDT
printer elog_tlog_ent is idle. enabled since Thu 16 Aug 2012 11:10:19 AM PDT
printer elog_tlog_entrot is idle. enabled since Thu 16 Aug 2012 11:10:20 AM PDT

Scripts on mccelog which start the print pipes -

/etc/init.d/st.elog_pipe

/etc/init.d/st.elog_pipe script calls  /mccelog/logxml/bin/st.elog_pipe

pipe processes running on mccelog normally -

# ps -ef | grep pipe | grep -v grep
cddev 16361 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry.pl mcc_ent
cddev 16360 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_make_entry.pl make_ent
cddev 16359 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_rotate.pl rotate
cddev 16358 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl facet
cddev 16357 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl spear3
cddev 16356 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl tlog
cddev 16355 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl lcls
cddev 16342 1 0 16:50:21 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl accl
cddev 16368 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry_rotate.pl tlog_entrot
cddev 16354 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl swlog
cddev 16364 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry.pl spear3_ent
cddev 16353 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl pcdpse
cddev 16351 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl amrf
cddev 16350 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl bic
cddev 16369 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry_rotate.pl spear3_entrot
cddev 16349 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl rf
cddev 16348 1 0 16:50:22 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl lband
cddev 16347 1 0 16:50:21 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl pack
cddev 16344 1 0 16:50:21 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl mcc
cddev 16346 1 0 16:50:21 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl nlcta
cddev 16363 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry.pl tlog_ent
cddev 16345 1 0 16:50:21 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl spps
cddev 16362 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry.pl lcls_ent
cddev 16366 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry_rotate.pl mcc_entrot
cddev 16365 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry.pl facet_ent
cddev 16370 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry_rotate.pl facet_entrot
cddev 16367 1 0 16:50:23 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe_entry_rotate.pl lcls_entrot
cddev 16343 1 0 16:50:21 pts/4 0:00 /usr/bin/perl /mccelog/logxml/bin/elog_pipe.pl pep

Email distribution list for elog outages email -

xfd-fc@slac.stanford.edu; Divekar, Shashikant P.; Warren, Jonathan; Nelson, Janice L.; Guerra, Eduardo; Craft, Jim; Ratkovsky, Serge; Steele, David A.; Stanek, Michael W.; Schuh, Peter M.; Gibbs, Matt; Brobeck, Kenneth C.; Zhou, Jingchen; Rock, Judith E.; Pandey, Poonam

Apache webserver basics -

Following Directory statements are defined in /var/www/conf/httpd.conf on mccelog

<Directory "/var/www/htdocs">
<Directory /var/www/htdocs/elog/wsbin/>
<Directory /var/www/htdocs/elog/test_wsbin/>
<Directory /var/www/htdocs/elog/wbin/>
<Directory /var/www/htdocs/elog/dev/>

User Authentication -

User Login/Authentication is done by /www/htdocs/elog/bin/afs.pl script.  This script gets invoked when you click on following -

Login Button

New Entry Button

Quick Entry Button

This script can be tested by manually running it.

$ /www/htdocs/elog/bin/afs.pl divekar mysecretword
 

Something about /var/www/conf/httpd.conf statements -

ScriptAlias

The ScriptAlias directive tells Apache that a particular directory is set aside for CGI programs. Apache will assume that every file in this directory is a CGI program, and will attempt to execute it, when that particular resource is requested by a client.

mccelog $ cat /var/www/conf/httpd.conf | grep ScriptAlias
# ScriptAliased directories, uncomment the following lines.
ScriptAlias /cgi-bin/ /www/cgi-bin/

mccelog $ ls -la /www
lrwxrwxrwx 1 root other 8 Jan 21 2011 /www -> /var/www/

mccelog $ ls -la /www/cgi-bin/
total 6
drwxr-xr-x 2 root other 512 Aug 2 12:55 ./
drwxr-xr-x 10 nobody bin 512 Jul 3 09:10 ../
-rwxr-xr-x 1 root other 94 Jul 1 2008 first.cgi*

Running CGI scripts anywhere in your domain

If you don't want to be restricted to running CGI scripts within the ScriptAlias directory in your domain, and want CGI scripts to run anywhere in your domain, add the following line to your "httpd.conf" file.

AddHandler cgi-script .cgi

 

If you want the .pl extension recognised as a CGI script as well, simply append the extension to the list, as follows:

AddHandler cgi-script .cgi .pl

$ cat /var/www/conf/httpd.conf | grep -i AddHandler
AddHandler server-parsed .shtml
AddHandler cgi-script cgi pl

Explicitly using Options to permit CGI execution -

You could explicitly use the Options directive, inside your main server configuration file, to specify that CGI execution was permitted in a particular directory:

<Directory /usr/local/apache2/htdocs/somedir>
Options +ExecCGI
</Directory>

The above directive tells Apache to permit the execution of CGI files. You will also need to tell the server what files are CGI files. The following AddHandler directive tells the server to treat all files with the cgi or pl extension as CGI programs:

AddHandler cgi-script .cgi .pl

On mccelog server /var/www/conf/httpd.conf  contains following line for DocumentRoot -

DocumentRoot '/var/www/htdocs'

In Apache, all the files that will appear on the server are kept in the "htdocs" directory, if you installed in the default location it would be /var/www/htdocs.

You can create a file /var/www/htdocs/info.php, add following one line into that file and save it ( in htdocs directory).

<? phpinfo(); ?>



Now open an internet browser and type in http://mccelog/info.php . You should get a page of information about PHP.

Here you will also notice that oci8 support is enabled.

bash-3.00$ uname -a
SunOS mccelog 5.10 Generic_147440-19 sun4u sparc SUNW,Sun-Fire-V240

 


bash-3.00$ strings /opt/TWWfsw/php525/bin/php | grep -i oci
OCi6
associative_array
Node must be associated with a document
Imported Node must have associated Document
Ocirc
ocirc
OCI8
Oracle (OCI) driver for PDO

mccelog $ ./TWWfsw/php525/bin/php -m | grep -i oci
oci8

To find out oci8 libraries installed on server are compiled for 32 bit or 64 bit -

mccelog $ file /opt/TWWfsw/php525/lib/extensions/2.2.6/oci8.so
/opt/TWWfsw/php525/lib/extensions/2.2.6/oci8.so: ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped

The ldd utility lists the dynamic dependencies of executable files or shared objects. ldd uses the runtime linker, ld.so.1, to generate the diagnostics.

bash-3.00$ ldd /opt/TWWfsw/php525/bin/php
libpcre.so.0 => /opt/TWWfsw/libpcre74/lib/libpcre.so.0
libresolv.so.2 => /lib/libresolv.so.2
libxml2.so.2 => /opt/TWWfsw/libxml26/lib/libxml2.so.2
libdl.so.1 => /lib/libdl.so.1
libz.so.2 => /opt/TWWfsw/libz12/lib/libz.so.2
libiconv.so.2 => /opt/TWWfsw/libiconv19/lib/libiconv.so.2
libm.so.1 => /lib/libm.so.1
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V240/lib/libmd_psr.so.1


PHP.ini is very useful and it is a configuration file that is used to customize behavior of PHP at runtime. This enables easy administration in the way you administer Apache web server using configuration files. The Settings in which upload directory, register global variables, display errors, log errors, max uploading size setting, maximum time to execute a script and other configurations is written in this file.
When PHP Server starts up it looks for PHP.ini file first to load various values for settings. If you made changes in PHP.ini then you need to restart your server to check the changes be effected.

mccelog $ cat /etc/opt/TWWfsw/php525/php.ini | grep -i oci
;extension=php_oci8.dll
extension=oci8.so

/var/www/htdocs/index.html file contains following -

$ cat /var/www/htdocs/index.html
<html>
<head>
<META HTTP-EQUIV="refresh" CONTENT="0;URL=http://mccelog.slac.stanford.edu/elog/wbin/elog.php">
</head>
<body>
</body>
</html>

elog.php - This file is the 'main page' for the elog.

 

 

Perl Programming/DBI - Perl Database Interface -

There is a comprehensive library of modules for connecting to databases from Perl programs. It is maintained by Tim Bunce and it is called DBI - database interface. The main website for DBI is http://dbi.perl.org/

To use DBI to connect to a database you need at least two CPAN modules. One is the main DBI module, simply called DBI. The other one is a DBD - a database driver module. There are DBI drivers for many mainstream database management systems, such as MySQL and Oracle. The examples in this tutorial concern Oracle; accordingly, the database driver for Oracle is called DBD::Oracle.

DBI (previously called DBperl) is a database independent interface module for Perl. It defines a set of methods, variables and conventions that provide a consistent database interface independent of the actual database being used.

DBD::Oracle is the Oracle specific module for DBI. It can be downloaded from CPAN

 

Some of the DBI and DBD related statements in new_elog_1.9.pl script -

require DBI;
use DBD::Oracle qw(:ora_types);

$dbora=DBI->connect("dbi:Oracle:","$ENV{LOGGING_USER}","$ENV{LOGGING_PASS}",

                     { PrintError => 1,

                       RaiseError => 1,

                       AutoCommit => 0

                                 } ) or die $DBI::errstr;


Testing perl dbd module -

# perl -e 'use DBD::Oracle'

# echo $?

0

How do I check the version of DBI and DBD modules in my perl environment?


mccelo# /usr/bin/perl -mDBD::Oracle -e'print"DBI: $DBI::VERSION\nDBD:$DBD::Oracle::VERSION\n"'
DBI: 1.37
DBD:1.14

Quick testing of oci8/php connectivity with development database MCCODEV -

Logon on mccelog as cddev

Create file /var/www/htdocs/elog/wbin/connect.php

<?php
// Create connection to Oracle

$conn = oci_connect("elog_reader", "put_pw_here", "MCCODEV");
if (!$conn) {
$m = oci_error();
echo $m['message'], "\n";
exit;
}
else {
print "Connected to Oracle!";
}
// Close the Oracle connection
oci_close($conn);
?>

Go to URL - https://mccelog.slac.stanford.edu/elog/wbin/connect.php

If everything is correct then you will see message "Connected to Oracle!"

 

Quick testing of perl/dbi connectivity with development database MCCODEV -

# ssh mccelog -l cddev

$ id
uid=3745(cddev) gid=1006(cd)


$ . /mccelog/logxml/bin/env.sh

$ echo $LOGGING_USER
elog_writer@MCCO

$ export LOGGING_USER=elog_writer@MCCODEV

$ echo $LOGGING_USER
elog_writer@MCCODEV

Create /tmp/perl-ora-connect.pl  file  and execute it -

$ /tmp/perl-ora-connect.pl
02-AUG-2012

These are the contents of   /tmp/perl-ora-connect.pl file -

#!/usr/perl5/5.6.1/bin/perl

require DBI;
use DBD::Oracle qw(:ora_types);
use Time::ParseDate;
use File::Basename;
use File::Copy;
use File::stat;
use XML::Simple;
use Data::Dumper;
use Getopt::Long;
use POSIX;


my $dbh = DBI->connect("dbi:Oracle:","$ENV{LOGGING_USER}","$ENV{LOGGING_PASS}")
or die "Couldnt connect to database: $DBI::errstr";

# A simple date fetch

# Prepare the SQL statement.
# $sth is a statement handle - an environment for running an SQL statement.
my $sth = $dbh->prepare('select sysdate from dual') # NOTICE - no ; in the end!
or die 'Couldnt prepare statement: ' . $dbh->errstr;

# Execute the SQL statement; don't print it yet
$sth->execute or warn 'Execute failed: ' . $dbh->errstr;

# This "loop" prints all the rows (actually just one, in this case)
while (my @row = $sth->fetchrow_array) {
print "@row\n";
}

$sth->finish();

 

General sequence of actions -

After server reboot, one main httpd process starts and it forks few other httpd processes.

Normally the output of "ps -ef"  would show about 20 httpd processes.

After data from web interface is entered httpd process starts logXml.cgi script.

/var/www/htdocs/elog/wbin/logXml.cgi script  accepts entries for the electronic logbook via HTTP and will post them using the logXml_write function

included in the Jlab::logXml module. These files are put under /nfs/slac/g/cd/mccelog/logxml/new directory.

As and when logXml.cgi script runs, output of "ps -ef" would show following type of process -

nobody 27840 25012 0 14:28:30 ? 0:00 /usr/perl5/5.6.1/bin/perl /var/www/htdocs/elog/wbin/logXml.cgi

XML file is put under /a/surrey04b/vol/vol1/g.cd_mccelog/logxml/new directory

/mccelog/logxml/bin/elog_loader script running continuously collecting files from /a/surrey04b/vol/vol1/g.cd_mccelog/logxml/new directory

          and feeding those to /mccelog/logxml/bin/elog_loader script calls /mccelog/logxml/bin/new_elog_1.9.pl  script.

/mccelog/logxml/bin/elog_loader sources ". /mccelog/logxml/bin/env.sh"

After doing entry from mccelog website following are some of the interesting processes –

nobody 16898 14382   0 18:01:10 ?           0:00 /usr/perl5/5.6.1/bin/perl /var/www/htdocs/elog/wbin/logXml.cgi

  cddev 20799     1   2   Jul 17 ?         674:04 /usr/local/bin/bash /mccelog/logxml/bin/elog_loader

 cddev 16947 20799   0 18:01:11 ?           0:00 /usr/perl5/5.6.1/bin/perl /mccelog/logxml/bin/new_elog_1.9.pl --file=20120804_1

When a small file created from mccelog url using "Quick Entry" button, the logXml.cgi script puts a xml file under /a/surrey04b/vol/vol1/g.cd_mccelog/logxml/new 

directory. For this specific test file the xml file contents are like follow -

<?xml version="1.0" encoding="ISO-8859-1"?>
<log_entry type="LOGENTRY">
<title><![CDATA[shashitest]]></title>
<program>152</program>
<timestamp>2012/09/18 15:05:47</timestamp>
<priority>normal</priority>
<os_user>apache</os_user>
<hostname>mcctest</hostname>
<text type="text/plain"><![CDATA[shashitest at 3:05]]></text>
<logbook>tlog</logbook>
<log_user>divekar</log_user>
</log_entry>

As you see for the above entry, Title is shashitest and contents of the file are "shashitest at 3:05". 

 

/mccelog/logxml/bin/env.sh has following related statements -

LOGGING_USER='elog_writer@MCCO'

LOGGING_PASS='XXXXXX'

export LOGGING_USER

export LOGGING_PASS

/mccelog/logxml/bin/elog_loader script calls /mccelog/logxml/bin/new_elog_1.9.pl

/mccelog/logxml/bin/new_elog_1.9.pl connects to MCCO prod database and puts entries.

Following statements are from /mccelog/logxml/bin/new_elog_1.9.pl file -

$dbora=DBI->connect("dbi:Oracle:","$ENV{LOGGING_USER}","$ENV{LOGGING_PASS}",

                     { PrintError => 1,

                       RaiseError => 1,

                       AutoCommit => 0

                                 } ) or die $DBI::errstr;

new_elog_1.9.pl perl script parses xml-based log entries and performs basic data validation.

If the data from the file looks good, this script will insert it into the elog database.

Upon successful committing of the data to the database, this script will write out a final xml file containing the log_id (serial) number assigned by the database.

If the data from the xml file cannot be successfully committed to the database, an xml exception file will be written out, which can be analyzed and can

potentially be reprocessed after the problem has been corrected.

/mccelog/logxml/bin/elog_loader script transfers files from /a/surrey04b/vol/vol1/g.cd_mccelog/logxml/new directory  to /a/surrey04b/vol/vol1/g.cd_mccelog/logxml/unprocessed directory.

Files are fed one at a time to a perl script /mccelog/logxml/bin/new_elog.pl which parses them and inserts them into the database using SQL (via perl DBI).

This is how xml files looks ( Pay attention to lines containing Title and Data ) -

# cat /a/surrey04b/vol/vol1/g.cd_mccelog/logxml/new/20120731_135012_10701.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<log_entry type="LOGENTRY">
<title><![CDATA[Title: Test]]></title>
<program>152</program>
<timestamp>2012/07/31 13:50:12</timestamp>
<priority>normal</priority>
<os_user>nobody</os_user>
<hostname>mccelog</hostname>
<text type="text/plain"><![CDATA[Data:Test]]></text>
<logbook>tlog</logbook>
<log_user>divekar</log_user>
</log_entry>

How to find out which perl modules are installed ?

# cat /tmp/check.pl
#!/usr/perl5/5.6.1/bin/perl

# list installed modules
use ExtUtils::Installed;
my $instmod = ExtUtils::Installed->new();
foreach my $module ($instmod->modules()) {
my $version = $instmod->version($module) || "???";
print "$module -- $version\n";
}

divekar@mccelog $ /tmp/check.pl
AFS -- 2.03
Authen::Krb5::Simple -- 0.40
CGI -- 3.04
Crypt::SSLeay -- 0.51
DBD::Oracle -- 1.14
DBI -- 1.37
Data::Dumper -- 2.102
Digest::MD5 -- 2.27
HTML::Parser -- 3.31
HTML::Tagset -- 3.03
Jlab::logXml -- 1.7
MIME::Base64 -- 2.20
Mail::Sendmail -- 0.79
PHP::Session -- 0.22
Perl -- 5.6.1
Storable -- 2.07
Test::Simple -- 0.48_01
Time-modules -- ???
UNIVERSAL::exports -- 0.03
URI -- 1.25
XML::NamespaceSupport -- 1.08
XML::Parser -- 2.29
XML::SAX -- ???
XML::SAX::Expat -- 0.37
XML::Simple -- 2.08
libwww-perl -- ???

Perl module DBD-Oracle gets built for perticular ORACLE_HOME. In case you are referencing 11g ORACLE_HOME but the perl is built for 9i ORACLE_HOME,

then the prl script would give following type of error -

DBD::Oracle::st execute failed: ORA-03106: fatal two-task communication protocol error (DBD ERROR: OCIStmtExecute) [for statement ``select user_id,username from elog_users'' with params: ]) at /tmp/perl-ora-connect.pl line 20.
Execute failed: ORA-03106: fatal two-task communication protocol error (DBD ERROR: OCIStmtExecute) at /tmp/perl-ora-connect.pl line 20.
DBD::Oracle::st fetchrow_array failed: ERROR no statement executing (perhaps you need to call execute first) [for statement ``select user_id,username from elog_users'' with params: ]) at /tmp/perl-ora-connect.pl line 23.

Building new perl, perl modules and special case with DBI and Oracle::DBD modules -

# ssh mccelog

# bash

export ORACLE_HOME=/afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0

$ echo $ORACLE_HOME
/afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0

$ which make
/usr/ccs/bin/make

$ echo $LD_LIBRARY_PATH
/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/usr/X11R6/lib:/usr/local/lcls/package/octave/lib/octave-3.0.2::/afs/slac/package/oracle/new/lib:/afs/slac/g/lcls/package/java/jdk1.5.0_14/jre/lib/i386:/afs/slac/g/lcls/package/java/jdk1.5.0_14/jre/lib/i386/server:/afs/slac/g/lcls/package/python/tcltk/lib:/afs/slac/g/lcls/epics/base/base-R3-14-8-2-lcls6/lib/solaris-sparc:/afs/slac/g/lcls/epics/extensions/extensions-R3-14-8-2/lib/solaris-sparc:/afs/slac/g/lcls/tools/lib/solaris-sparc:/afs/slac/package/cmlog/solaris-gcc-3.1.1/lib/solaris-gnu:/afs/slac/package/matlab/linux/2007b/extern/lib/glnx86

# tar -xvf perl-5.16.1.tar

# sudo tcsh

# cd /mccelog <<- as root

# chown -R -h divekar:mccelog perl-5.16.1 <<- as root

# exit <<- exited root. now local user divekar

# cd perl-5.16.1

# ./Configure -des -Dprefix=/mccelog/perl-5.16.1

# make

# make install

# export PATH=/mccelog/perl-5.16.1/bin:$PATH

$ export LD_LIBRARY_PATH=/mccelog/perl-5.16.1/lib:$LD_LIBRARY_PATH

$ echo $LD_LIBRARY_PATH
/mccelog/perl-5.16.1/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/usr/X11R6/lib:/usr/local/lcls/package/octave/lib/octave-3.0.2::/afs/slac/package/oracle/new/lib:/afs/slac/g/lcls/package/java/jdk1.5.0_14/jre/lib/i386:/afs/slac/g/lcls/package/java/jdk1.5.0_14/jre/lib/i386/server:/afs/slac/g/lcls/package/python/tcltk/lib:/afs/slac/g/lcls/epics/base/base-R3-14-8-2-lcls6/lib/solaris-sparc:/afs/slac/g/lcls/epics/extensions/extensions-R3-14-8-2/lib/solaris-sparc:/afs/slac/g/lcls/tools/lib/solaris-sparc:/afs/slac/package/cmlog/solaris-gcc-3.1.1/lib/solaris-gnu:/afs/slac/package/matlab/linux/2007b/extern/lib/glnx86

$ cat /tmp/check.pl
#!/mccelog/perl-5.16.1/bin/perl

###!/usr/perl5/5.6.1/bin/perl

# list installed modules
use ExtUtils::Installed;
my $instmod = ExtUtils::Installed->new();
foreach my $module ($instmod->modules()) {
my $version = $instmod->version($module) || "???";
print "$module -- $version\n";
}

$ /tmp/check.pl
Perl -- 5.16.1

$ which perl
/mccelog/perl-5.16.1/bin/perl

$ cd /mccelog/shashi/ExtUtils-MakeMaker-6.62

$ perl Makefile.PL

$ make

$ make install

$ /tmp/check.pl
ExtUtils::MakeMaker -- 6.62
Perl -- 5.16.1

Installed other perl modules one by one...

Issue with DBD:Oracle module - It gets installed but if the LD_LIBRARY_PATH is not containing 32 bit oracle libries, we face problem.

While connecting to Oracle the perl script gives following type of error -

...Oracle.so' for module DBD::Oracle: ld.so.1: perl: fatal: /afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib/libclntsh.so.11.1: wrong ELF class: ELFCLASS64 at ....

$ . /tmp/env11g.sh
$ /tmp/perl-ora-connect11g.pl
Can't load '/mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1: perl: fatal: /afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib/libclntsh.so.11.1: wrong ELF class: ELFCLASS64 at /mccelog/perl-5.16.1/lib/5.16.1/sun4-solaris/DynaLoader.pm line 190.
at /tmp/perl-ora-connect11g.pl line 5.
Compilation failed in require at /tmp/perl-ora-connect11g.pl line 5.
BEGIN failed--compilation aborted at /tmp/perl-ora-connect11g.pl line 5.

$ ldd /mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so
libclntsh.so.11.1 => /afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib/libclntsh.so.11.1 - wrong ELF class: ELFCLASS64
libkstat.so.1 => /lib/libkstat.so.1
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 => /lib/libsocket.so.1
libgen.so.1 => /lib/libgen.so.1
.....

..........


$ file /mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so
/mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped

This problem can be fixed by either including Oracle 32 bit libries in LD_LIBRARY_PATH or by recreating DBD perl module with proper options.

1st option -

$ export LD_LIBRARY_PATH=/mccelog/perl-5.16.1/lib:/afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib32:$LD_LIBRARY_PATH

2nd option is rebuild DBD-Oracle module -

$ cd /mccelog/shashi/DBD-Oracle-1.50

$ perl Makefile.PL -r=build64

$ make

$ make install

 

$ file /mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so
/mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so: ELF 32-bit MSB dynamic lib SPARC32PLUS Version
1, V8+ Required, dynamically linked, not stripped

$ ldd /mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so
libclntsh.so.11.1 => /afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib/libclntsh.so.11.1 - wrong ELF cl
ass: ELFCLASS64
libkstat.so.1 => /lib/libkstat.so.1
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 => /lib/libsocket.so.1
libgen.so.1 => /lib/libgen.so.1
libdl.so.1 => /lib/libdl.so.1
libsched.so.1 => /usr/lib/libsched.so.1
librt.so.1 => /lib/librt.so.1
libaio.so.1 => /lib/libaio.so.1
libm.so.2 => /lib/libm.so.2
libthread.so.1 => /lib/libthread.so.1
libpthread.so.1 => /lib/libpthread.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V240/lib/libmd_psr.so.1

$ bash
LCLS Development Environment is set

$ export LD_LIBRARY_PATH=/mccelog/perl-5.16.1/lib:/afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib32:$LD_LIBRARY_PATH

$ ldd /mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so
libclntsh.so.11.1 => /afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib32/libclntsh.so.11.1
libkstat.so.1 => /lib/libkstat.so.1
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 => /lib/libsocket.so.1
libgen.so.1 => /lib/libgen.so.1
libdl.so.1 => /lib/libdl.so.1
libsched.so.1 => /usr/lib/libsched.so.1
librt.so.1 => /lib/librt.so.1
libaio.so.1 => /lib/libaio.so.1
libm.so.2 => /lib/libm.so.2
libthread.so.1 => /lib/libthread.so.1
libpthread.so.1 => /lib/libpthread.so.1
libnnz11.so => /afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib32/libnnz11.so
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V240/lib/libmd_psr.so.1

After rebuilding the DBD-Oracle module with proper options -

$ file /mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so
/mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped

$ ldd /mccelog/perl-5.16.1/lib/site_perl/5.16.1/sun4-solaris/auto/DBD/Oracle/Oracle.so
libclntsh.so.11.1 => /afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib32/libclntsh.so.11.1
libkstat.so.1 => /lib/libkstat.so.1
libnsl.so.1 => /lib/libnsl.so.1
libsocket.so.1 => /lib/libsocket.so.1
libgen.so.1 => /lib/libgen.so.1
libdl.so.1 => /lib/libdl.so.1
libsched.so.1 => /usr/lib/libsched.so.1
librt.so.1 => /lib/librt.so.1
libaio.so.1 => /lib/libaio.so.1
libm.so.2 => /lib/libm.so.2
libthread.so.1 => /lib/libthread.so.1
libpthread.so.1 => /lib/libpthread.so.1
libnnz11.so => /afs/slac.stanford.edu/package/oracle/f/11.1.0/sun4x_510/11.1.0/lib32/libnnz11.so
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V240/lib/libmd_psr.so.1

The ScriptAlias directive tells Apache that a particular directory is set aside for CGI programs. Apache will assume that every file in this directory is a CGI program, and will attempt to execute it, when that particular resource is requested by a client.

mccelog $ grep -i scriptalias /var/www/conf/httpd.conf
# ScriptAliased directories, uncomment the following lines.
ScriptAlias /cgi-bin/ /www/cgi-bin/


mccelog $ ls -l /www/cgi-bin/
total 2
-rwxr-xr-x 1 root other 94 Jul 1 2008 first.cgi

 

Note: If Apache has been built with shared module support you need to ensure that the module is loaded; in your httpd.conf you need to make sure the LoadModule directive has not been commented out. A correctly configured directive may look like this:

      LoadModule cgi_module modules/mod_cgi.so

mccelog $ cat httpd.conf | grep -i loadmodule | grep -v "^#" | grep -i cgi
LoadModule cgi_module modules/mod_cgi.so

Explicitely using options to permit CGI execution -

You could explicitly use the Options directive, inside your main server configuration file, to specify that CGI execution was permitted in a particular directory:

<Directory /usr/local/apache2/htdocs/somedir>
Options +ExecCGI
</Directory>

The above directive tells Apache to permit the execution of CGI files. You will also need to tell the server what files are CGI files. The following AddHandler directive tells the server to treat all files with the cgi or pl extension as CGI programs:

AddHandler cgi-script .cgi .pl

mccelog $ cat httpd.conf | grep -i cgi-script
AddHandler cgi-script cgi pl

mccelog $ tail -33   /var/www/conf/httpd.conf

 

# Define the authentication for wsbin and allow .cgi to be executed.
<Directory /var/www/htdocs/elog/wsbin/>
Options +ExecCGI
AllowOverride AuthConfig
</Directory>

<Directory /var/www/htdocs/elog/test_wsbin/>
Options +ExecCGI
AllowOverride AuthConfig
</Directory>
#######
</VirtualHost>

</IfDefine>

<Directory /var/www/htdocs/elog/test_wbin/>
Options +ExecCGI
AllowOverride AuthConfig
</Directory>

# Define the authentication for wsbin and allow .cgi to be executed.
<Directory /var/www/htdocs/elog/wbin/>
Options +ExecCGI
AllowOverride AuthConfig
</Directory>
<Directory /var/www/htdocs/elog/dev/>
Options +ExecCGI
AllowOverride AuthConfig
</Directory>

 

How to run taylor mccelog (a note from Shashi, 03/13/15)

On mcelog you can run taylor manually once every three months.

1) Run taylor ONLY AFTER root disk has been mirrored. Schedule for that you can find from root's crontab file.
2) Schedule a 30 minutes downtime on a POMM day just as precaution.
3) Comment out the do_not_run_taylor from /etc/taylor.ops file.
4) Bring down the webserver (/etc/init.d/httpd stop)
5) taylor everything
6) Immediately after taylor completion - Again uncomment the do_not_run_taylor from /etc/taylor.ops file.
7) Bring up the webserver and check.
8) In case of issues, reboot the server and check.
9) In case you still have issues then .... boot from the secondary disk (mirror disk).

About the error message issue we sometimes experience -
Our wallet location is on AFS/NFS. The problem you mentioned about "oracle error messages" is experienced generally

when we have AFS or NFS slowness issues. To troubleshoot this kind of problem I used to execute a PHP command line script

from mccelog which would fetch some records from database using oracle wallet as "elog_reader".

Also when you see such problem "ps -ef | grep httpd | grep -v grep | wc -l" will show a high number!

Normally you would see maximum 10-12 [REVISION NOTE: this number may acutally be around 25] of httpd processes on mccelog when working good.

It's also a good prectice to restart httpd once a month.

 

Problem of Oracle errors appearing intermittently when attempting to read E-log entries

The problem symptoms referenced in the last paragraph of the "note from Shashi" section above are Oracle error messages intermittently appearing on E-log system web pages when attempting to read E-log entries. As Shashi noted in this paragraph, the problem is believed to be related to disk access slowness when attempting to connect to Oracle, which is now done using the Oracle Wallet facility. This disk access is AFS: the Oracle wallet directory accessed is /afs/slac/g/lcls/tools/oracle/wallets.

It is believed that AFS file server unavailability causes one or more Apache web server httpd processes to become "stuck". Subsequent requests to these processes to service Oracle connection requests fail (as a result of user attempts to read E-log entries, for example). Requests to "good" httpd processes are still serviced successfully, which explains why the problem is intermittent as a request is selected to be processed by either a "stuck" or "good" httpd process.

The problem may be cleared up by stopping and then immediately restarting the Apache web server on mccelog as described in the first part of the "Required System Component" section of this document (near the top of this document).

If it is desired to research the times and duration of AFS disk access unavailability, search the mccelog system log for the string "afs":

  1. Log on to mccelog as yourself and obtain sudo access with a command such as "sudo tcsh".
  2. cd /var/logs
  3. grep -i afs messages | less
There are also "messages.*.gz" files in the /var/logs directory that can be unzipped and examined to search for earlier log messages prior to the first log message in the "messages" file.

 

Author:  Bob Hall 20-Mar-2012
Shashi Divekar 21-Aug-2012 Updates made
Bob Hall 13-Mar-2015 Added new section describing problem of Oracle errors appearing intermittently when attempting to read or create E-log entries