Building a Fully Encrypted NAS On OpenBSD

mistermark writes "Two years ago this community discussed my encrypted file server. That machine has kept running and running up until a failing drive and a power outage this last week. So, it's time to revise everything and add RAID to it as well. Now you can have an on-the-fly encrypting/decrypting NAS with the data security of RAID, all in one. Here is the how-to."

Comments

Netcraft...

[Anonymous Coward]

mistermark's failed hard drive only further confirms that BSD is, in fact, dying.

OK

[Anonymous Coward]

WTF
IsA
NAS
?

Re:OK

[Anonymous Coward]

Network Attached Storage

Re:OK

[Whiteox]

You mean everybody who's got a computer hooked to another with a network cable has a nas? Geez! And I thought I didn't have one!

Re:OK

[thc69]

WTF
IsA
NAS
?

http://en.wikipedia.org/wiki/Nas

Re:OK

[thc69]

LOL, somebody modded me up without clicking on the link. It was a joke, folks; that wiki is for the rapper who goes by the name "Nas".

Re:OK

[Anonymous Coward]

hm.
So does he rap his lines in AES?
or blowfish?

Re:OK

[thc69]

Unlike his peers, I've found that he does manage to rap in something resembling english. I even manage to like one of his tracks ("Hip Hop Is Dead", which is assembled from all kinds of familiar and comfortable samples, loops, and structures), which is really quite amazing to me.

Pretty In-depth

[GizmoToy]

Wow, that was a pretty in-depth how-to. It even has a mechanism (via cron) to notify you within 15 minutes if a drive fails. This sounds like a pretty interesting solution. I think I may have to give it a try with a spare box I have laying around. Thanks mistermark. I'm impressed.

Re:Pretty In-depth

[ComputerSlicer23]

I'm shocked the raid tools for OpenBSD aren't better then that. Not a dig at it, OpenBSD generally prides itself on exceptional tools. OpenSSH, CARP (their replacement for VRRPD), their firewall tools and everything else. Linux has a system call that can be used to monitor the status of a RAID array. It can kick off an arbitrary command, including starting up recovery and/or e-mail alerts. Technically the system call doesn't, but the mdadm tools that use the system call can.

I really hope somebody replies telling me, I'm an idiot and that OpenBSD has exactly such tools. Well and they really exist, as opposed to the clever slashdot behavior of telling me I'm an idiot and be completely wrong.

Kirby

Re:Pretty In-depth

[jd]

Is it just me, or is there something that needs rethinking in the statement: "How is an approach that uses a standard Unix utility... shockingly unexceptional"? (emphasis mine) Either the phrasing was unintentional, or one person on this site is having problems understanding "exceptional".

By-the-by, most simple functions can be performed via webmin or some other admin tool, in a way that is platform-agnostic to the user. Well, when the module is written correctly, that is. A number are very poor. However, unless you are doing something that requires specific platform awareness, it should be for the tool to do things in the most effective way for a specific platform.

Administrators - ideally - should know principles, methodologies and other higher-level detail, except when low-level detail adds something of value. Which happens and there's no escaping it. When such low-level detail is needed, you WANT to know the syscalls, the user/kernel sockets, the virtual filesystems that provide direct access to kernel parameters. When you are doing high-level operations, you absolutely do NOT want to be messing at that level. You can't possibly hope to keep a heterogeneous network going if you have to micromanage each platform.

(In fact, most corp networks are very homogeneous because their admins are inept enough TO micromanage and therefore CANNOT cope with having multiple platforms. Remember, no homogeneous system - however good - will ever have the best solution to any of the problems before it. It will be a compromise on everything. Heterogeneous networks can always have optimal solutions for everything, requiring only that you use abstract thinking and abstract mechanisms for all the generic stuff.)

Re:Pretty In-depth

[Depili]

The difference is that mdadm on linux gets notified for drive failures via a system call and thus doesn't need to poll the status and act like cron...

Re:Pretty In-depth

[DrSkwid]

Webmin : because EVERYONE has a web browser available. Idiot.

Re:Pretty In-depth

[larry bagina]

From the mdadm man page:

MONITOR MODE
...
This usage causes mdadm to periodically poll a number of md arrays and
to report on any events noticed. mdadm will never exit once it decides
that there are arrays to be checked, so it should normally be run in
the background.

Re:Pretty In-depth

[LuSiDe]

Besides, OpenBSD's disk encryption is vulnerable to dictionary attacks as it doesn't support PKCS#5 PBKDF2.

Re:Pretty In-depth

[ComputerSlicer23]

I believe the mdadm tools on Linux actually block the system call until on a change in the status. I didn't state that clearly. So you get immediate notification, RAID re-builds. I wrote something that checked every 2 minutes on all of our RAID devices (Nagios and scripting are great). Generally mdadm and it's alerts informed me once I had those setup, soon enough that could go in and disable the Nagios alerts prior to it noticing.

Kirby

Re:Pretty In-depth

[Anonymous Coward]

most simple functions can be performed via webmin or some other admin tool

If you don't know your way around a shell you'd never get a decent unix admin job. I've interviewed people for ~$80K unix/linux admin jobs where at least 4 or 5 times it's gone like this:

Me: "The machine name is foo, your user name is 'test' and the password is 'test'. Connect to it and configure (whatever)".
Them (looking at a flashing cursor prompt): "Durrr... where's web browser for teh Webmin?"
Me: "Shell only."
Them: (randomly bashing at keyboard): "Durrr..."

Re:Pretty In-depth

[jd]

Oh, you're absolutely right, and that's precisely because you must be able to do the low-level stuff, if you're an admin. And the command line is a powerful facility. NEVER be without one. Even non-admins should be familiar with command lines, because some things need the extra control.

However, only an idiot would rely solely on the command line for everything. Why? Let's look at Linux for a moment. You're pretty much guaranteed ash-level scripting at a minimum on the system, but any shell script on the system could potentially be written in more than two dozen scripting languages. Linux networking - are you using net-tools derivatives or iputils derivatives? The syntax isn't identical. Basic commands - GNU or Heirloom? Makes a difference. So even for something as "standard" as a Linux environment, there are a gigantic number of permutations.

This is not a bad thing. Different tools for different needs. It's a very good thing. But if there's nothing to abstract the details, you'd better have a damn good memory. I'm very very good at remembering such trivia, but I would not be capable of going to absolutely any Linux box using well-established tools and be 100% guaranteed a command line environment I could use. Nobody at all is that good.

I am fine for admining most Linuxes, HPUX, Solaris, SunOS, OSF/1, FreeBSD, OpenBSD, VxWorks and about a dozen other Un*x variants and derivatives. But in a real-world environment, to be truly optimal, you SHOULD be looking at 20+ different types of Operating system. Random administration of twenty totally different environments is possible, but you WILL want the basics to be abstracted out. It could be GUI-based, it could be shell scripts. Who cares? I'm not saying the solution has to be graphical, only that it has to be abstract. (By graphical, I'm including ncurses, as you can webmin with links or lynx perfectly well, and linuxconf is still a perfectly viable abstraction layer, albeit just for the one OS.)

The days of single-OS environments (especially "Windows shops") are numbered. It's not a viable model any more. You really can't use a hammer for everything and expect to get the results of a well-equipt craftsman or artisan. The model of the artisan is the model that the IT industry desperately needs to get back to. We are masters of our crafts, we should be respected as such, and we should be at the forefront of eliminating single solutions. Single solutions are BAD. They eliminate your ability to adapt, they restrict your thinking and they make you vulnerable to any flaws or limitations they may have. Since the first days of Open Source, you've never needed to be a prisoner to any method. The methods are YOUR servants, not the other way around.

Re:Pretty In-depth

[ComputerSlicer23]

If you read the actual mdadm code (I used v2.6.2 from http://www.cse.unsw.edu.au/~neilb/source/mdadm/). Looking at Monitor.c 487 of the Monitor function, it "polls" the file. Waiting 60 seconds (by default, you can set the delay lower). However, if you look at the mdstat_wait(int) call, you'll notice that it's doing a select on the "/proc/mdstat" file. It'll break out of the select if fairly quickly. Force a mirror break, and if you have it setup to get an e-mail, you'll have the e-mail with in your in box in seconds. There's no 1 minute or 15 minute lag.

I'd swear that at one point it used an ioctl to extract all of this information, but it's been ages since I actually read the mdadm tools source... Heck it might have been the precursor tools... mdtools or mdctl or whatever it was called before.

Kirby

Re:Pretty In-depth

[turbidostato]

"(In fact, most corp networks are very homogeneous because their admins are inept enough TO micromanage and therefore CANNOT cope with having multiple platforms. Remember, no homogeneous system - however good - will ever have the best solution to any of the problems before it. It will be a compromise on everything. Heterogeneous networks can always have optimal solutions for everything, requiring only that you use abstract thinking and abstract mechanisms for all the generic stuff.)"

You seem to forget two things:
1) When you are going "generic" the best you can get is the max common divisor (or whatever that concept is called in English) and you loose your "optimal solutions for everything" approach.
2) The "optimal solutions for everything" takes a lot of particular nuisances for every "optimal platform" the "optimal solution" happens to be. Worse than that: for the "optimal solution" to be such optimal you not only need to know its own nuisances but the interactions of such nuisances with its environment. In few words, to really obtain an "optimal solution" you end up needing to be an expert on the platform said "optimal solution" happens to be... for every platform every "optimal solution" within your heterogenical environment happens to be.

Luckily enough, your "corp network inepts" know that and since they *have* to micromanage for whatever is critical for their companies backline, they tend to micromanage on the less platforms they can afford. Within every corp environment there will be just a few of *real critical* tasks where they must optimize (think, say, Google or SAP or Youtube) and a whole lot where "good enough" is, well, good enough and then they'll go where their expertise is even if they end up with suboptimal solutions for not so important problems.

In fact, that's why OpenBSD is not more deployed: it might be better as a firewall than, say, Red Hat Linux but, usually, Red Hat Linux makes a "good enough" iptables-state-aware firewall for a company that relies on a, i.e., bussiness-critical certified IBM+Oracle+SAP pile. Well, in fact (once again), a Red Hat-based iptables-state-aware firewall managed by a savvy Red Hat-certified sysadmin makes a *better* firewall than an OpenBSD-based one managed by an OpenBSD-unsavvy sysadmin (you are not going to hire another sysadmin just for a secondary task when your current staff can fulfill it good enough, and you won't make an expert on a liminary used platform out of an already overloaded sysadmin, right?), so more to the point.

Re:Pretty In-depth

[turbidostato]

"So even for something as "standard" as a Linux environment, there are a gigantic number of permutations."

There are *potentially* a gigantic number of permutations. In fact, as any senior sysadmin can tell you, it all ends up being "is it BSD or SysV?", "man whatever" and your own "standards" (like, "oh, well, of course Exim is up to the task, but we are a Postfix shop here"), so it is not such a big problem. It only *seems* to be a problem for the casual outsider but the fact is that any senior professional worth its wages will tame it... easily.

"But if there's nothing to abstract the details, you'd better have a damn good memory."

I would say that if you don't have such a "damn good memory" there are a lot of other trades you can try (imagine an actor: "well, I'm better than de Niro but, unluckingly my memory is so flacky..." OK: you don't have the qualities and actor needs, so look for another trade). On the other hand, I have not such a good memory for trivia but still I do quite well: Unix-like systems really are not about trivia (while so it seems) but about concepts. I can say I don't even know out of my head but four or five options to `ls`, but I *do* know what `ls` is about and how to type in `man ls`. On general grounds I know what to expect from a unix-like system so it's only a matter to search on the manuals, man or info pages or the Internet for the "trivia" that will make the thing I know it can be done to happen so for the day to day things I use my head directly; for everything else I use my head to look for the trivia. And it works.

