Jump to content

Ashoat

Chief Financial Officer
  • Posts

    6,455
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by Ashoat

  1. Ashoat

    Awesome news!

    More than a year ago, Facebook reported having more than 30,000 servers... my guess is that the number has gone up significantly since then.
  2. The HelioNet database has been moved. At this point, it looks like HelioHost.org and HelioNet are completely moved to Cody, and that Cody is functioning as the nameserver for all HelioHost accounts.
  3. Ashoat

    Awesome news!

    You definitely can't host Facebook. We don't really have any hard mathematical data, as most of this stuff is done holistically. I'd say that if your account is using around 25% of our resources then we'll suspend it.
  4. Ashoat

    Awesome news!

    We are financed almost entirely by the ads on HelioHost.org. Between Stevie and Charlie, we have 2 TiB of disk space. Thanks for the compliments!
  5. Okay... HelioHost.org and the account database have been successfully moved. In addition: the records for HelioNet have been changed. I'll move the HelioNet database once the DNS sets in.
  6. Okay, your account should be on the new IP within 24 hours.
  7. Okay, I see your point... if the info hadn't propagated to Europe at that point, then updating the record on Stevie as well wouldn't have hurt. Anyways... I've done steps 1 and 2 so far, and I just turned off BIND on Stevie. All DNS requests for HelioHost are now being handled by Cody.
  8. Closing due to inactivity...
  9. Actually, moving to the new nameservers should take the same amount of time (~4 hours) as moving the domain itself. While switching nameservers (ie. move from ns1.heliohost.org to ns1.someotherhost.com) takes about 24 hours, changes of A records (as was the case for moving ns1.heliohost.org to a new IP and similarly for moving heliohost.org to a new IP) usually take about 4 hours. This is because DNS records of type "NS" usually have a TTL of about 24 hours, while DNS records of type "A" usually have a TTL of about 4 hours. What's notable here is that no NS records have been changed - all domains are still pointing to ns1.heliohost.org. It's just that the A record for ns1.heliohost.org has changed.
  10. Thanks PS: the pattern is that actual, physical servers get "ie"-ending boys' names, and virtual servers get "y"-ending boys' names. I give most of my home/office hardware girls' names...
  11. Closing due to inactivity... Let's keep the conversation going in the Moderator Discussion forum.
  12. No problem... glad everything worked out Closing this thread now...
  13. I'm moving HelioHost.org to Cody today. The process will work as follows: 1) Copy all the files from Stevie to Cody. 2) Switch DNS records from Stevie to Cody. 3) Stop all modifications to the accounts database temporarily. 4) Copy database over to Cody. 5) Switch Cody to point to localhost database. 6) Switch Stevie to point to Cody's database. I've already added code to all the scripts to allow for managing multiple and remote servers. Next step after this is to move HelioNet. On Thursday, I'm disabling BIND on Stevie. After this, I'll start to set up Johnny, another VP on Charlie. This one will host user accounts, and will be full-featured (ie. RoR/JSP/ASP.NET)... but as a result will be less stable than Stevie, and will be advertised as such. Some time after that I'll disable RoR on Stevie, and ask that all RoR users migrate to Johnny. IMPORTANT NOTE: after I switch the DNS record for heliohost.org to Cody, everyone who is trying to log in to cPanel via "heliohost.org/cpanel" will be unable to login. Instead, try to log in using the HelioHost.org home page.
  14. Okay, you should have a dedicated IP within the next 24 hours.
  15. I'm assuming it works?
  16. Okay, the account is deleted. You should try to register again in around two hours and eight minutes.
  17. Ashoat

    New nameserver

    DNS changes have propagated to me and it looks like everything is working! On Thursday I'll switch off BIND on Stevie.
  18. Don't run the fix_corrupt_domain.py command arbitrarily! It removes the domain's records from the system. It's specifically for corrupt DNS records... this issue was the result of a missing httpd.conf entries. icechen1: Would you mind recreating your account? We can delete it, and then you can sign up again. It looks like your domain record (among other things) is missing now (as a result of the fix_corrupt_domain.py run), and the easiest way to recreate those things is to just recreate the account.
  19. Good idea!
  20. Your IP address should be changed.
  21. I'm not sure... what I know is that the phonify scripts were still running. It might be a bug in PHP or a bug in your script.
  22. Ashoat

    New nameserver

    Since the zones have been synced between Stevie and Cody, and since all changes to Stevie are set to update Cody, my understanding is that no changes should occur to any HelioHost accounts.
  23. Ashoat

    New nameserver

    Hi everyone, I've set up a new virtual server (Cody) on Charlie that is going to function as our nameserver (and also the host for mission-critical websites, but I'll set that up later). After syncing all the DNS records from Stevie, I've moved the records for ns1.heliohost.org and ns2.heliohost.org to point to Cody's IPs. Hopefully, we shouldn't have any trouble. The DNS records should propagate over the next two days, and that point we'll be sure everything worked out. Once that happens I can disable the nameservers on Stevie, which should decrease server load and improve service reliability. Thanks, djbob
  24. asweeba: What cPanel says isn't relevant. Like I said, cPanel /thinks/ that all non-default IPs are dedicated. However, unless I've explicitly told you that I've assigned you a dedicated IP, you don't actually have a dedicated IP. If it's working out for you anyways, that's good - we have a limited supply of dedicated IPs.
  25. I guess you could create a CGI script that ran a bash command that counted the number of processes already running (ie. `ps aux | grep phonify | grep -vc grep`) and prevented the PHP script from running otherwise. You could have the CGI script run as a cronjob and touch a file when there are spare spots, and the PHP script would read that file to make sure there were spots.
×
×
  • Create New...