Category Archives: Technical

Technical

WP auto upgrade/plugin updates, file owners and CHOWN

This has been a vexing activity lately: attempting to perform WP auto-updates and plugin updates on multiple WP installations end in failure. I thought the problem simply came down to deleting or chmodding 777 the offending directories (such as upgrades and/or uploads). When that turned out to be an unwieldy and insecure proposition, I turned to what I suspected might be an FTP issue, by switching to ProFTP server. Still unsuccessful, I suspected an SSH issue–no dice. A file system method switch in wp-config for WP? Nope, not that either. Trying to install suExec for PHP? It was already enabled, and forcing a recompile nearly crashed my server.

In the end, what gave me a clue was the section on file permissions in the WP codex and some forum posts suggesting ownership changes. A handy phpinfo-type script such as <--!? php echo(exec("whoami")); --> dropped in the appropriate directories aided in identifying ownership of certain folders.

It turns out that since I’ve been using FileZilla SFTP with root (yes, I know it’s highly insecure) credentials, I’d been carelessly uploading WordPress folders and plugins with root ownership, causing havoc with the auto-update system. Since the affected folders weren’t owned by the user, the user could not use their own ftp credentials to update their WP installations. I would either see error messages such as not being able to download files to the upgrades folder or unable to create plugin directories–all because the user did not own those folders.

Unfortunately, FileZilla doesn’t have a mechanism to check ownership. It only permitted chmodding file permissions, as far as I could tell. This of course created even more of a mess because I was chmodding under root, not user.

I used shell access (e.g. PuTTy) to identify ownership. To list folders and file ownership in a directory:

ls -l folderpath

To change ownership of a folderpath:

chown -R username:usergroup folderpath

where -R applies changes recursively. For my dedicated server setup, username and usergroup happened to be the same (I did not set up user groups in Apache). In this instance, folderpath referred to the root directory where WordPress was installed. Incidentally, changing the ownership of the folders reset all of the directory permissions to 755, and file permissions to 644–exactly how I wanted them.

This may have also corrected my issue with PHP sessions (still testing) with Captcha logins and form submission. I enabled PHP sessions and restored directory permissions on the working Captcha folders to 755. Will continue to test this.

Also, be wary of changing ownership on public_html. One of my sites had user:user ownership on the folder, causing the website to be inaccessible. Chown-ing the public_html back to user:nobody fixed the issue.

Technical

Protecting copyrights

I’ve had a run-in with scrapers and sploggers about a couple of years ago when my main site was exposed to the public. After locking down the info and making the domain private, I’m now thinking of more proactive ways to protect a blog site. Since the garden info is slowing being spun off to its own domain, I’ve taken action to post a Creative Commons license after each section with the help of the Open Attribute plugin. I’ve also bolstered the contact form by going with the Fast Secure Form, related to the SI Captcha anti-spam plugin. I’m wary of opening up comments, pingbacks and trackbacks at the moment until I determine if FriendConnect will allow users to register and follow my blog without a formal WP-based registration.

Meanwhile I have to be vigilant. I have Akismet, and I need to review my Analytics stats to ensure that I’m not being targetted by leeches. Of course, I also can look up who’s been duplicating my content on Copyscape.com. And I should think about watermarking my photographs…amateur as they are.

Technical

Modding WordPress themes

I planned on upgrading the visuals on the spinoff garden site with some fancy new graphics. But I also discovered that I could easily change the headline fonts by using Google web fonts. I also added a custom-colored dragonfly favicon to the site via an online editor.

I also integrated the Google Friend Connect system to the new site, but I’m still having a hard time comprehending all of its functions. It seems much of it is disconnected from Google itself, and I’m not sure how practical an addition it will be. The issue I’m experiencing relates to the commenting system, and so far all I’ve been getting is a message stating: “We’re sorry…We were unable to handle your request. Please try again or return a bit later.”

Last task related to the new site is opening comments/pingbacks/trackbacks. Putting the site up publicly risks spamming, but I think the experience will give me an opportunity to learn how to prevent attacks in the future.

Update: got some help from the GFC wiki installation document. Looks like the GFC comments works and has replaced the native WP commenting system.

Technical

Hair-pulling Chrome bug

I’ve been experiencing a recurring problem with the Chrome browser that has other users pulling their hair out and switching back to Firefox. The issue is apparently an old one, in which the Chrome browser fails to render checkboxes correctly. Other users mention radio boxes are affected too.

In my quest to spin off my garden content into a separate blog, I’ve been dependent on a plugin to also port over the photo links. The Faster Insert plugin requires me to bulk select/deselect photos, and when the checkboxes disappear, that makes the task impossible. I hope that the Google team fixes this issue soon.

Technical

More ways to unban an IP from iptables

Since my iptables keeps growing, listing the whole table can take more than a few minutes these days. I dug around and found a couple of options that will do the job faster:

iptables -D chainname -s theipaddress -j DROP

Alternately, you can list:
iptables -L -v --line-numbers

Then delete:
iptables -D chainname linenumber_of_IP_to_delete

This will make cleaning up the Fail2Ban tables a lot easier, especially if one of your users decides to ban himself and you have to sift through a ton of numbers to find his IP.