Debian NAS

I wanted a centralized home storage system that could feed all my other toys. Data stored on this will include MySQL datafiles, our MP3 collection, website directories and all our receipts printed out in PDF format (Yay! CutePDF) among other things. And so the fun began…

I did some test installs of various “turnkey” solutions such as Openfiler.

Openfiler just didn’t seem stable enough. Arrays would claim to have faulty drives and start rebuilding the arrays at the strangest times. Only to find out, via 3rd party tools, that the drive was fine. The web interface was ok but I would have organized it differently. Minus that, Openfiler has a lot of potential.

In the end, for what I wanted, it was easier to do a netinstall of Debian and add the things I needed.

Started with this: Debian RAID

Raid5 first
Raid1 with leftovers
Flat filesystem
Swap on Raid5

Bad mainboard
Bad harddrive
BIOS truncation of HD hardware address forcing me to "find" the bootdisk manually.

ECS RS482-M754 w/ AMD Sempron 3200+ (Bundled)
4x Seagate Barracuda 7200.10 ST3250620AS 250GB
2x AllComponents 512MB 184-Pin SDRAM DDR 400

The mainboard had problems POSTing but I couldn't really determine if it was board, memory or CPU, so it (board, memory and processor) was replaced with:

AMD Sempron 64 3400+ Manila 1.8GHz Socket 754
2x Kingston 512MB 240-Pin SDRAM DDR2 800

Ended up having a dodgey harddrive too. Awaiting the RMA return. But that didn't stop the project, it's just running without a spare at the moment.

NFS with assigned ports: Securing NFS

This is used for our websites' files and MP3 collection. The MP3's are accessed internally via Jinzora and accessed via laptops, HTPC's etc.

9 times out of 10, we're accessing the NAS interactively from laptops running windows. I didn't really look for a site that explained how to setup Samba on Debian. Just knit picked around google until my shares were up and running.

AoE for database files: AoE on Debian

First, the above URL is not quite complete, it's missing a few steps, which I have outlined below.

There are some security risks one should be aware of when implementing AoE. One item is the ability to X-mount an AoE LUN on another server causing corruption and all sorts of other nastiness. I've heard there are certain implementations that allow MAC filter and other security mechanisms to make this more secure. But in the end, you will still be shipping data in the clear over the wire.

I decided the ease of use were worth the risks.

Given that data files were going to live on the AoE devices, I wanted some extensive, longterm testing. I kept the originals and did some link chicanery for the test.

As I stated earlier, the AoE How-To linked is not complete but still makes a decent starting point. Below is a quick step-by-step.

Keep in mind the initiator is the "client" and the target is the "server". These are Debian specific instructions.

Install the client tools
apt-get install aoe-tools

Create the /dev structure
aoe-mkdevs /dev/etherd

apt-get install vblade

Create a device to export
lvcreate -n myAoE --size 10g my_vg0

Export device in userland for testing
vblade 0 1 eth1 /dev/my_vg0/myAoE &


List AoE devices

Create filesystem on device
mkfs.ext3 /dev/etherd/e0.1

Mount our new AoE device
mount /dev/etherd/e0.1 /data

And there you have it. In the end, I have 500GB of usable space in the first array. This includes a spare. All told, $415 delivered from NewEgg.

Next, I will be adding 4x 500GB drives for another array. At the current prices, you just can't beat the $ per GB.

Hits: 66

Security Audit Time Again!

So, I’m sitting there, minding my own business because it’s towards the end of the work day and I just want to get home. Then an email comes in, another security audit is coming down the pipe. No big deal, been through them before, but they are a pain in the ass.

I figured what the hell, I’ll read through the requirements to see what they are looking for. I get to about line 5 of the email, and right there, amidst all the other ludicrous requests is them asking for my “/etc/shadow report”. There is no “report” that can be yielded from the shadow file, other than brute forcing the passwords and seeing what comes up. I know for a fact that these jackasses aren’t bright enough to actually asking for that, so that must mean… The light comes on, WHAT IN THE *censored* DO THEY NEED MY SHADOW FILE FOR? IT’S GOT ALL THE GODDAMN PASSWORDS.

