Krydos

Your main domain has been changed to moneygalz.heliohost.us

Try changing this line subprocess.Popen("/home/ar7/bot.py") to this subprocess.Popen("/home/ar7/bot.py", shell=True)

Yes, after the Ricky rebuild a lot of people switched to Tommy and he ended up getting pretty overloaded. As you can see here https://www.helionet.org/index/topic/43675-no-free-tommy-signups/ free signups have been closed on Tommy for over a month to help reduce the load. It's slowly getting better. When we release the new server hopefully in a few months a lot of people from Tommy will move to the new server and it will help Tommy's stability too.

Oh, I thought he was talking about actual subdomains, not the special proxy subdomains.

Put this in the .htaccess file in the webroot of each domain and subdomain to force https: RewriteEngine On RewriteCond %{HTTPS} !=on RewriteCond %{REQUEST_URI} !^/.well-known/ [NC] RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Are you trying to remove www from the beginning of your domain too?

The ip you posted from is not blocked. If you provide some other ips that you think are blocked I could check them too. Is there any error when you try to FTP? Are you using FTPS, FTP, or SFTP? We recommend SFTP. FTP is insecure, and FTPS rarely works right. Does this help? https://unix.stackexchange.com/a/164093 It seems like the topmost directories lose their timestamp, but all files and subdirectories should keep them.

Are you only using firefox? Does the same error come up with other browsers? I viewed your site with chrome, safari, and edge and it works on all of those. Maybe it's something specific to firefox? I don't have firefox installed so I can't test that.

There you go https://krydos.heliohost.org/cgi-bin/modules37.py

WHM allows you to edit and delete all the accounts on the server, so no you don't have access to that. We use Apache not Nginx, but you can easily do redirects using modrewrite in your .htaccess file.

I deleted your Comodo certificate and generated a new autossl certificate using Let's Encrypt instead. Does that one work any better for you?

We don't actually offer heliohost.org subdomains anymore. Since you created your account prior to us getting the heliohost.us domain you're allowed to keep your domain, but no one can have new ones. As far as setting up a separate domain probably the easiest would be to register a domain for free at freenom and add it as an addon domain to your account. Addon domains are completely separate from your main domain. If you think it's somehow related to heliohost.org subdomain you can try going to https://krydos.heliohost.org/ It uses the same autossl certificate on the same server as you.

Python 2.7, or Python 3.7?

Your ssl certificate is valid, and it appears as if autossl is working fine. https://www.sslshopper.com/ssl-checker.html#hostname=daskunk.heliohost.org The CA error means that it is the "cPanel, Inc. Certification Authority" or the "COMODO RSA Certification Authority" chain that is the problem. Neither of these CA's have revoked their certificate, and both are valid until 2025+. The certificate that domain is using was issued on June 7th, so it's strange that it start happening on July 4th. You went almost a month using that same certificate before anyone noticed any issues with it. Anyways, here is an article for understanding that error and some ideas of how to fix it https://geekermag.com/error-code-dlg_flags_invalid_ca/ One that is really simple that stands out to me is simply clearing your browser cache.

Your main domain has been changed to rickalmeida.online. It looks like your software is still trying to redirect to the old domain though so make sure you edit the config file and update the domain there too.

Unarchived.

Your username is actually abhibab1 and you aren't suspended you're archived. Suspended means you violated our terms of service. Archived means you didn't log in for 60 days or more. Unarchived.

Deleted. Jenova, archived accounts can't be deleted by that script. It only deletes active accounts.

Well, virtualhosts are data, and I would consider the statement "filling up our server with useless data" would apply to virtualhosts as well as the files in your home directory. At one point we were so low on storage space that we were deleting accounts that had been inactive for only a couple weeks. We barely had enough space for the active accounts, but that was a few years ago.

Interestingly, the heliohost.com domain was registered 2 years before we existed, has never been used for anything, and has never been up for sale as far as we know. I suppose if they offered it to us at a reasonable price we would buy it because it is a common mistake that people put .com instead of .org.

We aren't heliohost.COM we're heliohost.ORG.

You main domain has been changed to http://thedragons.net/

