Krydos

Make sure you're receiving our emails. They come from no-reply@heliohost.org. You should receive a warning a couple days before your account goes inactive, and then another email when your website is taken offline.

I had another idea. You could make a loading page that would load instantly, and then check if ghost is running. Then if ghost is running redirect automatically. If ghost isn't running or gives a 503 error it just waits a second and tries again until ghost is functional, and then it redirects. Here's a quick example: <?php $url = "https://ghost.krydos.heliohost.org/"; $msg = "Loading ghost..."; if ($_GET['retry'] == "") { echo "$msg<meta http-equiv='refresh' content='0;url=?retry=yes' />"; exit; } $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE); curl_setopt($ch, CURLOPT_TIMEOUT, 10000); $f = curl_exec($ch); $h = curl_getinfo($ch); curl_close($ch); $status = $h['http_code']; if ($status == "200") { header("Location: $url"); exit; } else { echo "$msg<meta http-equiv='refresh' content='1;url=?retry=yes' />"; exit; } You can test it out at https://krydos.heliohost.org/ghost/ which redirects to ghost at ghost.krydos.heliohost.org Obviously if you're using this code on a production website you'd want to style it and make it a little prettier... haha. Also meta refreshes are kind of a dirty hack and are frowned upon and you shouldn't use them, but they still work. A better page refresh option would be javascript. Also this page the way it's written will just try again and again and again over and over forever, which could cause load problems if ghost wouldn't start and someone left this page open refreshing over and over all day. So it would be wise to implement a counter and after the page refreshes like 5 times, just give up and display an error message. Like I said, it's a quick example.

I just opened my ghost install in a browser https://krydos.heliohost.org/ghost/ and it took like 15 seconds, but it didn't show a 503. Maybe they changed the behavior in the newer version that I installed? EDIT: Nevermind, I guess it was a fluke. I killed the ghost process and tried loading it again and it gave the 503 this time.

An external cron that we set up is going to cause just as much load as an external cron from any other site. The way passenger works is this. Node applications take a lot of memory when they're running, but they only need to run when someone is actually looking at the website. The first time you request a node page it takes a second or two to load, and once the node app is running it responds quickly. After 5 minutes or so of no page hits passenger wisely unloads your node app from memory which helps keep your account and the whole server's load low. This is by design. The problem with ghost is it stupidly says 503 when it's loading instead of just taking a second longer to load like a normal node app and then showing the home page. People have asked ghost to change this behavior and they have stupidly refused. Obviously you've discovered that to avoid that 503 error you just keep ghost from unloading from memory by setting up a cron or site monitor to ping your website every once in a while. This is why you're getting suspended. Your ghost page is never unloading from memory. Your sitemonitor or cron or whatever is causing so much load that you're getting suspended. It doesn't matter if the page request comes from our servers or someone else's server. The solution to your high load is to just let passenger do it's thing and unload your ghost when it's not being viewed. The other option is of course you could also get a vps and then your ghost app could run constantly and you wouldn't even need a cron or sitemonitor to keep the 503's away. https://www.heliohost.org/vps/ Another option is you could edit the ghost code to not display the 503 error somehow.

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

Does your script have some sort of exit condition, or should it run forever? EDIT: Why don't you try this:

The data cannot be recovered because a hacker had access to your account and was using it for illegal phishing activity. There could be stolen information in your files, and giving you the data could essentially be giving you credit card numbers, etc. All the data is being held as evidence for law enforcement. This happens all the time with wordpress. The best solution is to not use wordpress.

Remote access enabled.

I can see your cronjob now, and it looks right. We'll find out if it works in 8 hours and 15 minutes I guess.

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

I guess we'll wait for the tutorial link?

503 means your script on port 4000 isn't running. Also, you only need to do 'RewriteEngine On' once at the very top of the .htaccess. Doing it over and over won't cause an error, but it looks kind of silly. I checked your cron jobs, and I don't see anything listed. Did you delete it?

Which version of python are you using?

We have an account on Tommy that did 47 GB of traffic last month. That's more than 100 times as much traffic as you got. Here is your load graph for the last week: You definitely don't need to worry about overloading Tommy.

Trying to block certain IPs or trying to block certain bots just makes you look guilty of something. I wouldn't be surprised if legitimate crawlers like google down ranked you for doing suspicious stuff like that. Maybe link to the article you found and we can read it ourselves?

See how there is no / at the front? Without that leading / it tries to look for a directory called home in it's present working directory. To be an absolute path it needs the / at the start.

Maybe I should contact Invision and see if we still qualify for the renew price of $25 per 6 months. https://invisioncommunity.com/buy/self-hosted/ We could honestly just do the same thing as last time: Pay the renewal fee once, download and install the latest version, and then let the license lapse again. All you lose out on with an expired license is new version downloads and Invision support.

You could try editing /home/roguitar/public_html/chat/server/websocket_server.php on line 9 and change ../vendor/autoload.php to the full path /home/roguitar/...etc The other option is you could edit the cron command to change to the correct directory first. The command would be something like this then: cd /home/roguitar/public_html/chat/server/ && /usr/local/bin/ea-php72 /home/roguitar/public_html/chat/server/websocket_server.php

Theme set to desktop.

