Log in

No account? Create an account

July 16th, 2008

All Your KnowledgeBase Are Us

Very excited about Mediawiki's semantic extensions.  I used some of its search capabilities today and it reminds me of the library.  To get this idea moving, I need to a) plan the project, and b) implement it.  Of course major changes shouldn't happen until all systems are backed up and verified, which means two more systems and tape purchases.

Vap0rtranz KB

The MediaWiki reinstall part is simple compared to importing content.  It worked before; the only hassle is testing virtual hosts and redirects.

user search -> frontend: wiki.vap0rtranz.ignorelist.com

frontend:: DDNS, DNS, Apache, PHP
backend::  MySQL

The content import part will be difficult.  I found one wiki_import utility that essentially calls ImportText.php, aka. it probably handles ASCII and nothing more; there is a Word .doc importer, and/or OpenOffice will export to MediaWiki files.  So I'll end up doing some perl/php scripting to do bulk imports, which is exciting.

Some more difficulty comes from keeping the original content available to the wiki users until everything is maintained in the database.  The wiki is running from Gentoo and the content from Windows; this can't change without a) buying more disks or b) revamping my test lab.  I have neither time nor money.  Once Samba is working on the middle-woman, Jackie, the originals should be available to wiki users via DFS.

jorge:(original file -> NTFS -> MS CIFS) -> jackie:(Samba -> DFS) -> joy(cifs -> Apache)

I must press forward with this plan so that I call pull from all me (sic) memory banks, anywhere, anytime!  MUAhahah!

Backup Early, Backup Often

Just a pat on the back for getting my backup project moving.  This had been stalled by SCSI bus errors (due to my stupidity in putting a Fast SCSI-10 tape drive on the same ribbon as an Ultra Wide SCSI drive on a SCSI-2 host).  I rebuilt the hardware without the Ultra disk and there are no errors on the host.  It's now backing up my other systems to tape.

Rather than just getting backups working again, I also delved into the depths of recovery practices.  Ever since working for Arsenal (arsenaldigital.com, which backs up AT&T's and Verizon's datacenters, and now a wholly owned subsidiary of IBM) I've been anal about B&R practices.  Just tarring something up works for a laptop; for servers the following happens: databases are restored to inconsistent states, files change size and turn all garbled inside, ACL's are missing so users complain about Access Denied errors, and generally the backup takes too long and/or grinds services to a halt.  Actually the later happens to laptops but there should be some time relative to the user's circadian rhythm when a backup won't be noticed.  Such is not the case for multi-user servers.  Bacula reminds me of Veritas, which we used at Arsenal, and it takes care of these problems via schedules, libacl, LVM and VSS, along with pre/post scripts for the custom needs of applications.  My own cpio scripting can't come close to its scalability ... although it is laborous to setup, especially if one is not familiar with B&R practices. 

As Jim would say, the B&R motto is: "backup early, backup often".