Brian

Rough time frame would be within the next 90 days, but that can change either way (sooner or later). As of right now we plan on giving people the option to stay on the legacy plans, or upgrade to the newest plans and adjust their pricing accordingly.

The only thing you should be using your email address as the username for is our helpdesk at https://support.hawkhost.com and our client area at https://my.hawkhost.com/clientarea.php. When logging into cPanel (http://yourdomain.com/cpanel or http://yourdomain.com:2082) the username would have been provided to your in your new account information email, and it's usually a variation of the first letters of your accounts primary domain name. That is what you should be using as the username for logging into FTP, and not your email address.

When you say email.com are you using your actual email address as the user name? The username for FTP is the same as your cPanel login, at least for the main account. If you did create a second account with that username then that would be valid. From what you've pasted that is my only guess that it's a username / password authentication error. If you contact our support desk (https://support.hawkhost.com) and provide us with the exact hostname, username and password you're using to connect we can attempt to replicate the issues ourselves + look into why it isn't working.

All very good points! We are in the process of doing a major re-work on what we bring to the table with VPS plans, and that includes writing our own VPS control panel. Once that is rolled out and everything is working there, it opens a lot of doors on what we can potentially do along the lines of our VPS plans. I'm going to re-open the discussion for the remote / dedicated MySQL instances with the other staff and see what ideas are thrown around.

One thing to keep in mind is that, despite the "headache", we can always move you to a reseller from a shared account if you wanted to upgrade. Best of luck in the research and post back if anything else comes up!

The tool you used for that traceroute takes the traceroute from that website, not from your local connection. You'll notice the IP on the first hop of the one you provided is a 72.249.*.* IP, where I bet if you go to http://whatismyip.hawkhost.com it won't match that. So that being said, that route is perfectly fine for that traceroute. It exits Dallas over Level3 and stays on Level3 until a clean exchange to the Softlayer network. Do you have a support ticket open regarding this issue yet? It's going to be your most reliable method for support at this time if you do not.

Thanks for the suggestion! This is an idea we've thrown around for a while now actually. It's one of those features which we know would be good to offer and would most likely be a great option for some users, it just hasn't come to the forefront as a project which we *have* to push out within, say, 3 months. We definitely have intentions on offering this at some point, but I'd be lying if I put a timestamp on it or made any guarantees. As a client, what would you be willing to pay for a service like this? Would $10/mo for a dedicated, remote and optimized MySQL server be a fair price? Should it be more, less? I'd be curious to hear your thoughts on pricing for this from the customers perspective.

In theory it shouldn't increase your risk or cause any problems. The major benefit of the reseller account in this instance is organization and isolation.

If you sign up with a shared account, the dedicated IP would be configured to your account only. That being said, any addon, sub, or parked domains which you add would use that IP. If you sign up with a reseller account, you can have more than one dedicated IP. So then what you would do is order a dedicated IP and you could assign it to your one e-commerce site only, and then use another IP for all other sites. Hopefully that is clear and helps but if not just let me know and I'll clear it up

Sorry about the lack of availability on chat -- we're finishing up some training of new staff and our usual operators are working with the new employees to get them up to speed. You did mention email and it really is the most efficient way to communicate with us. Our helpdesk is staffed 24/7 so you'll receive a prompt reply if you do go that route. As far as the phone goes I did check with our staff who answers the phone and showed them this. They could think of one voicemail which they did return the call for and said they were sent straight to voicemail after trying to call twice. I'm not sure if that's you but it could be.

Thank you for bringing this to our attention. I'm going to bring this up with management and work with them to see how, if at all, the system allows for improvement and what we can do to make calling a more professional experience.

We've identified a potential issue on Jupiter after researching some specifics provided to us by users via support ticket. Last night during a maintenance window our sysadmins rolled out an upgraded kernel which will allow us to track isolate and resolve the issue. As mentioned previously as well all your shared accounts will be getting migrated this weekend (we just finished preparing the new server for production) so between those two events any degradation in performance you've seen will be resolved.

We recently implemented CloudLinux on Jupiter (December 27th) which will limit your resource use if you're using more than the account is allocated. This may account for any slowness you see, you should login to your cPanel and check the real time CPU usage. At the server level though overall system resources are fine. We keep a close watch on all machines with multiple performance monitors so if something goes wrong or is going wrong we know. One other thing to keep in mind is we're moving Jupiter to shared only () here shortly to isolate it from reseller accounts like it's with now. While this may or may not effect performance of the account it's worth noting. It's impossible to say though what exactly is causing the issues you're seeing without knowing more about your account, and those are obviously details we can't obtain through a public forum. Anyone having issues I strongly urge you to submit a ticket at https://support.hawkhost.com, explain the issues in detail, and our helpdesk team will investigate the problems immediately.

We haven't had any other complaints of performance issues with Jupiter recently, so there is nothing known which could be attributing to the issues you're seeing. Have you tried contacting our support department regarding this yet? By raising a ticket we'd be able to pull up all of your account details and work with you to attempt to replicate the problems you're seeing and resolve them.

At this time we do not have an immediate plans to move to 5.5.X, and it all depends on when our control panel provider (cPanel) pushes it into their stable build. If you wanted to run that version of MySQL and have services with us you'd need to use a VPS.

If you'd like to be added to our testimonials portion of the website just email [email protected] with the testimonial and a verification you're the website owner and we'll get it added into the rotation.

Just wanted to let you know we did commit a report into our internal tracking system to have some of this modified so once again thanks for your suggestion

Heard of them about a month ago and if memory serves they did win some awards / honors for a new technology innovation for 2010 (TechCrunch comes to mind). As far as if they're compatible, yep it should be. Again if memory serves you update your nameservers to theirs so they take control of your DNS zone and you then use an A record to point to our servers so we still have the content but they control the DNS.

All the images appear to be working for me. Can you provide some more information about where you're seeing issues?

All sites and services should now be working as usual. Please submit a ticket if you see any further issues.

fsck has completed on the /var /usr and /home partitions and all are now clean. The system is being rebooted now and will be back online in approximately 5 minutes.

fsck on the /home partition has completed, we're beginning on /usr now and /var afterwards.

75% on the /home partition.

55% on the /home partition. Once that's complete we'll be running fsck on the /var and /usr partitions (these take about 10 minutes each) and will be booting the system back up.

fsck is currently at 25% on the /home partition.