Posts Tagged ‘website’
* testing Crosspress (plugin)…
Posted on April 16th, 2009 by doug. Filed under website.
One of the issues with social sites, networking and the co-mingling of work and life – I can have several different “sites”, but I will never have the time to work with all of them. I will update this blog. I won’t necessarily ever get around to its copy on blogger.
IF I can update here, in one place, and as much as possible have that flow through any other sites, at least to keep them showing current links, I haven’t left them dead on the vine, and I haven’t turned my life over to them either.
This post is testing:
- CrossPress
- LiveJournal Crossposter Remix
- TwitterTools
- LinkedIn – which actually runs a feed slurp from LinkedIn’s end…
- WordBook – Facebook plug in.
Ready, computer?

* …and the https redirect is still in place.
Posted on September 3rd, 2008 by doug. Filed under website.
I checked just for grins. If you are running Linux or some variant of UNIX, /etc/hosts is your (testing) friend.
I placed an entry for the hostgator IP address pointing to my primary domain. A UNIX host will check files first, DNS second [1]. If I point the browser to https://primarydomain.com, I get:
an information.com redirect from hostgator
The redirect is still there.
I ran my sites on https for quite awhile. Many of the search results I have in google point to that https:// URL. Think about that.
If https:// redirects properly to http://, there is no issue at all. If the https:// times out, many users will figure it out, again, not much of an issue. At the very least they’ll think maybe the site is down, and quite possibly try again.
Eventually the search results will reflect the current addressing.
If those users get to a site that appears as if it is supposed to be at that address — the result page for that hostgator redirect looks very similar to many of the pages parked on domain names no longer in use — that pretty much drops that user out completely. He got to the site, he got an apparently valid response. It no longer exists anymore, for him. That’s destructive, damaging.
And the thing is, it’s MY domain name. Not theirs. I thought it up, I registered it. It directs to my creativity, my writing. Not in any way, shape or form is this redirection an acceptable behavior. It is an action allied with the dark side, done because they can, not because it is right.
— dsm
[1] Note
You can change the order in which a host resolves network addressing, and many other pieces of network data in /etc/nsswitch.conf.
By default most distributions have the entry “hosts: files dns”. Some include “nis”. This file can change the default behavior.
* back in the family, but just for a second…
Posted on September 3rd, 2008 by doug. Filed under website.
from hostgator…
On Wed, Sep 3, 2008 at 1:59 AM,
wrote: Hello Douglas,
Your account appears to be a recent addition to the HostGator family. If there was a problem with the service you were receiving, I’d like to see if I could help you.
We would like the opportunity to resolve any problems you may be having with our service. There maybe something that I or one of our administrators can do to resolve your issue.
I look forward to your reply.
So I’m back in the family. ;^) But not for long.
I replied…
You had numerous opportunities to resolve this.
None were availed of.
This was the final straw:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
support@hostgator.com
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 Connection denied after dictionary attack (state 14).
and this didn’t help:
“Doug,
I do see what you are trying to do, and the only way this will work properly now that i see that you have a shared account is that you upgrade to a reseller. Let me try and explain why.
On a shared account, you can only have the primary domain with an SSL. What you would need to do is get a reseller account, and then setup you non SSL subdomains as accounts of their own.
If you have any questions we’ll be glad to answer them.
Thank you,k”
That plus redirecting https://primarydomain.com to a bogus search page after uninstalling private SSL, pretty much put you guys on the side of evil.
Please cancel my account and refund my money. I spent much of the weekend trying to sort this out.
–doug
Several hours later…
I understand your frustration however I am showing that your domain name servers (DNS) are not pointed to HostGator and in face after conducting further research I see an administrator had picked up on this as well and notified you that you must allow the propagation period for a domain name when you change the DNS. Propagation period is any where in between 48, no more than 72.
I am showing the DNS is not pointed to HostGator any longer there fore we are unable to show if there is still an issue with your account however the DNS seems to be the last and final resolution since all other issues (such as clarifying the URL’s) were resolved.
I look forward to your reply and how you would like to proceed.
Regards,
Yeah – actually the DNS is completely correct – it points to that other hosting company…
Last reply – after this I’m just going to send the same polite request for a refund.
That was the resolution of the issue. A different hosting company. It is absolutely pointed correctly.
The DNS had been pointed correctly and propagated completely. The issue has never been technical – this is administrative design that forces a higher cost than is acceptable in the market. Two individual accounts with the features I want would run $20.00 per month at hostgator. The only expansion is into a higher level “plan” at 24.95/month. And the behavior and hard sell is outrageous.
You were as of yesterday still redirecting https:// traffic from my domain to some advertising search site, from which you probably derive revenue. I consider that wholly inappropriate – https should either redirect (your apache servers are quite capable of that) to http or time out without a connection.
Please complete cancelling my account and refunding the money.
–doug
By the way, almost none of these communications are consistently the same person – so far I’ve run through at least three different tech people and four to six sales guys, depending on whether or not you count the “Live Chat” last evening or so.
— dsm
* resolution from hostgator… sort of
Posted on September 3rd, 2008 by doug. Filed under website.
I’ll never get a response – the email to hostgator support was blocked. Somehow, that’s just perfect.
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
support@hostgator.com
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 Connection denied after dictionary attack (state 14).
Well. That’s one solution.
hostgator has a live chat. I opened one at 11:30 PM to the sales section. They responded.
I indicated that the blocked email was an issue, outlined the rest of the issues, and asked that my account be canceled…
How likely am I to recommend hostgator? One of the questions on the webform I was directed to submit to cancel asked that… Not bloody likely. But there isn’t an option to select quite that…
— dsm
* up-sell: if you pay us more, we can fix that…
Posted on September 3rd, 2008 by doug. Filed under website.
I moved my websites off my home servers several weeks ago. I have Verizon FIOS and for some reason they finally got around to adding port 443 to their blocked ports, outgoing. They had always blocked port 80.
I chose hostgator.com to host the sites. I did some research, most of the reviews of the company were laudable. One reviewer indicated that after three months hostgator had insisted he needed to move to a dedicated server because of the “load he was generating”. He complained in the review that that was not the case, that hostgator was upselling. I didn’t understand the term…
I think I do now. But I’m still shocked at how fast the service went downhill. Three days ago I was still reasonably ok with hosting with hostgator. Now, late Tuesday evening, DNS for my domains points to a new hosting facility’s nameservers. And I’m writing this.
I did two things correctly. I kept current backups of everything hosted. And I did not transfer any domains to the hosting facility. My domain registrar is in Europe – I’ve been using them for almost 8 years, they’ve been outstanding to work with.
If your domain is registered outside of your hosting facility, redirecting traffic is just change the DNS nameserver delegation. You don’t even have to tell the old hosting company there is a change until after the DNS has propagated.
Here’s the thing – hostgator monitors the whois record. At one point in this whole saga I determined I might have part of a solution if I re-pointed DNS to everydns.net, and then used a web redirect to fix hostgator’s bogus https redirect – it didn’t work, but almost immediately this became a subject in the support tickets I had opened with hostgator. It would make sense – issues would definitely stem from nameserver re-pointing. But it also is a damn good warning of which customers are leaving the fold.
I purchased one year’s hosting at $9.95 per month. I added $2/month for a dedicated IP address, a requirement for private SSL. I checked the shared SSL – it only served directories from within ~/public_html. I wanted the websites isolated from each other, outside of each other’s document root, so that didn’t seem to be the right solution. Initially (this is important) addressing any query to a domain at https resulted in a timeout and that SSL connection being unavailable. Proper behavior – I wasn’t yet set up for that, so it should not be present.
Once nameservers had propagated and I could access the site, I asked that they enable private SSL using my existing SSL cert. They would – at a $10 charge to install the cert. OK, so be it. I authorized that. (Cha-ching…). They enabled the SSL. It worked… Sort of.
What it did was allow private SSL access to the primary domain. And no SSL access anywhere else on the hosted site – subdomains, add-on domains, nothing was accessible by either the private SSL or the shared SSL. Any SSL query would redirect to the primary domain home page at https:. I figured OK, they put in a blanket redirect, I’ll open a ticket in a bit and work that out.
Three days ago I opened the ticket. And over the Labor Day weekend, I pursued a solution. Sigh.
I described the situation. I had SSL access to the primary domain, but could no longer access subdomains or add-on domains via SSL – all I wanted was for the primary domain to be full securable, and to be able to access the WordPress administrative functions for two add-on domains via SSL, and to access password-protected subdomains with SSL. Neither of these is public, shared SSL would have been acceptable.
I was initially told that this could be done by moving the subdomain out from the dedicated IP address and back to the shared IP.
Good morning,
This issue is being caused because the certificate is setup to use primarydomain.com so when you access port 443(https) via that IP you are sent to that website. What you will need to do is have the other domain https://dougmunsinger.com taken off of the dedicated IP and then you can use the shared SSL. Would you like us to do this?
Thanks,
I asked if that would solve the subdomain access as well…
Would that also solve access to subdomains within primarydomain.com? Or would those subdomains need to go off the primary domain and onto dougmunsinger.com as the domain (which is possible, I think, but not a perfect solution)
– doug
And I got a reasonable response. I don’t think sales was on the line yet at this point.
Hi Doug,
All the domains you wish to use the shared ssl will need to be moved off of that dedicated ip. Let us know how you would like to proceed.
Thanks!
I was then told I couldn’t do that – hell, let me quote the reply:
Good afternoon,
This cannot be done as it would conflict with the VHost, as the shared IP is different than your dedicated IP and your IP is hard set in the zone file.
Thanks,
Interesting response. True, too. But it is a limitation of their setup and procedure, not impossible. They do a funky
add-on-domain.primarydomain.com
redirected in apache to
add-on-domain.com
or maybe that’s reversed. At hostgator you have to guess what the DNS records actually in place are. And you can’t see server-level redirects or address re-writes at all…
– so once the dedicated IP is assigned you are screwed. However – that’s process. Not a true limitation.
By this time the system had opened two tickets – not sure how. Both on the same issue, and until the very end of the thread they couldn’t seem to combine them… Eventually I got:
“Hi Doug,
The issue here is that you only have one account as a shared client. In order for these domains to be moved off of the dedicated IP they will have to have their own account. Were you thinking about moving up to a reseller package? You could then create separate accounts for each of these. Please let us know if you have any questions or if I a not understanding what you want to do correctly.”
So actually, I could have the solution if I paid more money. After several clarifying emails, where I insisted that a reseller account was out of the question, and that this functionality was simple and should just be fixed to work, back and forth, we have this response:
“Doug,
I do see what you are trying to do, and the only way this will work properly now that i see that you have a shared account is that you upgrade to a reseller. Let me try and explain why.
On a shared account, you can only have the primary domain with an SSL. What you would need to do is get a reseller account, and then setup you non SSL subdomains as accounts of their own.
If you have any questions we’ll be glad to answer them.
Thank you,k”
So – I’m paying more at this point, for a dedicated IP address and private SSL to the primary domain – for less functionality?
I asked that they revert the dedicated IP back to a shared IP and re-enable shared SSL. They did, as of Sunday evening late.
They also redirected https traffic obnoxiously. As soon as this was reverted, instead of https:// URL’s either redirected to http:// (appropriate) or simply unreachable (appropriate) – they were redirected to some search site.
As soon as I refused the upsell to a reseller account (Cha-ching – that literally is double – $25/month ($24.95, but who’s actually counting 5 cents at this point?)), responsiveness dropped to pretty much zero. Instead of a one hour response, which had been usual, I got overnight. Maybe. And the responses stopped actually addressing the issues.
I complained bitterly about this redirect on Monday, and got no response. I did get:
Hello,
It appears that the domain has just had its nameservers changed. The WHOIS information shows that it was changed today and was pointing previously to dns.gandi.net. It is now pointed to
NS1065.HOSTGATOR.COM
NS1066.HOSTGATOR.COMIt normally takes 48 – 72 hour for the nameservers to completely propagate, allowing you to view your site using the domain name around the world. You might not be able to use the domain name to view your site until after that time.
If there is anything else we can help you with do not hesitate to ask.
Thank you,
Hmmm. I wasn’t aware that whois actually gave a history of nameservers. Actually, checking the command, it does not. That suggests they monitor the command at hostgator for changes. And since he had the history, they save the data for at least their tech support guys, if not their salespeople. At the point in time I changed the DNS nameservers, it was with an eye to finding a workaround for the hostgator https redirect, while trying to get tech support to address it.
A reasonably courteous response, actually. But it completely avoided addressing the https redirect (that redirect really pissed me off – can you tell?). Which has nothing at all to do with nameservice at this point – I verified this behavior on remote access servers where the DNS change (brief – like 20 minutes) was never even seen. I just now edited /etc/hosts and re-pointed to the hostgator address for the server instead of the current one and as soon as I do, https brings back the same page. Just intentionally coercive.
Because Verizon used to allow port 443 (SSL) a lot of the search results for the sites I administer are https. A bogus redirect was unquestionably not acceptable. I sent sales queries to bluehost.com and to dreamhost.com, both are listed by WordPress as acceptable hosting companies.
I made up a list of questions which outlined exact requirements, hopefully to avoid this same situation. Both companies gave good answers. This was starting Sunday evening through Labor day, Monday. I chose dreamhost.com, moved the site, re-pointed the nameservers. In a day or so (well within the 45 day trial period at hostgator) I’ll ask hostgator for my account to be closed and the money refunded, after I delete everything off of the server. Once that’s done I’ll click “publish” on this article.
un-Cha-ching.
You know, just out of curiosity (and since I’m already off the hosting anyway), I’m going to submit another ticket to see how much it takes to remove the redirect… It may not be a true test, but let’s see how flexible they are in the face of adversity. Here’s the email to open the ticket:
I recently asked that private SSL be dismantled for this account. It was. Once it was dismantled a redirect went into effect for https://myprimarydomain.com to http://searchportal.information.com/index.mas?epl=00680014UV_a_verylongstring.
Please remove this redirect. Acceptable behavior for this kind of thing is for https:// urls to redirect back to http:// OR for https:// to time out since the connection is not available.
To redirect to a bogus URL for https is unacceptable. I have re-pointed the domain away from hostgator to resolve this issue to a host I use for other domains. I can re-point back on my local DNS for testing purposes – please let me know when you have removed this behavior.
Thank you,
— doug
My guess is the response won’t be satisfactory, but should be interesting to see what happens.
…12:19 AM 20080903, no response at all.
On the other hand – the host dreamhost placed me on had root filesystem space issues tonight – they responded, and I could watch through the (full) bash shell on the server as they fixed it, up until
Broadcast message from root@server (pts/8) (Tue Sep 2 19:22:38 2008):
The system is going down for reboot NOW!
Connection to server closed by remote host.
The website was also down after they assigned a dedicated IP address – this was resolved within 5 minutes of reporting it. Just an apache misconfig.
This kind of sysadmin stuff I can tolerate, within reason.
At this point I have two dedicated IP addresses and SSL enabled successfully on both of my primary sites. I’m paying slightly more than for the single account at hostgator, but certainly less than two or more shared accounts on hostgator would have cost.
— dsm
* moved, left forwarding address…
Posted on August 20th, 2008 by doug. Filed under website.
…sort of.
My ISP fixed the DNS flaw. In doing so, they managed to stop caching ANY DNS results and slowed every action from within my local network to a crawl. This lasted for about nine days. Aaaarggggg.
Tech support or any kind of customer service from Verizon is a nightmare. So are they all, it seems. Somewhere along the line, service became an option, rather than a requirement. I was almost at my point-of-no-return – where the pain of waiting on hold and then escalating up until I find someone who understands that this is their issue, not mine, and that they need to fix the DNS caching was unavoidable.
Fortunately I went out of town for a week.
On my return the DNS had been fixed, and the speed was much better. And Verizon finally realized if they want to prevent web servers from running out of home networks they need to block port 443 as well as port 80. I’m pretty sure this was as a result of investigating the slowness in their own network – one of the things I would have done was to look at traffic. In taking a closer look at what was flowing over their lines, they plugged the port.
That means… Actually that just made an immediate necessity of what I had determined to do anyway. I needed to get this site into a data center. I already knew that. In a real network it can run on port 80, there are UPSes and backup power, 24×7 monitoring. Much bigger pipes.
Thanks for finding the site again, on port 80 this time. It no longer needs SSL, really, except for admin tasks. In moving it I put in relative links instead of full URLs, so it becomes a bit more portable, and easier to maintain.
— dsm
* two bugs…
Posted on August 2nd, 2008 by doug. Filed under website.
I fixed two bugs in this site design…
The first was a failed comments function. The “Submit Comment” button failed to submit any actual comments. I hadn’t tested it. I was looking through google’s picture of the website, and found google complaining that /comments/feed (the rss url for comments) didn’t exist… OK, I can fix that. I’ll just submit an initial comment…
It would not submit, and further looking didn’t show any reason. I took a look at the comment code in a different theme for wordpress that did have the comment code functioning correctly, and by slowly changing one bit at a time, I got the code in this one to work
The second was minor – the “engineer” image was a relative link on the front page, and failed to translate (IT SHOULD!) to the comments page (WTF?). I changed that to a full URL and it should work now anywhere in the site.
—dsm
Store and Forward Messages wrote about the irony of writing about SSL certificates in websphere MQ, and also running a site only under https (which this one is) without a proper certificate… He’s correct, that’s bug #3.
With the DNS exploits running particularly rampant, it’s no longer workable to leave a mismatched cert. Firefox 3.x also makes certificate errors much more glaring and intimidating. I ordered and placed a correct signed certificate.
The site now runs on port 8443 on a separate server with the corrected cert. I’m still investigating being able to port shift from the original (virtual) server at port 443 to the new one on 8443 without having to have the 443 cert validated… ProxyPass in Apache works directly to dougmunsinger.com. The old URLs will work the same and still throw the same certificate error. Directly to 8443 after that, and no further mismatches…
I can live with running this on a separate server, but the apache2 config for virtual servers SUGGESTS that each named server can use a separate SSL cert and it doesn’t work that way. All the virtuals use the first certificate encountered in the config.
* the engineer
Posted on July 27th, 2008 by doug. Filed under website.
I was searching for an image to put at the top of the page on this weblog – I searched for engineer. I figured I would find a triangle and a compass, something engineer-like – perhaps a slide rule… And I found… this.
The engineer as superhero? Outstanding.
I found this comic book at daraja.com
The Engineer – “Konstrukt” – Issue #1
The Engineer – “Konstrukt” – Issue #2
The Konstrukt sounds like a descendant of the “Continuum Transfunctioner” (a powerful and mysterious device – its mystery is only exceeded by its power)
recent posts
- home to Boston, daughter in remission
- visually healthy bone marrow…
- matter of the lungs
- Fall through code to a success…
- another tool for SVN – list_repositories.pl
- svnadmin.pl – perl cgi script to manage svn over apache
- testing Crosspress (plugin)…
- subversion compile and install as non-privileged user…
What I'm Doing...
- flying back to Boston tomorrow, and watching my daughter come off a ventilator and breathe on her own... 2 weeks ago
- writing a startup and shutdown sc ript for all of jboss-land 2009-08-25
- finished and deployed svnadmin.pl cgi, documented it and checked into subversion... next is more log4j edits, and deploy jsvn (java svn) 2009-05-08
- More updates...
Posting tweet...
















