Tony

All shared accounts have access to the pear installer through cPanel.

You should be able to park more. If it's not letting you please open a support ticket so that we can look into it.

The PHP5 version on all servers is now 5.2.4

On Saturday September 15th between 1pm EDT and 5pm EDT we will be upgrading all our servers PHP 5 to PHP 5.2.4. We do not expect any down time while we perform this upgrade we will just be performing an apache restart once PHP 5.2.4 is installed. If you're interested about any changes in this version please visit http://www.php.net/ChangeLog-5.php#5.2.4. Date: 09/15/2007 Start time (EDT): 1:00pm End time (EDT): 5:00pm Duration: 5 hours (few minutes per server large window to perform maintenance across all servers)

The server upgrade has now been completed. If you are experiencing any problems please contact our support department at https://www.hawkhost.com/support/

Yep that would be why as it is technically a new machine. So you're already on the new Mars machine. In fact the majority of the customers on Mars are already on it, we're just moving a few last accounts.

Starting on Tuesday August 28th we will be upgrading our Mars server. We expect only about 1-2 minutes of down time at most for each account to be migrated over. This migration will only involve us switching the server, we will not be changing IP addresses so this should be cause any DNS issues. The only issue we see coming up would be due to large sites taking a while to restore resulting in some data being lost if they are modified constantly. We however expect this to not cause many issues as the upgrade of Mercury went unnoticed by the majority of our customers and their visitors The reason for this upgrade is our Mars server is showing it's age only being a dual cpu server. We've started deploying quad cpu raid-10 based systems and it was Mars turn to receive the upgrade. The new server will be the following specifications Quad Core Xeon 3220 - 2.40GHz (Kentsfield) - 2 x 4MB cache 4 GB DDR2 667 4x250GB SATA II Raid-10 This is a much more powerful server compared to the current Mars one. It adds 2 extra CPU's to the mix and along with that it adds two more hard drives and will use the much performance and redundancy oriented raid-10 configuration. With raid-10 we could potentially lose up to two hard drives and continue to still function. We will also be able to swap out drives that fail on the fly which means no down time. If you have any questions or concerns do not hesitate to contact our support department. Start date: 08/28/2007 End date: 09/3/2007 Duration: 7 days (Estimated)

