badrihippo

I didn't understand how exactly the $_SESSION variables are getting overwritten. I thought if a new user joins, they would have their own set of $_SESSION variables which doesn't interfere with the first user's $_SESSION? Maybe you can try sharing the part of the code that updates the $_SESSION variables so I can see how it's working?

I think you might be disallowed from cd'ing into /usr/bin/perl since that is a system folder. /usr/bin/perl is the correct path for the system-wide perl installation. But looking at your tutorial, I think in your case you need to make your own perl folder for custom scripts (not /usr/bin/perl). The default path for your home folder is /home/YOUR_USERNAME. So for example if I want to access the perl folder at the top level of my file manager the path will be /home/hippo/perl (because my username is hippo). If your username is cyber then the path will be /home/cyber/perl. Try replacing /usr/bin/perl to /home/YOUR_USERNAME/perl in the above scripts (i.e. cd /home/YOUR_USERNAME/perl/usr, cd /home/YOUR_USERNAME/perl/GeoLiteCity, etc.)

If you're writing the HTML by hand, one possibility is that the page is only using ASCII characters and not the full UTF-8 character set. To fix that, make sure you have the meta tag <meta charset="utf-8"/> somewhere in the beginning of your HTML. If that doesn't work, maybe you can share the link of your website so I can take a look?