"But in a real-world environment, to be truly optimal, you SHOULD be looking at 20+ different types of Operating system."

I remember a conversations few years ago when I was explaining that by then I was hired as a "smart guy" for a foreign company. "What an smart guy is" asked the one I was talking to. Well, the guy that they call whenever any "techy thing" is beyond their abilities, and I explained some examples like how to mix and match some given HTTP server on a given platform or how to tie a given search engine with a given OLE-based word processor to publish results on a given Java-based platform on a given OS. But, but... do you really are an expert on such obscure combinations? Of course not! I'm an expert, if at all, on understanding problems and searching for answers if they exist or deploying alternates if they do not exist. But this is terribly unefficient -told my counterpart, there must be experts for any problem realm that would know the answer right out their minds or after a few minutes are most, and you expend four to eight ours with any single problem! Well, "average" is the answer. When you are opened to a very variable/uncontrolable environment unless you already have a gigantic network of experts (and then you have the problem about how to ask what) you expend less having and "all terrain resolver" than having to find for the right expert on every problem you affront. Well, I think the "all terrain resolver" concept fits quite good to a senior sysadmin: it is not neither about your memory nor your overall knowledge about nuisances (while it greatly helps, of course) but about your "expertness" to understand concepts, reduce problems to their constuent elements, and then look for the needed trivia.

"in a real-world environment, to be truly optimal, you SHOULD be looking at 20+ different types of Operating system. Random administration of twenty totally different environments is possible, but you WILL want the basics to be abstracted out. It could be GUI-based, it could be shell scripts. Who cares?"

That's a great true, specially regarding shell scripts (GUI environments bring problems on their own, like their -usually, lack of proper accountability and repeatability) but then it means one of two things: those "abstraction tools" where developed either by you yourself, maybe on another lives (I, for example, was quite an expert on Sendmail on a different life but I'm no more: I still depen

One link in the chain...

[Architect_sasyr]

One step in the long process. Kudo's and gratitude for putting this up, it will certainly make my process easier.

I wonder, are there any full HOWTO's on this? 802.1x and IPSec both come to mind. The protection is useless if the server is powered on of course.

Re:One link in the chain...

[Anonymous Coward]

Or the OP is not from US of A, so has never attended 'high school' and has no clue what 'grade 5' is.
Maybe the OP's first language is not English?
Get a clue.

Re:One link in the chain...

[Yggdrasil42]

Thanks for clarifying the OP's error, but why the patronizing tone?
Most people on the planet don't speak English natively, and a large part of the Slashdot population is from that group.

Since you can't tell if the OP does or does not belong in that group, being a little less harsh would make the world a nicer place. Why not start there?

Re:One link in the chain...

[giminy]

When ending a sentence with a quotation, you are supposed to place the period inside the, "quotation marks."

Also note that quotations are always preceded with a comma, and always followed by a comma (inside the quotation marks). Your example sentence should be, 'Saying, "kudo's," means, "belonging to kudo," which I don't think you meant.'

Colons are only used in written English to delineate lists of words or phrases: to demonstrate proper sentence technique, to accurately correct someone's grammar, etc. In your example, a use of quotation marks would be the correct way to do it. Alas, you do not know how end a sentence with a quotation, so we'll let you go on this one.

If-Then clauses should be separated with commas as well. If you are in the third grade, then I can understand the confusion. If you are a high school student (or beyond), then there really is no excuse for making such basic errors in your grammar.

Best,
Reid

Yes but...

[Anonymous Coward]

Yes but... does it run on Linux?

Re:Yes but...

[Anonymous Coward]

>Yes but... does it run on Linux?
Of course it [VMware] runs BSD!

Been looking for something like this

[the_humeister]

Although, since the OS is just there to boot and allow access to data, I was thinking of using a 1GB CF card to put the OS on. I like the RAID 1 setup the instructions are easy to follow, but how about other RAIDs?

Re:Been looking for something like this

[I kan Spl]

Most decent BIOSs know how to boot from a flash drive, or if you want to be fancy you can get a PCI to Flash card with a boot prom.

Just don't put any swap on the CF card, they are limited to 10k writes/block before they start failing. If any swap winds up being used for FS caches (it will) your OS boot device will only last 2-5 years at most.

Re:Been looking for something like this

[Anonymous Coward]

"I was thinking of using a 1GB CF card to put the OS on..."

If you are talking about OBSD as an OS on that CF, then a 64MB CF is more than enough unless, of course, you need for more space.

Re:Been looking for something like this

[JayAEU]

Just make sure you don't follow TFA's recommendation regarding the choice of identical drives for the RAID array, which would make the whole point of redundancy moot.

Identical drives are just that, identical. This means that they also are very likely to fail at the same time or may not survive a RAID reconstruction process to rebuild the other failed drive.

My advice would be to make them identical only in size and maybe the interface, but for the love of God, do pick different manufacturers and production months for the drives.

Re:Been looking for something like this

[cheater512]

Well a 1mb card would work just fine too unless you need more space. :P

Re:Been looking for something like this

[jdowland]

Is it not the case that you need to get identical sector sizes, too?

Re:Been looking for something like this

[Anonymous Coward]

Remind me I should never hire you. Many enterprise level arrays require (for firmware reasons and testing validation) that the drives be identical. If all drives of a certain lot died on a specific day, I think people would notice. The purpose of RAID is to be able to survive a drive failure.

Re:Been looking for something like this

[JayAEU]

Is it not the case that you need to get identical sector sizes, too?

Not really, the physical sector size only matters when doing a hardware RAID, but even then, most modern controllers cope quite well with different disk.

Some people claim that identical sector sizes help performance somewhat, but so far, I haven't been able to reproduce any evidence for this.

Re:Been looking for something like this

[JayAEU]

Remind me I should never hire you. Many enterprise level arrays require (for firmware reasons and testing validation) that the drives be identical. If all drives of a certain lot died on a specific day, I think people would notice. The purpose of RAID is to be able to survive a drive failure.

If you'd read TFA, you might have noticed that we're not in a enterprise level setting here.

On the contrary, the suggested solution is advertised for home use. As such, entry-level disks are being used, not the expensive enterprise level SCSI stuff you're probably used to, dear AC.

Aforementioned entry-level disks certainly do have the property of failing frequently, and according to Murphy they do so in the worst possible moment you can imagine, a RAID rebuild.

Re:Been looking for something like this

[CastrTroy]

I thought that most CF cards were working up to 1 million writes/block now. They are making hard drives for laptops that use only flash/NAND memory for storing data. However, I'd still shy away from using the device for swap or temp/log files. Any extra strain on these types of devices could probably spell bad news. I don't even see why you'd need swap space if you're just running a file server. The amount of RAM you would need is very minimal, especially on a home setup, with maybe 5 computers accessing it, and any gain you'd get from adding swap would probably be offset by the longevity of the server.

Re:Been looking for something like this

[CastrTroy]

Actually, Identical drives are in fact, not identical. What they are is built to the same specifications. They actually use different atoms and molecules to make up the components of the drive. They were most likely manufactured on different days, or at least at different times. If you took two drives from the same production line, and put them through the exact same usage, I imagine the probability of them both breaking within the same week to be somewhere close to zero, maybe even close to requiring the "Heart of Gold". I've never seen a corporate Raid setup that used different models of drives for drives in the same array, and have never heard of this being an issue.

Re:Been looking for something like this

[Anonymous Coward]

You make a great point! As an easy fix, start with a set of identical drives. Remove one and replace it after a month. Remove another and replace after the next month, and so on, until you've replaced all but one.

By your logical, all your failures will be precisely one month apart! No worries, plenty of leeway to rebuild.

Re:Been looking for something like this

[rossifer]

Aforementioned entry-level disks certainly do have the property of failing frequently

According to Google, consumer grade hard drives fail at the same rates and with the same predictability as enterprise grade drives.