Well our plans of upgrading to Apache 2 relied on cPanel sticking to their release schedule of cPanel 11. They were unfortunately quite a few months behind on just releasing it as stable (did this on August 15th). The new Apache building tools which include Apache 2.2 are not slated to hit Stable until September 26th. All our servers run on RELEASE which is pretty much stable so we may see Apache 2 a bit earlier than that (we'll be testing upgrades before we even try it). You can find more information about cPanel's release schedule by visiting http://www.cpanel.net/products/cPanelandWHM/linux/cpanel11/index.html . Doing this sort of web server setup without doing it through cPanel is obviously ill advised so we're not going to be attempting that. Even when other hosts start to try to use it once it gets past Alpha and hits more of a beta release we're not going to be attempting the install. There is probably going to be numerous issues with the Apache 2 upgrade so we're just going to watch other hosts run into all the issues. This is exactly what we did with cPanel 11 and our transition was much better than others who migrated early. Apache 2 itself does not introduce anything special to the end user, what it does provide however is better performance (less resources being used). As for extra modules we'll of course be evaluating modules and possibly installing them. But one step at a time we'll deploy Apache 2 first with that Ruby will hopefully be supported. After that we'll look to doing Python. Of course at this time all our machines run Python it's simply not an Apache module. So what we've been doing while idle with cPanel 11 and Apache 2 is doing internal upgrades to our servers as well as our we handle things. For example the Mercury server you're on was upgraded to a quad core system with 4x250GB SATA II raid-10. As it stands we are now also much better prepared to quickly migrate users to other servers with no down time. This is huge for us in the future if we ever deploy multi server setups. We've also been working on better documentation when it comes to sales, billing and support and we hope to have that up on our site some time in September.

This has been completed as of 08/12/2007 at 9:20pm EST (GMT -5). The upgrade did not go as smooth as we had hoped, but overall there was minimal down time during the move. The only real issue we ran into were the few customers we had on this server using our shared hosting platform. They were on an IP we were unable to move to the new server (relates to how all our ip's route to our servers now). We changed the IP for those shared customers and moved everything across but we anticipate some DNS issues which are unavoidable. We've also renamed the server back to Mercury to avoid confusion. Overall the move went well and we plan on doing our other dual opteron servers in the near future. We of course will be posting notices about when those moves will be happening and we anticipate no issues after having done this sort of move once already.

Starting on Friday August 8th we will be migrating accounts from our Mercury server to our newly deployed Saturn server. We expect about 1-3 minutes of down time per account while we do the migration. The migration will only involve the switching of servers. IP addresses and everything else will stay intact during the move. The only issue we could see arrise is large dynamic sites take longer to move so we recommend if your site is very large and relies on a database to contact us. The issue with large sites is once the move starts it takes a copy of the database and then restores it on the new server. If the site is large enough some content may arrive on the old server before we do the IP switchover. So if you're at all concerned about this we welcome you to contact us about scheduling a time to do your move. The reason for this upgrade is the Mercury server is showing it's age and at times has slow downs. We feel that upgrading to much better specifications will help solve this issue. It will also help us in the future when deploying new features there will be less added strain on the server. The new specifications are as follows: Quad Core Xeon 3220 - 2.40GHz (Kentsfield) - 2 x 4MB cache 4 GB DDR2 667 4x250GB SATA II Raid-10 This is a much more powerful server compared to the current Mercury one. It adds 2 extra CPU's to the mix and along with that it adds two more hard drives and will use the much performance and redundancy oriented raid-10 configuration. If you have any questions or concerns do not hesitate to contact our support department. Start date: 08/10/2007 End date: 08/17/2007 Duration: 7 days (Estimated)

Well it looks like our servers meet all the requirements. But that version you linked to me is actually pretty old. I'd look at getting the latest version from their site: http://www.ftrsoft.com/fclicksql.html . I'd try that version and see if it actually installs.

Well, first of all I'm not sure exactly what the FClick web site is so I just visited a site based on a google search and I assume it is the correct site. So on the installation and it not going any further is there some sort of error you are receiving or is it a blank page or what exactly? Secondly an easier way to track clicks on downloads, well I'm sure there are many other solutions out there if FClick does not work properly.

Well they're good suggestions but I still don't think that would help our forum at all. The majority of our customers are businesses or people with no interest in visiting a forum. We simply have it because it's good for the few that do use it.

This should be completed; unfortunately there was a misunderstanding about the maintenance window between myself and the technicians doing the maintenance. We had to have several minutes of down time during the window to migrate our secondary ip's to their new vlans. I'm very sorry about any inconvenience this may have caused.

On Saturday between 10pm EST and 12am EST we will be migrating Mars, Mercury and Venus to new primary IP addresses. The reason for this is to expand out our web server VLAN in order to accommodate more machines. Once this is done it will now be possible to easily move secondary IP's from one server to another. We do not expect any down time during this time however anyone referencing the servers by their main IP can no longer do this. Once this is completed over the next few months we have plans of upgrading Mars, Mercury and Venus to much higher specification machines gradually. Thanks to the maintenance on Saturday we will also be able to transfer accounts to the upgraded servers without the need for dns changes or any down time or issues what so ever. As always if you have any questions about the maintenance please contact our support department. Date: 7/14/2007 Start time (EDT): 10:00pm End time (EDT): 12:00am Duration: 5-10 minutes

We're now offering public uptime reports provided by Pingdom. You can find the reports at http://www.pingdom.com/reports/9zo4vo0z6qoq/ they are as of a few days ago and track just the web servers on each machine. The reporting is in 1 minute intervals so we imagine each month there will be 1-2 minutes of down time reported just due to the fact it can pick up a lot of things normal 5 minute intervals do not. Please keep in mind the uptime percentage will not be accurate until the month ends. So at the end of the month will show whether or not we met our 99.9% uptime for each machine.

You are very welcome. It sure has been a long 2 years and I'm glad your experience has been great. I've told the rest of our staff about the post just so they know we're doing something right. We rarely hear about the good experiences (totally normal) so it's great to see a positive post once in a while.

On Monday July 2nd we will be performing the upgrade to cPanel 11 on all servers. We will be doing this throughout the day and do not expect any interruption of web server service. We do however expect periods of time where cPanel will be unavailable due to the upgrade. We have no exact estimate on how long this will take or an exact time each server will have the upgrade performed. If you have any questions about this do not hesitate to ask our support department. Date: 5/21/2007 Start time (EDT): 10:00am End time (EDT): 10:00pm Duration: 12 hours (Estimated)

Date: 06/24/2007 Start time (EDT): 2:00pm End time (EDT): 3:15pm Services Affected: Power Location: Localized to SR01 At approximately 2:00pm EST, areas of the datacenter Hawk Host utilizes suffered power interruptions. This was related to a faulty power alarm panel which resulted in automatic shutting down of power. The panel was replaced and power was fully restored at 3:15pm EST. The emergency response team of the datacenter will be onsite throughout the night, however no further issues are anticipated. Hawk Host personally did not have any servers actually lose power but Mars, Mercury, Venus and several of our dedicated servers customers lost connectivity for about 20 minutes. The reason for losing connectivity was due to switches and routers in that are connected to these machines losing power. We appreciate your understanding and continued business with Hawk Host.

All servers are now running PHP 4.4.7 and PHP 5.2.3.

We'll be upgrading all servers PHP 4 version to PHP 4.4.7 tonight which will require a few web server restarts which should not be noticable. We're very sorry about the short notice on this it has just been a common request for us to upgrade and we feel it would be best to upgrade now. Since it does not require any down time what so ever we feel it's not much of a big deal to upgrade. Now we'll also be upgrading all PHP5 versions to PHP 5.2.3 on Saturday June 16th during the day. Just like the PHP4 upgrade this will result in no down time just a few web server restarts to confirm that PHP 5 is working. The reason for these upgrades is to patch several PHP holes that have been discovered and as a result patched in these versions. If you have any questions or concerns about these upgrades feel free to contact support.

This does not affect our current DNS situation in anyway. We run a clustered dns system so all our name servers share the same physical machines. But you're free to use the new ones ns1.hawkhost.com and ns2.hawkhost.com if you want to.

Jupiter Uptime Report May 2007 Date Average response time Uptime Downtime 1 207.685 ms 100.00% - 2 174.352 ms 100.00% - 3 241.597 ms 100.00% - 4 326.878 ms 100.00% - 5 229.525 ms 100.00% - 6 272.219 ms 100.00% - 7 254.205 ms 100.00% - 8 219.840 ms 100.00% - 9 205.840 ms 99.41% 8m 23s 10 225.274 ms 100.00% - 11 151.111 ms 100.00% - 12 281.649 ms 100.00% - 13 230.580 ms 100.00% - 14 153.435 ms 100.00% - 15 119.230 ms 99.59% 5m 55s 16 267.593 ms 100.00% - 17 469.450 ms 100.00% - 18 336.235 ms 100.00% - 19 305.317 ms 100.00% - 20 233.299 ms 100.00% - 21 311.694 ms 100.00% - 22 369.952 ms 100.00% - 23 323.252 ms 100.00% - 24 128.759 ms 100.00% - 25 215.860 ms 100.00% - 26 157.408 ms 100.00% - 27 170.726 ms 100.00% - 28 215.612 ms 100.00% - 29 138.891 ms 100.00% - 30 120.242 ms 100.00% - 31 166.592 ms 100.00% - Average Response Time: 233.042 ms Uptime %: 99.97% Total Downtime: 14m 18s Reponse Time Graph (Click for full size) [ATTACH]26[/ATTACH] Uptime Graph (Click for full size) [ATTACH]25[/ATTACH] Jupiter was not as affected by the DDOS in the area but did have some down time relating to it. The other outage that was several minutes I'm unsure about it may have been us upgrading things. Other than that it met the 99.9% uptime easily for the month.

Mars Uptime Report Date Average response time Uptime Downtime 1 210.783 ms 100.00% - 2 146.691 ms 100.00% - 3 229.048 ms 100.00% - 4 326.857 ms 100.00% - 5 247.180 ms 100.00% - 6 231.391 ms 100.00% - 7 286.589 ms 100.00% - 8 232.486 ms 100.00% - 9 212.729 ms 100.00% - 10 244.653 ms 100.00% - 11 183.525 ms 100.00% - 12 245.631 ms 100.00% - 13 215.453 ms 98.75% 17m 38s 14 187.032 ms 100.00% - 15 148.476 ms 99.40% 8m 42s 16 277.405 ms 100.00% - 17 409.671 ms 100.00% - 18 277.810 ms 100.00% - 19 266.017 ms 100.00% - 20 215.406 ms 100.00% - 21 265.296 ms 100.00% - 22 329.298 ms 100.00% - 23 331.832 ms 100.00% - 24 231.380 ms 100.00% - 25 215.745 ms 100.00% - 26 184.334 ms 100.00% - 27 207.291 ms 100.00% - 28 217.116 ms 100.00% - 29 161.605 ms 100.00% - 30 133.612 ms 100.00% - 31 172.193 ms 100.00% - Average Response Time: 233.695 ms Uptime %: 99.94% Total Downtime: 26m 20s Reponse Time Graph (Click for full size) [ATTACH]24[/ATTACH] Uptime Graph (Click for full size) [ATTACH]23[/ATTACH] The same as the others it had some down time due to the large ddos that affected numerous providers in the area. Other than that everything was great and we met the 99.9% uptime.

Mercury Uptime Report Date Average response time Uptime Downtime 1 245.532 ms 100.00% - 2 163.876 ms 100.00% - 3 301.407 ms 100.00% - 4 313.166 ms 100.00% - 5 256.960 ms 100.00% - 6 239.890 ms 100.00% - 7 259.733 ms 100.00% - 8 237.736 ms 100.00% - 9 258.596 ms 100.00% - 10 305.023 ms 100.00% - 11 174.789 ms 100.00% - 12 186.599 ms 100.00% - 13 195.719 ms 98.74% 17m 48s 14 174.546 ms 100.00% - 15 168.961 ms 99.58% 6m 0s 16 289.565 ms 100.00% - 17 382.996 ms 100.00% - 18 293.194 ms 100.00% - 19 313.572 ms 99.59% 5m 48s 20 228.402 ms 99.04% 13m 47s 21 309.642 ms 100.00% - 22 292.759 ms 100.00% - 23 309.178 ms 100.00% - 24 170.137 ms 100.00% - 25 163.400 ms 100.00% - 26 163.375 ms 100.00% - 27 195.064 ms 100.00% - 28 254.618 ms 100.00% - 29 131.276 ms 100.00% - 30 135.750 ms 100.00% - 31 193.669 ms 100.00% - Average Response Time: 235.778 ms Uptime %: 99.90% Total Downtime: 43m 23s Reponse Time Graph (Click for full size) [ATTACH]22[/ATTACH] Uptime Graph (Click for full size) [ATTACH]21[/ATTACH] Mercury as our others servers experience connectivity issues the one day due to a ddos attack that affected numerous providers in the area. The other outage related to the fact we lost a drive in Mercury which in turn caused all sorts of CPU usage problems. So we decided to swap the drive out to correct the problem.