Fixing "JRun too busy or out of memory" for PCI compliance

One of our servers here at Vivio is routinely scanned for PCI compliance purposes. Until just recently, we've been using FuseGuard (A Web Application Firewal, or "WAF"), to block intrusion attempts to our web application. With new PCI standards that force us to allow PCI scans through our WAF (or IDS or whatever), we had to allow these requests through, but that brought to light another, different, problem.

During the PCI scan, our Apache logs would get a lot of the following error messages:

[notice] jrApache[13857: 62679]  returning error page for JRun too busy or out of memory

Initially we thought that since the message was coming from the JRun connector, that the issue had something to do with the connector. However, after quite a bit more research, we found it had to do with JRun itself, and the specific number of post parameters it's configured to accept. Any more then the default "100" post parameters, and you'll get the error you see above.

To change the number of post parameters, you will need to update your neo-runtime.xml file. For our case, ours was found here:

/opt/coldfusion9/lib/neo-runtime.xml
NEO XML Example

IMPORTANT: Editing this file isn't particularly easy. Opening it in VIM gives you a big wall of text.

By increasing the following parameter from 100 to 300, we were able to succesfully complete our PCI scan:

<var name='postParametersLimit'><number>300.0</number></var>

Hopefully this helps anyone else having this issue.

Railo CGI remote_addr/remote_host says 127.0.0.1

When installed on to a Linux/Apache machine, the Railo installers will install mod_proxy_http as the default connector for Apache to Tomcat/Railo. The result is the same as you'd get with any other proxy, where the remote host is replaced with the address of the proxy (in this case 127.0.0.1) and the original requester's IP address is placed in the "X-Forward-For" header.

simplicityIf you need to find the original requestors IP address you can accomplish this in one of two easy ways.

Pull the IP from the X-Forward-For Header
This can be done easily using the following single line of code:

GetHttpRequestData().headers['X-Forwarded-For']

Use the Tomcat Remote IP Valve
This can be done simply by opening up your Tomcat server.xml file and adding a single line of code right under your "<Engine>" tag:

Change this:

<Engine name="Catalina" defaultHost="127.0.0.1">

To this:

<Engine name="Catalina" defaultHost="127.0.0.1">
<Valve className="org.apache.catalina.valves.RemoteIpValve" />

Restart Tomcat and you'll now see the IP address of the original requesting client populate your CGI scopes.

Apache 2.4 - 403 Forbidden (AH01630: client denied by server configuration)

I recently updated one of my development machines to Ubuntu 13.10 which now uses Apache 2.4 by default. In my case, I had updated a machine that was previously running Ubuntu version 13.04 and had been running Apache 2.2.

Apache 2.4After the upgrade, I was disturbed to find that none of my sites worked! I kept getting Apache 403 (Forbidden) error messages. I figured the upgrade had changed my configurations or something... but after fruitlessly messing with the config files (and seeing nothing wrong with them) I figured I'd look in the apache error log, which is located in /var/log/apache2/error.log by default on Ubuntu 13.10. To my surprise, I found lots of the following errors:

AH01630: client denied by server configuration: /path/to/my/sites

I had never seen that before. Then I noticed at the top of the log file "AH00163: Apache/2.4.6 (Ubuntu)". Ohhhhh....  So we're using the new 2.4 eh? After some google searches, I found out that Apache 2.4 comes with some security enhancements that attempt to make it more difficult for hackers to hide their files on a compromised system. That's neat, but I need to get my sites to work.

After reading a bit of the 2.4 Access Control Documentation, I found that a quick easy fix is to add a directory rule to your main apache config file (/etc/apache2/apache2.conf by default on Ubuntu):

<Directory /path/to/my/sites>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

Restart Apache, and boom, all sites are now loading just fine. The idea behind these rules is to make it so that hackers who, say, use SQL injection to access your PHP site, have a harder time hiding their files in obscure directories on your system, amond other things.

Hope this helps!
Jordan

 

Resetting Pulseaudio on Ubuntu 13.04 (new sound card)