Outside of a few specific cases (death star's, for instance), buying a bunch of the same disks will work just fine, and going to great lengths to get drives from different manufacturers and manufacturing lots doesn't seem to be worth the effort.

according to Murphy they do so in the worst possible moment you can imagine, a RAID rebuild.

And this is why you should still have a backup of your RAID. The ability of a RAID to tolerate one failure is at least partially offset by the fact that there are more parts that can fail.

Regards,
Ross

Re:Been looking for something like this

[Anonymous Coward]

Remind me I should never hire you. Many enterprise level arrays require (for firmware reasons and testing validation) that the drives be identical. If all drives of a certain lot died on a specific day, I think people would notice. The purpose of RAID is to be able to survive a drive failure.

"enterprise" level arrays probably have many more disks available. They're probably RAID 5. They probably have hot spares in the array and maybe even cold spares on hand. They probably are brand new and won't be in service forever. They probably have better cooling and cleaner power. They're probably covered by warranty and fast on-site replacement programs. They are probably monitored 24/7 and have staff available 24/7 to replace failures quickly. And everything is probably hot swap so failures can be replaced immediately.

The typical user of this software probably doesn't have many drives in the array. He probably doesn't have any spares, hot or cold. The drives are probably used or recycled from a desktop. The server probably sits in a closet on (at best) a cheap UPS. The drives may or may not be under warranty but a vendor probably isn't going to be on-site in 4 hours with a replacement should it be needed. There is probably no real-time monitoring and alerting and failures will be replaced as soon as the sole administrator gets around to finding a replacement on ebay.

Remind me not to hire someone without any reading comprehension or critical thinking skills.

Re:Been looking for something like this

[Fulcrum of Evil]

If you took two drives from the same production line, and put them through the exact same usage, I imagine the probability of them both breaking within the same week to be somewhere close to zero, maybe even close to requiring the "Heart of Gold".

If you took 10 drives, though, the probablility of 2 of them failing within a week of each other is probably around .5.

Re:Been looking for something like this

[drinkypoo]

However, I'd still shy away from using the device for swap or temp/log files. Any extra strain on these types of devices could probably spell bad news.

While I agree in principle, you should be okay if you keep the device mostly empty. They do block remapping and rotate through blocks...

The amount of RAM you would need is very minimal, especially on a home setup, with maybe 5 computers accessing it, and any gain you'd get from adding swap would probably be offset by the longevity of the server.

RAM is pretty cheap these days. Slap even half a gig in there and you will probably never feel a crunch (we're talking about an appliance here.)

As for logging, I would like to have support to store it on a logical volume, on an actual volume, or across the network.

Re:Been looking for something like this

[NoMaster]

For reference, and for info: I've just finished rebuilding my OpenBSD firewall here, which boots off a 512M CF card attached to a CF->IDE adaptor & has 512M of RAM. It's been running like this for ... oh, 3 years now? ... with a fresh new install of OpenBSD every 12 months or so.

The slackers way of doing it:

1. Get your OpenBSD install CD
2. Install a basic OpenBSD setup - no games/X/comp sets - to CF
3. Copy /var to somewhere like /proto/var. If you're really brave, copy /etc to /proto/etc as well.
4. mkdir /proto/dev, and "MAKEDEV all" in there.
5. Edit /etc/fstab to mount / ro, and swap mount /proto/var, /proto/dev/, & /proto/etc over the original /var, /dev, and /etc to mfs (ramdisk)
6. Reboot
7. You probably want to link /tmp to /var/tmp as well. Do that now.
8. Install rsync, edit /etc/rc.shutdown to rsync your /var (& /etc) filesystems back to /proto/var (& /proto/etc), and add a cron job to do this daily.
9. Enjoy your new CF-booting OpenBSD install!

Note: this is the slackers way - a better way to do it is to use the flashdist or similar build scripts, but that requires a build machine. This way is, I reiterate, is for slackers who can't be bothered doing that ;-)

It can be fine-tuned - for example, you don't really need all of /etc or /dev in mfs, though there can be a few things in there that require write-access. Still, with RAM cheap, it's just as easy to mount it all that way. One day, if I run out of RAM, I might change things a bit.

An explanation

[Anonymous Coward]

Kdawson clearly killed the other editors, and is now posting all stories. If you see anyone else posting, it's actually kdawson using their account. Look for more dupes, April Fool's Day jokes, and Slashvertisements soon.

Re:An explanation

[FreakyLefty]

Gullible fool. Having learnt from all the murder tips given in the recent Hans Reiser stories CmdrTaco has obviously killed the other editors and is using kdawson's account to leave a false trail. You'll know it's true when kdawson posts a moving and heartfelt eulogy to Taco.

Re:An explanation

[unitron]

Well, Taco did kill off JWZ about a decade ago. :-)

needs usability

[r00t]

Right from the initial install, by default, this should work.

Encrypted backups should be default and easy, with reminders.

You need multiple keys: whole-system, per-user, and swap. The swap key gets replaced at boot with something random.

Ultimately, it needs mandatory encryption. This would exclude OpenBSD; you need a mandatory policy framework like SE Linux to make it happen. Mandatory encryption means that normal users are prohibited from removing data from the machine without first encrypting it in an approved way. This most likely solves part of the backup problem. It also reduces the insider threat, while still allowing transfer of data between secure machines.

Re:needs usability

[BuR4N]

I think you just described Windows Vista Bitlocker.

Re:needs usability

[dleigh]

This would exclude OpenBSD; you need a mandatory policy framework like SE Linux to make it happen. Mandatory encryption means that normal users are prohibited from removing data from the machine without first encrypting it in an approved way.

If you want to stick with a BSD-based system, FreeBSD has Mandatory Access Control support; there are projects to port the MAC framework to NetBSD and OSX.

Re:needs usability

[jd]

Mandatory encryption won't help a whole lot. Mandatory access controls that utilize encryption might help some - it doesn't protect off-site data but DOES limit the device you copy data onto, as the device must be authorized to hold the data. It is then the problem of the device as to how to protect things. Not perfect, but a major improvement, as it means Joe "The Spy" User can't copy onto an unauthorized device to decrypt later at Evil HQ, and Fred "The Idiot" Flintstone can't copy top secret DoD construction plans onto public FTP servers. As has happened, according to reports.

(The point of MAC is that MAC requires that there be explicit permission given by someone who has the authority to give that permission. It is not implicit, unlike DAC where anything not expressly prohibited is implicitly allowed.)

The encryption thing can be improved on a little, if it is not secret key -or- uses an OTP calculator that only resides on authorized machines. The latter is getting a little into security through obscurity, but still works to a degree if the calculator is any good and the underlying crypto is sufficiently strong. As async encryption is slow, you'd probably want a crypto accelerator, but there are countless such systems. Don't blame the algorithms if you don't want the solutions.

Re:needs usability

[r00t]

The point is to protect off-site data. You can copy the data to a DVD-R, but you don't get the key. Take that DVD-R to another secure system which has the key though, and you can read the data.

Re:needs usability

[dintech]

I think you just described Windows Vista Bitlocker.

For some reason I read that as Windows Vista Blocker and got excited there. Never mind...

ZFS

[hitchhacker]

Any idea if OpenBSD supports Sun's ZFS filesystem?

-metric

Re:ZFS

[larry bagina]

No, but FreeBSD 7 and OpenSolaris do.

Re:ZFS

[Anonymous Coward]

Has anyone seen a guide on using OpenSolaris on something like a VIA epia processor with RAID-Z and ZFS?
I believe the 1.5GHz C7 would be more than adequate, and you could use something like a Jetway J7F4K1G5D board with gigabit ethernet and a 25W peak power consumption. Assuming ~10W per drive, you could put together an array of 4 non-homogeneous spare drives at an idle power consumption of 50W or so. You can put 4 drives on an epia board like above (2 SATA, 2 IDE) and probably another 4 or so using an SATA PCI card.

Re:ZFS

[Nimrangul]

I do have an idea, the answer is no. The timeframe for it's support is when Sun releases ZFS under an ISC-style licence.

Re:ZFS

[Anonymous Coward]

I'm too lazy to dig up links right now, but I've read on the OpenSolaris forums that Raid-Z on ZFS really benefits from using a 64-bit CPU.

Re:ZFS

[LuSiDe]

OpenSolaris has bad hardware support, and while Pawel did a terrific job the port for FreeBSD 7.0-CURRENT isn't quite there yet. ZFS requires a lot of RAM and indeed 64-bit (FreeBSD/AMD64) is recommended. You'll need at least 1 GB RAM, with 512+ MB dedicated to ZFS. You'll need to fine-tune via sysctl.

The EPIA is nice but probably too slow for ZFS. At the vey least you can only use it as fileserver and will have to delegate other applications to other computers. Why not get a cheap, low-power dual-core AMD with EE (and SFF)? Mine (EE + SFF) has an idle of 10W and a TDP of 35W. I admit not as low-power as EPIA, but here that box is the only computer 24/7 on, and does a lot more than merely NAS.

This sounds great and all..

[mr_stinky_britches]

but can it do 2 gzips at the same time!?

USB drives?!?

[Anonymous Coward]

I can't believe that after developing such a nifty system, the author suggests it can be expanded with USB drives.

USB was o.k. last year, but with 20GB/sec effective transfer rate at most, it simply doesn't do a large modern HDD justice anymore. For me, the only justification for USB is convenience and everything small enough that it can be self-powered by USB, like some 2.5" HDDs.

Anyways, I would caution anyone from crippling their crypto box transfer rates with USB.

Re:USB drives?!?

[gardyloo]

USB was o.k. last year, but with 20GB/sec effective transfer rate at most, it simply doesn't do a large modern HDD justice anymore.

    Jeeeeezus! Either I'm way behind the times, or your "GB" was meant to be perhaps a thousand times smaller.

Re:USB drives?!?

[node159]

Shit I don't know what crappy USB enclosures you're using, but dam man, get something decent.

Re:USB drives?!?

[hmallett]

When is your next book "More Typo's I found on the Internet" coming out?
It's late and nitpick stuff like this has been driving me nuts all week.

There shouldn't be an apostrophe in Typos...

Re:USB drives?!?

[gardyloo]

Yeah, and shouldn't he have said "nitpicky stuff"?

Re:USB drives?!?

[Thing 1]

Yeah sorry, It's late and nitpick stuff like this has been driving me nuts all week.

"Why do you have a captain's wheel around your waist?"

Re:USB drives?!?

[Anonymous Coward]

Actually it's 1024 times smaller...

Yawn... I prefer Ubuntu for this function

[Anonymous Coward]

I've been doing encrypted Raid5 machines for years. XFS, on top of Loop-AES, on top of software Raid5 is the bomb. Add nfs-kernel-server and samba and you have a full service network server. It's pretty easy with Ubuntu, and now Feisty (with kernel 2.6.20) supports hot plug eSata, for fast backup to portable eSata disk drives. ZFS with encryption might conceivably replace the XFS/Loop-AES/Raid5 recipe someday, but at the current rate of progress, it looks to me like its a year away at least. If Seagate gets their act together, and starts shipping 1TB drives with hardware AES support, we might see a big jump in disk throughput. In any event, I use a headless file server with a frozen version of Dapper for the fileserver, and then run Feisty on a diskless machine that boots off the file server. If I need Windows, I just use VirtualBox on the diskless Feisty machine. And of course, it's all backed up offsite every night with rsync. Rsync is indeed our friend. So why would I need BSD again?

freenas...

[Tmack]

Meh...

1. download FreeNAS
2. install to USB/CF drive (it needs ~32Mb)
3. configure * reboot on the USB/CF drive (or if your mobo cant boot to those, maybe a CD or spare HD)
4. ?
5. Profit!

Tm

Re:freenas...

[Anonymous Coward]

I could not really find out whether FreeNAS supports encryption, but there is another FLOSS alternative: the CryptoBox project. It uses dmcrypt, is multi-user capable and has a nice Web GUI.

http://cryptobox.org/

Re:freenas...

[Anonymous Coward]

Collecting Underpants!!

Re:freenas...

[LuSiDe]

I could not really find out whether FreeNAS supports encryption

Latest FreeNAS supports 'encryption' (ahem, i meant disk encryption) via GELI.

Re:freenas...

[Anonymous Coward]

Of course, the performance on FreeNAS is so abysmally slow that nobody has the n^m years it would take to actually copy the data off even if they could break the encryption.

Already done

[DogDude]

Well, it's already done. It's called FreeNas. Typical OSS advocate. Re-inventing the wheel... yet again.

Re:Already done

[Anonymous Coward]

Oh, oh! Or we could just use Gentoo! Or a previously made hardware NAS! Dipshit. The man wants to use a specific system, not your random option, the one that suits his needs. Perhaps he takes security seriously? You really grind my gears, assholes like you, going around telling people what they should and shouldn't do, condecending to them.

Just because there is an already existing solution to a problem, does not mean that that is the solution to every problem. Do you snipe with a Desert Eagle? No? Well shit, it's a fucking gun isn't it? No need to go around reinventing the gun!

The man just made a highly detailed how-to for something quite complecated, and all you can do is be a whiney bitch. Christ, you need your internet membership revoked.

Re:Already done

[davmoo]

FreeNas does encryption now?

Re:Already done

[Architect_sasyr]

It does not. If we read through the article we do find, however, that the author suggests FreeNAS for a NAS, OR CryptoBox for hardware encryption. IMHO neither solution leads to the extension into a full blown server that the OpenBSD option gives.

My $0.02 AU

Re:Already done

[DogDude]

Yes, it does. AES, Blowfish, and 3DES. And it also does RAID.

Re:Already done

[empaler]

Just because there is an already existing solution to a problem, does not mean that that is the solution to every problem. Do you snipe with a Desert Eagle? No? Well shit, it's a fucking gun isn't it? No need to go around reinventing the gun!

The man just made a highly detailed how-to for something quite complecated, and all you can do is be a whiney bitch. Christ, you need your internet membership revoked. You seriously owe me a cup of green tea. (I've had to reduce my coffee intake on the advice of my doctor)

Re:Already done

[Anonymous Coward]

First of all, FreeNAS is FreeBSD, not OpenBSD. And second, don't you have some cheapass dogfood to feed to your ugly wife? What are you doing posting on Slashdot, YET AGAIN?

Re:Already done

[Anonymous Coward]

The question is do you want a full blown server? If you don't, for example because that is harder to manage, then you opt for a NAS solution as pointed out in this thread. If you do, would you perhaps be glad to let a server running Linux or FreeBSD + RAID + disk encryption instead? Why OpenBSD? Why would you trust OpenBSD to do that, while discounting FreeBSD or Linux? That is a far more interesting question IMO.

Re:Already done

[DogDude]

Actually you're wrong. FreeNas does encryption. 3 kinds, even.

Re:Already done

[Anonymous Coward]

Sure thing, next time you see a random stranger, just tell him to pay up for the green tea, I'm sure you'll get me eventually.

Re:*BSD is Dying

[mdemonic]

**BITE**

Netcraft should know since they run fbsd themselves
You have pasted this troll before, have you not?

Re:Yawn... I prefer Ubuntu for this function

[Anonymous Coward]

Could you write up/point me to a howto for this? I'm interested in setting up a similar system but would prefer sticking to ubuntu rather than moving to bsd.

You must be new here.

[Anonymous Coward]

Does it seem strange to anyone else that the last several front page stories in a row have been posted by kdawson? Who is kdawson anyways? 1)No
2)He's an editor
3)???
4)PROFIT!!!

