October 2008 Archives

SSD vs. SAS vs. SATA

| | Comments (2)
So the new server is almost done. It's going to be 32G per motherboard for a total of 64G, not 64G per motherboard for a total of 128G as previously reported. Turns out you can only run 4 quad-rank modules per quad-core opteron, and dual-rank 4G modules cost north of twice as much per gigabyte.

But I've got the ram on my kitchen counter, and the server in the garage. All I'm waiting on is the disk and the last 2 CPUs, neither of which I've bought, waiting for the latest prgmr.com consulting check to clear.

so, I need disk. I've got 2x3.5" bays per motherboard in this server. I was initially planning on just mirroring those new Seagate 1.5TB sata disks, but I'm a little concerned with performance, so I'm exploring the alternatives.

The advantage of the sata, of course, is the cost-per-gigabyte. we're talking around $360 for 1.5TB of mirrored space. performance is pretty awesome, too, at least for sequential access. But this isn't sequential access, so I'm a little concerned that 2x SATA spindles isn't going to cut it, performance wise.

Now, one option is to just put in a pair of 300GB 10Krpm SAS disks. about the same price for disk, add another $150 for a cheap supermicro sas card. But this means I give out considerably than 10G of disk for every 1G of ram. Considering that most of my customers are in the 256-512M range, that's not much disk. and if I want 15Krpm, that's twice as much cash. ouch.

So here is what I was thinking... for around $200 I can get a single 64G sata-attached ssd. now, these things aren't particularly fast for sequential transfers, but for random access, they are awesome. Just what I want. More to the point, those SSDs are tiny, and don't need to be mirrored for reliability. I can fit them in the space reserved for the cdrom drive, so I could use the 64G ssd card and the mirrored sata. you'd get around 2G ssd for every 1G ram you bought, and around 40GB of sata per gigabyte of ram.

So yeah. my only worry with the 64G SSD card/1.5TB sata arrangement is that it is more complex, I mean, you have one fast disk and one slow disk.

I'm still thinking of a storage server that will let me give customers disk via iscsi or AoE or something... but last time I looked, it was all either expensive, unreliable or slow. I'll experiment and see what I come up with.

So a while back I bought a MandyLion brand password token from ThinkGeek.   The idea is that my brain simply can not remember an adequate number of secure passwords.   Now, in my personal business I try to minimize this by using keys and ssh-agent everywhere, but I do need to keep passwords for accounts hosted elsewhere.  (I can't, for instance, throw up a new vserver and run an interface to my bank.)   Also, I need to remember passwords for clients (all my entreprenurial activites are funded by my consulting activities)     And this token, while not all that secure, is worlds ahead of little bits of paper in my wallet. 

Well, I got the token several months ago.  I promptly imputed a few client passwords into it, and used it to generate secure passwords for some of my accounts.   The password input is pretty clumsy (for input, it's got five buttons total)  but it works, and without a computer.  Well, the thing comes with some windows management software.  A 'policy manager' they call it.  I figure I'd load it up and poke around. 

Well, while I'm fairly impressed with the design of the token itself, I can't say the same for the 'policy manager'  -  so I initialize the token and play around a bit.  Not much you can do, aside from inputing passwords on a real keyboard.  Easy, yeah.  But do you really think I'm going to trust  my passwords to a windows box?  right.    so the management software is kinda useless.  But the irritating thing is that I found I could no longer input passwords on the device.  I could generate random passwords, but I couldn't input passwords, which presented a problem, as I said that many of the passwords I have to remember are generated by someone else.    Re-initializing the token didn't fix this problem.

I e-mailed ThinkGeek about it, and they talked to MandyLion.   The advice I got back was "re-initialize the token"  -  I mean, what did I expect from a device with windows-only software?  

Anyhow, the other night I sat down and figured it out.  Here is how I managed to reset the thing back to factory defaults:



1. I re-initialized the token using the provided software (It still won't let me manually enter passwords at this point, but it clears any policy I had set with the windows software.)

2. from the 'View' menu, I simultaniously press the up and down arrows to get to the 'options' menu.   I press the center button, then I press the down arrow to get to the 'set locks?' option.  I press the center button. I press the down arrow until I get to 'shutout' option.  I press the center button.  Now, I press the down arrow until I get to the 'destroy' option, and I select it with the center button.    (I'm now in the 'set locks?' menu again) I scroll down to the 'attempts?' option.  I press the center button to select, then I scroll down to '3 tries'  and press the enter button to select.  I'm done here, so I use the left arrow to go up menus until I am logged out of the device.

3.  I enter the wrong access code more than 3 times, and the LCD says 'Destroy' for a while (less than a minute)   -   after  the screen goes blank, pressing the center button prompts me to select an access code.  The device appears to be back to factory defaults (I can both randomly generate passwords as well as entering them by hand.)

So  yeah.  my password thingr is working again.

GNU screen for collaboration

| | Comments (2)
GNU Screen is often used for keeping programs running while their user is logged out, but it is also very useful for collaboration when more than one user connects to a session. To do this, "multiuser on" must be set in the session, either in the screenrc file or with : in the session. Then the user who didn't start screen must connect to it with screen -r and the username of the owner of the session and the name of the session like "screen -r nick/31346.pts-15.lion". The name of the session can be found by the owner doing screen -ls or root looking in /var/run/screen/ in the owners session directory where there is a named pipe with the name of the session. The screen binary must be setuid root with chmod u+s and owner root. The session owner must explicitly allow the other users to connect with "addacl otherusernames" either in the screenrc or in the session. Then when both users are connected they have the privileges of the session owner and can see what each other are doing, allowing demonstration of various system tasks or issues.