EnterpriseOne CNC Admins Need To Know Everything About Everything
Read Time:2 Min, 59 Sec
I admit that I am a "Jack of all trades, master of none". Which can be a good thing as in the second paragraph of the Wikipedia entry.
A Jack of all trades may also be a master of integration, as the individual knows enough from many learned trades and skills to be able to bring their disciplines together in a practical manner.
Ok, I’m getting a little off track.
With that said, I don’t think that any EnterpriseOne CNC Admin can be a master at everything. That may be a little strong, but unless E1 is your only responsibility and you have very little changes to make, knowing everything about everything that touches your EnterpriseOne system is an extremely difficult pursuit.
In our staff of 30 or so, I feel that I am one of a few that have a pretty extensive background in a wide variety of information technology related subjects. However, yesterday, my "master of none" was exposed.
We are running tools release 8.96.1.5. This release uses IBM’s HTTP Server, which is IBM’s slightly modified Apache HTTP Server 2.0. Although I’ve worked on many different systems, I’ve never had the privilege of administering a mission critical Apache HTTP Server until we started using it for E1 and even then it always… just ran. I never really had to do anything with it besides the httpd.conf modifications required by E1, which are specified very simply in the EnterpriseOne documentation.
Well, yesterday, we had users calling saying that they "couldn’t view PDFs". We were receiving IBM Websphere logs that indicated that the system was unable to write to the /temp directory. Well, the reason for this message was found when one of my colleagues logged-on to the server and noticed the pop-up that said the "E:" drive was out of space.
Now, we know what was going on, but why? There is usually about 10GB of free space on that drive. What could have taken it all. Granted, I haven’t looked in quite a while, but nothing else runs on that box, but the E1 web client.
After a little bit of head-scratching, we found that the culprit was a log file. The Apache access log file. Unknown to me or my non-Apache admin colleagues, the Apache access logs are set to not truncate automatically. In other words, they build and build and build until you have no more disk left.
Fortunately, I was able to find a way to create a new log file after either an amount of time or when the a specified file size is reached. It uses the rotatelogs application that ships with Apache and is configured within the httpd.conf file.
Essentially, you send all Apache access logging through the rotatelogs application which then writes the log to your specified location. This is called "Piped Logging". Here is the basic syntax:
rotatelogs [ -l ] logfile [ rotationtime [ offset ]] | [ filesizeM ]
And this is what I am using:
CustomLog "|bin/rotatelogs.exe logs/access_%Y%m%d_%H%M%S.log 3600" common
This configuration forces a new log file to get created every hour (3600 seconds).
Another benefit to using piped logging is that the log files are not locked by the Apache.exe process. This allows the ability to delete the current log file.
Unfortunately, I have been unable to find a way to delete old files within Apache. I may have to resort to some bat file or VBScript for that.
Average Rating