New Install Of Sytist On Amazon Ec2 Instance

I have just created a new Sytist 0.8.8 install on an Amazon Linux LAMP EC2 Instance but when I go to create a page (About Us) in the Admin section all OK and can see it in the menu, but the actual link reports a 404 error Not Found, neither can I upload any images via the GUI uploader they get to 100% and then error with 500 error, but I can upload my imagery via FTP, the GUI sees them and just hangs on processing when trying to import them.

Is this a Permissions error somewhere on the folders??

Edited by

I was just looking into Amazon's EC2 services yesterday, and would love to know the steps you took to set this up. From what I saw on the Amazon site, you'd have to use SSH to install Apache and PHP before doing anything else.

Yes, what you're describing is a permission issue with the folders. It's what I experienced on my installation before setting the write permissions on all the folders, including (and especially) the main Sytist folder.

Edited by

Hi Alan, yes indeed have completed the setup via SSH and installed latest Apache and PHP successfully but i can t quite get to the permissions issue. I really y need to know what permission CHMOD need to be set on the stylist folder hierarchy just so i can check them all. Do i need to change the http.conf file? or any other files?

Edited by

Alan i recommend this link http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-LAMP.html on how to install LAMP on the Amazon Linux 64bit Instance, just follow the easy steps.

Edited by

What I had to do on my installation was set permissions on all the folders to 777. Since Sytist is the only thing running on what is essentially a VPS, that should be safe, as long as all the passwords are secure.

Thanks for the link. Hopefully, Amazon will eventually set up a GUI interface to deploy EC2 instances. That would make it easier for more people.

Edited Thu Oct 01, 15 9:31 AM by Alan Tutt

Amazon do indeed offer a great GUI, (see attached) just click 'Launch Instance' and follow the quick start setup, or do you mean for the LAMP config. You will need to install SQL too

Edited by

I am not familiar with Amazon EC2 at all. But if the folders / pages are not getting created, it is most likely a permission issue. So the main folder Sytist is installed in needs to be writable. You may need to change the permissions to 0777. Or see of you can using something like suPHP so the files are writable at default 0755 permissions.

Edited by

Are the correct permissions set?? See attached

Edited by

Hi Tim, the default folder for webpages after installing Apache, Php & SQL is /var/www/html/ this has 775 permission, i have installed the Sytist folder inside html with all folders only (not files) with the permission 777. Is this correct? or does the /var/www/html - html folder require 777 in order for it to work? Cheers Paul

Edited Thu Oct 01, 15 10:40 AM by Paul Fox

Hi Tim, Just changed CHMOD permissions to 0777 for the /var/www/html HTML folder and all now working fine. Now when I create a page the link works as it should but i still cannot upload any photos via the uploader or process via FTP. Don't really want to provide 0777 for all the folders, as insecure.

Edited Thu Oct 01, 15 11:46 AM by Paul Fox

You will needs to set the sy-photos and sy-upload folders to 0777. Basically all the "sy-" folders except for sy-inc and sy-admin. Also when you upload a folder of photos to sy-upload you will need to set it to 0777.

Would be best to see if you can using something like suPHP or fast CGI so you don't have to bother with permissions.,

Edited by

It also sounds like an image processing module didn't get compiled into PHP, such as GD or ImageMagick.

Tim, I understand you like suPHP and FastCGI. I recently looked into these, and they're still slower than DSO, which is one of the main reasons I'm sticking with DSO.

Just having a clear set of instructions detailing the required PHP/Apache modules and what folders need what permissions is all folks like us are looking for. Of course, it would be better if the software were written to limit the need for write permissions, especially on any folder that contains program code. This is considered part of "best practices" in PHP coding.

Look at it this way. One insecure script can compromise an entire account, which may be running multiple domains and/or scripts, even with suPHP. suPHP only protects other users from a hacked account. It doesn't help to protect different scripts from each other on the same account. Proper use of permissions can do that.

suPHP may be more convenient, and protect users from other accounts, but when it comes to protecting one script from another on the same account, it's actually LESS secure than DSO with limited write permissions.

As it stand now, Sytist's main index.php, sy-main.php, sy-footer.php, sy-config.php and other php files may be overwritten by a hacker.

Wouldn't you want to protect your customers from the next WordPress security issue?

Edited Thu Oct 01, 15 12:34 PM by Alan Tutt

If a folder is not writable, then it can't create new folders, pages, process photos, etc .... which is needed with any website unless you want to make the pages then upload them yourself.

I asked an owner of a web hosting company a while back what it was that allowed the folders to be writable with default permission. He runs VERY tight and SECURE servers. This was his reply:

Some hosting companies (usually older ones or extremely lazy ones) never bothered to install it, but suPHP is a very important module not only for security (making it so that folders only need be 755 and files 644 to be writeable by the account owner's scripts) , but also for important practical purposes such as this - if you SSH into the shell/root of a server and do a "top" on a server that is not running suPHP you'll see that all of the running processes are listed as "nobody" which is not very helpful when you're trying to figure out who is using 90% CPU! When you do a "top" in shell on a server running suPHP , each process has the customer's master account name next to it to easily identify which account is using which resources / running which processes.

Edited by

Hi Tim,

New pages can be added to a website without writing any files. The way most CMSs fetch pages is to have a set of directives in an .htaccess file which capture the requested URL and pass it to the program as a query string, which is then used to pull data from the database. In this scenario, new pages are simply saved to the database. No new files involved.

Of course, using the database is only 1 way to do it. Another is to put all custom pages into a single subfolder, check the URL with your code, and then "include" the requested page from a subfolder. This can be done without any database connection at all, and without using write permissions on the root folder.

And if the PHP code uses FTP commands with the right credentials (username, password), then files can be created (or updated) anywhere those credentials are valid. Again, without using any special permissions on any files or folders, and regardless of the server configuration.

The answer you quoted doesn't directly address the question you mentioned. What makes suPHP able to write to files without special permissions is because suPHP runs PHP code "as the user", which means it can do anything with any of the user's files that the user him/herself could do.

This is both a blessing and a curse. A blessing for those who sell shared hosting on a single server, because of the reasons mentioned by your friend, and because when code runs as the user, that code does not have access to any files from another user's account. This is why most hosting companies choose to implement suPHP or FastCGI.

The curse is that when code runs as a user, it can generally overwrite any file in that user's account, and if one script is compromised, all files become open to attack. That is, without implementing some VERY strict permissions so that the account owner cannot change the files without first changing the permissions -- something very few hackers attempt to do.

Those of us who have VPSs or dedicated servers, when we're conscious of the details, often CHOOSE to run PHP as an Apache module for the speed benefit, and for the added security within a single account.

All we're trying to say is that different situations call for different approaches, and not everyone runs PHP as CGI. And when PHP is run with the DSO loader, having write permissions on folders than include PHP code is a security risk. Write permissions should be limited to data folders only.

Edited Thu Oct 01, 15 4:41 PM by Alan Tutt

Hi, did any one get a best practice solution to this. I too have just installed a LAMP stack on EC2 and followed http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-LAMP.html. When I run Tim's stylist.php script to check the server requirements prior to install, it complains the file is not writeable.

Edited by