November 2006 Archives

Looks like I found the culprit that caused my PlugIns to disappear on my MT 3.33 installation. Turns out it was my old friend SELinux!

This had crossed my mind before but the fact that it was working at one point and then just ceased working caused me to dismiss SELinux as an issue. Maybe something was updated in the upgrade process that Fedora uses and altered the SELinux policy after the upgrades were installed. I'm using Fedora 6 on this new system which I'm still configuring Movabletype and other applications on before making this system my new web host.

I'm very surprised I have not ran into this issue on my current MT 3.2 installation.

I cannot take credit for the fix though seems that Sixapart advised the fix a while ago to a user who ran into this with Fedora 4 MT 3.2.

I found the following fix via a Google search on the user's Sixapart blog they recommended the fix to who was giving details of his upgrade from MT 2.66 to MT 3.2.

Here are the contents of what I found and it worked for me:
####################################################################################
Do you have SELinux enabled on this server? You can run "system-config-authentication" as root to verify that this is enabled. The settings of SELinux are what caused the PlugIns to not be seen by Movable Type.

In this file: /etc/selinux/targeted/contexts/files/file_contexts
there is this rule:
/var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t

That rule basically means that the /var/www/cgi-bin directory (and all subdirectories) have a "httpd_sys_script_exec_t" context. Meaning that CGI scripts can execute from this location.

In the case of the /var/www/cgi-bin/mt/PlugIns directory, each Plugin directory (and the /var/www/cgi-bin/mt/PlugIns folder itself) should have a context type of httpd_sys_script_ro_t. This allows read-only file access to the directory and files and also execute permission.

To adjust the context for the PlugIns folder, use this command:
chcon -R -t httpd_sys_script_ro_t /path/to/mt/PlugIns
####################################################################################
Now I'm continuing to go ahead configuring this new web server for testing and then roll-out!

I also posted this to Sixapart forums: http://forums.sixapart.com/index.php?showtopic=59878

I also just completed pointing this system to my other WAN static ip.adress on my other router, pointing my Apache web server to the second NIC I just installed a couple of days ago and I'm ready to resume configuring Movabletype to move the content over to this system. I also had to rebuild my blog pages and edit my styles CSS file to point to the proper ip.address I'm using for testing purposes.

Why do things like this get fixed late at night give you some energy to start configuring more until you hit a new issue and then you end up with very little sleep?

Well this time I'm going to go to bed like I should........ but let me do a few more things first.....

Wow!! Tonight really emphasized why I need to take some time and just straighten out my wiring situation in my computer room. I have had so much other real life drama I cannot even discuss I have taken a patch and get to it later mentality since the other issues are far more serious but I need to get this straight soon! I have also been on vacation so I relaxed and indulged in some other hobbies as well such as sight seeing and Scuba diving.

Okay what happened? Here’s the long and long of the story!

I have been testing out my new web server installing the base OS packages and performing updates. Until now I have been letting this new system I built running Fedora 6 run into whatever issues it can before I started installing and configuring my web applications.

Well last night before going to bed I decided to start with my web applications and installed Movabletype 3.33 on this FC6 system. I got everything up and configured up until I needed to configure my first blog and went to bed.

Today I explored the Sixapart Movabletype forums, manuals notes to see if I wanted to go to dynamic pages or PHP since a few of my other applications are PHP and I decide to stick with static pages for a few reasons.

I then started the process after watching some basketball and football games to start configuring my first blog and importing the data from my existing blogs over but first I wanted to test some functions. I ran into the typical permissions issues on plugins and directories. I then tried testing Stylecatcher and after running into more permission issues determined it couldn’t get out of my router on port 80.

I decided to fix this by opening up port 80 briefly on my router that is on the same network as my current web server briefly knowing the potential issues with two systems pointing to port 80 on the same router. Well Stylecatcher worked nicely and of course my current web server stated toggling with my web server I’m testing and this made my Web pages act little nuts for about 5 minutes until I discontinued pointing to the new web server with the router.

I guess I could have made Apache look for this system on another port other than 80 but I had a better idea that I wanted to do for other reasons. My other idea was to put another NIC in this system so it would connect to both my networks for data transfer and redundancy reasons. This way it would point to my other static ip.address and I could test at will and have minimal changes to make it my main web server when switching back to my other network.

I put in the additional NIC which wasn’t an issue. I took the system out of the rack put the card in plugged everything back in plus I also plugged in the new NIC to my other network and this is where the weirdness started!

I had it pick up an ip.address via DHCP just to prove it was working and connecting to the correct network. This seemed to work ok but I should have noticed the ip.address it picked up. I then set the ip.adress statically and then rebooted and walked away for a minute.

When I came back after the reboot I checked in /etc/sysconfig/devices/ and there was a device called “ifcfg-eth0.bak. I looked in “system-config-network” and it was listed there as well as “eth0.bak” along with “eth0” & “peth0”. “peth0” turned out to have the settings of my original NIC along with “eth0.bak” with “eth0” having the DHCP settings of the new NIC.

Well I tried to change “eth0” back to the original settings and that didn’t work. Then a new interface named “peth0.bak” appeared. I cannot remember all of the various different combinations of generated NIC names that I tried and were automatically generated but there were quite a few!

I then decide to look at my other multi-homed Linux system that is running Fedora5 and search in Google and other search engines for what some of the variables were in the/etc/sysconfig/devices/ files. I found I had to switch “PEERDNS=yes” to “PEERDNS=no” and fix my “resolv.conf” to the proper DNS nameservers for my ISP.

I switched the new NIC back to DHCP after all of this to prove it was connecting to the correct network. I checked the systems and they resolved the other systems in my network off both interfaces properly. I then checked the DHCP ip.adress assigned to my new NIC and it had a WAN ip.adress!!

The only way this could happen is if it was connecting straight to my WAN which I found out it did! I have my WAN come into a switch and then I have two routers connected to that switch and give both routers my static WAN ip.addresses and then each router has its own set of LAN addresses.

What happened during one of my testing periods when I was switching my LANs’ over to Gigabit was somehow both routers went to a Gigabit switch on the respective networks shared with multi-homed systems. All my systems have static ip.addresses so this issue never showed before!

I had to go through my spaghetti of LAN cables and make sure that from my ISP’s modem it comes to my 10/100mb switch, to my 4 port routers and then they uplink to the 1gb hubs and then to the correct systems!

This just shows what could happen when you test and don’t put things back. This has had to been like this for a few months. Now my network speed should be better for the WAN & LAN. Plus it heightens the awareness that I need to put into action my game plan with my patch panels and wire harnesses that I have already purchased to get things in order!