Difference between revisions of "Shells websites"
imported>Wikiadmin m |
imported>Wikiadmin (→Web proxies) |
||
| (16 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
You can run a website from your shell account. | You can run a website from your shell account. | ||
Simply place the html and/or php files in your public_html directory. | Simply place the html and/or php files in your public_html directory. | ||
| − | |||
Your website will be visible at the subdomain yourusername.insomnia247.nl. For historical support insomnia247.nl/~yourusername is redirected to your subdomain. | Your website will be visible at the subdomain yourusername.insomnia247.nl. For historical support insomnia247.nl/~yourusername is redirected to your subdomain. | ||
| − | |||
==Web proxies== | ==Web proxies== | ||
| Line 11: | Line 9: | ||
This also goes for any other material that can give anonymous users access to your resources.<br /> | This also goes for any other material that can give anonymous users access to your resources.<br /> | ||
Any copyrighted or illegal material hosted on your public site will result in automatic suspension of your account. | Any copyrighted or illegal material hosted on your public site will result in automatic suspension of your account. | ||
| − | |||
==CGI== | ==CGI== | ||
| Line 17: | Line 14: | ||
| − | ==MySQL== | + | ==MySQL/monogdb/Postgres== |
| − | + | Databases are available on request. The 'manager' command will do this. | |
| − | |||
==Rails== | ==Rails== | ||
| Line 27: | Line 23: | ||
cd testblog | cd testblog | ||
bundle install | bundle install | ||
| − | rails server -p | + | rails server -p 5040 |
| − | From here on you can continue with things like generating controllers and writing your app as normal. | + | From here on you can continue with things like generating controllers/routes and writing your app as normal. |
| + | |||
| + | If you require gems that are not globally installed consider using something like: | ||
| + | bundle install --path=$HOME/.local-gems | ||
| + | Don't forget to add this directory to your GEM_HOME and PATH. | ||
| + | export GEM_HOME="$HOME/.local-gems" | ||
| + | export PATH="$PATH:$GEM_HOME" | ||
| + | Add these lines to your ~/.bash_profile or the start of your rails boot script to ensure your local gems are found. | ||
| + | |||
| + | If you want to run your rails app trough mod_passenger ask our staff to configure this for your subdomain. | ||
==Permissions== | ==Permissions== | ||
Your Apache processes and all child processes of Apache like php and cgi etc. run as a separate user that is dedicated to your website.<br /> | Your Apache processes and all child processes of Apache like php and cgi etc. run as a separate user that is dedicated to your website.<br /> | ||
| − | This user is named [your-username]-www. So it can access the files in your public_html directory you and your www user are in the same group. This group is exclusive to your account so no Apache processes from other users have permission to read your files.<br /> | + | This user is named [your-username]-www. So it can access the files in your public_html directory you and your www-user are in the same group. This group is exclusive to your account so no Apache processes from other users have permission to read your files.<br /> |
===Security=== | ===Security=== | ||
| − | The practical upshot of having a separate www user is that you can now deny your Apache processes access to any files that you want to keep from being available over HTTP. (SSH keys are a good example of files where you might want such protection.)<br /> | + | The practical upshot of having a separate www-user is that you can now deny your Apache processes access to any files that you want to keep from being available over HTTP. (SSH keys are a good example of files where you might want such protection.)<br /> |
Since the Apache process accesses your files through group permissions all you have to do in order to keep them from being accessible to Apache is revoke group access on them. (Hint: If you don't know how to manage file permissions read up on how to use the chmod command.)<br /> | Since the Apache process accesses your files through group permissions all you have to do in order to keep them from being accessible to Apache is revoke group access on them. (Hint: If you don't know how to manage file permissions read up on how to use the chmod command.)<br /> | ||
Having this type of permission system will prevent any sensitive or security critical files you have from being exposed trough something like an LFI bug in your php. | Having this type of permission system will prevent any sensitive or security critical files you have from being exposed trough something like an LFI bug in your php. | ||
===suwww=== | ===suwww=== | ||
| − | There is a slight practical drawback to having the Apache process run as another user. Often when php processes create new files they will be created without group write permissions. This means that they are owned by your www user and you cannot easily delete them.<br /> | + | There is a slight practical drawback to having the Apache process run as another user. Often when php processes create new files they will be created without group write permissions. This means that they are owned by your www-user and you cannot easily delete them.<br /> |
| − | To remedy this we have introduced the '''suwww''' command. If you run this command from your shell you will be logged into your www users account giving you full permissions on any files your Apache user has created.<br /> | + | To remedy this we have introduced the '''suwww''' command. If you run this command from your shell you will be logged into your www-users account giving you full permissions on any files your Apache user has created.<br /> |
You can also use the suwww command to check and verify if your Apache user indeed does not have access to files you don't want it to. | You can also use the suwww command to check and verify if your Apache user indeed does not have access to files you don't want it to. | ||
Latest revision as of 09:21, 18 October 2015
Contents
General
You can run a website from your shell account. Simply place the html and/or php files in your public_html directory.
Your website will be visible at the subdomain yourusername.insomnia247.nl. For historical support insomnia247.nl/~yourusername is redirected to your subdomain.
Web proxies
If you want to run a web proxy or a php shell you are allowed to do so only under the condition that you password protect it.
This also goes for any other material that can give anonymous users access to your resources.
Any copyrighted or illegal material hosted on your public site will result in automatic suspension of your account.
CGI
CGI is available in the cgi-bin directory of your public_html folder.
MySQL/monogdb/Postgres
Databases are available on request. The 'manager' command will do this.
Rails
To create and run rails apps use these commands:
- See the ports page for more info on which ports you can use for your Rails app.
rails new testblog -B cd testblog bundle install rails server -p 5040
From here on you can continue with things like generating controllers/routes and writing your app as normal.
If you require gems that are not globally installed consider using something like:
bundle install --path=$HOME/.local-gems
Don't forget to add this directory to your GEM_HOME and PATH.
export GEM_HOME="$HOME/.local-gems" export PATH="$PATH:$GEM_HOME"
Add these lines to your ~/.bash_profile or the start of your rails boot script to ensure your local gems are found.
If you want to run your rails app trough mod_passenger ask our staff to configure this for your subdomain.
Permissions
Your Apache processes and all child processes of Apache like php and cgi etc. run as a separate user that is dedicated to your website.
This user is named [your-username]-www. So it can access the files in your public_html directory you and your www-user are in the same group. This group is exclusive to your account so no Apache processes from other users have permission to read your files.
Security
The practical upshot of having a separate www-user is that you can now deny your Apache processes access to any files that you want to keep from being available over HTTP. (SSH keys are a good example of files where you might want such protection.)
Since the Apache process accesses your files through group permissions all you have to do in order to keep them from being accessible to Apache is revoke group access on them. (Hint: If you don't know how to manage file permissions read up on how to use the chmod command.)
Having this type of permission system will prevent any sensitive or security critical files you have from being exposed trough something like an LFI bug in your php.
suwww
There is a slight practical drawback to having the Apache process run as another user. Often when php processes create new files they will be created without group write permissions. This means that they are owned by your www-user and you cannot easily delete them.
To remedy this we have introduced the suwww command. If you run this command from your shell you will be logged into your www-users account giving you full permissions on any files your Apache user has created.
You can also use the suwww command to check and verify if your Apache user indeed does not have access to files you don't want it to.
