Skip to main content
ExLibris
  • Subscribe by RSS
    • Back
    Aleph
    Ex Libris Knowledge Center

    Where do services get their environmental variables set?

    1. Last updated
    2. Save as PDF
    • Article Type: General
    • Product: Aleph
    • Product Version: 16.02

    Description:
    We are having an operating system type problem (not an Ex Libris problem), but are having a hard time figuring out where to look. I hope you can give us some clues!

    History: Last Thursday morning, our campus OIT installed the Daylight Savings Time patches on our production Aleph server, horn, along with some other, unspecified changes. At that point, we lost the ability to connect directly to the server as user "aleph". Later in the day, that was fixed. Friday morning at 9:00 a.m., we did our daily restart of the pc_server and began having the problem I'm concerned about here.

    Description: Up until February 16 (at approximately 9am), ALEPH GUI users were able to use custom services that employed the Net::SFTP perl module without incident. After this point, these custom services have failed with a problem accessing the "/.ssh/known_hosts2" file. (They should be trying to access the /exlibris/aleph/.ssh/known_hosts2 file.)

    Details: The point of failure for the SFTP custom services appears to be that the shell- and Perl-scripts no longer have access to the "aleph" user's "HOME" environmental variable when the service is run from the GUI. The "HOME" environmental variable ($ENV{HOME}) is called from the Net::SSH::Perl module in the course of establishing shared-keys and known-hosts information for SFTP file transfers. It appears that, when the service is called from the GUI, the ALEPH pc-server spawns an "sh" process, which in turn spawns a "csh" process that calls the service in question. It seems fairly certain that the point of failure in environmental variable access can be traced to one of two possibilities: (a) the ALEPH pc-server "aleph" user has lost access to its basic environmental variable settings, or (b) the "sh" command executed by the "aleph" pc-server user somehow has changed permissions or changed access to the environmental variables. Either way, it seems fairly certain that this problem is a result of the changed permissions schemes implemented by OIT.

    Our Question: Can you describe what happens when the ALEPH GUI runs a service? Specifically, where would it be looking to establish its environmental variables? I suspect this will be easy to fix if we can figure out where to look.

    Resolution:
    From site: With help from the listserv, we were able to solve the problem.

    The batch queue had been started when the "aleph" user could not login to the server directly (you had to login as someone else and then "su"). Once that problem was fixed, we didn't restart the batch queue. We restarted it just now and everything works again.

    • Article last edited: 10/8/2013