Asus Xonar DSI've been having a huge number of issues with both my sound and my video drivers since upgrading to Ubuntu 13.04. The problem is that my hardware is getting older, and the drivers aren't always "up to snuff" with the latest builds. I understand that hardware evolves and in order to remain current with the latest hardware, backwards compatibility isn't always on the top of everyone's priority list. I'm not mad at anyone about this, but it means that I have to take some time to both figure out what's happening and take the time and spend the money to fix it, and that sucks a little. So, to help others out who may be having the same issues I have, I'll talk a little about what I've been doing to keep up to date.

With my sound, after upgrading to Ubuntu 13.04 I had driver issues with both my SB Live and the onboard sound chip that came with my motherboard. Both would crackle and pop during VOIP conversations due to what I could only deduce as a timing issue due to lack of proper drivers.

To fix this, I needed to get a new supported sound card. I reviewed the ALSA web site and found a card that was fully supported by ALSA and I could also work with as far as affordability & quality. I chose the ASUS Xonar DS which used the fully supported AV66 chipset.

Once I received the card, however, things did not go as well as expected. Pulseaudio would not report that I had even installed the card, and still showed the previous card as being installed. I needed to "reset" Pulseaudio so that it would see my new card. To do this, I ran the following commands:

First, I removed ALSA (just in case it was reporting something incorrectly as well) and Pulseaudio and purged their configurations. This gave me a "blank slate".

$ sudo apt-get remove --purge alsa-base pulseaudio indicator-sound

Next, I needed to re-install what I just removed because, yes, I actually want to use my new sound card:

$ sudo apt-get install alsa-base pulseaudio indicator-sound
After that, we just needed to reload ALSA that's running in memory so that the new/changed modules take effect:

$ sudo alsa force-reload

After this, my shiny new card was working perfectly.

Hope this helps someone else out there!

Update for Ubuntu 14.10

I just recently had to reset pulseaudio for Ubuntu 14.10, and my tried and true article here failed me. Performing these actions in Ubuntu 14.10 no longer fully reset pulseaudio. However, after (a lot of) digging, I found the following bug report, as well as a suggestion to remove a user-specific configuration file located in the user's home directory.

$ rm -rf ~/.config/pulse$ sudo reboot

Once you remove the user-speific config directory, logging out and logging back in (or in this case just rebooting) will get you the default configs.

I also had some trouble with my new video card's HDMI interface. For whatever reason Ubuntu would default to using the HDMI interface over my sound card, so I installed the Pulse Audio Volume Control (pavucontrol), and it allowed me to easily set my preference for my sound card via it's GUI interface.

$ sudo apt-get install pavucontrol$ pavucontrol

After making these adjustments my system was pretty happy. Hope this helps you too!
 

Update for Ubuntu 16.04 (quiet sound)

Just a quick update for a little change I had to make for this sound card on Ubuntu 16.04. When I did the re-install, I thankfully didn't have to do a reset like I did previously, but the sound was super-quiet, and messing with the GUI tools didn't seem to help much. What FINALLY made the significant change was updating ALSAMIXER via the command-line. Oh, command-line, how I love you so.

Basically, I just typed in the following:

$ alsamixer

Then I just used the arrow keys to modify the levels for my sound card. I set mine to 90, as I prefer to use the physical controls on the speakers directly most of the time.

Howto: Mass Rename File Extensions in Linux/BASH

Just recently I had a bunch of HTML files (files with a .html extension) that I wanted to rename to .cfm so that they would be interpreted by Railo. To do this, I created a quick BASH loop and ran it directly in the command line:

for i in *.html;
do mv $i `basename $i html`cfm;
done

The semi-colons at the end of the first two lines will tell bash that you want to enter more commands, and BASH will typically respond by giving you a new line with a greater-then symbol in front of it. So, the output of your loop will look something like this:

myserver $ for i in *.html;
> do mv $i `basename $i html`cfm;
> done
myserver $

The first line creates a "for" loop for every extension you want to change. In my case, since I wanted to change all files with the .html extension, I used .html. The second command creates a subshell (using the ` marks) and uses the basename program to remove the previous "html" entension. The subshell result is then passed back and used in our move command. For example, if you simply typed:

$ basename myfile.html html
myfile.

So the subshell is returning the file name plus a dot. Once that happens the second move command turns into this:

$ do mv $i myfile.cfm

... which is what gets looped over as many times as we need it to in order to rename all the files!

Hope this helps!

 
periodical