• Home
• Blog
• About
• Gallery
• Map
• Resume

RHEL System Configuration Changes for Oracle 10G

Below is a list of RHEL system configuration changes that Oracle 10G requires before it is installed.

First, check the following kernel parameters using the commands below:

/sbin/sysctl -a | grep kernel.shmall
/sbin/sysctl -a | grep kernel.shmmax
/sbin/sysctl -a | grep kernel.shmmni
/sbin/sysctl -a | grep kernel.sem
/sbin/sysctl -a | grep fs.file-max
/sbin/sysctl -a | grep net.ipv4.ip_local_port_range
/sbin/sysctl -a | grep net.core.rmem_default
/sbin/sysctl -a | grep net.core.rmem_max
/sbin/sysctl -a | grep net.core.wmem_default
/sbin/sysctl -a | grep net.core.wmem_max

If any parameters are lower than the examples below, you will have to increase them by editing “/etc/sysctl.conf” file, adding the appropriate lines as expressed below. If the current value is higher, leave it as is.

kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144

Next, edit your “/etc/security/limits.conf” file, adding the following lines:

oracle          soft    nproc           2047
oracle          hard    nproc           16384
oracle          soft    nofile          1024
oracle          hard    nofile          65536

If your current “/etc/pam.d/login” file does not already contain the following line, add it:

session    required     pam_limits.so

Finally, add the following lines to your “/etc/profile” file:

#Tweaks for Oracle
if [ $USER = "oracle" ]; then
    if [ $SHELL = "/bin/ksh" ]; then
    ulimit -p 16384
    ulimit -n 65536
    else
    ulimit -u 16384 -n 65536
    fi
fi

These are just the basic steps I take. See the “Oracle Database Installation Guide” for more complete instructions.

Recovering From a Corrupt NetInfo Database on OSX.4

I managed to corrupt my NetInfo database on an OS 10.4 server a few weeks ago by not cleanly unmounting the drive after booting from DVD and resetting the admin password. Long story short, this left me with no users on the system at all. With no users, I could not log in to create one, so I had to blow away the NetInfo database and restore it to factory defaults. This should only be done when you only have a small number of users, and don’t mind having to re-create them. Only the user account information is deleted, and the user directory is retained, but you will have to manually add any users you may have back into the system through the GUI, making sure that the new “user” references the old “user’s” account directory.

If you have more than just one or two users, you should use the procedure to recover from one of your NetInfo database backups. A backup of your this database is made at 3:15 every day so long as the computer is running. It is stored in “/var/backups/”, and here are some instructions on how to recover it from it. If, however, you don’t care about re-adding users, and simply want to get into your system quickly, or if you don’t have a backup to restore from, here is how you can do it:

BEWARE: THIS WILL COMPLETELY ERASE ALL USER ACCOUNT INFORMATION FROM THE SYSTEM!!! You are warned.

1) Start by booting your Mac into single user mode. To do this, hold down both the “Apple” and the “s” keys as the system boots.

2) The system will have mounted the “/” filesystem read-only to protect against data loss. To get “/” mounted read-write, we have to run two commands:

# /sbin/fsck -fy

# /sbin/mount -uw /

3) Now “/” is mounted read-write, so we can start with the real work. First, rename your existing NetInfo database to something else so the OS will not see it on the way up:

# mv /var/db/netinfo/local.nidb /var/db/netinfo/local.nidb.bad

# mv /var/db/netinfo/network.nidb /var/db/netinfo/network.nidb.bad

4) Next, remove the “.AppleSetupDone” file so the OS will kick you back into the installer upon boot and you can recreate your users.

# rm /var/db/.AppleSetupDone

5) Finally, reboot your system and recreate your users, making sure they are pointed towards their existing account directories.

# reboot

Horde / IMP on RHEL 4 From RPM HOWTO

Whenever you go to install applications and services on registered RHEL servers, it’s always nice to use the RPMs because up2date will keep everything current for you. Managing upgrades gets a whole lot easier when you can bring your system up to current with one simple command. Because of this, I decided that I would try to use as many RPMs as I could when I set up our latest Horde / IMP installation.

Unfortunately, RedHat does not supply RPMs for the Horde applications, but luckily CentOS does. You should be able to download them from here. Get the latest version, which at the time of this writing was horde-3.1.3-1 and imp-h3-4.1.3-1.

Don’t install them yet though because Horde and IMP have always had a lot of dependancies which must be installed and enabled first. Installing the following RPMs should take care of them.

