Krydos

I had a similar experience with my krydos.tk domain. I've never really hosted anything there. It's just said "Blank." like that for like six years now, but out of nowhere they yanked it out of my control and put a bunch of like porn spam ads and stuff on whomever might type in my domain. When I logged in to the control panel it said that my domain was too active for a free domain or something, and they needed to charge me $20 USD a year to keep it. Eventually they gave up trying to scam me out of money because I just ignored them, and (unlike wolstech) I was able to just edit all the references to krydos.tk there were in the world and change them all to krydos.heliohost.org. Then when they were done trying to extort me I registered krydos.tk for free again a few months later. THEN! (as if that wasn't enough already.) They flagged my whole freenom account as suspicious or a hacker or a bot or something. They never would tell me what the problem was exactly, and said I could never have my account back. Ok... So I created a new account and registered krydos.tk on the new one. It's just all really bizarre. Not worth the effort. Also, I've apparently earned myself 26.5 years of free domains. Yay!

There is no SSL certificate installed on your account. You can install it by selecting your domain, copying the certificate, the private key, and the chain file to https://tommy.heliohost.org:2083/frontend/paper_lantern/ssl/install.html and then click install certificate. If you wish you can PM me those three text blocks and I can install it for you. I never check my PMs though so make sure you post in this thread if you do decide to PM me so I can know to check my PM box. This tutorial is for installing a free Let's Encrypt certificate but it may help you too http://wiki.helionet.org/Installing_an_SSL_Certificate_on_Tommy_with_ZeroSSL

Awesome! Just let me know your wiki username, and I'll get you promoted.

You can change your own url with this script http://www.heliohost.org/classic/support/scripts/domain

If you tell us the actual domain we could check the settings for you and verify that they are correct.

display_errors = On for all versions of php on Tommy now. Here is an example file where the line is missing a semicolon http://krydos.heliohost.org/error.php How does that look? I opened the file with vim, and it says the encoding type along the bottom of the screen. It caught my eye because when a file has standard linux encoding it doesn't show anything there. This is actually a really common reason for cgi executables to cause 500 errors, but it rarely makes a difference with php scripts. As you could see the php still executed, but threw header already sent errors. To fix the encoding I just copied the code from the broken file, deleted the broken file, created a new file with the same name in vim and pasted the code back in. I think your real question isn't how did I do it, but rather how can you do it though so it doesn't happen again in the future right? I would recommend creating the file through cpanel file manager and then copy/pasting the code in if you think you might be having encoding issues. root@tommy [/home/hypo/public_html]# file -i * cgi-bin: inode/directory; charset=binary count: application/octet-stream css: inode/directory; charset=binary cus.txt: text/plain; charset=us-ascii error_log: text/plain; charset=us-ascii images: inode/directory; charset=binary indexgood.php: text/x-php; charset=us-ascii index.php: text/x-php; charset=us-ascii js: inode/directory; charset=binary listenerold.php: text/x-php; charset=us-ascii listener.php: text/x-php; charset=us-ascii paypal_success.php: text/html; charset=us-ascii resp.txt: text/plain; charset=us-ascii I'm not sure because I already deleted the broken file, but I believe it was octet-stream just like your count file.

Changed back.

It works now http://hypo.heliohost.org/ The problem was your file encoding was screwed up, and php kept reporting that the headers had already been sent due to the file encoding being wrong for linux.

Your username was already in use on these forums. Since I renamed your forum account the username maicol07 is now available to create a new account.

Can't you just change the error reporting level in the script if you need it? I've always just looked in the error_log file myself. The settings that we have now are just the default settings that cPanel installs PHP with.

How did you install Joomla? Softaculous? From source?

The username is the same as your forum username, and the email address is d******e@yahoo.co.uk

Tommy uses the same nameservers (ns1.heliohost.org and ns2.heliohost.org) as Stevie did so you probably won't need to change anything at all. Just add them to your new account and they should start working. There is a backup at https://www.heliohost.org/backup/ for you, but it's only 180k so I don't know how much might be in there for you. Let us know if you need help accessing it.

Set the nameservers of the domain to ns1.heliohost.org and ns2.heliohost.org and try adding the domain again.

Thanks! Looks good. We're actually going to get Stevie running again possibly as early as Monday. We'll see how it goes.

I made a php script with your code and it gives me the same session ID on Tommy over and over even without https: <?php session_start(); echo session_id(); http://krydos.heliohost.org/session/ Perhaps something is going on with your browser? Incognito mode? What happens when you try a different browser?

Yeah, no problem. We all would appreciate it if you could create a wiki account at http://wiki.helionet.org/ and create a tutorial for people to do what you have just done. This would be especially useful for people if you use windows on your home pc since most people use that os. I find it makes more sense to people from the point of view of another user such as yourself. You could use http://wiki.helionet.org/Java_Servlet http://wiki.helionet.org/Installing_an_SSL_Certificate_on_Tommy_with_ZeroSSL or http://wiki.helionet.org/Running_Auto_Backups as templates.

Oh yeah, one other thing. The command django-admin startproject command creates your settings.py file with ALLOWED_HOSTS = [] Django on Tommy will report an error unless you specify your domain or use a wildcard there. ALLOWED_HOSTS = ['*'] Specifying an exact domain will be more secure, but for the future people who may read this the * will work for all of your websites.

Yeah, of course you can. The reason I did a structure like I did is because I started with our old djangotest.zip file which was originally created with like django 1.2 or something ancient, and adapted it to work with the newest django 1.10 that I installed. I'm guessing that's how the django-admin startproject command did things back then, but you're right that command has a very different structure in the latest version. Using python 3.6 and django 1.10 on my home computer I created a project called hello which looks like this /hello/ /db.sqlite3 /manage.py /hello/ /__init__.py /wsgi.py /settings.py /urls.py Obviously it doesn't work, as you found out already, if you just upload it like that. So we need to make a few changes. The most important things are the .htaccess to force django to process the files, and the .wsgi file that ties it all together. So on the server it looks like this so far: /public_html/ /db.sqlite3 /.htaccess /hello/ /__init__.py /dispatch.wsgi <----- simply wsgi.py renamed /settings.py /urls.py And the code for the .htaccess is this RewriteEngine On RewriteBase / RewriteRule ^(media/.*)$ - [L] RewriteRule ^(admin_media/.*)$ - [L] RewriteRule ^(hello/dispatch\.wsgi/.*)$ - [L] RewriteRule ^(.*)$ hello/dispatch.wsgi/$1 [QSA,PT,L] Obviously, the last two lines replace "hello" with whatever the name of your project is. This still won't work though because the wsgi.py/dispatch.wsgi file doesn't have the paths correct for running on the production server yet. Here is what django-admin created import os from django.core.wsgi import get_wsgi_application os.environ.setdefault("DJANGO_SETTINGS_MODULE", "hello.settings") application = get_wsgi_application() This is what I changed it to which works both locally and on Tommy import os, sys # edit your username below sys.path.append("/home/krydos1/public_html") from django.core.wsgi import get_wsgi_application os.environ['DJANGO_SETTINGS_MODULE'] = 'hello.settings' application = get_wsgi_application() Now, when you make a change to wsgi.py locally also copy it to dispatch.wsgi before you upload it. Here is my test case with the django project running on the root of the domain (instead of in a folder like on my main account). http://krydos1.heliohost.org/

Mono is installed for SSL now too https://www.laparcela.tk/aspa/index.aspx

Well, I made some progress on it, but now it looks like it's having some path related issues: http://sest.gq/ At least it's throwing helpful errors now instead of useless 500 errors.

@byron that was the reason /home/albertoc/public_html/djangotest/.htaccess was throwing a 500 error yesterday. He has fixed that and I was explaining why /home/albertoc/public_html/.htaccess was throwing a 500 error today which is the file you renamed. @albertoc there are a couple things going on here. First of all manage.py is pointless to upload since you don't have shell access so you may as well delete that to reduce the chance of security holes. Second since this isn't a dedicated django server the structure of your application is going to need to be a little different. On a dedicated django server like your application is set up to run on everything other than the media directory would be processed through mod_wsgi, but this is a shared server and the hundreds of other people sharing the server with you don't want the performance hit of everything being processed twice like that. The .htaccess rules is how you specify that you want things to be processed through your dispatch.wsgi file. In your application this is called wsgi.py, but it won't run like that because not all .py files on the server necessarily have to be django files. I have it set up so everything with the extension .wsgi is processed as django. Any other extension will not be processed through mod_wsgi. This is the key to tying the whole thing together. Simply renaming that file and setting up the proper rules in .htaccess so everything is processed correctly through the .wsgi file should be enough to get you going. I messed around with your files for a bit, but I can't get it working either and I've run out of time for now. I'll be back to fiddle with it some more later.

@byron, What the .htaccess file does on a django site in this example is force everything (other than static files in the media folder) to be processed through dispatch.wsgi. That's what ties the whole thing together as django rather than seperate html files etc. If the django site itself has a 500 error renaming the .htaccess just makes the django not process at all. @albertoc, the 500 error is because (as I explained about) /home/albertoc/public_html/.htaccess is trying to send all requested to be processed by /home/albertoc/public_html/dispatch.wsgi but that file doesn't exist.

It's not possible, but other people have requested it too https://features.cpanel.net/topic/multiple-cpanel-logins-cpanel-subusers Depending on what you need your subuser to be able to do you could just create them an FTP account so they can access or modify the files on your site. You can even set it up so one account only has access to one domain and another account only has access to another domain if you're account has more than one website on it.

You should have access to edit the wiki now. Let us know if you have any questions or would like us to review your changes and additions.