Same thing that was already posted. As some feedback to this link though, I tested it out and it works. It's definitely more complicated than zerossl was though. Oddly enough though, I tried doing a zerossl certificate after their major site redesign and I couldn't get it to work. I don't know if their site was broken when I was trying, or if I'm a special kind of dumb that can figure out a command line tool with 100 cryptic flags, but I can't figure out a simple web based gui. I don't know. Here's an example of the command I ran: le64.exe -email "admin@krydos.heliohost.org" -key account.key -csr krydos.csr -csr-key krydos.key -crt krydos.crt -domains "krydos.heliohost.org" -generate-missing --handle-as dns --live The krydos.csr and krydos.key files can be generated in cpanel by going to https://johnny.heliohost.org:2083/frontend/paper_lantern/ssl/csrs.html The link is for Johnny because Tommy and Ricky have autossl so you shouldn't need to do this.When you generate your krydos.csr and krydos.key files the CSR page will also create a .crt file that you apparently don't need for anything. So that can be kind of confusing I guess.The krydos.crt file listed above is generated by the le64 program, not the cpanel CSR page.Only run the command without --live at the end to test a few times, and when you're confident it's working right add --live to make the real certificate. Running it with the --live flag too many times would hit LE's really low rate limit and you'd have to wait some time to try again.I did my tests with DNS validation, but it's probably easier for most people to place a .well-known/acme-challenge file which is the default, so remove that flag too if you want otherwise you have to create a TXT record on your domain.The account.key I already had from previous Let's Encrypt SSL certificates. Not sure how you would generate a new one, if someone can chime in and explain that it'd be great.If the program runs correctly it will create the krydos.crt file, and then you go to https://johnny.heliohost.org:2083/frontend/paper_lantern/ssl/install.html to install the krydos.key file that you created when you made your krydos.csr, and the krydos.crt file that this le64 program made. That confused me for a minute because I assumed the program would output a new .key file for some reason.

Cron is the simpler way to start your socket script, but it can also cause you issues. You're only allowed to do 2 cron executions per day, so if you waste them both debugging then you need to wait until the next day to try again. Running cron 3 or more times could result in your account being suspended.People have a tendency to use cron to start scripts, and then they don't know how to stop the script and the poorly written script runs amok on the server causing massive load and the account ends up suspended for it.If you want to try cron anyways knowing the risks, your command would be something like this /usr/local/bin/ea-php72 /home/roguitar/public_html/chat/server/websocket_server.php First set the cron execution to ONCE A DAY, and then since the server runs on UTC look at this https://www.google.com/search?q=what+time+is+it+utc and set the hour and minute fields to be a few minutes in the future. To stop all of your scripts you can run a cron like this killall -u roguitar and set it for a few minutes in the future as well. So one start and one stop and you're done for the day on cron jobs, so make them count. The count resets at midnight UTC so I guess you could run one at 23:58, 23:59, 00:00, and 00:01 and be fine, but if you kept that going you'd be suspended. The better way to do this is to use cgi to start and stop your script. I'm not going to copy/paste everything here from the wiki, but take a look at https://wiki.helionet.org/tutorials/discord-bot#starting-and-stopping-your-bot The same idea can be used to start and stop a php socket script as well.

Suspended accounts do still cause a little load, but only like 1% of the load they would cause unsuspended. Still if someone on our servers gets the reddit hug of death suspending the account will help some, but not enough. The few times that this has happened I've actually had to delete the offending account's dns records, and after a few hours when the cached A records dropped off the internet the load finally came down to allow the other thousands of domains on the server to return to normal. The moral of the story, if your site is going to make it to the front page you should probably be using a VPS, not shared hosting. Even paid shared hosting would probably suspend you to get everyone else's sites back online. The chart updates once an hour, and the days are broken up based on 00:00 UTC. So at 01:00 UTC your current day's bars will show your load for the last hour, at 02:00 UTC your current day's bars will show your load for the last 2 hours, and so on. I've gone to great lengths, and spent a lot of time developing this load system to be as fair as possible. A lot of other hosting companies just suspend you if you go over X amount of memory used. This is silly though because if the server is fine, and everyone else's accounts are still online and fine why does it matter if one account crosses an imaginary line? Our system a popular account can sometimes cause massive load that any other hosting company would suspend for sure, and be fine. The downside to our system is it tends to cause some confusion because people have a good day like that with, just making up some numbers to illustrate my point, say 5000 people viewing their site or whatever and don't get suspended. Then they have another day where only 4000 people visit their site and they get suspended for it, but the second day with less views happens to coincide with 15 other accounts also getting 3000 page views causing the whole server to get overloaded and performance to drop for everyone. The first account is still causing the most load on the server with 4000 views, but they might not understand the bigger picture of the whole server. The reason I got upset is because our system can be a little confusing for users, I totally understand that, and your comments are just making it even more confusing to people, and making it seem even more unfair. Does that make sense now?

There you go https://krydos1.heliohost.org/cgi-bin/modules36.py

Pick a port that isn't already in use, like 4000, and use cgi or cron to start your script running listening on that port. Then use something like this to redirect requests to that port RewriteEngine on RewriteRule ^socket/(.*)$ http://127.0.0.1:4000/$1 [P,QSA,L] Then if you go to olimppius.heliohost.org apache will handle the html/php, but if your requests go to olimppius.heliohost.org/socket/(.*) it will be proxied to the internal port 4000 where your script is listening. Please be aware that port 4000 will not be accessible directly. For example olimppius.heliohost.org:4000 will just time out because the firewall will block it, but the firewall won't block internal ports between apache and your script.