If Sendmail takes several minutes to start, and your PHP scripts hangs when attempting to send emails via sendmail (eg: using the mail() function), ensure that your hosts file has its host name as an alias to localhost.

For instance, your hosts file should look something like this:

[leo@crow ~]$ cat /etc/hosts
127.0.0.1               localhost.localdomain localhost
109.169.59.122                     crow

You would want to add your host name to 127.0.0.1:

[leo@crow ~]$ cat /etc/hosts
127.0.0.1               localhost.localdomain localhost crow
109.169.59.122                     crow

Once that’s done, Sendmail should start and work normally.

The following is the unixbench benchmark ran on the XEN-PV Aquatic package offered at DamnVPS (ThrustVPS)

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.2)

   System: crow: GNU/Linux
   OS: GNU/Linux -- 2.6.33.3 -- #1 SMP Thu May 13 22:30:34 BST 2010
   Machine: x86_64 (x86_64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (4788.0 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
   18:49:48 up  5:11,  2 users,  load average: 0.08, 0.02, 0.01; runlevel 3

------------------------------------------------------------------------
Benchmark Run: Fri Jul 30 2010 18:49:48 - 19:18:08
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       14337184.0 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2868.0 MWIPS (9.9 s, 7 samples)
Execl Throughput                               1545.8 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        243675.8 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           62276.1 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        705056.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                              363431.4 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  72559.7 lps   (10.0 s, 7 samples)
Process Creation                               3171.4 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2853.2 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    389.9 lpm   (60.1 s, 2 samples)
System Call Overhead                         421968.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   14337184.0   1228.6
Double-Precision Whetstone                       55.0       2868.0    521.5
Execl Throughput                                 43.0       1545.8    359.5
File Copy 1024 bufsize 2000 maxblocks          3960.0     243675.8    615.3
File Copy 256 bufsize 500 maxblocks            1655.0      62276.1    376.3
File Copy 4096 bufsize 8000 maxblocks          5800.0     705056.0   1215.6
Pipe Throughput                               12440.0     363431.4    292.1
Pipe-based Context Switching                   4000.0      72559.7    181.4
Process Creation                                126.0       3171.4    251.7
Shell Scripts (1 concurrent)                     42.4       2853.2    672.9
Shell Scripts (8 concurrent)                      6.0        389.9    649.8
System Call Overhead                          15000.0     421968.1    281.3
                                                                   ========
System Benchmarks Index Score                                         466.6

Here is my rant on eTecc Communications. Skip to the last paragraph to skip all the gory details.

I was hosted at SteadCom since April 3rd, 2010. Except for the two major downtimes, one due to PacificRack and the other due to some sort of network problems, I had a fairly pleasant experience with SteadCom. For $10 per month, I got 40GB disk, 1TB bandwidth, and 768MB memory (with the same in swap) on a Q6600 @ 2.40GHz processor. The benchmark results are somewhere on this blog; just search for steadcom.

What does this have to do with eTecc? Well, eTecc recently acquired all SteadCom VPS customers. Throughout the month, they emailed about 3 times with your standard “our company is the best” message, while reassuring that they will make the migration from SteadCom servers to eTecc servers as ‘seemless’ as possible.

On Wednesday, July 28, I got this email:

ATTENTION! SteadCom servers will be shut down on August 1st, 2010, if not sooner, due to recent datacenter complications on the behalf of SteadCom. Thus, the original migration schedule has been accelerated and we require your immediate attention.

If you should have questions or require assistance during this expedited situation, please do not hestiate to contact us at any time. We are here to help.

The seamless migration of your account from SteadCom servers to eTecc will begin July 27, 2010. This migration has been segmented into several pieces in order to ensure a fluid transition with little to no downtime. Based on the type of account that you have, OpenVZ, XEN, or a shared hosting environment, we have prepared the following schedules. If you need help determining the type of account that you have, please contact support.

(snip)

XEN Based Accounts

A new VPS account will be setup on your behalf, using the same Operating System as your previous system, on eTecc’s enterprise level Parallels Virtuozzo platform as of July 28th, 2010. You will then have the ability to migrate any data or configurations to your new account until SteadCom systems are closed on August 1st, 2010. If you should require assistance in this migration, please do not hesitate to contact eTecc support technicians, we will be happy to help.

Accessing Your Account

In order to access your new account, please login to our Web Site control panel to retrieve your new access credentials. Please note, for some accounts the accounting information was not provided due to SteadCom bookkeeping methods. Thus, those accounts will be prompted to confirm their billing information before access to their new login information is released.

(emphasis mine)

Okay, so I have 3 days before the SteadCom servers goes offline. 3 days notice that my existing server will go offline and that I must *manually* transfer all my data to their new VPS. Why they even bothered calling this a ‘seemless migration’ is way beyond me. “Okay, whatever” I thought. I expected that they would contact me shortly regarding my new VPS server login. Nope. eTecc simply did nothing until I contacted them about my new VPS IP late Thursday.

Even though the email said I can get my server info from the customer control panel, all that is displayed is

To access your IP information, please add a credit card using the “Add Credit Card” link at the bottom of this page.

Meaning, if I wanted my server details, I had to give them my credit card as that was the only option offered. After asking them about payment by paypal did they then give me a subscription button. It was only after I paid and waited for approximately 17 hours did they finally reply with my new VPS IP address, with nothing else; not even a root password for the new VPS. The customer panel still showed the same message about me needing to add a credit card. I guess they don’t consider payment via paypal ‘confirmation of billing information’. /sigh

Now I’m starting to get worried and frustrated. The SteadCom server is supposedly going to shutdown that night. I’ve paid them the amount due, and yet I still haven’t received my server login or any other details other than that my server IP is 68.169.197.152. Their staff was taking their sweet time replying to my tickets and I still have all my data to transfer.

Instead of bothering with this joke of a company, I ordered a new VPS at DamnVPS (ThrustVPS) with instant setup. I then canceled the paypal subscription to eTecc shortly after. Within an hour (faster than their usual support responses), Derek (the president of eTecc) emailed me, asking why I canceled the subscription. Having explained my reasons and my frustration, he kept refusing to refund the $10 that I paid the day before, even though I haven’t even been given the VPS login details other than the VPS IP (meaning, I couldn’t even use the service I paid for). It is now 5 PM Friday, and I’ve still yet to receive the server password for my eTecc VPS, with the SteadCom VPS planned to go down hours later.

However, with my DamnVPS VPS, I’ve recompiled, reconfigured and transferred all my sites from SteadCom to DamnVPS in 2 hours. Had I not moved to DamnVPS, my sites along with all my data would be lost, all thanks to eTecc’s gross incompetence.

TL;DR Version: I would suggest whoever is interested in VPS hosting to not touch eTecc with a 100 feet pole. They failed at every aspect of being a good hosting company. Slow, incompetent support, no service after payment, and their lack of initiative with their customer’s needs. This so-called server migration of theirs simply highlights their sheer lack of competence.

I understand if a host does not give refunds, but honestly, I gave them $10 for absolutely nothing. It’s like going to a coffee shop, paying for your coffee, and all you get is a cup with no coffee. No Refunds? Fine, so long as I get what I paid for. But in this case, it just shows that eTecc is simply nothing more than a scam. You won’t get a server, you’ll get their half assed attempt at giving you a server.

If you need a good budget VPS, get one with Rus at DamnVPS (ThrustVPS). Although I’ve only had this VPS for about a day, I have been on the DamnVPS’s beta and I’m confident the server will be as solid as when I tested it.

I’ve posted this review on WHT.

Ticket contents follows:

Having needed to use a jquery lightbox plugin, in this case: Lightbox2 (huddletogether.com), my client noticed that it generated javascript errors on IE.

Message: Invalid argument.
Line: 116
Char: 165
Code: 0
URI: http://________.com/static/js/jquery.js

After poking around, it seems as though there was an extra ‘;’ which caused IE to messup.

Change the line:

$('#outerImageContainer').css({width: '250px', height: '250px;'});

on line 42 in lightbox.js to

$('#outerImageContainer').css({width: '250px', height: '250px'});

should fix the issue.