Alhamdulillaah, I have really been engrossed in using ffmpeg, one of the most amazing a/v command-line tools out there, for my various personal video projects.  However, recently I was experiencing a recurring bug where I could not work with some specific codecs when either the input or the output file was on a particular drive (!).  The drive in question happened to have only one FAT32 partition, so I suspect it may have had something to do with it, as using another drive for both input & output would generally work flawlessly.  The particular action I was trying to perform was to encode a sequence of rather large JPEG files (3072×2304) into a single video file using the outstanding (but still somewhat experimental and/or unstable) FFV1 lossless codec.

So, I visited the ffmpeg website and looked at some of their bugs, but didn’t see anything related to this.  Then, after seeing some of their pre-bug report checklist, I decided to check the version of ffmpeg I had on the system, and found it to be from March.  So, I pulled-down a fresh copy of their trunk via subversion and ran configure & make (I did not run make install).  Running the resulting ffmpeg binary from this compile run worked perfectly, alhamdulillaah.

The lesson is, if you’re running into a bug with either ffmpeg or any other package, then give a shot at running the latest code, if available.  It may seem like common sense, but I had underestimated just how easy it would be.  Surely, other packages may not work as simply, but it really was a piece of cake in this case.  Now I guess I need to learn how to package RPMs so I can help out the Livna project to get this latest code into their repository, which I also understand is not simple task, as many other projects rely on ffmpeg…

function search
{
    time find . -name '.svn' -prune -o -exec grep -inH --color -e "$1" '{}' ;
}

The search function takes as its only parameter the string for which you are searching. Three standard *nix programs are utilized – time, find, & grep.

The time program is completely optional, and I just like to use it on most commands I execute in the terminal because I like to see how my different parameters affect general execution time.

There are seven arguments to the find command, amongst them being the call to the grep command, which will be explained later. The first argument to find, ‘.‘, simply tells find “search in this directory”. By default, find will also recursively descend into subdirectories, and this is the behavior that I was looking for. The second argument, ‘-name‘, states that I want to match according to a name or pattern. The third argument, ‘.svn‘, is the pattern which I am trying to match – in this case, the special directories that hold specific subversion information. The fourth argument, ‘-prune‘, tells find that I want to exclude directories that match the previous pattern. This means, do not list directories that match ‘.svn’ nor their contents. The fifth argument, ‘-o‘, behaves like a logical OR. In the context of this usage, it means, execute the previous match OR what comes after me. So, if the first pattern matched, then find moves to the next file, or begins to execute the next parameter, which is ‘-exec‘, which tells find that I want to execute a command for every matched file (in this case, not the 1st case, which would be all files that do not match ‘.svn’).

The seventh argument is actually a command that find will run on every match in the current case, which is a call to the grep command. Specifically, the arguments to grep are -i, which means search without regard to case (case-insensitivity), -n, which tells grep to print the line number with every match, -H, which tells grep to print the filename for every match, --color, which tells grep to highlight the searched term in the matched line, and -e, which tells grep that the pattern is a regular expression. “$1” actually tells bash to insert the first argument to the call to the function (search) on the command line – in this case, it is the actual term for which we are searching.

The last part of the function definition has two parts, “'{}'” and “\;”. “'{}'” is the syntax find uses to insert the filename of the matched file in the current case when running with the -exec argument. The reason I put the curly brackets in quotes was based on the tip from the find manpage, which stated that curly brackets are generally parsed by the shell environment. Putting them in quotes will prevent this. The final bit is the escaped semi-colon, “\;”. This tells the -exec argument of the find command that there are no more arguments to pass to the command find should run for every match in this case. Once again, because semi-colons are generally parsed by the shell environment, escaping them with a forward-slash will prevent them from being parsed, thus allowing them to be passed to the find command.