Or something like that.

Or...

[XCondE]

You can install Debian Etch and let the installer do it for you.

Re:Or...

[Anonymous Coward]

I was going to post that one!

Pretty Useless

[mvdwege]

Seeing as that he uses per-volume encryption, this is pretty useless. It makes his 'server' pretty much a single-user NAS box, because as soon as another user gets an account to access the file server, they get access to the data.

Data encryption on a fileserver only makes sense if it is done on a per-user level. This is not News for Nerds, as this is basically just another implementation of how to encrypt your local disk.

Mart

Re:Pretty Useless

[DamnStupidElf]

Seeing as that he uses per-volume encryption, this is pretty useless. It makes his 'server' pretty much a single-user NAS box, because as soon as another user gets an account to access the file server, they get access to the data.

As long as the server remains physically secure, and assuming there aren't gaping root privilege holes in the security, the files on the disk are still protected by the file system permissions. As long as the users can trust the admin, they don't have to trust each other.

Data encryption on a fileserver only makes sense if it is done on a per-user level. This is not News for Nerds, as this is basically just another implementation of how to encrypt your local disk.

Databases with private information like credit card or social security numbers should be on encrypted disks. Not to protect against users, but to protect against the drive being replaced or stolen before it can be wiped (secure wiping is not necessarily secure either, especially as drive technology advances, since what was wiped 5 years ago may be easily readable now).

There's really no advantage to having a server encrypt and decrypt each user's data with a different key. The server will have to know all the keys to perform the decryption at least (public keys allow secure encryption without the server knowing the private key), so it's only as secure as encrypting the entire drive and then relying on filesystem permissions. Root will always be able to read any files that are encrypted/decrypted on the server itself. If clients encrypt their files before storing them on the server, then the server can safely store everything in plaintext.

Re:Pretty Useless

[mvdwege]

There is really no advantage to encrypting data if you have other means to restrict access to a server.

Volume encryption only makes sense if there is a significant risk of losing physical control over the volume, i.e. on portable media. If your hypothetical server with private information is not in a secure datacenter, you're doing something wrong.

So, considering that a fileserver will have some form of access control anyway (in case of this NAS box, the locks on his house), why encrypt the entire volume in the first place? The first insecure client that connects makes the whole exercise moot, not to mention giving out the key to multiple users. And if there is no access control, neither physical nor logical, then it is just a local disk connected to a network instead of directly to a (S)ATA/SCSI bus. And local disk encryption is old hat.

Mart

Re:Pretty Useless

[bfields]

Databases with private information like credit card or social security numbers should be on encrypted disks. Not to protect against users, but to protect against the drive being replaced or stolen before it can be wiped....

If, as the original poster suggests, a large number of people in your organization have to have access to the key for this to work, then it doesn't really add much security--stealing the key off someone may not be any harder than stealing the drive.

There's really no advantage to having a server encrypt and decrypt each user's data with a different key. The server will have to know all the keys to perform the decryption at least

No, you'd do all encryption and decryption on the clients. This also has the advantage of offloading all the CPU-intensive crypto to the clients. Some complexity is required to make this work for shared data, but it's possible.

Re:Pretty Useless

[Bishop]

Using disk or volume encryption is part of a layered security approach. Even in secure facilities things are stolen.

Physical security mitigates the threat of an attacker gaining physical access to the machine. Disk encryption mitigates the threat of an attacker gaining access to the disk (e.g. theft). File encryption mitigates the threat of an attacker gaining access to the running system (e.g. over the network). For good security you should use all of these tools.

Re:Pretty Useless

[DamnStupidElf]

If, as the original poster suggests, a large number of people in your organization have to have access to the key for this to work, then it doesn't really add much security--stealing the key off someone may not be any harder than stealing the drive.

The server has a single key which uses it encrypt/decrypt the data on the disk. It sends plaintext to the users, or optionally uses some other encrypted protocol to get the data to the clients. The users don't see the hard disk key. Other access controls are needed to ensure they don't just steal all the data over their client connection.

No, you'd do all encryption and decryption on the clients. This also has the advantage of offloading all the CPU-intensive crypto to the clients. Some complexity is required to make this work for shared data, but it's possible.

Typical public key certificate setup. Define groups and users as keypairs, and encrypt each file's random symmetric cipher key with the public keys that should have access. It's harder to manage (just as hard as any certificate setup) and changing permissions requires re-encrypting the entire file, but it's probably necessary over unsecured networks with untrusted users.

Re:Pretty Useless

[DamnStupidElf]

Volume encryption only makes sense if there is a significant risk of losing physical control over the volume, i.e. on portable media. If your hypothetical server with private information is not in a secure datacenter, you're doing something wrong.

Unless you want to pay to have someone shred your used hard disks, encryption is really the only safe way to keep the data on them secure. If you want warranty replacement on dead disks, you'll probably have to send them back for an RMA with the data still on them if it's not encrypted.

A physically secure location also won't protect you from a warrant. If someone really needs to do something that violates a law somewhere, it would make sense to encrypt the disks so that recovery of the evidence is impossible. Hell, a media server with music and movies ripped to it might even fall under that category, depending on how angry the MAFIAA gets.

So, considering that a fileserver will have some form of access control anyway (in case of this NAS box, the locks on his house), why encrypt the entire volume in the first place? The first insecure client that connects makes the whole exercise moot, not to mention giving out the key to multiple users.

The key only exists on the server, the clients never see it. They just see a normal mount via NFS, SMB, or whatever. Yes, a client with spyware or a malicious user on it can pull all the unencrypted data. That's a risk that has to be mitigated if the data is important enough, but no more of a risk than a traditional unencrypted network server.

Re:Pretty Useless

[deviantphil]

There's really no advantage to having a server encrypt and decrypt each user's data with a different key. The server will have to know all the keys to perform the decryption at least (public keys allow secure encryption without the server knowing the private key), so it's only as secure as encrypting the entire drive and then relying on filesystem permissions. Root will always be able to read any files that are encrypted/decrypted on the server itself. If clients encrypt their files before storing them on the server, then the server can safely store everything in plaintext.

Encrypting before storing would be all well and good except:

1. Users tend to leave the organization.
2. Users tend to loose keys and forget passwords. At which point they expect the IT department to be able to recover their data.

Re:Pretty Useless

[mvdwege]

The key only exists on the server, the clients never see it. They just see a normal mount via NFS, SMB, or whatever.

That makes even less sense. How does the server authenticate the client? If the server just decrypts and serves up the data to any client that connects, what's the use of encrypting? And if the server requires authentication to serve up the data, it could implement access controls just as easily. That leaves you with keeping data secret from other users/the administrators/someone with a warrant. That's what per-user encryption is for.

I'm sorry, I'm still not convinced volume encryption makes sense in this particular scenario.

Mart

Re:Pretty Useless

[BLKMGK]

BINGO! I've been reading the comments here wondering when the F someone was going to ask this. If someone runs off with my personal NAS then yeah I'm protected. If someone kicks in my door and logs in via a workstation or using their machine having observed my password this does NOTHING. Perhaps I could have a key secured on my workstation which is kewl but what about my XBMC'd XBOX? My aTV? My just about anything HTPCish that's like an appliance that wants to access it? Couldn't I just as easily have a PGP'd file that appears as a F/S for my workstations to send things too and leave the rest wide open and be just as secure?

I dunno' but from the first read of this article I couldn't help but wonder exactly WHAT he was trying to protect. Physical theft of the disks okay but at home I'm more concerned with the *AAs kicking down my door and whining about my having ripped all my DVD to the media server than I am someone sneaking in and snatching up my HDs. Frankly if someone has gotten into my home to do that I have bigger issues - as will they when the dogs spot them! :-D

Neat idea and perhaps an improvement over his other setup but I'm not sure this is nearly as cool as some might think when they read the headline for it....

Re:Pretty Useless

[DamnStupidElf]

BINGO! I've been reading the comments here wondering when the F someone was going to ask this. If someone runs off with my personal NAS then yeah I'm protected. If someone kicks in my door and logs in via a workstation or using their machine having observed my password this does NOTHING. Perhaps I could have a key secured on my workstation which is kewl but what about my XBMC'd XBOX? My aTV? My just about anything HTPCish that's like an appliance that wants to access it? Couldn't I just as easily have a PGP'd file that appears as a F/S for my workstations to send things too and leave the rest wide open and be just as secure?

Dead man switch? Alarm system? Simple menu-based security on the media PC with a reasonable timeout? All you really need is just a script that unmounts the encrypted drives if the wrong menu choice or action is made more than two or three times, or if no network activity has occurred for 30 minutes or something. If you're asking how to evade a dedicated surveillance team monitoring you with binoculars, wiretaps, keyboard loggers, and spyware, then I obviously have no idea. At that point, you might as well have encrypted your drives so that when you suspect you're being watched you can press a button to wipe the encrypted master keys from the disk within a few seconds instead of hours to wipe the data, since you'll probably be raided when you do it.

Re:Pretty Useless

[DamnStupidElf]

That makes even less sense. How does the server authenticate the client? If the server just decrypts and serves up the data to any client that connects, what's the use of encrypting? And if the server requires authentication to serve up the data, it could implement access controls just as easily. That leaves you with keeping data secret from other users/the administrators/someone with a warrant. That's what per-user encryption is for.

The server authenticates clients the same way a traditional setup does, with usernames and passwords or host based authentication for NFS. I didn't say either of those were particularly good choices for secure file system access. scp would obviously be better, but isn't suited to realtime streaming. Mounting filesystems over an SSH tunnel or VPN between the client and server would work too. Per user encryption is probably better, but I don't know of many filesystems that support secure transparent user encryption, or of any that support group permissions. I haven't looked very thoroughly though, since I don't have a need for multiuser encryption.

Re:Pretty Useless

[LuSiDe]

Good points which should certainly be taken into account but it does not mean disk encryption is utterly useless. Let try to address them.

Changing password, key management are other examples of important features. If you log in from insecure computers (e.g. via SSH), consider to use USB stick + S/Key. GELI has emergency destruction which is also a useful feature. Another point to take into account is metadata on any NAS clients, and the NAS server itself. Ofcourse, you log out of your computer(s) when you're not behind 'em (e.g. sleep); that is computer security 101. In some jurisdictions such as UK you have to give your key whereas in other jurisdictions you don't have to cooperate w/your own prosecution, although you may be lied to and/or be intimidated. When someone kicks in your door, your setup should be made in such way, that even with all machines on, the data cannot be accessed. They'll then power down the NAS and they're doomed. Logging out Samba, OpenSSH, not saving root passwords on clients are all mandatory, but quite logic measures.

What a moron

[pugdk]

