JT's Blog

So I decided it was finally time to set up a little ESX cluster with OpenFiler. Everything was going smoothly until it came time to configure OpenFiler… being that I’m not a storage guy. Then the OpenFiler people seem to want to make money off selling the admin guide. *sigh*. Fortunately, there is a *great* little howto here. Thank you Lee Wynne.

Then I got the first ESX host connected no problem, but the second wasn’t connecting despite every bit of troubleshooting I tried. Fortunately, it seems that other people have not only done this before me, but they’re smarter than me. Crumpuppet figured it out here. (scoll down into the thread.) Basically, it looks like a bug – either with ESX or with OpenFiler.  The fix is in the /etc/initiators-allow and /etc/initiators-deny files, a TCPwrappers sorta way of controlling access by iSCSI initiators. It basically only lets the first one in and rejects everything else. Nice. I wasted 2 hours of my life on this one. The fix, in a nutshell:

I was scratching through the openfiler settings on the console, and found two files – initiators.allow, and initiators.deny. I did a couple of tests on OF in adding initiators to the local network. When adding one, it added an entry for it in the “allow” file, as you would expect.

But – the deny file had one single entry that looks like this:

iqn.2006-01.com.openfiler:tsn.6ef258ca57df ALL

I figured, the allow one gets processed after this one, so my “allowed” initiators will be given access anyway. This was not the case. Every time I made a change to the list of initiators on the OF web interface, this line was added to initiators.deny. I put a comment in front of it and restarted the iscsi-target service. I finally managed to discover my iSCSI target on my esx hosts.

So remember to check these files! If you also have the “ALL” line in initiators.deny, just put a # in front of it, and run:

service iscsi-target restart

This will probably have to be done every time you add a host. I’m not prepared to write-protect the initiators.deny file for in case OF cries about it, but can anyone think of a fix for this?

I recommend you read the entire thread and consider the security implications of this hack. For now at least, I’m up and running.

While monkeying around with my little test lab, I swapped one NFS server out and put a new one in. I expected mounts to be flaky and need to be reconnected. However, when I got on the Linux machines that had the swapped filesystems mounted, I got all kinds of errors like “cannot stat” etc.

The key to fixing this is first and foremost to cd /. and get out of that folder. Then run lsof. You might want to try lsof |grep foldername of the mount point. Then you can kill -HUP the process ID and voila! Done!

I struggled with this issue for the millionth time and figured I’d document it myself rather than having to troll the internet to find the answer (which I found here).

I don’t like Bloomberg’s corporate policies. Did you know that if you work at Bloomberg’s company, if you resign or quit, let’s say to go earn more money, you can never come back? The philosophy is that “you were employed as an asset to the company and if you leave, you’re hurting the company. How could we hire back someone who would hurt the company?” But the corporate environment there is no better than most corporate environments.

Despite bringing a reasonable business acumen to the Mayor’s office and not being in the pocket of big business, I don’t like Mike’s mayoral policies either. I’m going to speak about the ones that have impacted me.

First of all, how is it acceptable for a politician to do a power-grab in plain sight and nobody be COMPLETELY up in arms? I mean, this guy has changed one of the most fundamental laws in our country, and through financial might (nobody can oppose his advertisement coffers) and political power (due to the fact that nobody will be able to oppose him, nobody else will stand in his way and risk political suicide) he has managed to steal power from the voters.

Continue reading…