wolstech

lfd: Failed POP3 login Your mail client is configured incorrectly. Unblocked (it may take a few minutes to unblock).

Processes for none1632 have been terminated. This tutorial on building a Discord bot talks about starting/stopping long-running Python scripts: https://wiki.helionet.org/tutorials/discord-bot#how-to-get-started-with-a-discord-bot You should be able to adapt the start.py and stop.py from that to your application

Try signing in here: https://johnny.heliohost.org:2083/ I will say that load and performance issues are normal for Johnny though. That server is meant for experimenting and testing, not actually hosting a stable website, so it sacrifices stability and uptime to let more users have an account and the flexibility to run what they want. If you're to the point where you need to host a production website that works like you'd expect (i.e. is reliable and up all the time), you should move to Tommy. That server is intended for production use, and we much more tightly control load on Tommy to ensure it has good uptime. To give an idea, for the past few days, uptime for each server: Tommy: 100%Ricky: 99.27% (but really slow)Johnny: 96.2%

That account is not suspended. It's working fine when I open it.

Weird. cPanel is supposed to make sure the domain has an NS record = NS1.heliohost.org and NS2.heliohost.org before allowing an addon or alias domain. By design, this is not supposed to work. The fact it did is kind of odd. I thought maybe someone had turned on the allow remote domain option, but nope. I have no idea why this worked...

@Bailey: He can't. His attempt to add that will fail with a nameserver error because we don't support CNAME/A records for alias/addon domains. The only ways to make that domain work here is to use it as the main domain.

It is indeed a weird behavior. In the past we've tried setting up a specific page that's supposed to be shown for this, but it has never really proved reliable due to how cpanel works...

The weird page is because you're forcing SSL on a domain that doesn't have a certificate installed. When you do that, the server will serve the content of a random domain that has SSL installed (typically it'll be a random user's website, your domain just got lucky and the user's website looks like it could be from us). It fixes itself once AutoSSL runs and a certificate gets set up. I just manually ran AutoSSL for you so you can skip the 24 hour wait. Give it another few hours for the certs to install and Apache to restart again and it will work properly. You may need to clear your cache once its working in order to see it. 8:28:15 PM This system has AutoSSL set to use “cPanel (powered by Comodo)”. 8:28:15 PM Checking websites for “esn024” … 8:28:17 PM The website “thebrooksreflections.thebrooksreflections.heliohost.org”, owned by “esn024”, has no SSL certificate. AutoSSL will attempt to obtain a new certificate and install it. 8:28:19 PM The system will attempt to renew SSL certificates for the following websites: 8:28:19 PM thebrooksreflections.thebrooksreflections.heliohost.org (thebrooksreflections.com www.thebrooksreflections.com mail.thebrooksreflections.com webmail.thebrooksreflections.com cpanel.thebrooksreflections.com webdisk.thebrooksreflections.com thebrooksreflections.thebrooksreflections.heliohost.org www.thebrooksreflections.thebrooksreflections.heliohost.org) 8:28:42 PM The system has completed the AutoSSL check for “esn024”.

Changes can take several hours to take effect (Apache needs to restart).

Unpinning and locking due to being obsolete. Bailey, can you make a replacement post? I'll pin the replacement.

Unarchived.

It appears to be an issue with WinSCP. Specifically, accounts that use password-based authentication don't seem to work in WinSCP: I could not get any of the Tommy accounts I have passwords for to log in successfully using a password on WinSCP (even root failed with the password, but it worked fine when I used my SSH key...). Those same accounts that failed in WinSCP work just fine with a password if I use Filezilla's SFTP.

I changed it to the .heliohost.us one already, you're fine (it takes like 30 seconds to change it in WHM).

Changed. It may take an hour or two start working, and SSL may take up to 24 hours. The main domain change tool does not work reliably for the .us subdomains which is why you're having trouble. It's a known issue.

If you had users who maintained a specific portion of a website for instance and needed access to only some portion of your account. They're not used very often.

For SFTP, you can only use the cPanel username and password. The "extra FTP accounts" options only work for plain unencrypted FTP on port 21.

Unarchived.

Pretty much. Once I removed the expired one it went out and got the new one when I ran it. It won't replace a third party certificate (even if it's expired or otherwise invalid), so it kept ignoring your main domain until I removed the expired cert.

