wolstech

Additional complaint from another user is here: https://helionet.org/index/topic/62336-hh870980-re-account-move-completed/ Escalating since this is 3 now suddenly...

Can't locate LocalSettings.pm in @INC (you may need to install the LocalSettings module) (@INC contains: /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at View.cgi line 20.: /home/suranet.eu.org/openvms.eu.org/cgi-bin/View.cgi, referer: https://openvms.eu.org/ Looks like includes that are missing. Not sure if Krydos can install these or not.

The account has been reset. Please look for an email to finish setting up a replacement account. I would suggest blocking this IP range in .htaccess once you set the new account up before doing anything: 172.68.0.0/14 This range is where the attack came from.

Krydos can cancel your service. Escalating...

Sure. Apologies for the delayed response, I've been running around and on my cell phone most of the day. The hour I had this morning at my desk I spent troubleshooting someone's image generation issue on the new Tommy. I'll do this for you when I'm at a computer tomorrow morning.

It doesn't work on 5.6 for me either. I'm going to assume GD is broken on 5.6 considering 7.4 works. Krydos would need to fix this, as I don't have the ability to do so.

Nope. Your account is working. The issue appears to be that your index.php is just a file_get_contents() that displays another website...that other website is down. Other files on your account are available: https://dahuhunter.heliohost.org/README.txt

CF is supported with external domains such as eu.org, but some features such as seamless account moves will not function as we cannot update DNS settings on your behalf in such a configuration.

Cloudflare is not supported for domains ending in heliohost.us and helioho.st.

It's a path, PHP version, or account issue. That gd1 script works on my account under PHP 7.4: https://wolstest.helioho.st/gd1.php (Note that I didn't use an absolute path for the font file either, I used ./DejaVuSansMono-Oblique.ttf ) Here it is on 5.6 on my account, but I'm waiting on an Apache restart to see if this version works: https://php56.wolstest.helioho.st/gd1.php If it turns out it works on my 5.6 link once Apache restarts, Krydos is probably going to say the fix is to reset your account and rebuild it. You're on a legacy cPanel account, those are well known to be full of bugs.

That error is usually caused by an unsupported browser. Please try again in a desktop version of Chrome, Edge, and Firefox.

It would be best if we just reset the account to delete everything so you can start over. There's no way of knowing what the hackers did. Do you want me to reset your account? if not, I'll delete the WP install and its content manually for you before I unsuspend it. Please let me know how you want to proceed.

Yes, Krydos can do this.

No it wasn't. It has never been active on any version of Tommy or Johnny.

Our system disagrees with you on that, and indicates there are at least 2 accounts being used from the same network or computer as yours. Nonetheless, open0 has been unsuspended. The other accounts associated with it will not be unsuspended. It may take a few minutes to start working.

Krydos can look into this for you.

The account benyoudz should be active.

You're suspended for creating more than one account. Users are only allowed to have one account. Which one do you want to keep?

Looks like an issue on your registrar's end. There's no NS records being advertised for that domain: https://bybyron.net/php/tools/dns_records.php?domain=rainsplashmedia.com&rec=NS Our name servers are configured for that domain if you specifically query them, so the issue is your registrar's NS records being missing: nslookup rainsplashmedia.com ns1.heliohost.org Server: UnKnown Address: 65.19.143.3 Name: rainsplashmedia.com Addresses: 2001:470:1:1ee::1002 65.19.154.90

Domain changed. It can take up to 2 hours to take effect.

The spam filter is definitely present on the new tommy and looks to be turned on (the settings are under the mailboxes, under Mail, click on an address in the list, and you'll see Spam Filter as a tab). The server-wide settings are also identical. Since your account is a legacy cPanel account, it's likely full of weird bugs anyway. There's nothing obviously wrong, but these accounts are ancient and their conversion to Plesk introduced a lot of strange issues that only these accounts experience. The only solution we have for converted cPanel accounts is to reset them and let you rebuild it. You'd have to set your sites backup from backups and recreate your mailboxes if we do that. If you want to go that route, let us know.

The logic is that they'll eventually just delete on its own. We only keep two to start with because both copies must exist for the seamless live migration to work. Users who use external DNS can't benefit from that anyway. We just didn't implement the delete part for Tommy2 since it's both the first test of the system, and because the entire server will retire soon anyway. We also plan to use this code for internal moves down the road where user input is undesirable.

Unsuspended. I disabled node so it won't start on its own and get you suspended again until you fix it. It may take a little while to start working.

The file systems are not shared actually. It's two completely separate copies. That said, good to know about the scheduled tasks, and they could do this in some cases. For example, if it calls a URL to trigger the script, that URL will be called twice if the job is running on both servers. Since the domain's DNS updated to point to the destination server during the move, the new server's data is the data that updates.

I've added a deny from all to .htaccess to block the entire y2ameds.com site until you can clean it up. If this happens a second time, it's likely that one of the extensions or themes you used had a backdoor in it. EDIT: Your logs are full of hacking attempts too. All that traffic from the 172.68.0.0/14 range of IPs are hackers attempting to get into your site. If you rebuild your site, I'd recommend you block that entire range.