I somehow forgot to do filesystem-checks on the 'virtual' encrypted filesystem and exactly there were a lot of errors to repair (and that caused the machine to hang and/or go back to the debugger even when copying to it). So, as a lesson, if the shit really hit the fan and your machine acts up like mine did (for the first time in 2+ years), make sure you also fsck the svnd0c (in my case).

I mean seriously, the guy just now realized he should fsck his encrypted volume.... I would trust his howto as far as I could throw it. Why the hell did this make the slashdot frontpage? *sighs*

Don't use loop-aes anymore.

[Ayanami Rei]

Use dm-crypt with LUKS in the aes-cbc-essiv:sha256 mode (should be the default). There are policy issues and known plaintext attacks against loop-AES unless you the multi-key setup which _isn't_ the default... by the times the issues were widely known people were using LUKS because key management is more flexible.

Re:Don't use loop-aes anymore.

[twistedcubic]

There are policy issues and known plaintext attacks against loop-AES

Can you elaborate on this? How about a link? Are you slandering Loop-AES because of a personal grudge, or something else?

Re:Don't use loop-aes anymore.

[c0nehead]

http://lwn.net/Articles/67216/

Re:Don't use loop-aes anymore.

[Anonymous Coward]

There are policy issues and known plaintext attacks against loop-AES

Can you elaborate on this? How about a link?

Only one I could find is that CryptoAPI (hence LUKS) and TrueCrypt supports LRW whereas loop-AES does not.

Re:Don't use loop-aes anymore.

[Anonymous Coward]

Any crypto system can be used in the wrong way, leaving it open to attack. Loop-AES is no different. You need to use 65 multi-key mode, of course. The file containing the 65 keys is encrypted again, using an iterated salt value, and a 20 character password. The USB key that holds *that* encrypted file (and associated scripts for mounting and checking the encrypted volumes) is encrypted *again*, using a different salt value and an iteration count that is so high it hurts. It takes my machines a full 2 minutes to run the 200 million iterations on the salt+20 character password to decrypt the USB key. This is because the guys with infinite resources have certainly built hardware accelerators (think arrays of FPGAs inside banks of Cray supercomputers) to do fast password searches. I figure they can do a key iteration at least 1K times faster than I can, and probably 1M times faster. But with a 200M iteration count, they are still screwed on a brute force search on a 20 character password, at least for the next 5 or 10 years. The LUKS encryption system looks interesting, but until I can benchmark it as substantially faster than loop-AES, I see no real reason to switch.

Re:Don't use loop-aes anymore.

[LuSiDe]

Why LUKS was developed. LUKS supports LRW, ESSIV, and TKS1.

Re:Don't use loop-aes anymore.

[twistedcubic]

The only thing I could find in this pdf about insecurity in loop-AES's CBC is

So, the user has no other option than to use CBC and its probably secure (or not) variants that are included with loop-AES and TrueCrypt.

I was asking for evidence of "policy issues and known plaintext attacks against loop-AES". Still looks like slanderous FUD to me. For some perspective, please search the LKML for arguments between Fruhwirth Clemens and Jari Ruusu.

Re:Don't use loop-aes anymore.

[twistedcubic]

There is nothing in this article about a weakness in loop-AES.

Re:Don't use loop-aes anymore.

[Daffy Duck]

Notice how all the documents favoring and supporting the LUKS ideas were written by the same person? The only thing that made LUKS "standard" is that Jari Ruusu and Linus Torvalds were having a pissing match about the licensing status of Brian Gladman's optimized AES code, which ended with Jari pulling his code from the kernel. So LUKS (which uses the same AES code) is a standard because the author didn't have a personal confrontation with the kernel team at that time. Later, though, Clemens declared:

The Linux kernel is a design disaster. This might be a consequence of the development style. However, the result is that I have dropped any intentions to support LRW on Linux.

So you don't have LRW support on Linux.

Meanwhile, I've yet to see any expert review of either system. The closest I ever saw was David Wagner (well known crypto expert at Berkeley) saying that Clemens "does not understand cryptography very well".

I use loop-aes myself, partly because it's actually pretty easy to use, and mostly because of the extraordinary effort that Clemens put into denying the existence of the problems with his dm-crypt code. Just to be clear, the "well known" problems with loop-AES were shared by dm-crypt, and they were only well known because the loop-AES author acknowledged them loudly and fixed them while Clemens kept shouting "no no no there is no attack and you are stupid".

Re:Don't use loop-aes anymore.

[LuSiDe]

So you don't have LRW support on Linux.

There is much to say about Jari Ruusu as well. Thanks for pointing our my sources were one-sided.

However, this quote of yours is a lie. Update yourself. LRW is very important, and has been around since Linux 2.6.20. Its well worth changing to LRW if you're using LUKS. TrueCrypt dropped CBC altogether, in favour of LRW, merely only supporting CBC for backward compatibility. This is due to known attacks on CBC which LRW (and EME) mitigates. For example the watermark attack. While EME solves even more attacks, it also generates much more I/O than CBC or LRW hence there is a performance drawback.

Just to be clear, the "well known" problems with loop-AES were shared by dm-crypt, and they were only well known because the loop-AES author acknowledged them loudly and fixed them while Clemens kept shouting "no no no there is no attack and you are stupid".

Ah, I see. When will loop-AES support LRW?

Re:Don't use loop-aes anymore.

[Daffy Duck]

However, this quote of yours is a lie. Update yourself. LRW is very important, and has been around since Linux 2.6.20. Its well worth changing to LRW if you're using LUKS. TrueCrypt dropped CBC altogether, in favour of LRW, merely only supporting CBC for backward compatibility. This is due to known attacks on CBC which LRW (and EME) mitigates. For example the watermark attack. While EME solves even more attacks, it also generates much more I/O than CBC or LRW hence there is a performance drawback.

Agreed, and thanks for the update. As for LRW in loop-AES, only Jari can tell you. :) In the absence of expert evaluations of either system, I opted against the one whose author's response to newly discovered vulnerabilties was to bury his head in the sand. Now that it seems that he's no longer driving the code base, I'm back to square one. :( Cheers.

Re:Don't use loop-aes anymore.

[Daffy Duck]

Upon doing some further reading, I'm not sure that generic LRW is desirable for software-based disk encryption. The IEEE storage encryption folks dropped LRW due to concerns about leaking the tweak key.

His system is great and all but...

[Anonymous Coward]

I am still looking forward to windows home server. I know, I know its not open source and is from what many people here consider to be the evil empire. But, it does do things that I have not seen anyone in open source doing (the seemless backing up across as many external drives as you want for instance). Hopefully in the coming years some open source projects will get started to do what Home server will be doing.

Re:His system is great and all but...

[cheater512]

Uhhh....You can do that with FOSS. It just doesnt have a pretty GUI.

Re:His system is great and all but...

[martin_henry]

you might have to settle for small business edition...there is no "home server" --> http://www.microsoft.com/windows/products/windowsv ista/editions/default.mspx

Re:His system is great and all but...

[Zantetsuken]

Not YET there isn't - as he said, he's looking *forward* to it. A quick Wikipedia or Google search using "Windows Home Server" will get you your info...

Really though it won't be worth it at all - more than likely I'm thinking it will be retail only (HP, Dell, etc). Also, being Server '03, I'm guessing its gonna take a bit more power to run than what a cli install of Linux or BSD can make do with, meaning less options of older underpowered machines to use which can be found for dirt cheap...

Re:His system is great and all but...

[Saurian_Overlord]

That comment didn't say anything about Vista. He (or she) said "Windows Home Server."

http://www.microsoft.com/windows/products/winfamil y/windowshomeserver/default.mspx

Re:His system is great and all but...

[Kryten107]

Hopefully in the coming years some open source projects will get started to do what Home server will be doing. Take a look here: http://www.ubuntuhomeserver.org/ Yes, I know, it's Ubuntu, but the point is that there are some people in the community that are trying to make it happen. Almost all the necessary services exist, it's just a matter of gluing them together and slapping a decent GUI on it.

Re:His system is great and all but...

[Anonymous Coward]

awesome, cheers for the link.

Use UnRaid

[Anonymous Coward]

A fine alternative is UnRaid (just Google it). Boots from a USB stick. It is basically RAID w/o striping, with 1 parity drive for up to 13 data drives. Lose 1 drive and it will rebuild and recover using parity. And if you have a catastrophic failure, instead of losing all data like RAID, you only lose the data on the failed drives and the others are fine.

And your drives can be different sizes, so you can add capacity in any amount (i.e. whats on sale).

Re:Use UnRaid

[pe1chl]

It looks like what I want, especially the spin-down of unused drives and the separate use of each disk.
What I like less is the mandatory use of ReiserFS. Any idea if they plan to support other filesystems?

Do you have actual experience with this product?

Re:Use UnRaid

[Anonymous Coward]

I use it and it is a charm. The only feature missing is S3 suspend support and wake on lan, which is high on the list of features for the next version.

Particularly for a server that has large files, but infrequent use (think media server with movies and ISOs) drives can sleep for weeks. So less wear and tear on the drives, less noise, and less power.

What's the issue with RFS? I don't care if the guy is an axe murderer... the FS is good.

Re:Use UnRaid

[pe1chl]

I do have a server like that, but without RAID. Deliberately, because I do not want all drives to spin up when I watch a movie. The rootfs is on IDE-FLASH and the system is silent when not in use.
The redundancy solution in this product looks nice. Pity that it is closed source.

As a SuSE user I have ReiserFS filesystems on many systems, but on my mediaserver I used EXT3. It is slower, but for the operations done on this server it is not important. It looks like ReiserFS is on the way to be deprecated in Linux, and with no in-place conversion utilities available I would hate to be left with terabytes of data that is getting harder and harder to access.

Does the UnRaid support only SMB? Or can it do NFS as well?

Re:Use UnRaid

[cayenne8]

"It looks like ReiserFS is on the way to be deprecated in Linux..."

Really? I'd not heard that...is it because the developer is in jail?

What FS appears to be the one to use now on a Linux system?

Re:Use UnRaid

[pe1chl]

I think it is not mainly because Hans Reiser is in jail. The relation between Hans and the kernel developers has been difficult all the time.

Some time ago, maintenance on version 3.6 has been abandoned by Hans Reiser in favor of working on the 4.0 version. A few people at SuSE continued to work on it, but received negative comments from Reiser (who accused them of introducing new bugs). Of course the environment at SuSE has changed as well, and there has been an announcement that they will stop as well.
That leaves the 3.6 version without maintenance. We can only guess for how long it will survive in a changing kernel without becoming unstable or before it even no longer compiles.

The new version 4 has not been accepted into the official kernel, and the situation around Reiser likely has not increased the chance that it will be.
The developers state that EXT3 has been improved and will be further improved. That is probably the most used native Linux filesystem.

And of course other alternatives (ported from other systems) are becoming available.

All in all it is a bit sad, ReiserFS was a fast filesystem and I have good experience with it. But I am using Linux for nearly 15 years now, and if there is one thing I have learned it is that it is useless to row against the flow. When official support for something is being dropped, you have to look for an alternative.

Re:Use UnRaid

[cayenne8]

What's your opinion on say, XFS? I'd thought to move to that...especially on drives I'm working with video and other large files...

Re:Use UnRaid

[BLKMGK]

Just to clarify - unRAID doesn't have RAID either. Each disk is ReiserFS formatted as standard and can be pulled\mounted elsewhere. The only thing really non-standard is the use of a parity disk to store ones and zeros from the other drives. Drives spin down unless in use and parity will spin down too unless a write is being done. I have 12 drives in my system and normally 10 of them are sleeping while Bittorrent runs on a workstation writing to it. Performance isn't as good as some installations but for streaming it rox! Do SATA and performance is better, mine is all IDE. There are free versions available too and source is available when you boot it up....

