Here are my notes how I set up SVN over SSH to an SVN server that had been set up to run SVN as a single user, "svn".

So, we have multiple users on the remote side, all logging in as "svn" on the SVN server side.
Authentication is done via a dedicated key-pair, with special options to make SVN+SSH work.

See http://svn.collab.net/repos/svn/trunk/notes/ssh-tricks for more details.

These are just my notes, the above link is authoritative.


Procedure:

1. Generate a dedicated key pair

	[SVN Client]$ ssh-keygen -f ~/.ssh/svnssh
	Generating public/private rsa key pair.
	Created directory '/home/tsalolia/.ssh'.


  

It is trivial to set things up so you are able to select memtest86 as a boot option in GRUB:

Download the latest memtest source from http://www.memtest86.com.

Extract and follow the instructions in the README that comes with it to compile. Copy the resulting memtest.bin to /boot and edit /etc/grub.conf to have the following 3 lines:

title Memtest86
        root (hd0,0)
        kernel /boot/memtest.bin

Make sure you reboot to test.

In theory this should work with any x86 OS + bootloader. I am doing this with RHEL 4 + GRUB.

I've recently had a number of projects at work that want to mix multiple volume managers on a single server, specifically ZFS and VxVM for SAN volumes (actually, three including SVM for internal boot disk mirroring). The projects generally are for database servers, and want to use VxVM for database volumes because ZFS currently has some serious limitation on database size (limited number of devices recommended in a single zpool) and performance (single threaded checksumming, for one). However, at the same time, they want to have access to some of ZFS's features (in particular, the ability to oversubscribe filesystems, dynamic resize, snapshots and rollback) for some of the other filesystems.

Read an interesting discussion on the lkml list where Linus and friends talked about atime's performance impacts (http://kerneltrap.org/node/14148). Ingo phrased the problem best with:

' For every file that is read from the disk, lets do a ... write to
the disk! And, for every file that is already cached and which we
read from the cache ... do a write to the disk! '

Solutions are to mount your file systems with the noatime, nodiratime options. The only time this may cause a problem is if you have a local mail spool (the mailer will not know that new email arrived) or possibly with some backup software.

Although LOPSA is platform-agnostic, my current job has me solidly as a Solaris and EMC storage admin. I have experience on just about every other platform of at least a limited extent (DEC UNIX, SCO, HPUX, Windows 4.0, 2000, 2003, Linux mainly RedHat, FreeBSD, OSX, etc...). However all the new tricks I learn, most are going to be on the Solaris platform.

The latest two things I had to learn are how to handle shared memory allocations under Solaris 10, and the 'supported' way to make Veritas filesystems mounted in a zone.

Shared memory was interesting, I mainly googled and asked around until I got a couple of command lines. Then when that didn't work quite as expected in a zone, I borrowed a copy of the new Solaris Internals books to see if I was doing something wrong. Turns out I wasn't really, I just seemed to be running the box out of memory completely.