2007-03-20 21:01:00
One of the rules my employer Snow imposes on its employees is a rather strict certification track. Technically speaking each employee progresses through five C-levels, starting at 0 and ending up at 4. As you reach new levels of certification you will also reap benefits of your hard work.
Let's take the track that applies to me as an example:
C0 = no certification
C1 = LPIC1 (101 and 102) and ITIL Fundamentals
C2 = LPIC2 (201 and 202)
C3 = SCSA1 and SCSA2
C4 = SCNA and others
The irony of the matter is that I've already achieved both SCSA exams and the SCNA exam a long time ago, but that I'm still stuck at C0 because I haven't done my LPICs. So to work myself up the ladder I'm slogging my way through the requisite LPIC stuff, even though I'm not that fond of Linux.
The challenge here lies in the fact that haven't used Linux in a professional environment that much, so I'm at a disadvantage when compared to the rest of my colleagues. I'm really glad I've always been a rather good student, so cramming with a few books should get me through. I managed to score a 660 (87%) at my LPIC-101, so that brings some hope :)
And now I'm cramming for the 102 exam! Since I was postponing it way too long, I reckoned I'd better get my act together! This week I took two days off to dedicate myself completely to studying. I managed to work through six of the nine objectives in these two days, resulting in a thirty-one page summary so far. In two weeks time I'll take another two days and then I'll be ready!
Like last time I'll post my summary over here, to help out all those other souls trundling through their LPICs.
kilala.nl tags: work, lpi, studying,
View or add comments (curr. 3)
2007-03-13 20:25:00
I'm well fed up with the whole PCMCIA switcheroo that I had gotten into to run my stand-by duties. I finally went out to Media Markt to get myself a Wifi card of my own. Who cares if the laptop belongs to $CLIENT? I want to work dammit! X[
I bought the Linksys WPC54g which is the first card that I'd borrowed from a colleague. Back then the card worked a treat and I had no problems whatsoever. But this time around, nothing but trouble! ;_; I think the crucial difference lies in the fact that the card I bought is v3, as opposed to either v2 or v4 (which was what I'd borrowed earlier). Incidentally, I'm running Windows 2000 on this Thinkpad.
Installing the card seemed to work alright: the driver installed perfectly, the card was recognized and the configuration utility installed as well. But for some reason the config util would keep on reporting the card as "WPC54g is inactive", suggesting a driver problem.
Well... A little digging around led me to this thread at the Linksys fora. It seems that the configuration tool (aka "Network monitor") is actually a piece of shit software, that doesn't work properly with the WPC54gv3 *grr*. As was suggested in the thread I installed McAfee Wireless Security, which is an alternative and free configuration tool for Wifi cards.
And lo and behold! It recognized the card and found my Wifi network. Got me connected without a problem. Thank God for McAfee! (Never thought I'd say that!)
Needless to say that my trust in Linksys has gone down a bit. All in all this took me a good two hours, which has well soured my mood :/
kilala.nl tags: annoying, windows, other tech, sysadmin,
View or add comments (curr. 3)
2007-03-13 15:05:00
Today I was working on a shell script that's supposed to process multiple text files in the exact same manner. Usually you can get through this by running a FOR-loop where the code inside the loop is repeated for each file in a sequential manner.
Since this would take a lot of time (going over 1e6 lines of text in multiple passes) I wondered whether it wouldn't be possible to run the contents of the FOR-loop in parallel. I rehashed my script into the following form:
subroutine()
{
contents of old FOR-loop, using $FILE
}
for file in "list of files"
do
FILE="$file"
subroutine &
done
This will result in a new instance of your script for each file in the list. Got seven files to process? You'll end up with seven additional processes that are vying for the CPUs attention.
On average I've found that the performance of my shell script was improved by a factor of 2.5, going from ~40 lines per three seconds to ~100 lines. I was processing seven files in this case.
The only downside to this is that you're going to have to build in some additional code that prevents your shell script from running ahead, while the subroutines are running in the background. What this code needs to be fully depends on the stuff you're doing in the subroutine.
kilala.nl tags: unix, work, unix, sysadmin,
View or add comments (curr. 2)
2007-03-13 08:11:00
Well, It works, I can use my iBook at home from my desktop PC at work. I'd tested the whole setup at home, using both my Powermac and the Thinkpad $CLIENT gave me and VNC worked properly and rather smooth.
Unfortunately the Internet connection at $CLIENT isn't too great, so the VNC connection is a bit sluggish. Changing desktops (I run Desktop Manager to sort my apps across four desktops) takes a second or three and building a completely new screen takes about two. So it's not great, but it's doable at least.
I'll try this out for a few days, see how it pans out. If I don't get stuck in any way I'll leave my iBook at home from now on.
kilala.nl tags: apple, other tech,
View or add comments (curr. 0)
2007-03-12 22:08:00
For weeks on end I've been dragging my iBook along to the office at $CLIENT, even though I'm not allowed to connect it to their network. My iBook is indispensable to me, because it contains all of my archives and past projects, all my e-mail and my address book and calendar. I even use my iBook to keep track of my working hours (thank you TimeLog 3!).
Unfortunately, dragging my laptop around can get tiresome, especially if I ride my bike to work. Which is why I'm very grateful to one of my colleagues for suggesting the use of VNC or another remote desktop solution. Seriously, the suggestion was so obvious that I'm really ashamed that I didn't think of it. I guess I was just clinging -too- much to my dear, sweet iBook.
Anywho... What I'm about to describe is only one of many ways to implement a remote desktop solution for your Mac. A few other options exist, but this is the one I'm using. What we're going to be building is the following:
* I'm at my desk at work, using one of the PCs over there.
* My iBook, running Mac OS 10.4 is at home, connected to my wifi network.
* I will be using my iBook, from my desk at work :)
What you'll need:
* A VNC server. I chose to use Vine Server, which came recommended.
* A VNC client. For Windows and Linux I chose to use Tight VNC and for OS X I use Chicken of the VNC.
* An SSH server. This comes built in, as part of Mac OS X.
* An SSH client. For Windows I use PuTTY, while Linux and OS X come built in with a client.
* Your home IP address. You can find this by browsing to What is my IP address? at home.
Setting up SSH at home
You can use the basic SSH configuration that comes with OS X, but it's not rock solid. If you'd like to be extra secure, please make the following changes. This will disable remote root access and will force each user to make use of SSH keys. If you didn't, you could log in using your normal password which opens you up to brute force password attacks.
* Open Terminal.app and enter the following commands.
cd /private/etc
sudo vi sshd_config
* Change the following lines, so they read as follows. The last two lines a
PermitRootLogin no
PasswordAuthentication no
UsePAM no
* (Re)start SSH
Open System Preferences.
Go to "Sharing".
(Re)start the "Remote access" server.
Setting up the VNC server at home
Vine Server comes in a .DMG and you can simply copy the binary to its desired location. By starting the application you're presented with the applications configuration options, which has buttons at the bottom to stop and start the VNC server.
* You can leave most settings at their default values, but it's extra safe to change the following:
Connection -> set a password
Sharing -> only allow local connections
This secures your VNC server with a password and prevents people on your local network from connecting to your desktop. You'll only be able to login to VNC after logging in to your system through SSH.
* Press the "Start server" button.
Setting up your router
You will need to make your SSH server accessible from the Internet. Configure your router in such a way that it forwards incoming traffic on port 22, to port 22 on your Mac.
Setting up your SSH client at work
If you forced your SSH server to use public/private keypairs earlier, then you'll need to configure your SSH client to do the same. You can use ssh-keygen (OS X and Linux) or PuTTYGen (Windows) to generate a key pair. Please Google around for instructions on how to use SSH keys.
You will need to tell your SSH client to connect to your SSH server at home and to set up port forwarding for VNC. In both examples $HOME-IP is the IP address of your Internet connection at home.
* On Linux and OS X (from the command line): ssh -L 5900:127.0.0.1:5900 $HOME-IP.
* On Windows (in PuTTY): SSH -> Tunnel -> local port = 5900, remote port = 127:0.0.1:5900
What you're doing here is rerouting any traffic that's coming in at your work PC at port 5900 to port 5900 at your home box.
Setting up your VNC client at work
All of the real work is being done by the SSH session, so you can instruct your VNC client to simply connect to desktop 0 at localhost, or at 127.0.0.1. Enter the password that you set up earlier.
Adding more security
Unfortunately Hot Corners don't work through VNC and FUS kills your VNC session, so we'll need to find another way to lock your OS X desktop. Luckily I've found a way in this article. You can use Keychain Access to add a small button to your menu that will allow you to lock your screen.
And there you have it! A fully working VNC setup that will allow you to use your Mac at home, from work.
kilala.nl tags: apple, other tech, writing, sysadmin,
View or add comments (curr. 0)
2007-03-01 14:26:00
Today I faced the task of replacing a failing hard drive in one of our Tru64 boxen. The disk was part of a disk group being used to serve plain data (as opposed to being part of the boot mirror / rootdg), so the replacement should be rather simple.
After some poking about I came to the following procedure. Those in the know will recognize that it's very similar to how Veritas Volume Manager (VXVM) handles things. This is because Tru64 LSM is based on VXVM v2.
* voldiskadm -> option 4 -> list -> select the failing disk, this'll be used as $vmdisk below.
* voldisk list -> select the failing disk, this'll be used as $disk below.
* voldisk rm $disk
* Now replace the hard drive.
* hwmgr -show scsi -> take a note of your current set of disks.
* hwmgr -scan scsi
* hwmgr -show scsi -> the replaced disk should show up as a new disk at the bottom of the list. This'll be used as $newdisk below.
* dsfmgr -e $newdisk $disk
* disklabel -rw $disk
* voldisk list -> $disk should be labeled as "unknown" again.
* voldiskadm -> option 5 -> $vmdisk -> $disk -> y -> y -> your VM disk should now be replaced.
* volrecover -g $diskgroup -sb
The remirroring process will now start for all broken mirrors. Unfortunately there is no way of tracking the actual process. You can check whether the mirroring's still running with "volprint -ht -g $diskgroup | grep RECOV", but that's about it.
kilala.nl tags: unix, work, other tech, sysadmin,
View or add comments (curr. 2)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.