• mysql-4.1.20-1.RHEL4.1.i386.rpm
• mysqlclient10-3.23.58-4.RHEL4.1.i386.rpm
• mysqlclient10-devel-3.23.58-4.RHEL4.1.i386.rpm
• mysql-devel-4.1.20-1.RHEL4.1.i386.rpm
• mysql-server-4.1.20-1.RHEL4.1.i386.rpm
• perl-DBD-MySQL-2.9004-3.1.i386.rpm
• php-4.3.9-3.15.i386.rpm
• php-devel-4.3.9-3.15.i386.rpm
• php-domxml-4.3.9-3.15.i386.rpm
• php-imap-4.3.9-3.15.i386.rpm
• php-ldap-4.3.9-3.15.i386.rpm
• php-mysql-4.3.9-3.15.i386.rpm
• php-pear-4.3.9-3.15.i386.rpm

Assuming you will want up2date to handle upgrades of these packages, it is very important that you either use “up2date” to install them, or download them from correct channel at the RedHat website. You could also simply get them from the CD distribution that you used to install the system itself.

Once PEAR is installed, you will have to upgrade it, and install the PEAR::Log module.

[root@server]# pear upgrade -a PEAR-1.3.6
[root@server]# pear upgrade PEAR

Ok, now let’s make sure the web server is configured to start when the system comes up:

[root@server /]# /sbin/chkconfig –list httpd

You should see this:

httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

But if you see 5:off, simply run:

[root@server /]# /sbin/chkconfig httpd on

Now we enable and start up our new MySQL database server:

[root@server /]# /sbin/chkconfig mysqld on
[root@server /]# /sbin/service mysqld start

And we’re ready to install Horde and IMP. Install the following RPM’s, which will put everything in /usr/share/horde and creates a file called horde.conf in /etc/httpd/conf.d/

• horde-3.1.3-1.c4.noarch.rpm
• imp-h3-4.1.3-1.c4.noarch.rpm

This will install the HORDE and IMP packages in /usr/share, and /usr/share/horde respectively.

Finally, we start or restart apache:

[root@server /]# /sbin/service httpd start

Grab a browser and go to the following URL to proceed with the Horde and IMP configuration.

http://server.example.com/horde/

Installing OpenGroupWare 1.1.5 on RHEL 3

OpenGroupWare is an open source groupware package intended as an alternative to proprietary applications such as Exchange and PostPath. It is fairly robust in its feature set, and even integrates well with MS Outlook.

Its strongest points, in my opinion are that it does not depend in any way on Active Directory, and that it integrates well with open source standards like Open LDAP and University of Washington IMAP. Its downsides are that the documentation is sparse and scattered, that is is backed with PostgreSQL rather than MySQL, and that the package is bundled into a TON of RPM's.

I have not tried installing it from source, though I suspect that it would not be much more work than using the RPM's. Anyhow, if you want to install it for yourself, here are some quick scripts to help you, as well as some quick cookbook instructions. I installed it on RHEL 3 Workstation, though I suspect that it would work most Linux distributions.

The first thing we have to do is install the foundation for OpenGroupWare From the RHEL CD's or Website:

Install apache
Install PostgreSQL
Install PostgreSQL-devel
Install php
Install php_PostgreSQL

Next, run the following commands to get the database and webserver started:

# /sbin/chkconfig httpd on
# /sbin/chkconfig postgresql on
# /sbin/service postgresql start
# /sbin/service httpd start

Sendmail should already be installed and running, but if not, you will have to install it as well.

OK, so I said before that there are a TON of RPM's that you will have to install. These can be found at the OpenGroupWare website. Get them however you want, but if you have "wget" installed, you can use my script to fetch everything you need. You can omit the "devel" packages if you don't want to install the source code.

Ok, so now we have a directory filled up wit RPM's. Many of these have a lot of dependancies, so the order of install is important. The script below has them in the correct order, so you can either use it as a reference to install them yourself, or just save the script in the directory that has all your RPM's and run it. Your choice.

Some things to note about the install.

These all have to be done on one line or "rpm" will complain that it can's resolve dependancies:
rpm -Uvh ogo-webui-app-1.1.5-r1717.0.i386.rpm ogo-theme-default-1.1.5-r1717.0.i386.rpm ogo-webui-resource-en-1.1.5-r1717.0.i386.rpm ogo-webui-resource-de-1.1.5-r1717.0.i386.rpm

ogo-database-setup-1.1.5-0.i386.rpm sets up your PostgreSQL database and database user for you. The output should look something like this:

