Archive for July, 2006

rsync notes

rsync --delete --delete-excluded --exclude-from=~/.rsync/exclude -re ssh -avzp domainname.com:/path/

Use symbolic links to have them included in the rsync (for including a folder that is outside the root of the rsync), use Mac aliases to have them not included (to avoid having duplicates within the root folder).

You know how FTP can resume partial downloads that were canceled or stopped halfway through? Well, rsync can do this too!

Resume
rsync --progress --partial -e ssh

Database Modeling and Normalization

I’m studying database normalization techniques. This is something I should have done a long time ago. However, I didn’t have access to, or the skill set to operate software which could truly take advantage of a properly designed, fully normalized database model. Since I may soon, I’d better hit the books!

So far I’ve got a good grasp on the first three levels of database normalization. These work great for the type of data I’m working with. Also, I use MySQL, currently setup with MyISAM tables, but I should probably switch to using InnoDB tables, these support referential integrity, which I understand to prevent of orphans in lowest common denominator tables.

However, one thing I am stuck on and having a hard time digesting is the concept of dynamic attributes. For example, if I were to create a data type entitled “assets”, I would create a table called assets, and each entry would share a certain set of standard attributes, such as asset_id (primary key), created, destroyed, asset_type_id. The asset_type_id would then relate to the type of asset_type, for example, computer, desk, or office building. I keep thinking that all these asset types should share a table reference of attributes, so that they could all be stored in the same table, and their attribute would then be dymanically assembled from the reference table.

To explain, say we have a desk and a computer. These obviously have different attributes, but do they need to be stored in different tables? Maybe not. We could have a table like this:

asset_id | attribute_id | attribute_value 5 | 1 | Red

We’d get the asset type from the asset table, then get the attributes for that asset_type_id from an xml file, and then go from there. While this is nice in concept, I foresee it being a nightmare for developers. There would be so many complicated joins and loops I don’t think it would be worth it. Exactly, because what happens when you get a situation where you have two values for one attribute, like a computer can have two operating systems on it, or two ip numbers attached to it, several peripherals, and these may want to be further normalized.

However, it would be nice to be able to create a new asset type in XML, and simply drop it in and go. But I guess you could do that with a rich-in-metadata XML schema file, too.

**Database modeling is a balance between abstraction and specification.**

NagiosQL Notes




NagiosQL is a web front end for Nagios 2. We just installed it and it looks really cool. Since the documentation we’ve seen is mostly in German, we’ll try to post as much as we learn here in English.

After getting a blank page at the NagiosQL index page, I searched the web and found the NagiosQL wiki, which linked to a test file for nagiosQL. This file found that we didn’t have the php5 mysql extension setup.

http://www.nagiosql.org/wiki/NagiosQL_FAQ

Subversion Documentation

Subversion Rocks!

I’d been using Concurrent Versioning System, aka CVS, for some time to manage a previous software development project I had managed. It worked OK to do basic code management, backups and versioning control. However, the limits of CVS were apparent if you even tried to do anything beyond the basics. Don’t get me wrong, I don’t mean to trash CVS - the issues I ran into could have been my own lack of knowledge on how to use it!

Enter Subversion
I was introduced to Subversion through Nexista, which was hosted at Tigris. Tigris also hosted Subversion, so I gave it a shot. Seemed to fill the shoes of CVS perfectly well, the commands were similar so it was easy to learn. Hadn’t had any reason to try anything fancy, until now.

We rebuilt several of our servers so first I had to move the repository from one machine to another. We actually moved the entire filesystem, so the repository came with it. No problem. As an aside, here are instructions on doing it manually:

Migrate a subversion repository to another machine

Next, I created a branch. Branches are like alternate lines of software development. You can mix and match revisions along the branch developments in a very simple and straightforward manner. Best of all, branches do not complicate or overburden the repository, so if you have a reason to create a branch, go for it, create a subversion repository branch.

To keep learning about SVN, I decided to move the repository to another part of the filesystem. To do so, I used the commands outlined in the above link. Then I decided to merge to repositories, and rearrange the projects within the repository. Guess what, it all worked! And it all made sense! The free online book helps out immensely, so I recommend going directly to that source:

http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-sect-2.1

Just realized something about tags and branches. Since I am the only one developing software, a tag is all I need at this point. It seems like branches are better for concurrent versioning, where multiple people are working on different checkouts.

External Links about Subversion
A novices Subversion Tutorial

Tigris