Iptables is a firewall program that comes with Linux distributions which allows applications and clients to connect through the network and stop unwanted applications and clients from communicating to the operating system.

Here is a small example of a simple iptables script.

# Firewall configuration written by redhat-config-securitylevel
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
# Uncomment for logging
## :LOG-AND-REJECT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
# Uncomment for logging
##-A LOG-AND-REJECT -j LOG --log-tcp-options --log-ip-options --log-level debug --log-prefix "mymachine_firewall : "
##-A LOG-AND-REJECT -j REJECT --reject-with icmp-host-prohibited
#
# Allow return packets from established outbound connections
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
# Permit ssh
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
#
# Permit ping
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-request -j ACCEPT
#
# Enable rsh from the 100.138.10.16 host
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.10.16/32 -d 0/0 --dport 514 --syn -j ACCEPT
#
# Open up holes for tripwire to the tripwire servers
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.10.15/32 --dport 9898 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.10.15/32 --dport 8080 --syn -j ACCEPT
#
# Permit SMTP connections from anywhere
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 0/0 -d 100.138.10.11/32 --dport 25 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 0/0 -d 100.138.10.11/32 --dport 587 --syn -j ACCEPT
#
# Permit HTTP and HTTPS connections from anywhere
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 0/0 -d 0/0 --dport 80 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 0/0 -d 0/0 --dport 443 --syn -j ACCEPT
#
# Permit POP3S connections from anywhere
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 0/0 -d 100.138.10.15/32 --dport 995 --syn -j ACCEPT
#
# Permit IMAPS connections from anywhere
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 0/0 -d 100.138.10.15/32 --dport 993 --syn -j ACCEPT
#
# Permit SAMBA shares to the 100.138.0.0/16 network
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.0.0/16 -d 100.138.10.15/32 --dport 137 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp -s 100.138.0.0/16 -d 100.138.10.15/32 --dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.0.0/16 -d 100.138.10.15/32 --dport 139 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.0.0/16 -d 100.138.10.15/32 --dport 445 --syn -j ACCEPT
#
# Permit ftp (plus ports for passive xfers) from anywhere
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 0/0 -d 0/0 --dport 21 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 0/0 -d 0/0 --dport 50000:51000 --syn -j ACCEPT
#
# Permit MySQL connections
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.10.16/32 -d 0/0 --dport 3306 --syn -j ACCEPT
#
# Permit access to the Dell OMSA port from 100.138.16.x for management
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp -s 100.138.16.0/24 -d 0/0 --dport 1311 --syn -j ACCEPT
#
# Permit access to the Internet Printing Protocol (IPP) to share printers on a server
-A RH-Firewall-1-INPUT -i eth0 -p tcp -m tcp -s 100.138.0.0/16 -d 0/0 --dport 631 --syn -j ACCEPT
#
# Allow X11 connections
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.0.0/16 --dport 6000:6009 --syn -j ACCEPT
#
# Allow the 100.138.16.0/24 subnet to mount nfs
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.16.0/24 --dport 2049 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp -s 100.138.16.0/24 --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.16.0/24 --dport 111 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp -s 100.138.16.0/24 --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.16.0/24 --dport 32765:32768 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp -s 100.138.16.0/24 --dport 32765:32768 -j ACCEPT
#
# Allow clients on same subnet full access
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 100.138.16.0/24 -d 0/0 --syn -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp -s 100.138.16.0/24 -d 0/0 -j ACCEPT
# Deny rest
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

PF (Packet Filter) is a BSD licensed stateful packet filter, a central piece of software for firewalling. It is comparable to iptables, ipfw and ipfilter. I wanted to have a very simple example of how to setup pf on your freebsd machine and here it it :)

First enable pf by adding the following to /etc/rc.conf and rebooting you bsd host to take affect:

pf_enable="YES"
pf_rules="/etc/pf.conf"
pflog_enable="YES"
pflog_logfile="/var/log/pf.log"

when the machine is back up and running make sure pf is loaded:

moxz:~>kldstat | grep pf
 2    1 0xffffffff81022000 a3c      pflog.ko
 3    1 0xffffffff81023000 2bd41    pf.ko