Preparing...                     ########################################### [100%]
1:ogo-database-setup             ########################################### [100%]
PostgreSQL seems to be already initialized
and I can see it running:
PIDS used: 3456 3458 3459
We're on PostgreSQL 7 (7.4)
checking /var/lib/pgsql/data/postgresql.conf
need to patch /var/lib/pgsql/data/postgresql.conf for 7.4
backup current one to /var/lib/pgsql/data/postgresql.conf.20061213-153319
checking /var/lib/pgsql/data/pg_hba.conf
need to patch /var/lib/pgsql/data/pg_hba.conf for 7.4
backup current one to /var/lib/pgsql/data/pg_hba.conf.20061213-153319
The changes we've made require that we restart PostgreSQL...
Stopping postgresql service:    [  OK  ]
Starting postgresql service:      [  OK  ]
OK! PostgreSQL runs again: (3909 3911 3912)
creating database user: OGo
creating the database itself: OGo
we've successfully created both the user OGo and the raw database OGo
we'll now fill the database with the scheme itself
checking the logfile created during scheme rollin...
/tmp/database_setup_psql.sh.20061213-153319.log
removing log - not needed anymore

OK... Now everything is installed, and if you run the following command:

# /sbin/chkconfig --list | grep ogo

You should see the following output:

ogo-zidestore   0:off   1:off   2:on    3:on    4:on    5:on    6:off
ogo-webui       0:off   1:off   2:on    3:on    4:on    5:on    6:off
ogo-xmlrpcd     0:off   1:off   2:on    3:on    4:on    5:on    6:off
ogo-nhsd        0:off   1:off   2:on    3:on    4:on    5:on    6:off

Now, let's fire up these services:


# /sbin/service ogo-zidestore start
# /sbin/service ogo-webui start
# /sbin/service ogo-xmlrpcd start
# /sbin/service ogo-nhsd start

Everything should be up and running now, so you can grab a web browser and go to the following RUL:

http://server.domain.com/OpenGroupware

You will be logged in as the root user, so make sure to change the password.

If you are using this system as a stand-alone server, you are pretty much all set. We needed to authenticate it against our central LDAP, and point it towards our IMAP server though, so I added the following lines to "/var/lib/opengroupware.org/.libFoundation/DefaultsNSGlobalDomain.plist":


LSAuthLDAPServer = "ldapserver.domain.com";
LSAuthLDAPServerRoot = "dc=mydomain,dc=com";
imap_host = "imapserver.domain.com";
UseSkyrixLoginForImap = YES;


Make sure to put these lines at the end of the file, but before the closing braces.

The file should look something like this:

###### SNIP #######
{
"skyrix_id" = "server.domain.com";
LSConnectionDictionary = {
  databaseName = OGo;
  hostName = "127.0.0.1";
  password = "";
  port = 5432;
  userName = OGo;
};
  LSNewsImagesPath = "/var/lib/opengroupware.org/news";
  LSNewsImagesUrl = "/ArticleImages";
  Languages = (
  English
);
  TimeZoneName = GMT;
  WOHttpAllowHost = (
  localhost,
  "127.0.0.1",
  "localhost.localdomain"
);
  LSAuthLDAPServer = "ldapserver.domain.com";
  LSAuthLDAPServerRoot = "dc=domain,dc=com";
  imap_host = "imapserver.domain.com";
  UseSkyrixLoginForImap = YES;
}
###### /SNIP #######

Since the system won't let you authenticate the "root" user against the local database if your are using LDAP, you have to create a root user on your central LDAP.

Create an LDIF file called root.ldif like so:

###### SNIP #######
dn: uid=root,ou=People,dc=mydomain,dc=com
objectClass: organizationalPerson
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
uid: root
uidNumber: 0
gidNumber: 0
sn: Root
cn: Root
homeDirectory: /root
loginShell: /bin/bash
gecos: Root
###### /SNIP #######

Finally, run the following command to add the root user:


ldapadd -x -D "cn=Manager,dc=mydomain,dc=com" -W -f root.ldif"


You should now be authenticating against your central LDAP server. Have fun!

Working With Disk Labels in RHEL

When you install RHEL, the filesystems are labeled for you. Usually you won't have to mess with it anymore, but on occasion, you may want to change them to more accurately represent the data that is stored on that partition. If, for instance, you used to have all of your database files on a partition labeled "/database", but you have now moved them somewhere else, and you now wish to house your user account data there, it would make sense to change the label to something like "/users".