Re:Use UnRaid

[Anonymous Coward]

ZFS is newer. no partitions!!

Re:Use UnRaid

[pe1chl]

I will try to boot it up (first attempt failed as my system apparently won't boot from USB key so I will try something else) to see which sources are available.
I understood the workings of the parity disk, let's see if that is implemented in the kernel like RAID or if the whole thing lives in the userspace application.
It might be possible to just port over the parity idea to my existing server (which is running SuSE 10.0 from a 512MB IDE-FLASH disk)

Of course with this idea, each write will transform into two reads and two writes (to re-calc and update parity) so write performance probably suffers. Read should be as fast as a single drive, unless the method of implementation slows it down.

Re:Use UnRaid

[Darby]

What FS appears to be the one to use now on a Linux system?

There isn't one true filesystem. It depends on what you're doing with it. Reiser is really good for lots of small files, JFS is good for quickly deleting large files (MythTV box for instance). In testing I did for mysql with our particular useage patterns, XFS was *way* faster than JFS, reiser or ext3.

So our typical mysql box will have 3 different filesystems. ext2 for /boot, reiser for the system partitions and xfs for mysql data/log partitions.

Really, you should experiment with the applications you use in your environment.

Re:Use UnRaid

[BLKMGK]

Yes, writes are slower! However depending upon what it is you're trying to do that's not a really bad penalty. For a home user who wants to have a large NAS feeding an HTPC this works out great. Do NOT try to rip a DVD straight to it though (lol) as I found the performance maddening but ripping local, copying in background, and then streaming works very well in my case. The author has open sourced his changes to GPL code but has NOT done so with his management application which is his right, it's a pay for play application that I support and is geared for home users. It could perhaps be taken in other directions too, I've suggested it on the Ubuntu @ home forum that's building a home server to counter Microsoft's effort :-) Having used this software for more than a year I've found it mostly meets my needs and has gotten me through 2 drive failures no problems but did fail me when I did something stupid software wise but only lost two drives worth of data. I do not bitch about that too much as it was beta code I was running, oh well.

If you get too stuck getting to the source you might ask on their forums or if I can figure out, again, how to get at the source perhaps send it along. I cannot add much of anything to tweaking it but would happily enable others so inclined so long a sit's not a deluge of requests ;-)

*BSD Troll-in-One returns!

[Anonymous Coward]

All the *BSD is dying posts are contained in this one post. If you have mod points, please mod this up so that everybody will know that *BSD is dying! No need to post your own, as it will only be redundant!

Oh, and if I've missed any, please add your troll as a reply and I'll include it in the next Troll-in-one.

_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_

The *BSD Wailing Song

What's left for me to see
In my ship I sailed so far
What can the answer be
Don't know what the questions are.
And after all I've done
Still I cannot feel the sun
Tell me save me
In the end our lost souls must repent.
I must know it is for certain
Can it be the final curtain
As long as the wind will blow
I'll be searching high and low.
Who knows what's really true
They say the end is so near
Why are we all so cruel
We just fill ourselves with fear.
And heaven and hell will turn
All that we love shall burn
Hear me trust me
In the end our lost sould must repent.
I must know it is for certain
Can it be the final curtain
As long as the wind will blow
I'll be searching high and low
Final curtain
Final curtain


_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_

• flask of ripe urine
  pressed to bsd lips
  bsd drink up

_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_

I don't want to start a holy war here, but what is the deal with you BSD fanatics? I've been sitting here at my freelance gig in front of a BSD box (a PIII 800 w/512 Megs of RAM) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to another folder. 20 minutes. At home, on my Pentium Pro 200 running NT 4, which by all standards should be a lot slower than this BSD box, the same operation would take about 2 minutes. If that.

In addition, during this file transfer, Netscape will not work. And everything else has ground to a halt. Even Emacs Lite is straining to keep up as I type this.

I won't bore you with the laundry list of other problems that I've encountered while working on various BSD machines, but suffice it to say there have been many, not the least of which is I've never seen a BSD box that has run faster than its Windows counterpart, despite the BSD machines faster chip architecture. My 486/66 with 8 megs of ram runs faster than this 800 mhz machine at times. From a productivity standpoint, I don't get how people can claim that BSD is a "superior" machine.

BSD addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a BSD over other faster, cheaper, more stable systems.


_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_

It is common knowledge that *BSD is dying. Almost everyone knows that ever hapless *BSD is mired in an irrecoverable and mortifying tangle of fatal trouble. It is perhaps anybody's guess as to which *BSD is the worst off of an admittedly suffering *BSD community. The numbers continue to decline for *BSD but FreeBSD may be hurting the most. Look at the numbers. The erosion of user base for FreeBSD continues in a head spinning downward spiral.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of BSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI

Re:*BSD Troll-in-One returns!

[Anonymous Coward]

cock-sucking Kreskin [amazingkreskin.com] [amazingkreskin.com] [amazingkreskin.com] Dude...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Use LUKS with a high iteration count as well

[DamnStupidElf]

Since LUKS supports PKCS-5 style iterative hashing of the passphrase, it's a good idea to use that too. A million iterations only take a few seconds (10 on my 1.5Ghz Athlon) to compute at mount time, but make dictionary attacks a million times harder.

Nice PHB thinking there.

[Anonymous Coward]

Forcing people to encrypt the data before copying it off the machine doesn't do anything. They can still go ahead and decrypt it on their laptop and leave it like that since its more convenient. You can't solve social problems with technical solutions. The sooner you learn that the sooner you stop making people's lives difficult for no reason.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Yawn... I prefer Ubuntu for this function

[kwark]

What! You are saying that Ubuntu doesn't do this on install? Even the Debian Installer has support for these kind of setups.

Re:Yawn... I prefer Ubuntu for this function

[Anonymous Coward]

raid5 in software is a cpu killer, but I'll leave that to you.

In Soviet Russia...

[Anonymous Coward]

The data encrypts you!

NAS

[ebolaZaireRules]

hold you hand out... if it shakes, you have NAS

Suggestions

[LuSiDe]

OpenBSD on a fileserver? Firewall, sure. Fileserver w/RAID and disk encryption, no way. I would leave that task to FreeBSD (FreeNAS) or Linux (CryptoBox, Openfiler). If you are desperate for encrypted FS + RAID you can use MD + LUKS (Linux) or GRAID5 + GELI (FreeBSD) those are all available via FreeNAS, CryptoBox, and Openfiles. Suffice to say both have proven their stability, have a rich set of features (e.g. LRW), and are simple to set-up. The end-user NAS solutions are pretty sophisticated and have good web interfaces.

20 MB/sec is quite a shit performance IMO however if you don't use gigabit it'd be good enough. With GELI there is about 55% overhead compared to plain text. I haven't compared LUKS to plain text hence can't compare. On a side note, I doubt its useful to encrypt data you're receiving from distributed areas, nor that its useful to put such data in a RAID. A NAS doesn't run BitTorrent. If you're paranoid whereas you share your data over SMB, that might be the weakest point.

For our ricer folk, a nice, expensive RAID controller is necessary. For the smart people among this planet: do software XOR by getting an EE (or SFF) dual core AMD which are cheap and have a a low 10 idle W and have a low TDP (the SFF has 35W TDP). Get 4 Samsung SpinPoint T166 SATA (silent, low power, best bang for buck) and you have 1,5 TB RAID. All in all this costs about 650 EUR (probably less in USA) w/all hardware new including case, 2 * 1 GB RAM (2 * 0,5 GB would suffice too), and PSU. I should know, I bought and build such machine.

Forget ZFS for now. OpenSolaris has bad hardware support, and it is only partly ported on FreeBSD 7.0-CURRENT where it isn't stable and a bug in it takes the whole system down. While it does have a rich set of features, it also doesn't support encryption yet, although the feature has been planned for a year and perhaps on FreeBSD it can be used together with GELI. Performance of ZFS is also not to write home about compared to GRAID5. ZFS isn't mature yet. Nor is FreeBSD 7.0-CURRENT, ofcourse. It'll be part of FreeBSD 7.0 however, as an experimental feature.

Re:Suggestions

[Bishop]

Good recommendations on the hardware and software. A low power AMD X2 3800+ is a fantastic cpu for home servers. An AMD system beats Intel on price, and generally consumes less power at idle. The Intel Core 2 may be faster, but home servers are typically limited by hard drive speeds not cpu.

On the software side it is hard to recommend OpenBSD for a file server. OpenBSD has traditionally lagged FreeBSD, NetBSD, and Linux when in come to file system access, and it would seem to still be the case. While anecdotal, my Linux server with encrypted disks can get about 40MiB/s to and from the drive. The system was an AMD X2 3800 with 1GB ram running Debian/Etch/AMD64. The system was setup with EXT3 on LVM on dm-crypt with LUKS on software RAID 1 on two IDE Seagate 80 GB drives.

A sibling post mentions security. At this time that is a bit of a white elephant. There is no reason a FreeBSD or Linux system should not be just as secure as the OpenBSD system. All are using similar, if not the same, sever software.

Re:Suggestions

[Anonymous Coward]

And you have just proven yourself to be a complete fool, congratulations. Every time some dipstick on Slashdot says something this idiotic, I wonder how easy it would be to just start a firm and ask Microsoft for some capital, so that I could make viruses just so we could infect machines run by people like you. I am sure they'd like to be able to point to the hundreds of viruses we'd make as a sign of just how secure machines are when run by people like you.

There is a massive difference between running OpenBSD's ftp server, and the GNU's ftp server, you can bet on it. From prevelidge seperation to malloc allocation to NX bits, OpenBSD runs in a very different way from your FreeBSD or Linux system, that you would think otherwise shows a complete and utter lack of any knowledge of what OpenBSD is or how it works, go read it's website, you may learn something important about what a secure system is, but then, your head's a bit too far up your ass to be the kind to take advise, you only hand it out.

Re:Suggestions

[LuSiDe]

Theo, good for you. We don't use FTP servers on NAS, nor do we use such on RAID + full disk encryption setups as FTP defeats their purpose. We only use SMB/NFS on a NAS.

Its funny how the OpenBSD zealots are always ACs. Why don't you go play in your own garden? Now, I give you a point for having implemented PKCS#5 PBKDF2 since OpenBSD 4.0 (quite late but still), but you still miss obvious features such as not limited to: LRW, key management, emergency destroy, changing password without encryption. Besides, the performance of this setup is shit. You can tell by the fact that the write performance is 16 MB/sec, whereas the read performance is merely 25 MB/sec. The fact the author is possitive about such is striking. Note, how it does matter whether this is benchmarked w/bonnie++ on the box, or via say Samba, or some other method. Still, they both should be much higher even with the overhead of full disk encryption.

Re:Suggestions

[NoMaster]

Honestly though, for the average user running SMB mounts over a 100bps LAN, the CPU matters fuck-all. Having an AMD X2 3800+ or Intel Core2Duo in your server gets you dicksize bragging rights, a lighter wallet, and not much else.

I used to run a minimal linux installation - and later OpenBSD - on an old P100 as a home server, and with decent NICs the bottleneck was always either the theoretical LAN speed or SMB. I now run an OpenBSD Samba server on a 600MHz VIA Samuel 2 Mini-ITX system, and that's only so I could put it in a smaller quieter box. With a couple of clients pulling XviD video real-time off an external USB2 drive, I rarely see the load avg get above 0.3.