It was refusing because the expired certificate was not from AutoSSL. AutoSSL automatically ignores any domain that has a certificate from an outside source. I deleted that expired cert and manually ran it for you: 1:58:45 PM AutoSSL’s configured provider is “cPanel (powered by Sectigo)”. This AutoSSL provider does not poll for certificate availability immediately after a certificate request submission. Instead, it submits certificate requests then periodically polls the cPanel Store for each requested certificate and installs it after a successful retrieval. The system will record all requests, retrievals, and installations for the current AutoSSL run in this log. Analyzing “trenten”’s domains … 1:58:45 PM Analyzing “chy.trenten.heliohost.org” … 1:58:45 PM SUCCESS TLS Status: OK Certificate expiry: 3/29/21, 12:00 AM UTC (82.21 days from now) 1:58:45 PM Analyzing “destiny.trenten.heliohost.org” … 1:58:45 PM SUCCESS TLS Status: OK Certificate expiry: 1/26/21, 12:00 AM UTC (20.21 days from now) 1:58:45 PM Analyzing “trenten.heliohost.org” … 1:58:45 PM ERROR TLS Status: Defective ERROR Defect: NO_SSL: No SSL certificate is installed. 1:58:45 PM Attempting to ensure the existence of necessary CAA records … 1:59:25 PM No CAA records were created. 1:59:25 PM Verifying “cPanel (powered by Sectigo)”’s authorization on domains via DNS CAA records … 1:59:27 PM “cPanel (powered by Sectigo)” is authorized to issue certificates for all domains. 1:59:27 PM Performing HTTP DCV (Domain Control Validation) on 6 domains … 1:59:27 PM Local HTTP DCV OK: trenten.heliohost.org Local HTTP DCV OK: www.trenten.heliohost.org (via trenten.heliohost.org) Local HTTP DCV OK: mail.trenten.heliohost.org (via trenten.heliohost.org) Local HTTP DCV OK: cpanel.trenten.heliohost.org (via trenten.heliohost.org) Local HTTP DCV OK: webdisk.trenten.heliohost.org (via trenten.heliohost.org) Local HTTP DCV OK: webmail.trenten.heliohost.org (via trenten.heliohost.org) 1:59:27 PM No local DNS DCV is necessary. 1:59:27 PM Processing “trenten”’s local DCV results … 1:59:27 PM Analyzing “trenten.heliohost.org”’s DCV results … 1:59:27 PM AutoSSL will request a new certificate. 1:59:27 PM The system will attempt to renew the SSL certificate for the website (trenten.heliohost.org: trenten.heliohost.org www.trenten.heliohost.org mail.trenten.heliohost.org webmail.trenten.heliohost.org cpanel.trenten.heliohost.org webdisk.trenten.heliohost.org). 1:59:30 PM The cPanel Store received “trenten.heliohost.org”’s certificate order. (Order Item ID: 1089874177) The system will periodically poll the cPanel Store for the issued certificate and then install it after a successful retrieval. The system has completed “trenten”’s AutoSSL check. Give it a few hours and it should work.

Unarchived.

Unarchiving.

Krydos will need to answer that. I don't know Django. I looked at your .py files and don't see any other than manage.py that have a shebang line, but then, Django works differently too so it may not even have one like a normal .py script that I'd use in cgi-bin...

I updated my previous post for some common issues, but you may need to wait for Krydos to figure this out. EDIT: Looking at manage.py, you're using /usr/bin/env, which does not work here since it points to the wrong version of Python (2.7, which doesn't support Django). You need to specifically use /usr/bin/python3.7

Krydos is the only one who knows anything about Django. Very few people here use it. Normally I'd suggest trying to get the example on this page to work, but I'm not sure if it's still relevant since it was for an old version of Django: https://wiki.helionet.org/tutorials/django 500 error is usually something simple though, .htaccess syntax errors or a bad shebang line are fairly common. Note that you have to use this path to python in your shebang line in order for Django to work on Johnny: /usr/bin/python3.7 Plain /usr/bin/python won't work, nor will the env tool (points to wrong version of Python)

Let's see if Krydos can fix this for you. I'm not sure how quickly it will get done though, it sometimes take him a day or so to respond.