Continuing with my WordCamp NYC talks review, I'd like to point out the notes I took attending the talk Caching and Optimization for WordPress, by Jeremy Clarke.

I believe this was a great topic to be covered for people who actively maintain WordPress installations and have to deal with upgrades, stability and reliability. However, I also think Jeremy took a much more basic approach for this topic the way it shouldn't have to be. He would describe all the tools that he was showcasing from the most basic parts of it, like what's a terminal or why you should use it, to an audience attending the advanced development track.

Anyway, here are my notes:

• Expect a lot of traffic for your websites.
• First point of review, slow database queries.
• Caching.
  • Serving already fetched data.
• WP Super Cache (mandatory cache plugin).
• WP Tuner (resources information).
• YSlow, Yahoo's Firebug plugin.
• If necessary, use Gravatar.
• Memcached for WordPress.
• "CLI: The DOS-style of using a computer". What a quote.
• htop, a much more intuitive top.
• apachetop, an Apache processes visualizer.
• MySQL Tuning Primer Script.
• Use either APC, memcached or XCache.
• Monit, triggering commands.

After the talk I prompted him to whether he would consider also moving away from Apache and trying much faster alternatives like FastCGI PHP on nginx or Cherokee. He mentioned that he had considered it, but he preferred to stick with the most conventional and commonly used software for his installations. That's his opinion, of course. On mine, based on my own experience, dropping Apache is usually one of the best ways to workaround most of the issues around a slow WordPress.

Now thanks to WordPress.tv, we have a video of the talk that Jeremy delivered on a previos event:

And his slides:

Remember Vitacilina? A small aggregation library I wrote last year to be intended to replace Planet on Planeta Linux? Well, it never quite replaced it but it achieved some level of stability since I was using it for a number of tasks at work. So, during this long holiday weekend, I received a notification that the Request To Package bug I had filled against the Work-Needing and Prospective Packages in Debian has already been taken care of and the library had been uploaded. Of course, I could have made this myself a long time ago, but at the time it was simpler and faster just to hope someone else would do it at some point.

So, Dario did it. He packaged it and uploaded version 0.1 under the umbrella of the Debian Perl Group. Hurray!

But then I realized that Alexandr Ciornii had implemented some nice changes to Vitacilina back in September that I never got to include or release as a CPAN distribution. And so I just did. I've uploaded 0.2 to CPAN and you can fetch it with cpanf Vitacilina or wait for the Debian Perl folks to update it

Continuing my notes and remarks from WordCamp, I attended Writing Secure Plugins, which was given by Mark Jaquith (@markjaquith on Twitter). I found the talk to be also slightly introductory on security matters but nicely oriented to WordPress plugins and general PHP Web app development. I believe most of the tips given should be taken into consideration by every PHP coder out there, not just WP people.

The talk was split into the different attacks that are common on Web applications and mainly pointing to functions and actions to be taken. Here are my notes:

SQL injection

• esc_sql(), allows you to escape SQL queries.
• absint(), allows to convert an ID value to its positive integer value to prevent ID injection.
• $wpdb->update(), a WordPress API method to update data.
• $wpdb->insert(), a WordPress API method to insert new data rows.
• compact(), PHP core function that lets you use variable names as strings.
• $wpdb->prepare(), crafts a secure SQL statement with placeholders.
• $wpdb->get_var(), returns a single variable from WordPress data.

Cross-site scripting (XSS)

• "Everything is suspicious".
• esc_attr_e(), escapes a translated string to be used as an HTML tag attribute.
• esc_html(), escapes general HTML.
• esc_attr(), escapes a string for tag attribute.
• esc_url(), encodes URL.
• esc_url_raw(), encodes URL without HTML entities to be encoded.
• esc_js(), encodes JavaScript code.

Cross-site request forgery (CSRF)

• Understand the difference between authorization and intention.
• Nonces (token handling).
• wp_nonce_field() and then, check_admin_referer().
• current_user_can(), API capability checking.

