Perl Programmer/Consultant
Remote System Administrator
Free Software
... contact me
 
  while ($making_other_plans) { life(); }
  location('ipsstb', 'system_admin', 'web_hosting_provider_support');

 For Web Designers 2021-05-19 15:56:48 UTC Mail Delivery Problems? 

Monday, January 28 2013

Web Hosting Provider Support

It has been an interesting few days here in The Office Where Really Cool Things Happen. I wrote a stripped down, bare bones, just shy of a shopping cart application for a client who doesn't actually sell online. No payment card processing, no quantities, no options, just an opportunity to request samples and/or quotes for products. It was great fun writing it. More fun than it should have been, probably, but every now and then it's nice to take on a simple little job and do really well at it because it's so simple and so small.

Then the interesting but not in a good way part came: Making it run on the client's virtual server at a strange place that shall not be named. This hosting provider has the usual cPanel thing, and advertises that SSH access is available and root access can be provided on request. I really shouldn't need either, though I do prefer SSH so I can use scp rather than FTP or some silly web based uploader. scp is more secure, more convenient, and faster for a command-line guy like me. Eh, if I can get it I'll appreciate it, if not I'll be quite content to appreciate that I've got a happy client. But if it were that darn easy I'd not have a story to tell.

I went into the fray via cPanel, installed a bunch of perl modules, uploaded the custom code and templates and configuration files for the not-a-cart, edited the customary .htaccess file found in the customary location so that we could have slick REST URI's like /cart/add rather than cart.cgi?add=this;qty=42;color=red;question=why_me. No joy. The rewrite rule isn't working so the cool URL 404's, and when I visit the application directly I am greeted by my arch nemesis Server Error 500. No worries, these things are par for the course and with a quick perusal of the web server error logs I'll have it fixed in under a minute.

Nothing doing. The provider has configured things so that the error logs do not contain anything except 404 (not found). So I twiddle the code to show me fatal application errors in my browser, a thing I've done countless times before. Still nothing doing. Boy, aren't they crafty about keeping those errors hidden! But I'm craftier, and in a few minutes I've got the error message, and in 30 seconds or so I've got that problem solved.

But the rewrite rule? The .htaccess file isn't being parsed, so Apache is not configured to allow overrides. I'm not root so I can't get at the cool bits that configure this. The provider won't talk to me because I don't know passwords I've no need of or business having, and don't know the last four digits of the credit card associated with the account. My client, though, checked his most recent statement and found that the last four digits I gave them belong to a card that's associated enough that it drains his pocket into theirs every month. I was given a couple of passwords that were believed to be correct, but apparently were not. Several phone calls and email messages later, I'm still just scratching my head wondering why things have to be so darn difficult.

If I could get that root access that's advertised as being available, I'd have the problem solved in a couple of minutes, and if the Apache module that's required is already loaded I'll be able to spend one minute 45 second of that time playing with the cat. If they're like most of their competition they've got every Apache DSO module loaded up already anyway, so the cat would be in luck.

My client is thrilled with his new software, having visited it at the direct URL to see it in action. He's not so thrilled with the virtual server provider, and I can't say I blame him. This thing should have been done three days ago, but apparently "We truly provide great support" doesn't mean what I think it means. And it's really interesting to do a web search for the phrase, in quotes, "We truly provide great support. We really monitor the performance of our servers." which is found on this particular outfit's home page. I don't know what it means that so many web site are serving the same basic content with different pieces of flair, but I can guess.

And I guess it's just been driven home to me why I prefer and support owned, co-located servers and self-administered dedicated servers. It doesn't take me more than three days to get one to three lines added to an Apache configuration file. At my very slowest it's a next business day thing. I cost more than in-house 24/7 world class industry leading and in all other ways buzzword compliant support, but I cause much less frustration.

I hadn't intended to make this a marketing piece, especially such a lousy, long winded one, but what the heck. If you need a remote system administrator for your Unix/BSD/Linux machine, even for just a one-time quick fix, I'll be glad to do my very best to avoid frustrating the heck out of you. Feel free to get in touch.

Be well and stay safe out there, fellow space travelers.

UPDATE 2013/01/29: Resolution Is At Hand!

It appears that the stunning incompetence of the virtual server provider will end this story with a move to another host. The decision was based on the projection that it would be faster to move everything than to convince the current outfit to simply add one or two lines of text to an Apache virtual host configuration file.

This doesn't look at all like the 21st century we were promised when LBJ was in the White House! At least we got the tiny portable phones. :-)

UPDATE 2013/01/30: Well, Almost...

Today's news is that the new provider has thrown up a different set of hurdles.

  1. The account's cPanel doesn't include a Perl module installer.
  2. The account didn't come with SSH access at all but they did reconfigure for it, so in theory I can login and install the needed modules from the command line. I prefer that anyway.
  3. BUT there was a firewall in the way, and they had to reconfigure that.
  4. THEN SSH public key authentication failed.
  5. THEN their support folks told me that it was because I didn't have the corresponding private key on my workstation. I do, though, and it's the sixth or seventh in a series of workstations the same darn key has been on.
  6. SO... I went in via cPanel and fixed that problem. Newer versions of SSH servers don't look for the file authorized_keys2 any more because support for it was deprecated in the year 2001. I copied it to authorized_keys and logged in just fine. Once there I blew away the misnamed file then hard linked the name to the authorized_keys file just to keep that problem from biting in the future.
  7. NOW my module installation fails because the user I can login as doesn't have permission to use the gcc compiler.
  8. AND it apparently requires someone more deific than the front line support personnel to decide whether or not I can be trusted with a compiler.

I can work around that silliness easily enough, but first I have to create a 32 bit environment with appropriate versions of things. I'd rather not have to go to so much bother, but as they say in the movies, "a man's got to do what a man's got to do".

→ committed: 1/28/2013 20:28:12

[ / system_admin] permanent link

Comments: 0    Trackbacks: 0

 

Comments are closed for this story.

 

Trackbacks are closed for this story.

Save the Net

Creative Commons License

Project Honeypot Member

 
January 2013
Mon Tue Wed Thu Fri Sat Sun
 
28      

By Month:

By category:

Feeds:

Served to 44.192.253.106:48094 at 15:56:48 GMT on Saturday, June 19, 2021.

return(0.5097);