Labels are, of course, arbitrary, so there is no technical need to do this, and you could, instead simply change the mount point in the fstab file, mounting the partition by device name rather than label, but it is usually cleaner to change the label. Here is how you do it:

First, let's figure out what the partition is currently labeled as:

[root@calvin /]# /sbin/e2label /dev/hda4
/database
[root@calvin /]#

It's current label is "/database", and, since we have moved the database data somewhere else, we now want to store our user account data here, we need to change it to "/users".

[root@calvin /]# /sbin/e2label /dev/hda4 /users
[root@calvin /]#


That's all there is to it, now we check to make sure we have done what we think we have done.

[root@calvin /]# /sbin/e2label /dev/hda4
/users
[root@calvin /]#

Sure enough, it's now labeled "/users" and the data on the disk remains intact. Now all we have to do is change the appropriate entry in the "/etc/fstab" file to represent the change.

Change this:

LABEL=/database       /databases            ext3    defaults        1 2

To this:

LABEL=/users          /users                ext3    defaults        1 2

And you're all set to go. Make sure you have unmounted "/databases" before making the change.

Now, just run:
[root@calvin /]# mount /users
[root@calvin /]#

And you're all set to go. As always, change the values here to represent those in your environment.

Why Modern RAID 5 is Ideal for Oracle Databases

There is a convention of thought amongst Oracle DBA's that databases should never be installed on disks that are configured into a RAID 5 array. The argument goes, that since Oracle accesses and writes to random points within relatively large files, the overhead of constantly calculating block-level parity on these files is substantial, resulting in serious performance degradation. They suggest that RAID 1 (mirroring) is the ideal disk configuration since no parity needs to be calculated, and Oracle is more than happy to divide up its database over many smaller mount points.

This way of thinking has largely been correct over the years because most systems have traditionally used software RAID. This means that the CPU of the server itself had the job of doing all those parity calculations, and it really did slow down both the server and the disk when RAID 5 configurations were used. Oracle, in particular, had a hard time with these configurations for the exact reasons the DBA's point to.

In many cases, software RAID is still used, and to be sure, it is wholly inappropriate to deploy RAID 5 in these environments. However, it is increasingly common to find IT departments using a SAN-type architecture where the RAID type and configuration are invisible to the host operating system. In these environments, the the disk array has a dedicated controller that is singly tasked with handling all read, write, and parity operations. The RAID controller is no longer software running on a generic CPU, but rather firmware that is optimized to handle parity calculations. This results in a system where parity is calculated so quickly by the dedicated controller that differences in speed between RAID 1 and Raid 5 should be virtually nonexistent.

To prove this, I carved up our new InfoTrend EonStor A12F-G2221 into three arrays - a RAID 5, a RAID 1, and a RAID 10. I then set out to run some benchmarks on these different arrays to see what, if any, the differences would be.

The hardware used was as follows:

• Dell OptiPlex GX260, 2.2 GHz Processor, 256 MB Ram
• RHEL 4 Linux
• QLogic QLA2340 HBA
• InfoTrend EonStor A12F-G2221 with 1GB cache

• The RAID 5 LUN consisted of 4 drives
• The RAID 1 LUN consisted of 2 drives
• The RAID 10 LUN consisted of 4 drives

I then identified the iozone tests that most accurately simulated Oracle disk activity. What I really wanted to do was to simulate select and update queries on various sized files and see how the different RAID types held up under the load. To do this, I ran iozone, a well-respected benchmark utility, with the following arguments:

/opt/iozone/bin/iozone -Ra -g 2G -b /home/sysop/new/raid5-2G-1.wks

This put the disk through its paces, as it ran the iozone tests in automatic mode on a 2 Gb file, but in the end, I was interested in analyzing the following tests because they were the ones our DBA team suggested would most closely represent database activity.

Random Read (select queries)

This test measures the performance of reading a file with accesses being made to random locations within the file. The performance of a system under this type of activity can be impacted by several factors such as: Size of operating system's cache, number of disks, seek latencies, and others.

Random Write (update queries)

This test measures the performance of writing a file with accesses being made to random locations within the file. Again the performance of a system under this type of activity can be impacted by several factors such as: Size of operating system's cache, number of disks, seek latencies, and others.

Strided Read (more complex select queries)

This test measures the performance of reading a file with a strided access behavior. An example would be: Read at offset zero for a length of 4 Kbytes, then seek 200 Kbytes, and then read for a length of 4 Kbytes, then seek 200 Kbytes and so on. Here the pattern is to read 4 Kbytes and then %%[Page: 3]%%

