NAS Adventures, take two
Feb. 7th, 2014 08:02 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
torkellI've given up on the previous NAS - trying to put together a toolchain is proving to be too much hassle, and while I could blow away the custom firmware and put a stock Debian install on it the internets suggest that the Debian kernel doesn't support DMA at which point your performance drops through the floor. Plus it has a dead hard disk and a noisy fan.
So over Christmas I picked up my dad's other old NAS, a Netgear ReadyNAS Duo v1. Like the Thecus it's also Debian-based, but Netgear are running a real full-fat Debian install. And they provide an official addon to enable root SSH access at which point I can log in, download Debian's already-built toolchain, and use that. Simples!
Plus it also has two working hard disks and a much quieter fan :)
Anyway, now that I have a NAS that is actually usable I've been playing around with running PHP on it. I did try PHP on the Thecus, but it came with some prehistoric version of it (Craig's comment upon seeing the phpinfo output was "where did the other half go?") and the only database it supported was sqlite. Netgear on the other hand ship PHP 5.2 which is almost up-to-date, along with MySQL 5. They even publish a set of instructions at which point the whole exercise is again incredibly easy.
Until I tried installing Craig's Home Portal package, which relies on mod_rewrite at which point everything fell over. See, it was going to go wrong somewhere!
It took a lot of poking around and bashing of config files, but I eventually worked out the problem. See, if you create a HTTP share through the admin webpages it sticks an Options Indexes in the location definition. This disables all server options except for Indexes, at which point mod_rewrite sulks. See, mod_rewrite requires that either FollowSymLinks or SymLinksIfOwnerMatch is enabled, otherwise "you cannot use the rewrite engine... for security reasons". Except the way it handles this is to reject all requests with a 403 Forbidden error.
Fixing this merely requires enabling the missing options, though this is a bit tricky because you can't just put set them in a .htaccess file. Unfortunately the other logical solution of modifying the existing config doesn't work because the admin webpages will blow your customisation away without warning. The solution is to not enable HTTP access to the share through the admin pages, but instead to create a new config file in /etc/frontview/apache/addons/. Put something like the following in it:
Next challenge: trying to wring more performance out of PHP! It's a bit sluggish, probably because it only has a 400MHz Sparc processor.
So over Christmas I picked up my dad's other old NAS, a Netgear ReadyNAS Duo v1. Like the Thecus it's also Debian-based, but Netgear are running a real full-fat Debian install. And they provide an official addon to enable root SSH access at which point I can log in, download Debian's already-built toolchain, and use that. Simples!
Plus it also has two working hard disks and a much quieter fan :)
Anyway, now that I have a NAS that is actually usable I've been playing around with running PHP on it. I did try PHP on the Thecus, but it came with some prehistoric version of it (Craig's comment upon seeing the phpinfo output was "where did the other half go?") and the only database it supported was sqlite. Netgear on the other hand ship PHP 5.2 which is almost up-to-date, along with MySQL 5. They even publish a set of instructions at which point the whole exercise is again incredibly easy.
Until I tried installing Craig's Home Portal package, which relies on mod_rewrite at which point everything fell over. See, it was going to go wrong somewhere!
It took a lot of poking around and bashing of config files, but I eventually worked out the problem. See, if you create a HTTP share through the admin webpages it sticks an Options Indexes in the location definition. This disables all server options except for Indexes, at which point mod_rewrite sulks. See, mod_rewrite requires that either FollowSymLinks or SymLinksIfOwnerMatch is enabled, otherwise "you cannot use the rewrite engine... for security reasons". Except the way it handles this is to reject all requests with a 403 Forbidden error.
Fixing this merely requires enabling the missing options, though this is a bit tricky because you can't just put set them in a .htaccess file. Unfortunately the other logical solution of modifying the existing config doesn't work because the admin webpages will blow your customisation away without warning. The solution is to not enable HTTP access to the share through the admin pages, but instead to create a new config file in /etc/frontview/apache/addons/. Put something like the following in it:
Alias /mywebsite /c/mywebsite <Location "/mywebsite"> Options Indexes FollowSymLinks SymLinksIfOwnerMatch Order allow,deny Allow from all </Location>Then restart the webserver with /etc/init.d/frontview restart and it should all work (it does for me!).
Next challenge: trying to wring more performance out of PHP! It's a bit sluggish, probably because it only has a 400MHz Sparc processor.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-02-12 01:24 pm (UTC)Probably vastly different hardware anyway. I've spent far too much time on piddly little things like getting a userspace interface to the gpio module (that's not in upstream, so I have to port some code a guy wrote a couple of years ago to a modern kernel) to light the disk LEDs on the front panel. Well, it's IMPORTANT to know which disk to pull in a failure!
Thecus make really shitty firmware spaghetti^Wscripts.
no subject
Date: 2014-02-12 01:27 pm (UTC)no subject
Date: 2014-02-12 10:05 pm (UTC)