I saw a couple of questions regarding Rust on HelioHost. While it isn't officially supported, I did manage to get a simple Rust application running on Tommy! My method was based on the fact that you can upload Go binaries and run them according to this tutorial. Since a binary is a binary, why not deploy a Rust one the same way? The simple method: At its most basic level, a CGI script just has to return text along with headers. Consider the "Hello world" Perl script: #!/usr/bin/perl print "Content-Type: text/html\n\n"; print "Hello World!"; Based on this, I made the following Rust script, mini.rs: fn main () { print!("Content-type: text/html\n\n"); print!("Hello world!"); } Interlude: Experimentation (you can skip this italicised section unless you want the details) At first, I tried compiling this with a simple rustc mini.rs and uploading the resulting mini file to my cgi-bin. (I use Manjaro, which is Linux, so since HelioHost also uses Linux I didn't have to change the target architecture). However, that was resulting in a 500 Internal Server Error. To debug this, I tried running the compiled binary on a different VPS (running Debian, so it would have slightly older versions of libraries than Manjaro). I realised that the library glibc/libc6 wasn't matching. I found a related comment on this StackOverflow question suggesting using static linking as described in this other StackOverflow answer. I already had the dependencies, so all I had to do was add extra arguments to the compile process to make it: rustc -C target-feature=+crt-static mini.rs. This produced a statically linked binary which I could then run anywhere! To deploy the program to HelioHost, all I had to do was: Run the command to create a statically linked binary, rustc -C target-feature=+crt-static mini.rs (if you're not using Linux you'll have to also set up and specify the Linux architecture as a build target) Copy the resulting mini binary file (the one without the .rs extension) to my website's cgi-bin Set the permissions to 755 (rwxr-xr-x, in other words everyone has read and execute permissions and only the owner has write permissions) Navigate to my website's /cgi-bin/mini and the page rendered! I think a binary may not be necessary if you can compile using the same version of libc6 that's running on Tommy (assuming it has the libc6 library at all) The advanced method: Instead of returning plaintext, you can also use a library like rust-cgi to generate the output for you. I'm not sure how exactly it works since I'm not familiar with CGI but I'm guessing it will help do things like read header data? I followed the docs there to create an empty Cargo project and the following main.rs file: extern crate cgi; cgi::cgi_main! { |_request: cgi::Request| -> cgi::Response { cgi::html_response(200, "<html><title>My Site</title><body>Hello world!</body></html>") } } After this I ran cargo build with the modified flags to get a statically linked binary: RUSTFLAGS="-C target-feature=+crt-static" cargo build Basically, setting the RUSTFLAGS environment variable before running Cargo. If you're doing this often, you can also add the option to Cargo.toml: [build] rustflags = ["-C", "target-feature=+crt-static"] target = "x86_64-unknown-linux-gnu" ...and then simply run cargo build to get the binary. This created a larger binary than with the simple method; mine was around 8.1MB instead of 5.4MB. This is presumably because it has more features (that we aren't using right now) bundled from the library. But if you are using those features I'm guessing it'll be helpful. Uploading the resulting binary, target/debug/[your project name], to cgi-bin will make it get auto-executed whenever you load that URL. WARNING: MAKE SURE YOUR PROCESS ENDS! Most Rust web frameworks like axum, Actix, and Rocket fire up a permanently running web server listening on a given port. That will use up your CPU resources and probably push you over your limit—or, best case, cause your process to get killed after some timeout. Either way, it won't work! So make sure your process runs quickly, prints whatever it needs to, and then exits. It will repeat this for every request, just like the scripts for Perl, PHP, and other languages do. Unfortunately that means we can't use most Rust web frameworks, unless we figure out a way to make them work the CGI way (if you figure that out, please let me know!). Tip: Local testing To test your CGI scripts locally, you can go into any folder, create a folder named cgi-bin inside, and run the following command in the outer folder (i.e. not inside cgi-bin) python -m http.server --cgi This will fire up a local server (usually at localhost:8000), and anything you put in the cgi-bin folder (including Rust binaries) will execute the same way they would on an actual server.

Hi! These domains have always annoyed me. You can delete all the *.hippo.heliohost.org domains from my account, since I'm using custom domains anyway (sssnet.tk, and sometimes subdomains of snipettemag.com)

Thanks for the detailed breakdown! This makes a lot of sense; I didn't consider the "sharing/using it at the same time" aspect of it before. I just went back and re-read your original post too; there's quite an interplay between memory and storage here! First the storage was slow, so it was being offloaded to the memory to keep things running; now the memory is running out which means it may have to be swapped to the storage. Must be quite a balancing act to decide how much of which resources to upgrade. About the usage of CPU vs. memory, I can see that play out for myself too: most of the processes I have running there don't consume much CPU except for short periods while working, but the memory usage is constant.

Oh, so it's more of a "we have less of it so use it sparingly" thing than a "that's just how much it costs" thing?

Hi! In case this is helpful, I recently made successful payments with my international debit card. Putting notes here for reference, both for myself and if it helps you. TL;DR: Braintree might be worth a shot? (They're owned by PayPal, so whatever data you're giving them, they already have). In the past few months, I've made payments from India at the following places: GoFundMe - gofundme.com Kobo US - us.kobobooks.com Mozilla - donate.mozilla.org Mailgun - a bill from mailgun.com Note that this was with an international debit card. Local debit cards won't work, but at least my international one worked flawlessly. (It's still at a roadblock with Stripe and PayPal). I tried to figure out what payment gateways they used for collecting my card details, and here's what I got: I couldn't make out what GoFundMe uses; in their privacy policy they say they use different processor depending on the country Kobo was similarly opaque but IIRC they use Citrus Pay (I placed an order with them yesterday) Mozilla uses Braintree (a PayPal company but evidently with better payment processing than PayPal itself) Mailgun uses something called "chargifypay.com", but when I try to load that page it redirects me to a complicated billing/SaaS provider called Maxio. Looks like there was a separate billing management service called Chargify that has now been bought over. I was hoping for more details but that's unfortunately all I could find. If it's worth it, let me know and maybe I'll have a shot at writing to those companies and asking them directly what payment processor they use.

By the way, I've noticed the price jump is significantly more when upgrading RAM than it is for storage or even CPU upgrades. Is this because CPUs scale better but RAM has to be added linearly each time, or something? (Just trying to understand how this works; it's a pattern I've noticed in other hosting providers too)

It was an fsck issue; Krydos is resolving it on Discord. Not directly related to the DDoS though it could have been triggered by it! Thanks Krydos, and mods please mark this topic closed

Thanks for the heads-up! I'll run an analysis and see how much RAM my server is using; my guess is my team will choose to keep it for the upgraded amount since we can afford it at least for now.

I just read something about a DDoS attack on Discord. I guess that's what must have triggered all this. Take your time then; I'll check back in a few hours and see if things have stabilised. To add more information: when I try to SSH in I get the error, ssh: connect to host members.snipettemag.com port [REDACTED]: Network is unreachable curl on the other hand seems to be trying and then timing out, curl: (7) Failed to connect to members.snipettemag.com port 80 after 394 ms: Connection refused So (from my limited knowledge) I guess it could be some kind of DDoS-triggered network failure?

Hi, I woke up this morning to find that my VPS had a "read-only filesystem". I tried rebooting (shutdown -r now) to see if it solved the issue, but now it's gone mostly unresponsive: I can ping it, but can't load pages or SSH in. Could you check the status and restore the system? Domain: members.snipettemag.com (or hippo2.heliohost.org) IP address: 64.71.156.101 I'm using a custom SSH port which I don't want to post in public; if you let me know where to send it I can give it to you. I see other people have had similar problems (and I have, too, once) so I'm guessing this is a quick thing to solve? I don't remember what exactly happened last time, but I think it was essentially running fsck and then booting again. There are a few services to be started after boot, but if you get it to where I can SSH in, I can take it from there. Thanks, Badri

Oh, that was weird! Well, thanks for solving it 😁

I've been logging into my account to keep the site active, but I might have missed a date or logged in at the wrong place. When I load my website (sssnet.tk) it shows an "Ahoy there" queued account message. The HTTPS version of the site shows an "SSL not set up properly" message instead. The confusing part is that my main domain, hippo.heliohost.org doesn't show any of these errors. Instead, it show Apache's "Testing 123" landing page, which makes sense because I haven't really placed anything on the main domain. I tried logging into Plesk, and that happened smoothly with no indication of a deactivated account. However, when I tried to renew the SSL certificate for sssnet.tk, it was unable to do so, because .well-known/... is also being redirected to the same generic page. Could you reactivate my account, if that's what the problem is? And if not, perhaps something else is wrong in the setup?