Well, I start thinking, could just be a test, seeing if I’ll just upchuck the guts to my servers without asking why. So, I grind out a short email to the ol’ manager stating the fact (adlib here) that I wouldn’t give that file to my own mother.

Gets to be time to go, and as usual, I do a quick round to make sure none of the developers need anything from the “server god” before I go home for the day. I pop my head into the manager’s office, exchange a little chit chat. He then informs that “they (meaning the audit firm) got a lot out of us last time and I’m sure there is something in the contract.” I about breached my BVD’s on the spot.

Now, I don’t want to make it look like my manager is the devil himself. He does try hard afterall, but that comment got me thinking there is no conductor on this train and I’m just behind the coal car. This is gonna hurt.

So, if I am, in the end, forced to surrender that file to the audit team, I do so under protest. Nasty, rioting in the streets type peaceful protest. If and when my servers are r00ted, every swingin’ richard better be there with me while I rebuild. Everyone down from the CIO of the Americas to the audit team.

**Edited by Request**

Hits: 49

Staying on top of your ports, the easy way

I submitted this over at Soup’s but I’m such a literary genius, I thought I would put it here too:

A lot of people try to claim various things are the “mother of invention”, but as ?n*x or ?BSD admins, we know the truth. And that truth is…. LAZINESS. Yep, if it weren’t for lazy admins, we wouldn’t have half of the automation scripts we have today. This affliction is what finally forced me to learn some Perl.

Keeping your ports tree and, subsequently, your installed binaries up to date can be a tedious task to say the least. To help alleviate this situation (and to help resume my laziness and boredom) I wrote up a script to automate cvsup’ing my ports tree. I’m not going to sit here and tell you that I’m a scripting genius, the syntax of the script would just call me a liar. But I will tell you that this script works for me on both 4.x, 5.x and 6.x stable systems. If you find out it works on others, or modify it to do so, drop me a line at packetmad[at]kulish[dot]com.

Anyway, back to what we we’re talking about. What this script does is cvsup your ports tree, run portupgrade -na (NO PORTS ARE INSTALLED) and generate a nice looking email report sent to the address of your choosing. It’s actually fairly well documented with in the script itself (amazing, huh?)

Here is an example report:

cvsup SUCCEEDED on Thu Nov 13 00:30:00 CST 2003!!
For host!!

Legend: +:Upgrade / -:No Upgrade / *:Skipped / !:Failed

– security/openssl (openssl-0.9.7c)
– devel/libtool13 (libtool-1.3.5_1)
– security/openssh-portable (openssh-portable-3.7.1p2)
– lang/ruby16 (ruby-
– lang/ruby16-shim-ruby18 (ruby-shim-ruby18-1.8.1.p2)
– shells/zsh (zsh-4.0.7)
– net/ntp (ntp-4.2.0)
– converters/libiconv (libiconv-1.9.1_3)
– textproc/expat2 (expat-1.95.6_1)
– devel/gettext (gettext-0.12.1)
– devel/gmake (gmake-3.80_1)
– net/mpich (mpich-1.2.5_2)
– net/cvsup-without-gui (cvsup-without-gui-16.1h)
+ lang/perl5.8 (perl-5.8.1_2)
– sysutils/portupgrade (portupgrade-20030723)
– misc/screen (screen-4.0.1_1)

From there you can decide what/when you want to upgrade. It makes it A LOT easier to schedule your updates between Nethack sessions this way.

A note on requirements. It needs to have cvsup-without-gui, portupgrade and Perl 5 installed to work correctly.

If you are still interested, after all this rambling, the script can be obtained from ‘s download section.

Hits: 77