Openfiler issues
Monday, December 01st, 2008 | Author: Ozzik

So I decided to dedicate this first post to some stuff that’s been going on for the past week at work.
We decided to exchange all of our old “Lacie” and “Infrant” NAS units for one normal storage. Finally!
So we bought a white box server, and I set it up with Openfiler OS. Basically, I’m a FreeNAS fan, but the 64bit version is still in alpha stage, so I went for Openfiler, which already is 64bit. (It has to support the 16GB of RAM). Anyway, I don’t remember too many complications at the installation stage, except for the “msdos” and “gpt” issue: had to change the partition label to “gpt” for partitions of more than 2TB(done via parted).
Also, I’ll try to remember posting a “join openfiler to Active Directory domain” guide, as it’s really not that trivial. I’m lucky someone already did that part and published it on the forum.
But what I did have a hell week with was another issue. 2 actually.
First, for some project I was asked to open a share via http/WebDAV protocol, which was supposed to be a two clicks thingy, but turned out to be a 2 days hell.

I guess there’s some sort of a bug in the OS because while our samba shares worked very well, the HTTP share kept asking for a password. It didn’t matter what you enter - it was not satisfied.
I’m not gonna bore you with all the details of this mess, I’m just gonna tell you the final solution, if you ever in this situation.
For some reason, the way Openfiler imports users from the AD is putting them all in one group “domain users”. And while it works fine with regular samba shares (we had no problem assigning permissions by groups from AD), the HTTP/WebDAV (and FTP!) wouldn’t take it. So here we go:

Edit the file /etc/httpd/conf.d/openfiler-shares.conf
find the needed share and under the require group line put

require user \"username\"

also add the “domain users” group to the require group line.
Change the

AllowOverride None

to

AllowOverride AuthConfig

Next, create an .htaccess file in the root dir of that specific share and add these:

AuthType Basic
AuthBasicAuthoritative off
AuthUserFile    /dev/null
AuthName \"Sharename\"
AuthPAM_Enabled on
AuthPAM_FallThrough on
 #Limit GET HEAD PROPFIND OPTIONS REPORT>
                require group \"some groups with limited access\"
#/Limit> (replace the \"#\" with \"<\" in these 2 lines - it wouldn't show otherwise)
	
require group \"some groups with R/W access\" \"domain users\"
require user \"new user created especially for this\"

edit to fit your username and group, plus sharename.
The access limitations were copied from the automatically generated “openfiler-shares.conf”.
After that the only problem left was the autogeneration of the file and it was solved by editing
/opt/openfiler/var/www/includes/generate.inc:
just changed

AllowOverride None

to

AllowOverride AuthConfig

in 2 places (search for these places).

The main problem with it is that .htaccess is controlling the permissions now, but if you ever have to change these, you can always copy them from the openfiler-shares.conf to the .htaccess. It’s a 2 min job. Just have to remember it:) Of course, this will only be valid for those shares opened for HTTP or FTP. Other shares don’t need .htaccess and thus will still be controlled as before.

Ok, that was the first issue.
The second one is still fresh, as it happened today.
Suddenly, half the shares disappeared and the dmesg gave me something about the XFS errors.
To be fair, it’s not the first time we had those errors, and we were advised by the openfiler devs to upgrade to the newest kernel version, but since we had some problems with backup, we decided to wait. Today, the kernel decided that he had had it with us and made a couple of shares invisible to a human eye and access.
The solution:
unmount the problematic mounts. Then:

xfs_repair devicename

if it gives you a zero log error:

xfs_repair -L devicename

and you should be fine.
The -L means it deletes the log, so you might loose some data, that was in progress of writing when the crash occurred (that’s how I understood it from very little info I managed to get from googling, so you better double check it).
Next, I decided to go for the kernel update after all:

conary update kernel

but discovered that the network was down after that.
Luckily, the update places the new kernel beside the old one, so you can still log in to the old one and continue working.
After searching through the forum, I discovered it was an Intel e1000 driver issue, so tomorrow I’m gonna change the driver to e1000e and will update on the progress.
Also, somehow, after the upgrade, while I used the old kernel, I could only get 100Mb instead of previous 1Gb. Not sure if tomorrow’s operation will resolve this issue as well.

Anyway, that’s it for today.
C ya.

Ozzik.

VN:F [1.9.6_1107]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.6_1107]
Rating: 0 (from 0 votes)
Category: Admin's scene  | Tags: ,