Technical

It helps to know how things work

Linux Opinion Technical Training

It really helps to know how things work when it becomes necessary to fix them.

This was true when I was fixing audio equipment in the early ’70s, and supporting computers and software for IBM, MCI, Interpath, and Cisco over the years, and teaching Linux for Red Hat and my own company, Millennium Technology Consulting LLC. The intimate knowledge of how Linux works has also been invaluable since I started working with it in about 1996.

Unless you know how things really work, there is a tendency to use a shotgun approach to problem solving. That wastes time and, if replacing parts is involved or purchasing new software, can be quite expensive.

After all, would you be willing to pay for the auto mechanic to replace several perfectly good parts while trying to find the one part actually causing the problem – and to pay him for time and materials as well? Of course not. Although that used to be the case more often than it should have been.

I submit for your approval a problem I just fixed this morning – with this web site.

It was not a problem that affected the external operation of the DataBook web site, but I could no longer use any editor from within WordPress to edit pages and posts such as this one.

Because I know several important things about WordPress I was able to think about the problem and correct it on the first try. I know the following about WordPress:

  • The data for WordPress web sites is stored separately in a MySQL database. Separation of data and code is always a good thing to do.
  • There is one and only one, small site configuration file for each WordPress web site, wp-config.php.
  • All WordPress plugins, themes, and uploaded graphics also have their own directories.
  • The Apache web configuration is separate from the WordPress site configuration.

So it was a simple matter to simply delete the entire directory in which the WordPress instance was installed for that web site. Everything.

I then copied the entire directory structure from a known working web site to replace the one I deleted. I then copied the original wp-config.php to the appropriate location in the newly copied WordPress directory structure and my web site was up and running again. It was then trivial to copy from backups the rest of the plugins and graphics to complete the process. All in all it took less than 5 minutes.

Not having the understanding I do of how WordPress, MySQL and Apache work together to produce a web site, I would have been tempted to simply delete everything in the WordPress directory (/var/www) for that web site and start over by reinstalling WordPress and configuring it from scratch. As easy as that is for WordPress, it would still have taken much longer than it did for me to actually fix the problem.

If I had understood more about the PHP coding of WordPress itself, I probably could have simply repaired the offending file that was likely corrupted for some reason. But that would probably taken much longer in any event.

If you are interested in learning how Linux works so that you can identify, understand and fix problems in the most effective ways, try the Linux classes I offer at Millennium Technology Consulting LLC.

More about Fedora 18

Information Linux Reviews Technical Tips and Tricks

In my review of Fedora 18, I discussed my initial impressions of that newest release. Having now begun to install Fedora 18 on several more hosts in my constantly changing world I have found some interesting under the cover changes.

firewalld

A new firewall, firewalld, is now the default firewall for Fedora. Of course Fedora is the proving ground for many new things so, while this change was not particularly well documented, changes to Fedora in general should not be a surprise. The firewalld daemon is mentioned in three short paragraphs in the Fedora 18 release notes which only references the man pages for the new firewalld commands for further information, and once as being a new addition in the Technical Notes document. Both are available as PDF files from the Fedora Documentation Project.

The firewalld rules are quite complex compared to what I have been using with IPTables. This, and the fact that I am not yet familiar with the rule syntax or the overall structure of firewalld means that, for now at least, I need to revert to IPTables on my Fedora 18 hosts.

Reverting to IPTables

The good news is that the old IPTables firewall is still available until I can learn how to best create the firewall rules I need with firewalld. However it, too, has changed and some of the old IPTables rules, especially those using state related rule sets have been altered.

First, to convert back to IPTables, stop and disable the firewalld service and start and enable the iptables service.  Of course you must do this safely with your network disabled until you can get your new (old) firewall back in place. Then use the iptables-restore command to restore your old IPTables rules from the saved copy. You did save a backup copy of your IPTables firewall rules, right?

At this point, IPTables gives some errors indicating that one should use new connection tracking rules in lieu of the state-related rules. The best part is that IPTables is smart enough to give you the warning message and then translate the rules into connection tracking rules. At that point you can simply use the iptables-save command view the translated rules and redirect the output to /etc/sysconfig/iptables to save the translated rules.

So now I will take some time to learn this new firewall system while my IPTables firewall protects me.

Here is a link to the Fedora Project FirewallD documentation. http://fedoraproject.org/wiki/FirewallD

Install Issues with Fedora 16 and EXT4 Filesystem

Information Linux Technical

I just had an interesting experience while installing Fedora 16 on my primary workstation. It took me about 3 days and many attempted installations to figure this out. This is not a review, just a bit about my experience.

At first I wiped out my hard drive entirely since it has been several years since I did a really clean installation. That is, a complete wipe out of my hard drives—after first making certain that I had multiple good backups. Over time much cruft can accumulate from old application configuration and data and I wanted to get rid of everything except data I really wanted to keep.

Symptoms

The initial installation of Fedora 16 appeared to go well using the default choice of EXT4 for the filesystem type. After starting to make configuration changes and restoring a few directories in my non-root user home directory, KDE started crashing on a regular basis. It would indicate problems with Segment Faults. This is not good and can mean many bad things.

After installing several times with similar results, I decided to go back to Fedora 15. During the installation, I used EXT3. I had previously experienced an occasional problem with Fedora 15 while using EXT4, but nothing particularly repeatable. Many of the problems were during installation using EXT4 and I would get errors indicating that a specific package was not able to be installed. Looking at the log terminal (Ctrl-Alt-F3) most errors appeared to be on the DVD, but the DVD always tested as having no defects at the beginning of the installation.

Solution

My decision to use EXT3 was kind of on a whim, but the next install went without problems and I had no problems doing basic configuration. So I decided to reinstall Fedora 16 using EXT3 instead of EXT4 and have had no problems since. This is using the same physical hardware and the exact same partitions and logical volumes.

I think this indicates, at least to me, that there are still some bugs in EXT4. I have not however, seen this problem on some of my other systems. Perhaps it is the larger 1.5TB drives I am using on this system.

I hope this helps by preventing you from spending 3 days to discover and resolve this problem.