(more…)

PF (Packet Filter) is a BSD licensed stateful packet filter, a central piece of software for firewalling. It is comparable to iptables, ipfw and ipfilter.

Let’s say you have the following physical setup:

And you want to use FreeBSD as your firewall and Nat’ing device, here is a small guide on how to set that up.

On your freebsd machine add the following into your /etc/rc.conf file:

defaultrouter="100.138.196.1"
gateway_enable="YES"
hostname="thewall.domain.com"
ifconfig_xl0="inet 192.138.196.100  netmask 255.255.255.0"
ifconfig_bge0="inet 100.168.196.100  netmask 255.255.255.0"
ifconfig_xl0_alias0="inet 100.138.196.2  netmask 255.255.255.0"
ifconfig_xl0_alias1="inet 100.138.196.3  netmask 255.255.255.0"
ifconfig_xl0_alias2="inet 100.138.196.4  netmask 255.255.255.0"
pf_enable="YES"
pf_flags=""
pf_program="/sbin/pfctl"
pf_rules="/etc/pf.conf"
pflog_enable="YES"
pflog_flags=""
pflog_logfile="/var/log/pflog"
pflog_program="/sbin/pflogd"

(more…)

Yesterday I went through the trouble of upgrading to WordPress 3.1 and experienced a couple of issues that I wanted to report about. Specifically, the categories and tags permalinks were not working, giving a 404 error right after the upgrade. First, I thought that it was a bug in WordPress 3.1, but then I started investing the issue a little more and found out what the actual problem was. The second problem came up with my wordpress multisite (old WPMU) configuration – the /blog slug came back again and I had to deal with that issue separately as well. Gladly, I was able to find a fix for both of these issues and WordPress 3.1 is running very smoothly now. If you have a similar problem after upgrading to WordPress 3.1, follow along.

The problem with the permalink structure getting messed up is related to several plugins. The plugins that generate problems with WordPress are some of the most popular WordPress plugins and I hope the authors will come up with a fix soon. Meanwhile, you will have to disable them. Here is the list of plugins that break permalinks on WordPress 3.1:

• Simple Tags
• Multipage Toolkit
• Top Level Categories

If you have any of the above plugins, here is what you need to do:

1. Disable the above plugins
2. Within the admin area in WordPress Go to Settings->Permalinks
3. Copy your “Custom Structure” that you are using by selecting it and pressing CTRL+C
4. Change your permalinks to “Default” and Save
5. Change permalinks back to “Custom Structure” and copy-paste (CTRL+V) the permalink structure you were using before

The above will fix the problem with categories and tags not working – the permalink structure will be regenerated and life will be good ;-)

If you have a WordPress Multisite installation like me and you do not want to have the “/blog” slug for the first WordPress site, then after the above steps are done, you have to download and install the “Remove /blog slug plugin from WordPress MU“. Next, go back to your permalinks in settings once again, change it to Default again, then change back to your Custom Structure and the problem will be fixed. You can disable the plugin once this is done.

Hope this helps!

One of the biggest annoyances with WordPress, is the way it resizes images and makes thumbnails. First of all, it completely strips out all the EXIF information, including the monitor profiles, which makes thumbnails and resized images look slightly different in color than the original files (yes, even for images saved with sRGB profile). Second, the image quality of thumbnails and resized images is often poor, making images appear quite soft. This all happens because WordPress utilizes GD as the graphics library for processing images and there are no out-of-the-box options for the blog admin to improve the quality of images through the administrative interface. If WordPress allowed using other graphics libraries such as ImageMagick, you could easily improve the thumbnail and resize image quality and many more options such as sharpening could be added to process images. While the above might not be of interest to the general public, it is certainly something many photographers are looking for.

I found a great workaround to solve this problem! It will require you to edit your WordPress theme file and a single file from the WordPress source file called “media.php”. Unfortunately, there is no way to make it work without touching the WordPress files, because the function that resizes images called “image_resize” is hard coded and does not let plugins to change it.

(more…)