Re:Suggestions

[WuphonsReach]

Honestly though, for the average user running SMB mounts over a 100bps LAN

I don't know where you've been for the last 2-3 years, but gigabit networks are pretty mainstream at this point. Just about every computer made in the last 3-4 years has gigabit network ports and the small 4/8 port switches are dirt cheap.

And mini-ITX systems are not inexpensive (except in terms of running cost). You can put together an X2 3800+ system w/ 2GB of RAM and a decent motherboard for around $250-$300 (depending on memory prices). I have both a 600MHz C3 (fanless) and an Athlon64 X2 3800+ system (the 35W 3600+ CPUs are hard to find and rather expensive).

On the whole, I prefer my X2 system over the C3 mini-ITX. Yeah, the mini-ITX is cool and fanless and super tiny and really cool... but replacement parts are a wrench. If that little PSU conks out in my Morex Venus case, I have to hope that I can still buy the somewhat proprietary shaped replacement PSU from Morex. On the X2 system, it's in a bog-standard Antec p160 case with a standard ATX PSU. I always have a spare ATX PSU laying around, so it would take me all of 30 minutes to get the unit back up and running. Worst case, I could run around to the corner electronics shop and replace every component in the system with equivalent standard PC parts.

Proprietary or hard-to-replace-quickly hardware sucks.

Re:Suggestions

[Anonymous Coward]

Why is it you jagoffs on Slashdot all think than anyone posting in support of OpenBSD is, in fact, Theo de fucking Raadt himself?

Is there some collective mental defect that comes with getting an account? Should I be happy that I only come around when there is a discussion about something I find mildly relevent, and rather than having an account and password that I won't remember since I come by once every three or four months, have chosen to just post anonymously?

One example of the very gross deference between a Linux install and an OpenBSD install was given, that's not to say that I was implying that ftp is the only difference, cockwad.

Good Lord Almighty, what is wrong with you people? Seriously!

Re:Suggestions

[Bishop]

The context of this discussion is buying new hardware for a home server. Obviously junk you have sitting in the basement is cheaper then something new.

Check the prices. An AMD X2 is excellent bang for the buck. It costs only a few dollars more then the cheapest CPU and for that you get a second core, more cache, more speed, and virtualization support. At idle it likely consumes less power then a p100, and definitely supports larger hard drives. While the mini-itx systems are small and cool, the cost is rather high. If anyone here has dicksize bragging rights and a lighter wallet, it is you.

Re:Suggestions

[LuSiDe]

Good points.

Here's what I payed for CPU/MB/RAM

AMD Athlon 64 X2 EE 3800+ 90nm/35W SFF 2.0 GHz BOX 63
Abit AN-M2 73
2048MB DDR2-667 PC-5400 Corsair ValueSelect (2x 1024) 81

Those were approx cheapest prices I could find a few weeks ago. All in 1 it costs 217 wihch is $293, + S&H. Hardware prices in USA are lower than in EU though. Note that 2x 512 MB would have been suffice too however given I'm not going to run pure NAS (ie. some other software on it) and might use ZFS in the future its also a wise choice. Dual-core is also overkill, but again non-pure NAS plus I like the low-power EE/SFF.

GP wrote:

I used to run a minimal linux installation - and later OpenBSD - on an old P100 as a home server, and with decent NICs the bottleneck was always either the theoretical LAN speed or SMB. I now run an OpenBSD Samba server on a 600MHz VIA Samuel 2 Mini-ITX system, and that's only so I could put it in a smaller quieter box. With a couple of clients pulling XviD video real-time off an external USB2 drive, I rarely see the load avg get above 0.3.

This says little about performance, and it matters a lot what you do with your NAS. You do use Samba. Do you even use (software) RAID at all? Disk encryption? On a P1 100 MHz?

My old servers (various Ultra 5 400 MHz in a redundant setup; later w/CARP) had a max read and write speed over Samba of approx 3 MB/sec. Enough for real-time XViD. The machines ran Linux 2.6.x with LUKS. Now, this setup did not even saturate on 100 Mbit, nor did it run any other CPU intensive applications. Process kcrypt was clearly the bugger on this system. If you want to do anything serious with your NAS (e.g. watching or burning a DVD) you're gonna need gbit for sure, and all modern hardware supports this. In hindsight I should not even have used LUKS on all the data, but my new setup is a bigger RAID w/hardly any disk encryption. Still, software XOR requires CPU power. However the advantage of the processor I outlined above, is that it uses 7W idle (less than 10) and a TDP of 35W. You will hardly ever use 35W on this machine if you only use it for software XOR. The bottleneck on your VIAs will be the processor, I am sure of that. Please post some benchmarks?

I'm glad you're satisfied with your VIA, I'm satisfied with my X2/EE/SFF processor + other hardware. Its also relatively low-power, and is able to do a lot more as well. Its the only system I have on 24/7, and the machine even does firewalling on a small home network. Saved me the costs of a Soekris, whereas my electricity bill/initial costs aren't that much higher than VIAs + Soekris. I can even run remote X on this server, running X applications 24/7, without having any other computer (desktop) on. Oh and I don't mean to brag, I just want people to make a conscious decision. :)

TY

[Anonymous Coward]

Why that got modded as troll I dunno.

Not really a very fair description

[jimicus]

So he made a few mistakes which you consider stupid. TBH, as soon as anyone says "NAS" without considering RAID and backups, I think they're on a path to pain.

But at the end of the day, no matter how many things you think about, no matter how much effort you go to, there is always something that gets missed. AFAICT, he's only got one power supply and no UPS on there, and on any large filesystem I'd consider journalling (or Soft Updates on OpenBSD) a must these days.

You can build a system in which nothing is missed, and it always works no matter what happens. But then you're talking realtime mirroring across at least two sites, gigabit links between the sites and regular DR tests to make sure everything works as intended. A little more sophisticated than your average /. article.

Re:Not really a very fair description

[CastrTroy]

Exactly. I don't think this is supposed to be some replacement for a large corporate NAS. Then again, I didn't read the article. But if you want a file server for your home use, and you want it to be encrypted, then there's probably not a lot wrong with what he's doing. RAID mirroring makes the cost of storage double, so I could see why a home user might back away from that. Also, a UPS, while nice, probably isn't completely necessary, because a little bit of downtime while the power is off probably isn't a bad thing, because we can assume all the other computers in the house will have lost power also. I don't usually have localized blackouts within different areas of my house.

Re:Not really a very fair description

[pugdk]

Yeah, he made a few mistakes the last time.

What mistakes did he make this time?

I guess we will never see a slashdot frontpage story about the guy who followed the directions in this howto and lost all his files and wasted a lot of time.

All I'm saying is if you write a howto about this AND it gets posted to slashdot AND ends up on the fronpage, you better be damn good because people will follow this blindly and who knows what he forgot this time around...

As I stated above, had this not been on the frontpage I couldn't have cared less.

Re:Not really a very fair description

[pugdk]

eew, and I just posted the above as "code", so much for being perfect ;-)

Re:Not really a very fair description

[MikeBabcock]

The extras I value-add to a small machine for file serving, in order:

1. 
    
2. An extra hard drive for software RAID-1
3. 
    
4. A UPS with voltage regulation -- clean power is amazing at keeping systems running
5. 
    
6. A third hard drive for a fast unattended rebuild
7. 
    
8. SCSI drives
9. 
    
10. SCSI RAID controller

The first two are somewhat reversible, depending on needs of course.
Please note the lack of "enterprise-ready" here, this is for mom-and-pop file servers and home use.

Re:Not really a very fair description

[networkBoy]