It’s important to note that there are some caveats due to the meaning of certain characters being passed. For example, since I am using the -e argument within the grep command to specify I am matching by a regular expression pattern, characters such as “.”, which hold special meaning within regular expressions (e.g., “.” means “match any character here”), then you will need to escape the character. However, because the argument to the search function is being passed through the shell environment twice, that means, to include a literal “.” in your search, you will have to escape it twice. Just a tip I found out when doing a search for “d.enddate” (a field in a SQL database query).

So there you have it! A very fast & efficient way to search the contents of all files within a subversion working copy set without also having to go through the special .svn directories, which frequently munge the return results. Previously, I had been using only the grep command with the addition of the -r argument, which would tell it to recursively descend into directories. This works well, but it does not allow me to exclude the .svn directories. Combining grep with find, however, allows me to get exactly what I want. Alhamdulillaah.

The core of my server is, of course, the Apache HTTPD web server. For dynamic pages, I almost entirely rely on the PHP programming language. For database storage, I use MySQL. Finally, rounding out the most important services I run on my server is Subversion versioning server, which I use for nearly all my code-based projects now. I also run the IceCast2 server, but since its configuration is pretty-much independent of the other four packages I’ve described, I’ll leave that out for the time being.

I strongly prefer source-based installations for the flexibility you get when it comes time to install. With the advent of a large support community around the Fedora project, it’s really become less of any issue, as nearly every package is kept up to date with the latest version. This is good & well for my development machine at home. But my current host, Servermatrix, only supports Redhat Enterprise Server releases. Therefore, to get the latest versions of these server packages, I will need to go to the sources. Plus, you get to learn a lot more when you’re getting down-&-dirty with the code – configuring, compiling, and sometimes every altering code! Oh…the excitement!

Having said that, this configuration guide is going to be dealing with the source-based installations of these packages only. So, let’s start downloading. Here are the relevant links (I have tried to link to the most specific, version-neutral download page available for each package):

• MySQL Server
• Apache web server
• PHP
• Subversion

I strongly suggest you make a directory named “packages” or something unambigious in which to download & extract all your files. This is the way I do it, and it’s the way I’ll be doing it throughout this guide. How you do it is your business, but I can’t possibly know for sure how you’ll be doing it ahead of time. If you have a preferred, possibly superior package directory structure, by all means, do post a comment or let me know some other way. I’m always up for doing things the better way, if & when I discover such ways. However, I’ll be referring to the packages directory throughout this guide, so now you know to what I’ll be referring.
While you’re downloading these packages, now would probably be a good time to start reading up on the documentation for each package. Some more nice links to check out (I have linked to either the most updated documentation available online or, where appropriate, to the documentation related to the specific version covered by this guide):

• MySQL documentation
• Apache HTTPD documentation
• PHP documentation
• Subversion documentation (SVN book)

It’s probably a good idea to bookmark these pages. If you’re using a browser that supports tabs (e.g., Firefox), you might consider making a folder with just these relevant links. You’ll probably appreciate it multiple times throughout this guide.

Once you’re downloads have all finished, it’s time to start extracting! I usually download the bzip2 versions of each package, if they are available, because I like the idea of things taking less space where possible. With modern CPUs, the time difference between gzip compression & bzip2 compression is almost a non-issue, whereas the space savings almost always is significant (10 – 20% minimum, usually). At a later date I will probably go into more details about how the packages are structured, but for now, I’ll just explain how to get the files out & ready to configure. The command to extract the files will look like the following:

For bzip2-compressed packages:

tar -xf package-name-version.tar.bz2 --bzip2

For gzip-compressed packages:

tar -xf package-name-version.tar.gz --gzip

This will usually extract out the files into a subdirectory like this:

~/packages/package-name-version

This will become important as we do upgrades to newer versions. As you extract the new versions to their respective directories, you generally won’t overwrite your older versions. This is very useful, as you’ll be able to go to your older versions & retrieve your old configuration settings nearly effortlessly, which will save a lot of time when it comes time configure, compile, & install a newer version of an existing package.

So, once we’re done, we should have four files in ~/packages and four directories with names similar to the packages. We’ll stop here & proceed forward with another session when I’m feeling up to it.