AJAX CSRF

• &_ajax_nonce = NONCE

Privilege escalation

Stupid shit!

• Avoid exec() at all costs!
• Use blank or hardcoded paths instead of $_SERVER['REQUEST_URI'] on form submission.

Presentation

It's very pleasant for me to announce that the probably most descriptive domain name in Mexico for Linux, linux.org.mx, is now powered by Planeta Linux México.

I see this as a great milestone of all the members of the Mexican Linux community that have made Planeta Linux the number one Web site in Mexico for Linux. Also, please raise your drinks for @negrabarba, who made this possible, administrator of the DNS at UPN, where the domain name points to; and of course for Miguel, the owner of it.

Here I start a series of posts with my comments, notes and remarks on the talks that I attended at last weekend's WordCamp in NYC.

The first talk I attended was Securing WordPress, by Brad Williams (@williamsba on Twitter). First off, this talk wasn't too technical since it was focused to beginning developers whose background wouldn't be completely into systems administration, it was intended to a broader audience, which is exactly why I liked it so much and started taking notes. You need some mild level of expertise on WordPress for most of what Brad mentioned but you don't have to be an expert.

So, most of the notes I took were taken directly from the slides (that you can browse below in the Slideshare widget), but I also add some homebrewed comments myself:

Don't use the admin account: Change it

Hackers will most likely target to the most privileged account on a WordPress that by default goes by the name of "admin" and you don't seem to be able to change it easily from the administration panel. Go ahead and do it on the MySQL shell yourself:

UPDATE wp_users SET user_login="notadmin" WHERE user_login="admin";

Change your files' permissions

This is what Brad called "The Great Permission Debate". You are basically fine if you leave all files under 0644 and directories under 0755.

$ find wordpress_root/ -type f -exec chmod 644 {} \;
$ find wordpress_root/ -type d -exec chmod 755 {} \;

Take wp-config.php out of WordPress

Starting in 2.6, WordPress will also look for the wp-config.php configuration file on the parent directory of your WordPress directory, which depending on your setup, might be not reachable to your web server's public files.

Move plugins and uploads directory out of WordPress

Also since 2.6, WordPress can be configured so that you don't have your plugins and uploads directory (where you upload files from the administration panel) to point somewhere else. You can do it by setting the constants WP_CONTENT_DIR, WP_CONTENT_URL, WP_PLUGIN_DIR and WP_PLUGIN_URL:

define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/your/blog/contents');
define('WP_CONTENT_URL', "http://myblog.com/contents");
...

Remove the WordPress version from the META head

WordPress apparently uses the generator META tag to scan for WordPress installations and create statistics of usage. That also enables possible attackers to discover what version of WordPress you are using, and if you are using an old vulnerable one, you might get hit. You can use the WordPress function, wp_head() instead.

Stay current on updates

Of course, always focus on getting the latest updates installed.

Secure passwords

Don't use "password" or "a" or "123" as a password for your installations. I recommend generating your password with a little tool called pwgen.

Secret keys

You can add some salt to your password by setting values for a few secret key constants. This will make a better encryption on the information stored on the user's cookies. Codex puts this as an example:

define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YKC^Z7KKGh j>k[.Nf$y7iGKdJ3c*[Kr5Bg');
define('SECURE_AUTH_KEY', 'TufWOuA _.t>#+hA?^|3RfGTm>@*+S=8\"\'+\"}]<m#+}V)p:Qi?jXLq,<h\\`39m_(');
define('LOGGED_IN_KEY', 'S~AACm4h1;T^\"qW3_8Zv!Ji=y|)~5i63JI |Al[(<YS<2V^$T])=8Xh2a:b:}U_E');
define('NONCE_KEY', 'k1+EOc-&w?hG8j84>6L9v\"6C89NH?ui{*3\\(t09mumL/fFP_!K$JCEkLuy ={x{0');

For more information on each of these secret keys, go to read their documentation.

Change the WordPress tables prefix

The database for a WordPress installation uses a prefix on each of the tables it uses, by default "wp_". You can change it to be a custom value.

Make sure you have HTTPS and force login and admin access through it

If it's possible, enable SSL on your host and configure WordPress to pass all login information and administration access through it. You can do it by setting the constants FORCE_SSL_LOGIN and FORCE_SSL_ADMIN to true.

IP lockdown

If you are using the Apache webserver, you can configure it so that it only allows  access to /wp-admin from a given IP (work or home only). You can do just about the same with any other webserver available (namely, nginx).

Security Plugins

Some of the following plugins will make your life easier. I recommend taking a look at them, they are worthwhile!

WP Security Scan

Scans your WordPress installation for security vulnerabilities and suggests corrective actions.

WordPress Exploit Scanner

This plugin searches the files and database of your website for signs of suspicious activity.

WordPress File Monitor

Monitors your WordPress installation for added/deleted/changed files. When a change is detected an email alert can be sent to a specified address.

Login Lockdown

Login LockDown records the IP address and timestamp of every failed login attempt. If more than a certain number of attempts are detected within a short period of time from the same IP range, then the login function is disabled for all requests from that range.

Finally

Some of the actions here are just preventive or simple security by obscurity. Truth is, you will never be 100% secure and you have to be certain that you understand that.

Presentation

This is Brad's presentation:

During last weekend's WordCamp, Jeremy Clarke gave a bunch of tips for websites server optimizations (I'll summarize my views on his talk later on a separate post) and he showcased a plugin for Firebug that I didn't know about and caught my attention: Yahoo! YSlow. It is a really nice piece of software, it adds a tab on your Firebug window and will grade the performance of the web page you are browsing with a set of tips on how to make it faster, ranging from images, CSS, JavaScript, headers, etc:

I find this to not be the ultimate solution to fix your websites' loading speed of course, but something advisable to use and try to comply against.

I believe it's time for me to get my blog from D to A

Our tenth season continues next Tuesday night:

Perl Seminar New York
Tuesday Nov 17 2009
6:15 – 8:15 pm
NYPC User Group
481 8th Ave (Ramada New Yorker Hotel, West 34 St)
Suite 550

Main Topic: Perrin Harkins: "Choosing a Web Architecture for Perl"

Perl Seminar NY is once again pleased to welcome Apache expert and veteran Open Source contributor Perrin Harkins to speak at our meeting.

In the past few years, many new web proxy servers have come onto the scene with new performance promises and features. Servers based on non-blocking I/O bring claims of greatly improved performance. At the same time, FastCGI has become more widely used, giving people a possible alternative to mod_perl. Perrin's talk will help you choose the right architecture for your project by presenting a useful set of benchmarks and a comparison of strong points and key features.

Hope to see you on Tuesday November 17.

Jim Keenan
Moderator

I had a blast on Saturday. Let me put it again in bold, I had an awesome experience yesterday at WordCamp NYC. If you ever have the opportunity, you shouldn't miss the chance to attend one of them, it's really inspiring, people is very, very welcome and I loved the fact that there's so many people with all sorts of backgrounds and focused on many fronts on the Web and blogging world, not just technical.

During the course of this starting week, I'll be posting my notes and remarks on each one of the talks I attended, I believe they do require their own attention. With as much as eight simultaneous tracks, it was pretty much impossible to hear them all, so I focused on technical talks (go figure) and on the "beginning developer" track, since I pretty much knew close to nothing when it comes to WordPress core development.

Unfortunately I couldn't attend Sunday sessions due to health issues. I'm seriously sorry about that. Anyhow, to be honest, I cannot easily recall another conference that left me with such a nice feeling after attending it.

Also, expect more blogging here.

So I've spent quite some time in the last couple of months (whenever I had a chance, actually), to redesign how the core of Planeta Linux works, and I'll explain all the changes I've made to make it a much better solution that fully fits our current needs. If you are reading this with a feed reader, star this item, share the item, retweet the post! Let everyone know we are doing this for the Linux Latin American community!

If you're naive enough, you'll think about Planeta Linux as a simple Planet aggregation instance with a different set of people collections, which we used to call, ironically, instances, which aren't anything else but countries. If you don't know how we've been doing Planeta Linux for almost five years now, you'll think it's all just config.ini being fed to the planetplanet binary. Well, it has been like that, yes, but having a big set of planets (more than ten now) makes it a bit of a hassle to do any changes or try to do anything else but add, edit and remove people. The way we were handling it with Apache was already documented in the past.

Some of the multiple issues Planeta Linux has had in the past could be summarized as:

• Inability to have a unified templates set.
• Repeated feeds of the same person on multiple countries.
• Inability to know when a feed started to properly return valid items.
• Error-prone parsing.
• Difficulty to test on local environments.
• Decentralized subdomains with difficulty on sharing content or awkward navigation between contries.

And the list could go on. I realized this was a huge pain in the ass when I had the intention to centralize the subdomains into a single one: Instead of using the model $country.planetalinux.org, everything would have to come out from just planetalinux.org. Changing to that on our previous scheme was simply an hemorrhoid. So, I changed it all and the new model is much better and robust, even though you probably don't see a single difference on the current Planeta Linux output.

I started by getting rid of the horrible config.ini editing. Whenever you want to add an author, you simple drop a YAML file into the authors directory. It doesn't matter the location of the file as long as it's inside the authors directory. When I started importing all of the subscribers, I ended up with more than 620+ author files so I made a simple separation of files a-la CPAN: authors/d/da/david_moreno.yml. But at the end, it doesn't really matter, a) what your file is named, and b) where you put it, they will all get parsed and interpreted. Now, inside that YAML file there's a bunch of goodies. Firstly, you have the feed URL, the name of the person, his or her email, an array of countries where the feed should be aggregated into and other stuff such as the path for the hackergotchi, a twitter parameter for the Twitter feed, an enabled switch, etc. The good thing about it is that you can have all the parameters you want so we can build on top of that later (maybe identica profiles, LastFM usernames, whatever).

One of my future intentions is to have also an array of feeds on each author file which would empower us to have the same info for several feeds. With the new model, this should be much easier to implement anyway.

Anyway, basically, when you want to add or edit a feed, you just edit or drop the file on the authors directory. KISS.

Second big change, we switched to Planet Venus, as opposed to just Planet for the aggregation engine and you no longer need to have it installed since it's included now on the entire Planeta Linux tree under the venus directory. Venus implements a whole new world of features and good stuff on top of Planet, it was just a no-brainer to switch to it.

However, Venus still requires config.ini for each of its instances, so this is where the whole build process comes to play. I implemented a tool, script/build that does exactly that, it gathers all the info from authors and builds each of the countries. To create a new country, you just basically only have to add it to config/countries.list. The build script will use all of them as tasks and execute them at will.

Now, how the build tool works? As said, it gathers the data from authors and generates a config.ini on the fly. There's a config.ini template file on the template directory, as well as an index.html template (and rss.xml), and for the build script, it's just another Template Toolkit file so you can do all sorts of awesome and crazy shit with it. So it's all generated dynamically, with the information from authors, information from the config directory and it dumps it all on the www directory. Because of that, you can generate your own working copy of Planeta Linux or implement others or just play with it!

So basically, the whole process is like this for each of the countries:

The good thing about it is that there's no interaction for the administrator to deal with the config.ini either when adding an instance since I integrated a tool that adds a new subscriber to the authors tree automatically:

~/axiombox/planetalinux :master $ ./script/planetalinux.pl help add
planetalinux.pl add [-p] [long options...]

Adds a new author to Planeta Linux. The name, email, feed URL and
country where to place the author are mandatory. If the hackergotchi
image path is provided, the script will check the size for the image
and resize it if needed (ImageMagick needed). Any other flags and
values passed to this command will be appended on the resulting
YAML file.

Examples:

./script/planetalinux.pl add \
--feed http://example.com/feed \
--name "Tía Chonita" \
--email tia@chonita.com \
--countries ve \
--hackergotchi ~/images/chonita.jpg \
--twitter @chonita

./script/planetalinux.pl add \
--feed http://blog.wordpress.com/feed/atom \
--name "Isela Crelló" \
--email yeah@yeah.com.mx \
--countries mx,sv,gt \

./script/planetalinux.pl add \
--feed http://cofradia.sucks/feed \
--portal \
...etc

--feed feed URL -- mandatory
--name name of author of feed -- mandatory
--email email of author of feed -- mandatory
--countries country(ies) of author -- mandatory
--hackergotchi path to the hackergotchi image -- optional
-p --portal portal site flag -- optional
--twitter twitter feed of author -- optional

~/axiombox/planetalinux :master $

Cool things about this new "adder" script:

• It ensures that the author has an stored feed, name, email and country, at the very least.
• It checks whether the URL is a valid feed URL against the W3C feed validator.
• It checks that the email is valid.
• It checks that the countries specified are supported by the system.
• It takes a file path for the hackergotchi and using ImageMagick, it resizes it, converts it into the proper image type and places it under the appropiate image heads path.
• It creates the YAML and places under an appropriate location under the authors directory.
• It's awesome

Tutorial

Now, one of the good things about all of this is that you can create your own Planeta Linux running right there on your machine, given that well, it's just a nice big glue involving Perl for the processing, Python for the parsing and aggregation, the cache is stored on the tree as well, etc.

To start, you'll have to clone the repository if you haven't done it yet:

$ git clone git://github.com/axiombox/planetalinux.git

Change the directory to the repository and just run the dependencies installer for all of the modules used:

$ sudo perl installdeps.pl

Note that you'll have to be running perl 5.10 (it's been stable for almost two years now, dude! Upgrade!). If you already have most of the modules installed on your system, this shouldn't take that long. If you have nearly no Perl modules installed, it will probably take a little while. It might even need your intervention for some basic CPAN configuration. Once it's done, you should see something like this, at the end of the output:

.. testing loading modules...
- App::Cmd
- App::PPBuild
- Config::IniFiles
- Data::Validate::Email
- DateTime
- File::MimeInfo::Simple
- File::Path
- Modern::Perl
- Net::Domain::ES::ccTLD
- Template
- WebService::Validator::Feed::W3C
- YAML::Syck

.. done. enjoy!

.. please make sure you have PerlMagick installed.
.. the recommended way is: `port install p5-perlmagick` in Mac,
.. ..or 'aptitude install perlmagick' in Debian/Ubuntu.

Now, for the ImageMagick Perl bindings (for the "adder" funcionality) you'll need to install it depending on your operating system. If you are running some flavor of Debian (or Ubuntu), you just have to install the perlmagick package. On MacOS, I recommend installing the ImageMagick MacPorts port with the "+perl" flag. Depending on your configuration, you might need to install the Image::Magick module either from the CPAN shell or downloading it from web. Once all of that is done, you can just fire up the building system:

$ ./script/build all

You can just fire up a single country or other tasks by seeing which ones are available:

$ ./script/build --tasks

At this point you can go to your browser and navigate to the www directory on the repository where all the output has been dumped.

If you have any issues running your own local copy of Planeta Linux, please put a comment on this post, I'll glad you help you solve it and you'll be helping us making Planeta Linux much better than ever.

I'll be attending WordCamp NYC this upcoming weekend. There's a lot of very interesting talks and people speaking at the conference, so it was basically a no-brainer since it's being held in Manhattan. Plus, WordPress is one of the platforms I've always liked and admired on how they have achieved to become a mainstream product with a huge amount of active users and developers. I started using it way back in 2004 when it was b2/cafelog, so it's been a long ride.

If you'll be around, poke me.