on my home server I did the following:
P3 ABIT BE6II board, 512 megs ram 100Mbps ethernet.
I have a small boot drive, only has the OS and made a ghost (it crashes I don't care, just pop in a new disk and restore the image).
I have a pair of 300gig drives for dynamic content, they are mirrored.
I have JBOD for everything else (static content like media files) the static content is either unimportant, or already on backup media (DVD). I've found this is the ideal balance for me and servs my needs nicely.
Wouldn't fly in a corp environment, but for home it's ideal.
-nB

Re:Not really a very fair description

[Amouth]

interestingly I have had localized brown outs in parts of my house....

I have underground power and water got into the line.. and one of the legs would drop in voltage for no reason.. so instead of 2 120v legs coming in I had 1 120 and 1 60v leg.. when say the heater would cut on power would bleed across from one leg to the other and things would work but when it turned off anything that was on the 60v side would brown out..

it was odd as hell.. if I unplugged my fridge then half the house would start working again .. none of it made since - that is until I realized that my power meter wasn't working (one of the new digital ones).. as soon as I turned off the main breaker the power meter would boot up and be good.. so I called the power company.. they strapped a solid state transformer to my house for a week so I could live off of 1 120v leg until they could repair the line...

but due to over doing UPS's .. none of my computers ever lost power.. hell I was online playing games during the last few hurricanes..

Re:Not really a very fair description

[rifter]

All I'm saying is if you write a howto about this AND it gets posted to slashdot AND ends up on the fronpage, you better be damn good because people will follow this blindly and who knows what he forgot this time around...

While I'd agree that ideally you want something really good if you are being published on slashdot, if anything because of the scrutiny of the audience, I don't think many would agree with your suggestion about people who follow the instructions blindly. Beside the fact that no instructions should be followed blindly, especially if you are supposed to know what you are doing, we must consider the source. The fact it's slashdot should be a red flag, and there are probably more than a few people here who would say that anyone who follows advice from slashdot blindly deserves what they get; probably more than the number who would say that of any set of instructions.

Re:Not really a very fair description

[pugdk]

I couldn't agree more that you should not follow stuff like this blindly. However, the more links his howto recieves.. the higher the google rating the more likely people will stumble upon it without realizing it was posted on slashdot ;-).

Re:Not really a very fair description

[WuphonsReach]

A third hard drive for a fast unattended rebuild

OTOH, if you're going to be doing mirrored drives with a dedicated hot-spare... why do it as a (2) disk active (1) disk as hot-spare setup? Why not make it a (3) disk active RAID1 setup where all three drives are in use at all time.

You cut your recovery window (the time period during which you're only running on a single drive) down to zero. You'll have to experience a triple failure (not just a double failure) before losing the entire array. You're less likely to have your last remaining disk fail when you start stressing the system to bring that hot-spare up to speed.

(This is pretty easy to do with Software RAID. Possibly the more expensive hardware RAID cards might offer the capability as well. Other then the wear and tear on the 3rd hard drive, which would normally be idle, there's not much downside at all.)

3-way RAID1 also makes for a nice "shove it in a closet and forget it" setup. When that drive does fail, you've got a bigger buffer to get in there and swap out the bad drive.

Re:Not really a very fair description

[MikeBabcock]

We've debated this in the office many times. The problem with a 3 drive live scenario is the activity levels on the spare drive. In a hot-spare scenario, the spare drive has a much lower probability of failure after an initial burn-in period. It leaves the risk of a catastrophic two-drive failure during rebuild, yes, but I think it depends on the application.

Re:Not really a very fair description

[WuphonsReach]

I wonder whether mdadm would build to the fresh drive using one or both surviving disks in the array. If it only reads from one of the surviving disks in order to build the new mirror, then the other drive doesn't get nearly as much stress and would be a lot less likely to fail at a bad time. Plus, mdadm could use the other surviving drive to service read requests in a timely manner during the rebuild. It's something that I'd have to test (since I have individual lights on each drive in my 3-way RAID1).

Alternately, if we assume that mdadm is going to do a full resync of the array (putting both survivor disks through their paces), I think that the odds of failure of both survivor disks is 1/2 that of a single disk. Assume that there's a 50% chance that a survivor disk will fail during the resync activity required to bring a new spare up to speed as an active member of the array. In order for both disks to fail, you have to flip the coin twice and come up with tails both times. The odds of that are 1:4 (instead of the 1:2 from having only one survivor). So by running 3-way active RAID1, you reduce the risk (by half) of losing the entire array during resync.

At least, I'm pretty sure the math works out that way.

I wonder if a weekly resync (# echo check > /sys/block/md0/md/sync_action) would help ferret out "weak" disks ahead of catastrophic failure.

NAS is an overused acronym

[CarpetShark]

Network Attached Storage, Neural Attentuation Syndrome, Network Access Server...

People need to stop using this and find more unique alternatives. Along with "MAC".

Mr President

[Anonymous Coward]

Wow I didn't know the Commander In Chief posted on slashdot! :D

Re:What an Arrogant Bastard

[pugdk]

I will never claim to be perfect, but when a howto makes the _frontpage of slashdot_ I assume the person who wrote it knows what he is talking about.

Judging by his mistake with the fsck he forgot the last time I sure as hell hope people don't just blindly follow his directions this time. God knows what he might have missed this time around.

Had it not made the frontpage and/or had been buried in askslashdot I couldn't have cared less.

Informative my eye.

[Anonymous Coward]

Yes, openbsd can be a fileserver. Why is it shocking that a general purpose unix OS can be used for general server tasks? There's no need to use an insecure OS for your servers and only use openbsd as a firewall.

that would be blocked

[r00t]

You won't be decrypting it without a key.

If you do in fact have the key on your laptop, then you must have been authorized to carry the data around without encryption. That would be unusual.

The idea is that you can put an encrypted blob onto your insecure laptop, take this to a different secure machine which has the key, and then get access to the content on that secure machine. The laptop (or DVD-R, or CompactFlash) can't decrypt since it lacks the key.

But...

[gaelfx]

...does its milkshake bring all the boys to the yard?

Software RAID

[maz2331]

Software RAID... sorry, but never use it. 3Ware SATA RAID cards are cheap enough that the cost savings just isn't worth it. I consider my data to be worth the extra couple hundred bucks rather than monkey around with SW RAID that is a real pain to rebuild. For the REALLY important stuff, I use an Adaptec 3400 RAID card with 10 SCSI drives, and sustain 86 MB/s over a RAID-5. You can get this stuff off eBay cheaply enough that cash isn't a real issue at all.

Re:Software RAID

[bitbucketeer]

Software RAID is hardly a "real pain to rebuild". What is the real pain is finding accurate, up-to-date documentation on how to do it. But once you know how, rebuilding's not any harder than hardware raid (other than having to type a command to start it up).

Re:Software RAID

[Sancho]

And it has the benefit of not requiring that you purchase a spare controller.

Re:Software RAID

[drinkypoo]

Software RAID... sorry, but never use it. 3Ware SATA RAID cards are cheap enough that the cost savings just isn't worth it.

The only advantage to buying a RAID controller is that you get a lot of connectors. Otherwise, if you have any even fairly decent CPU, and you're not doing anything but shoveling data and maybe some logging, the main processor beats the living shit out of almost any CPU on any RAID controller. There are limited exceptions but those cards are highly spendy.

If you buy a super-cheap dual-core, say one of those $70 AMD chips, and slap some $10 host adapters in, you can probably get dramatically better performance than with any RAID controller less than five hundred bucks and do encryption at the same time.

Re:Software RAID

[WuphonsReach]

The only advantage to buying a RAID controller is that you get a lot of connectors. Otherwise, if you have any even fairly decent CPU, and you're not doing anything but shoveling data and maybe some logging, the main processor beats the living shit out of almost any CPU on any RAID controller. There are limited exceptions but those cards are highly spendy.

And keeping a lot of data off of the interface bus. Hardware RAID controllers are all about delegation. Get the data off the bus and onto the card as fast as possible, without sending it over the bus multiple times. Which is less of a concern in the days of boards with 30+ PCIe lanes.

But back in the PCI days (prior to PCI-X, but it still applied even to PCI-X), trying to do software RAID across the PCI bus would kill performance once you reached more then 4-6 disks. Instead of being able to tell the controller "write these X bytes of data" and only sending X bytes across the PCI bus, with Software RAID, you're probably looking at at least 2x (RAID1) up to 4x (RAID5) the bandwidth usage to write data.

That's where I think that mantra came from. Plus the (misguided?) idea that if a 3Ware / Areca RAID array fails, you can buy support from companies to troubleshoot the issue easily. With Software RAID, it's a lot easier to shift the blame around (making it difficult to get support).

That being said, I prefer the flexibility of Software RAID over the hardware RAID cards and typically use the 12-port 3Ware cards as dumb SATA cards. Mostly as a way of getting enough SATA ports to talk to the 15 drives installed in the hot-swap trays.

Re:Software RAID

[drinkypoo]

The only advantage to buying a RAID controller is that you get a lot of connectors. Otherwise, if you have any even fairly decent CPU, and you're not doing anything but shoveling data and maybe some logging, the main processor beats the living shit out of almost any CPU on any RAID controller. There are limited exceptions but those cards are highly spendy. And keeping a lot of data off of the interface bus. Hardware RAID controllers are all about delegation. Get the data off the bus and onto the card as fast as possible, without sending it over the bus multiple times. Which is less of a concern in the days of boards with 30+ PCIe lanes. [...] Instead of being able to tell the controller "write these X bytes of data" and only sending X bytes across the PCI bus, with Software RAID, you're probably looking at at least 2x (RAID1) up to 4x (RAID5) the bandwidth usage to write data.

It's true that the more computation is involved, the more serious the bus bandwidth issue gets. This is an excellent reason to build software-based RAID systems with Hammer-core processors today; they have their own memory controllers onboard. Thus the RAID processing doesn't involve a bunch of bandwidth over the only bus interface on the chip.

Also, the more cache you have, the less times the processor is actually going to go to main memory, which reduces the bus bandwidth used in RAID computations. So the ideal situation (to do this on the cheap anyway) is to use the cheapest K7-n processor you can find that has a lot of cache, and get the best of all worlds. (Plus HT links are faster in the newest processors, yes?)

Re:Software RAID

[Suicyco]

This was a joke, right? You wish to store files with RAID, by including a single failable, poorly performing bottleneck? HW raid is for windows desktops and low end usage.

SW raid allows you to have a separate controller for each drive, or bank of drives, outperforms ALL HW raid setups and as such is far superior to HW raid. Performance? I design HPC systems for a living. Very large ones. I can design a RAID-5 setup with over 400mb/s sustained transfer rates, easily. HW raid is a joke for mission critical applications, vendor ignorance notwithstanding. Ebay? WTF? I take it you build raid's for your gaming boxen at home.

The entire point of RAID-5 is redundancy. Using a single controller card defeats the ENTIRE purpose. Until they release controller cards with multiple redundant power supplies, separate replaceable channels, multiple 3ghz cpu's, 4gb ram, etc. I stick to my highly performing, highly available file server. The boxes I design for redundant storage ARE HW raid. Albeit one that costs a lot of money. If money IS an issue, perhaps HW raid is worth it. If money is no object, forget it, its a poor solution to the problem at hand.

Now, if you need drives that perform, for lets say a tb of local scratch disk, raid-0 is the way to go and hardware raid simply cannot compete in any way shape or form with the performance numbers of sw raid0. When I am forced to deal with machines that have integrated raid controllers and I cannot disable their raid features, I simply make a bunch of 1 drive raid0's (yeah an oxymoron, but it's how the controller deals with it) and then SW raid them together in a stripe. Using multiple scsi channels (or multiple serial attached scsi cards, even better) with multiple drive banks I can get drive performance that would blow your mind.

Re:Software RAID

[WuphonsReach]

(Plus HT links are faster in the newest processors, yes?)

That is correct. Newer Athlon64 / Opteron systems have faster HT links. I don't remember whether this also involves changes to the silicon on the motherboard or not (to support the faster HT links). Since I never (well, almost never) upgrade chips on older motherboards, I haven't bothered to find out.

NSLU2 support?

[Gothmolly]

Call me when this runs on my 266MHz ARM box, aka the Linksys NSLU2. My current setup is Debian Etch installed to a flash drive, and 2 250GB disks in RAID-1 w/ LVM hung off the USB ports. Near silent, and sucks about 10W of power.

User encryption and key escrow

[DamnStupidElf]

When users leave, their keys and passphrases should be deactivated so they can't use them later to gain unauthorized access. This is nontrivial because it implies that every file they've ever had the key for need to be re-encrypted with a new random key, which is a lot of processing. Practically speaking, it's better to assume that anyone who has access to the data has actually copied every available bit of plaintext and key material and plan the threat model and security around that assumption. In light of that, it may actually make sense to encrypt on both the client and the server. The server is assumed to have a key that no user knows, and the users have keys that the server doesn't know. Only collusion between a server administrator and a user would be sufficient to retrieve all the encryption keys necessary to do bulk decryption of stolen media, and only for the keys the user knows.

Key escrow is for users who forget their passwords. It also prevents the loss of data due to the loss of individuals (through firing, quiting, or death). Secret sharing can be used to ensure that n or more administrators are required to recover a key, for some n>0

BSD: Driver Deficit

[thirty2bit]

I looked at a FreeBSD NAS project (don't remember the name though- I've slept since then. FreeNAS?) that looked really neat. Booted from USB key so only data was on the drives. I was impressed what with I ready until I hit the part in the docs where it didn't work with Silicon Image 311x SATA chipsets. The most common fudging chipsets out there. Linux has no problems with that chipset but the FreeBSD has major ones?

That totally harshed my buzz on the thought of the project and put FreeBSD on the "still not ready for prime time" list for me. I'm hoping they will someday get that compatibility working some year because the project looks very promising.

Re:What an Arrogant Bastard

[Hatta]

I will never claim to be perfect, but when a howto makes the _frontpage of slashdot_ I assume the person who wrote it knows what he is talking about.

You must be new here.

Speed issues...

[Icemaann]

Naturally with an encrypted disk your going to have slower throughput. I've been considering setting up some sort delayed encryption scheme where you have a 10-20GiB area of unencrypted space, when something gets written to this portion it will be encrypted at a later time. I'm thinking it may be possible with unionfs/aufs or maybe with a custom script or FUSE filesystem.

Anyway, if your situation will permit data not be encrypted immediately, this would be a good compromise between speed and security....

No SMB

[tacokill]

Kind of deal killer.

Re:No SMB

[Chris Pimlott]

Ahem:

FreeNAS is a free NAS (Network-Attached Storage) server, supporting: CIFS (samba), FTP, NFS, AFP, RSYNC, iSCSI protocols, S.M.A.R.T., local user authentication, Software RAID (0,1,5) with a Full WEB configuration interface. FreeNAS takes less than 32MB once installed on Compact Flash, hard drive or USB key.

Re:No SMB

[tacokill]

Ahhh...I missed it. Thanks for the heads up.

No, no, no, no.

[jotaeleemeese]

You are using subjective judgments there. You have no way to know if the guy with the keys for the "safe" datacentre may be bribed to pull your disk and make a runner.

Encrypting cost you little and contributes to your peace of mind, it does not solve all problems, but at least addresses the one where a thief with light feet is involved....