I ran several instances of the same tests using the same command line to ensure that there were no anomalies, and the machine was doing nothing else during the tests besides running the host OS. The results were pretty much as I expected, and I found little to no variation between the raid types on this disk subsystem.

Random Read Tests:

In this test, there seems to be the slightest advantage to the mirror-type RAID arrays when it comes to very small files. This, I suspect can be attributed to actual drive head latency as, in RAID 5 volumes, the correct block needs to be found on a larger number of disks. This advantage quickly falls off, however as the file size grows, meaning that this slight advantage would not be seen in an Oracle database.

Random Write Tests:

In this test, both RAID 5 and RAID 10 seem to hold a slight advantage over the direct mirror. This, I would imagine can be attributed to the fact that the writes are happening over a larger number of spindles. This indicates that the controller is calculating the parity faster than the 2Gb connection speed to the disk subsystem. Again, the variation is incredibly small, so there is no arguable performance advantage to using one type of RAID over another when using a hardware controller.

Stride Read Tests:

Here again we see no real advantage to one RAID type over any other. It could be said that the RAID 10 volume held up ever-so-slightly better on this test, but any edge is so slight that it would be hard to imagine how this could translate into a noticeable performance gain in an Oracle database.

In the end, these tests proved my suspicion that hardware RAID controllers have become so efficient and fast that it no longer makes any real difference what type of RAID you decide to use for your Oracle database. Largely gone are the days when your disk space and RAID volumes were inexorably tied to the server itself. So long as you are using hardware RAID, and the LUNS are abstracted from your operating system, you can largely feel free to make the most of your storage dollar by using RAID 5 in your production database environments.

Changing Linux Mount Points

If you're familiar with UNIX, you know that changing mount points is really pretty easy. All you have to do is go into "/etc/fstab", "/etc/vfstab" (or whatever your flavor of UNIX happens to call its filesystem table) and change the mount directory.

If, for instance, you had a Solaris box, and you wanted to make the disk currently mounted as "/data" be mounted as "/database", all you would have to do is the following:

# umount /data
# mv /data /database
Change this line in "/etc/vfstab" from something like this:
/dev/dsk/c1d0s6 /dev/rdsk/c1d0s6 /data ufs 1 yes -
to something like this:
/dev/dsk/c1d0s6 /dev/rdsk/c1d0s6 /database ufs 1 yes -
and remount it as "/database".
# mount /database

With Linux, however, it's not quite so clear anymore... It's still easy, but it's just not so clear what you have to do since they have now taken to mounting filesystems using the volume label. Rather than pointing directly to the disk device, Linux points to the label, and "/etc/fstab" look more like this:

LABEL=/data /data ext3 defaults 1 2

You can always simply change the disk label, but if you don't care, you can just tell linux where the raw device is, bypassing the need to worry about the label. The easiest way to do this is simply to replace the "LABEL=/data" value to the "/dev" entry of the disk itself. Then, simply change "/data" to "/database" and you're all set.

Here is an example of what you would do to change the mountpoint of "/data" to /database":

# umount /data
# mv /data /database
Change this line in "/etc/fstab" from this:
LABEL=/data /data ext3 defaults 1 2
to this:
/dev/sda6 /database ext3 defaults 1 2
and remount it as /database
# mount /database

Remembering to change the example values here with those required for your situation.

Picking a Multiuser Blogging System

I'm a blogger. I'm also a systems administrator at a University. Thus, when the University decided to charter a project to offer each member of the institution a blog, I was selected to sit on the committee. We boiled all of the software choices down to Drupal, Movable Type, and Wordpress MU.

In my evaluation of these solutions, the software was ranked on a five-point scale against the following requirements, which we had decided were important to us. I've also included my personal rankings. In many cases the software received a lower ranking on a feature because it was not customizable by the individual user.

