wolstech

Sent manually.

It stops responding every few hours due to severe overloading. My sites are up and down all the time too. I get emails every time the database server fails. Three outages today so far, ranging from <1 minute to ~5 minutes each.

The main domain script will work to set a heliohost.org subdomain. That's provided it works at all (it has a high failure rate, usually due to server load, and until recently, it also didn't work for anybody on Johnny due to an API issue).

Done. It may take up to 2 hours to start working. If you see a 404 error or queued page, please clear your cache and flush your DNS resolver.

It arrived from the looks of it, but the BTC wallet is the only one I don't actually have access to because it's the Crypto->$$$ interface (it's part of the Bitpay account). The address is correct though and that's the same address I've sent crypto to before myself, so I see no reason it wouldn't arrive. I have access to every other crypto we support except BTC (since those wallets are also part of Heliomine). Moving...

The domain mirandat.heliohost.org should start working in the next few hours.

It's possible but not something we usually offer or support. I have to manually create it in WHM if that what she wants. The user-facing interface limits you to a single heliohost.org subdomain (as your main domain). I'll try to do this later on, Ricky is too slow at the moment to let me sign into WHM...

This got buried under all the account migrations. Krydos is the one you're waiting for, hopefully he'll see it now

It failed due to stale DNS entries. The domain olego.com has been cleaned up. Invite sent so you can try again.

It’s probably failing due to the main domain needing to be cleaned up. I’ll take a look when I get to a PC.

The DoS attack has sort of subsided. I'm still seeing tons of IPs getting blocked in the firewall, but it's not completely overwhelming the server now at least...

As a reminder, we do not regularly update PHP, so even though we will offer 7.3.9 when Tommy is released, there is no guarantee that it will remain current. We generally recommend not using WordPress, especially if this is what you want. It's the #1 cause of high load suspensions here at HelioHost, and is also notorious for being hacked (which historically has led to a phishing ban in ~90% of cases). It's so poorly written, bloated, and insecure that literally every other CMS in existence is a better choice. Sure it wins in popularity, but it loses in every other category that matters (most notably security, but performance is also a disaster). The security is so poor on WP, that one can actually argue that "security" and "WordPress" are mutually exclusive. There simply is no such thing as a secure WordPress installation. For those needing a full-featured CMS, we usually suggest Joomla instead. It's not 100% immune to the issues WP faces, but it has a much better reputation and a substantially lower chance of being compromised.

It’s not going to be September 9. It’s not even done being built yet, let alone tested. I’d add another week (or 2) at least. In the past, some server repairs have exceeded 6 months due to waiting for data center trips for part installations, so this is actually moving quite fast (happened to fail a week before an already scheduled maintenance trip). Only one or maybe two trips are made per year.

“Addon domains” in cPanel is what you want.

Nope. This is actually a fairly common occurrence here, usually a few times a year at least. More often than not, it’s retaliation for us banning abuse of some form (phishing or botnet typically).

@Krydos: Johnny's Apache has been down for almost a day and will not restart. Any idea what happened? The rest of the server seems to be working though (cPanel, mail, and FTP are up...).

Apache is the web server that actually serves websites. If it's down, then no website on Johnny will work. I have no idea what caused it to stop working...doesn't look like load based on the monitor.

Apache seems to be yes...http://heliohost.grd.net.pl/monitor/

Can you try a different internet connection (your ISP may have cached something that they shouldn't have)?

The domain ayegbajosh.com has been cleaned up.

It just means the server couldn't recreate your mysql databases during restore. The folder given /home/mickeyme/cpmove_failed_mysql_dbs.156744930 should contain the .sql files with the database contents. If you want to restore the databases, you can download the files, create a database in cpanel, then import the .sql file from the backup page. If you're not concerned about the contents, yes we can delete your account and send you an invite for a new one instead if you wish.

The domain nawit.tk has been cleaned up.

The account alanbald has been unarchived and should start working in the next few minutes. Domains for both of these accounts may take up to 2 hours to become functional.

The account mickeyme has been unarchived, however the mysql restoration failed due to a server error. You may need to use the files in the folder shown in the below error to restore your databases: [ 3585][RESTORE:1 ][A:mickeyme ]: Warning (“MysqlBase::_create_db_and_import_as_newuser_from_mysql_dbfile”, line 540): Failed to remove empty DB “mickeyme_mage224”: (XID tqrme9) The system received an error from the “MySQL” database “mysql”: 2006 (MySQL server has gone away) [ 3585][RESTORE:1 ][A:mickeyme ]: Warning (“DBBase::save_databases_in_homedir”, line 138): The system has saved the database archive data in the directory “/home/mickeyme/cpmove_failed_mysql_dbs.1567449308”. You may use this directory’s contents to restore your data manually. [ 3585][RESTORE:1 ][A:mickeyme ]: Warning (“Mysql::_restore_databases_and_map_them_to_cpuser”, line 178): The system failed to reinstall the MySQL database “mickeyme_mage224” as “mickeyme_mage224” because of an error: The MySQL server reported an error (MySQL server has gone away) in response to this request: /*!40101 SET character_set_client = @saved_cs_client */ at /usr/local/cpanel/Whostmgr/Transfers/SystemsBase/MysqlBase.pm line 294, <$_[...]> line 7580. [ 3585][RESTORE:1 ][A:mickeyme ]: Skipped item (“AccountRestoration::_run_restore_system_module”, line 437): The “Mysql” restore module failed because of an error: (XID 2fx2yw) The system received an error from the “MySQL” database “mysql”: 2006 (MySQL server has gone away) [ 3585][RESTORE:1 ][A:mickeyme ]: at /usr/local/cpanel/Cpanel/DBI.pm line 200. [ 3585][RESTORE:1 ][A:mickeyme ]: Cpanel::DBI::_create_exception(Cpanel::DBI::Mysql::db=HASH(0x38be830), "DBD::mysql::db selectrow_array failed: MySQL server has gone "..., undef) called at /usr/local/cpanel/Cpanel/DBI.pm line 188 [ 3585][RESTORE:1 ][A:mickeyme ]: Cpanel::DBI::_error_handler("DBD::mysql::db selectrow_array failed: MySQL server has gone "..., Cpanel::DBI::Mysql::db=HASH(0x38be830), undef) called at /usr/local/cpanel/Cpanel/MysqlUtils/MyCnf/Basic.pm line 242 [ 3585][RESTORE:1 ][A:mickeyme ]: Cpanel::MysqlUtils::MyCnf::Basic::get_server_version(Cpanel::DBI::Mysql::db=HASH(0x38be830)) called at /usr/local/cpanel/Whostmgr/Transfers/Systems/Mysql.pm line 852 [ 3585][RESTORE:1 ][A:mickeyme ]: Whostmgr::Transfers::Systems::Mysql::_restore_dbowner_password_and_privs(Whostmgr::Transfers::Systems::Mysql=HASH(0x665f840)) called at /usr/local/cpanel/Whostmgr/Transfers/Systems/Mysql.pm line 185 [ 3585][RESTORE:1 ][A:mickeyme ]: Whostmgr::Transfers:…hostmgr::Transfers::Session=HASH(0x37a61c8), 0, "johnnyheliohosresto201909021709366p7") called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 183 [ 3585][RESTORE:1 ][A:mickeyme ]: Whostmgr::Transfers::Session::Processor::__ANON__() called at /usr/local/cpanel/Cpanel/ForkAsync.pm line 67 [ 3585][RESTORE:1 ][A:mickeyme ]: eval {...} called at /usr/local/cpanel/Cpanel/ForkAsync.pm line 67 [ 3585][RESTORE:1 ][A:mickeyme ]: Cpanel::ForkAsync::do_in_child(CODE(0x253c760)) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Processor.pm line 185 [ 3585][RESTORE:1 ][A:mickeyme ]: Whostmgr::Transfers::Session::Processor::start(Whostmgr::Transfers::Session::Processor=HASH(0x3e3f6c0)) called at bin/restorepkg.pl line 319 [ 3585][RESTORE:1 ][A:mickeyme ]: bin::restorepkg::__ANON__() called at /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib/Try/Tiny.pm line 99 [ 3585][RESTORE:1 ][A:mickeyme ]: eval {...} called at /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib/Try/Tiny.pm line 90 [ 3585][RESTORE:1 ][A:mickeyme ]: Try::Tiny::try(CODE(0x37a63f0), Try::Tiny::Catch=REF(0x37a1998)) called at bin/restorepkg.pl line 324 [ 3585][RESTORE:1 ][A:mickeyme ]: bin::restorepkg::script("bin::restorepkg", "mickeyme") called at bin/restorepkg.pl line 54 Now unarchiving alanbald...

Piotr GRD described exactly the issue we've been seeing for the past week until a few days ago. It's better for busted NSes to be down entirely, because if it times out, the requesting device just asks the next one in the list. If it gets an answer, it just assumes that the information received is correct. NS1 was alive after Tommy came up, but until recently, had not been informed of most of the domains we have.