Samba is an Open Source/Free Software suite that provides seamless file and print services to SMB/CIFS clients. In laymen speak, it allows windows machines to connect to a Linux samba share :) I will break this guide down into 3 parts: Compile/Install, Setup, and Actually Running the Service.

1) Install Instructions

Download the source from the following URL: http://www.samba.org/samba/download You should get a file that looks similar to this: samba-3.4.0.tar.gz.

mv samba-3.4.0.tar.gz /tmp; cd /tmp
tar xzf samba-3.4.0.tar.gz; cd samba-3.4.0/source3

Setup up appropriate environment variables
*For solaris use /usr/sfw/bin/gcc

set path = ( /usr/sfw/bin $path )
setenv CC "gcc -Wl,-rpath,/usr/local/samba/lib"

*For Linux

setenv LD_RUN_PATH /usr/local/samba/lib

(more…)

Do you ever put category and tag descriptions while creating them? I used to do it in the beginning, but then as I got busy I started simply inserting tags and categories without any descriptions attached to them. Over time, I was getting a little annoyed by the fact that some categories and tags have names, while others do not, so I created a quick SQL code to take care of this issue. Basically, the SQL code just goes through all WordPress tags and categories and copies the category/tag name into the description field.

Make sure to backup your database before you do this!

Here is the code for updating category description:

UPDATE wp_term_taxonomy LEFT JOIN wp_terms ON wp_term_taxonomy.term_id = wp_terms.term_id
SET wp_term_taxonomy.description = wp_terms.name
WHERE wp_term_taxonomy.taxonomy = 'category'

And here is the code for updating tag description:

UPDATE wp_term_taxonomy LEFT JOIN wp_terms ON wp_term_taxonomy.term_id = wp_terms.term_id
SET wp_term_taxonomy.description = wp_terms.name
WHERE wp_term_taxonomy.taxonomy = 'post_tag'

I recently had to go through the nightmare of converting from standard WordPress installation to WordPress MU. The reason why I say “nightmare”, is because the process turned out to be rather complex and painful in terms of keeping all data consistent. My original plan was to simply export the data from WordPress standalone and then import it into WordPress MU. But after I imported everything, things did not work out as well as I hoped they would. For whatever reason, all of my categories and tags were messed up and when I went to the categories page in WordPress admin page, the categories showed 0 posts and the same thing happened with my tags.

I then tried to look for other ways to do this right and stumbled upon a suggestion in Google to simply rename the database table names. Everything seemed to work perfectly, until I started encountering database inconsistency issues with three separate blogs in one WordPress MU installation. It turned out that WordPress MU works by assigning one category/tag ID for the same category name that is used across different blogs. Inevitably, my categories and tags eventually started conflicting with different category IDs assigned to the same category/tag.

Wanting to fix this problem as soon as possible, I went back and tried to do it right from the beginning. It turns out that the best way to do it without creating any potential database inconsistencies is through export/import process within WordPress. Once I exported and imported everything, the problem with categories and tags not showing up came back to haunt me!

I looked at the data on table level and everything seemed to be mapped correctly, very similar to what I had in my original WordPress installation. I kept on digging until I accidentally tried something and it worked! I tried assigning the first WordPress post “Hello world!” to one of the categories and voila – it showed up! So, if you are experiencing the same problem with categories and tags in WordPress, here is what you should do:

1. Make sure not to delete the original “Hello World!” post that gets automatically created by WordPress. If you have already deleted it, create a new dummy post that you can later delete.
2. Make sure that the WordPress import process is successfully finished.
3. After all posts and pages have been imported, go to “Edit” under “Posts” and edit the “Hello World!” or dummy post.
4. Go through each of the categories and put a checkmark in front of every single category.
5. Save the post.
6. Visit both the “Categories” page in the admin section and the main page and make sure that all categories show up correctly with the correct number of posts attached to them.

This will fix the category mapping issue. Now let’s move on to tags.

The problem with tags is much more complex than with categories. If you have a large site with thousands of tags, you do not want to be manually inputting those one by one. Gladly, I found a good solution that worked for me!

You will need to have access to an SQL query tool to grab the tags data. Fire up PHPMyAdmin or whatever else you are using and type the following query against your current WordPress MU database:

SELECT CONCAT(wp_1_terms.name, ',') FROM wp_1_terms LEFT JOIN wp_1_term_taxonomy ON wp_1_terms.term_id = wp_1_term_taxonomy.term_id
WHERE wp_1_term_taxonomy.taxonomy = 'post_tag'

The above query should return a bunch of lines with all of your tags with a comma at the end. Obviously, you will need to change the wordpress blog ID if you are using a different blog ID than “1″. Start from the top and select everything all the way to the bottom, then press CTRL+C to copy the tags data.

Next, go to the same “Hello World!” dummy post and copy-paste the tags data into the tags input field and save the post.

All of your tags should now be correctly mapped! :)

This is another fix to Donncha’s Sitewide Tags plugin that eliminates the problem of having certain categories show up as numbers in the sitewide blog in WordPress MU. In my WordPress MU installation, there was a problem with specific categories showing up as numbers for whatever reason (I figured out the reason later and went through the nightmare of permanently fixing it). When I looked at the sitewide blog tables, some of the categories were written as numbers instead of full category names and category slugs. Apparently, Donncha’s plugin relies on WordPress MU handling the category IDs that are supposed to be the same across all blogs – i.e. a category in blog 1 should have the same category ID as a category in blogs 2, as long as the category names and slugs are the same. When I looked at my installation, I found out that I had different category IDs for the same categories, due to the fact that I simply renamed some of the main tables instead of importing/exporting them when I migrated to WordPress MU from standalone WordPress installation. I certainly didn’t feel like redoing everything from scratch and looked for an alternative solution that would work for me, so here it is.

Find the line: “$post->post_category = wp_get_post_categories( $post_id );” and modify the below foreach code as shown below:

    foreach( $post->post_category as $c ) {
        $cat = get_category( $c );
        $cats[] = array('name' => wp_specialchars($cat->name), 'slug' => wp_specialchars($cat->slug));
    }

Then, locate the first “switch_to_blog( $tags_blog_id );” line and modify the code as shown below:

    switch_to_blog( $tags_blog_id );

    /*
     * We first need to insert the categories into the new 'terms' table
     * Then we need to get the ID of the category and use it while inserting the post
     */
    if( is_array( $cats ) && !empty( $cats ) ) {
        foreach( $cats as $t => $d ) {
            /* Here is where we insert the category */
            wp_insert_category( array('cat_name' => $d['name'], 'category_description' => $d['name'], 'category_nicename' => $d['slug'], 'category_parent' => '') );

            /* Now get the category ID to be used for the post */
            $category_id[] = $wpdb->get_var( "SELECT term_id FROM wp_" . $tags_blog_id . "_terms WHERE slug = '" . $d['slug'] . "'" );
        }
    }

The last change is to use the category IDs that we grabbed above while posting the entry. Locate the line that says “$post->comment_status = ‘closed’;” and insert a single line as shown below right above wp_insert_post:

        /* Use the category ID in the post */
        $post->post_category = $category_id;

        $p = wp_insert_post( $post );

That’s it, now all categories will always have the right category name/slug in your sitewide tags blog!
P.S. The above code changes have already been applied to SiteWide tags plugin by Donncha, so make sure to get the latest version from wordpress.org.

If you are using Donncha’s Sitewide Tags plugin for WordPress MU along with Alex King’s Twitter Tools, you might get frustrated with the fact that you will see two duplicate notifications on Twitter – one from the original blog entry, and one from the sitewide blog.

Here is how you can stop duplicate twitter tools notifications in sitewide tags – you will have to edit Twitter Tools:

Open up “twitter-tools.php” in the plugin folder, then locate the “do_tweet” function in the code. Right under “function do_tweet($tweet = ”) {“, insert the below code:

		global $wpdb;
		if (isset($wpdb->blogid) && $wpdb->blogid == "4") {
			return false;
		}

My sitewide blog ID is “4″, so if yours is different, make sure to change the number to the corresponding blog ID. You can locate the blog ID in wpmu-blogs.php page. Save the file and you are done!

I know this is not the most elegant way of doing this, so if you come up with a better method, please let me know.