Intuitive Drupal:2 Movable Type:5 Wrodpress MU:5	Skinnable Drupal:2 Movable Type:5 Wrodpress MU:5	Pingbacks Drupal:3 Movable Type:5 Wrodpress MU:5
Trackbacks Drupal:2 Movable Type:5 Wrodpress MU:5	Supports XMLRPC Drupal:5 Movable Type:5 Wrodpress MU:5	Comment SPAM blocking Drupal:2 Movable Type:4 Wrodpress MU:5
Image support Drupal:5 Movable Type:5 Wrodpress MU:5	WYSIWYG Drupal:5 Movable Type:5 Wrodpress MU:5	RSS feed Support Drupal:3 Movable Type:4 Wrodpress MU:5
TAGS Drupal:5 Movable Type:5 Wrodpress MU:5	URL Rewriting Drupal:5 Movable Type:5 Wrodpress MU:5	Hosted here Drupal:5 Movable Type:5 Wrodpress MU:5
Single installation Drupal:5 Movable Type:5 Wrodpress MU:5	Single Database Drupal:5 Movable Type:5 Wrodpress MU:5	Single Table structure Drupal:5 Movable Type:4 Wrodpress MU:0
Mysql or Oracle Drupal:5 Movable Type:5 Wrodpress MU:5	Integrate with IDM (ex. CAS) Drupal:0 Movable Type:0 Wrodpress MU:0	Quota on file uploads Drupal:5 Movable Type:0 Wrodpress MU:5
Prefer PHP: Drupal:5 Movable Type:1 Wrodpress MU:5	Ease of Upgrade Drupal:4 Movable Type:4 Wrodpress MU:5	Cost Drupal:5 Movable Type:3 Wrodpress MU:5

Totals:
Drupal: 88
Movable Type: 90
Wordpress MU: 100

Drupal came in last not because it is unable to meet the requirements we had listed, but because it is not as intuitive as the other solutions, and there are many areas where the user can not be granted any granularity of control over the blog. There is, for example, no way to allow the individual user to manage comment spam settings. The administrator chooses the settings that are then applied globally to each user on the system.

Movable Type evaluated quite well. The user interface is very nice, and the entire software package is very feature rich from a user experience standpoint. It meets most of our pre-determined criteria, but there are no built in "file upload quotas", and the application is written in Perl. Also of possible concern is the fact that, while content exists within the database, it is delivered via static pages. This means that a site (all static pages) must be rebuilt whenever significant changes are made, such as changing a theme. It is anyone's guess how this static / dynamic model will scale to a very large number of users. Also of note is the fact the MT is a pay for product. Like any proprietary software solution, this can be both a benefit and a drawback.

Wordpress MU mets or exceeds all of our pre-determined criteria with one major exception. The database does not have a unified table structure, meaning each blog requires its own set of database tables. It is largely unknown how this model will scale to a large number of users, however wordpress.com has this software successfully rolled out to a large and growing number of users. Should we decided on WPMU, it may be worth discussing the implementation with the WPMU team. The user interface is both elegant and intuitive, and the user retains maximum control over most of the unique blog settings. It is, however, worth mentioning that WPMU has adopted the Web 2.0 standard of not versioning their releases. Upgrades are downloaded via a nightly builds directory, which means that version releases may not be as well tested as with a more traditional release strategy.

For my part, even though I scored it slightly higher, I have no real preference for Wordpress MU over Movable Type. Both are great blogging solutions, and I feel that we could find a way around MT's lack of file upload quota. I do, however, prefer either of these two solutions over Drupal because of issues surrounding usability, and customization.

In the end, the committee agreed that Wordpress MU was the winner. We will now go on to write the CAS authentication module, and see if we can get around the requirement that usernames have greater than three letters. We are also hoping to get in touch with the wordpress.com people to discuss how the non-unified table structure will scale to 30.000+ users.

Popular Posts

• Bash For loop Example (1211)
• Spencer Tunick Photographs More Than 18000 Nudes In Mexico City (641)
• Why Did my Arm Fall Asleep? (595)
• Little Japanese Trucks (376)
• Fish Supposedly Washed Up By Asian Tsunami (333)
• Solaris Disk Partition Layout & Mirroring Scripts (278)
• How to copy a Solaris boot drive to a disk with a different partition layout (272)
• RHEL Winbind Authentication Against Active Directory (249)
• Foreach Example in tcsh (246)
• VMware ESX 3.5 ntpdate strangeness (213)
• Recovering From a Stuck Symantec Ghost Virtual Boot Partition (212)
• More Fun With DIY ROVs (202)
• When Mac OSX SMB Connections Fail (195)
• Team Zissou Shoes (167)
• Whipped Magazine… Not real, but a funny mockup (162)

Tags

advanced lock picking Adventures basic picking blog bounce pick corruption diving flatland funny government guide hacking howard dean HowTo humor Iraq key keys linux lock lock pick lock pick guide locks master keys mit pick picking torque pick pressure pin column model pins plug rebreather republican rhel scuba scuba diving series solaris storage sun technology tumblers unix video zen

Sponsored Links:

Copyright © 2004-2008 spiralbound.net · Log in