Man, that would be amazing. We actually have unlimited bandwidth, and storage isn't really a concern either. What does matter is the number of virtualhosts on each server. Each domain that we host increases the virtualhost count by 2 (one for http and one for https), and that's the main source of load for small sites like yours. Each virtualhost increases the amount of memory that apache uses, and increases the downtime that we experience each time we restart apache. If we were to allow these virtualhosts to continue piling up from thousands and thousands of small, low traffic sites like yours it would eventually take several minutes of downtime to restart apache each time. A small downtime like 5-30 seconds is barely noticeable and most people just chalk it up to their internet being slow for a second, but if we have so many virtualhosts that each restart takes something ridiculous like 5 minutes people are definitely going to notice and complain. Larger hosting companies get around the virtualhost issue by creating many smaller servers to distribute the virtualhosts over dozens or hundreds of apache installs. Since we use cpanel it is very expensive to set up each additional server because of licensing costs, but we can maximize the number of sites we host by cramming as many people as we can onto our existing 3 servers. The monthly login requirement is in place, not to intentionally annoy people, but to keep our virtualhosts count as low as possible to keep our memory usage and restart time low. Now, as far as keeping your account active, plenty of other people do it just fine for years. We have one lady that has maintained an active account using the same free HelioHost domain since 2007. She logs in once every month just like everyone else for 14 years and counting. The guy that runs this independent monitoring site http://heliohost.grd.net.pl/monitor/ isn't a HelioHost admin, and isn't affiliated with us at all. His accounts that he uses to monitor our servers are identical to everyone else's and he has to log in every month to not just one, but three different accounts to keep them active. He's been running that server monitor since 2010. The only thing special about him is we have granted him permission to have more than one account at a time. There's dozens of other people who maintain active accounts for years on end too. Those are just two extreme examples. When you don't log in for 28 days you will receive an email reminder to login to prevent your account from going inactive, and you have 2 days to check your email and login. If you save your password in your browser you can simply click the link in the email, which brings you to the login page, and then click submit on your saved username and password on the website. How long does it take to click twice? 5 seconds? That's all it takes to keep an account active. Anyways, we get this request to not have to log in to cpanel all the time, and you seem like a person that would value equality. Maybe you think you're more important than everyone else, but based on your post it makes me think that equality is important to you. It wouldn't really be fair to everyone else to treat some people differently from everyone else. There's also the issue of if we make an exception for one person we'll probably have hundreds of other people come out of the woodwork asking for the same thing. So, since we get this request all the time we have come up with two solutions: You can donate instead of logging in. Each $5 you donate gets you +1000 MB storage up to a maximum of 5000 MB plus 1 month of inactivity immunity. The new server that we're going to set up hopefully in a few months will allow you to never have to log in to cpanel as long as your $1 subscription remains active. So option #1 probably doesn't appeal to you because you obviously don't need the storage space increase, and option #2 isn't available yet, but it might not appeal to you anyways since you want free. Anyways, I'm willing to give you a special option #3 that we haven't offered to anyone else yet. You can basically get the deal in option #2 early on Tommy instead of the new server. I don't want to do this for a lot of people because it would get confusing to keep track of everyone, but if you want to donate $1 for each month of inactivity immunity I'll grant it. So if you want to not have to login for the next year you can donate $12, etc. Eventually this deal will be offered to everyone on the new server so everyone is still being treated equally; you're just getting the deal earlier.

You're on Tommy now. Thanks for the donation.

We normally move donors to Tommy, but since we rebuilt Ricky recently a lot of the Ricky people moved to Tommy and Ricky is basically empty. Since Ricky is so empty and Tommy is a little overcrowded Ricky is currently the fastest server, but things are balancing out and eventually Tommy will be the fastest again. Do you want to move to Ricky for speed immediately, or do you want to move to Tommy for more speed in the long run? Since you're a donor you can move to Ricky for now, and then if that server ends up too slow for you after a few months or whatever just let us know and we can move you to Tommy.

Interesting. You're the only person who has reported this so it seems like it's specific to just your one database. Perhaps try backing up the database, dropping it, and recreating it?