Up until now I have been using ZF2 on a CENTOS environment with cpanel. I recently decided to move to Ubuntu and so far it has been really simple to setup a server.
I am however having a small permission problem which I am struggling to resolve.
I am using AssetManage which needs to be able to write images and files to the public folder.
Unfortunately, I cant seem to get the correct permissions to get this to work.
I have gone as far as setting 777 permissions to the public folder which makes no difference.
I have also changed the owner of public to: www-data which is the user that apache is using, and this does not help either.
What is likely the problem is the user/group I am using to load files to the server conflicting with the www-data user needing to perform various tasks on the server.
Is there a standard setup I should be looking at in terms of this?
SETUP:
Ubuntu: 14.4
ZF2
I have found some great tutorials to setup an Ubuntu environment. Here they are:
Basic installation
Enhanced installation
LAMP stack
All working perfectly now!
Related
When trying to setup automated backup under Ubuntu 17.10 using Deja-Dup I realized that one can not backup the root directory since a normal user starting the deja-dup application does not have all rights to access all files in /.
(german discussion about rather similar situation can be found here: https://forum.ubuntuusers.de/topic/wie-sichert-an-mit-deja-dup-ein-systemverzeich/)
The usual workaround to gksu the deja-dup application does no longer work on Ubuntu 17.10. It seams that a decision has been made to prevent users from starting graphical applications as root on purpose for it is often a bad/risky think to do.
However to create regular backups of a Systems / directory with deja-dup the application has to be configured and later on started as root.
Since the typical ideas like gksu, gksudo, sudo -H do not work unter Ubuntu 17.10 I would highly appreciate any advice on a secure practice to get to run deja-dup as root. Can someone help with advice?
I'm working on setting up a website and at first I thought the website was broken but then I look and I'm getting 403d on everything under /javascript/
I've double checked the filesystem permissions. I can rename the javascript folder to js and access the files just fine from a browser. I've tried finding all the locations where the site tries to access /javascript/ and change it to just /js/ but there are some other scripts running that are generating some script tags and it's not proving easy to find them all.
My question is, is there an easy(ish) way to find where apache may be hanging me up? It's a basic apache2 install on ubuntu 14.04 running in a digital ocean droplet.
Now I feel silly.
Just ran grep -r "javascript" . just the same as I was using it to look for references in the website and I see there's a default aliasing of /javascript in the apache2 conf of javascript-common (though it didn't seem to show up in conf-enabled). I ran sudo a2disconf javascript-common and I had access back to the folder.
I built the login functionality for a website on an AWS ec2 ubuntu with LAMP setup and it was working fine. The PHP files for this were located in /var/www/html. Then, to also allow login from an android device, I added and began working on the directory android_login_api in the /www folder. After adding several files and directories to this I noticed the website was no longer working and displayed "This webpage is not available" when I attempted to reach it. Despite completely removing android_login_api and attempting to revert the directory /www to just the way it was when it worked, this error remains.
I have spent a few days searching for a solution, but most answers pertain to the setup of apache which was already working fine for me. I tried restarting apache but neither index.php nor any other files I specify can be reached. I have also spent a lot of time trying to edit apache .conf files but with no luck.
Any ideas about what may have happened or if there is a specific path I need but may have accidentally altered would be greatly appreciated.
Most of access problems are caused by incorrect configuration of Virtual Hosts which seems like the problem here.
As you mentioned, the readable directory was /var/www/html and then you tried to access /var/www/android_login_api, which is not accessible by default and is specified in your virtual host file for the website. Location: /etc/apache2/sites-available
If you have done it different to this article, it will be difficult for anyone to help you. Don't create hosts in apache.conf. Read it before reading my answer further.
When you make changes to the virtual host, don't forget to use sudo a2ensite yoursite.com.conf as well as restarting apache service with sudo service apache2 restart after enabling the site.
The last thing that you should know about setting up websites is www directory owner. When you done making changes to files via FTP or SSH, run sudo chown www-data:www-data /var/www -R. www-data is the username like root used by Apache to allow external access. Otherwise the fiels will be accessible only with 0755 permissions by any other user and not 0644.
This is just a bunch of things essential to make changes and work with HTTP servers. Though my answer is not clear and I'm unable to point out your issue, I believe I've given you additional knowlege/consideration points to troubleshoot your issue. Drop a comment for more specifics.
I've recently been tasked with moving a client out of a shared hosting environment into an AWS environment where all the infrastructure was hosted and supplied by Amazon. The client is running multiple (dated) Drupal instances, but luckily I've been able to move the environment over and have it function, except for the errors below.
I've discovered that Drupal is generating errors throughout their environment(s) on the AWS instance, but not on the shared hosting instance, despite using the same except code base/database.
Permission Error(s): http://i.imgur.com/cRQOo4W.jpg
Timezone Error(s): http://i.imgur.com/VFgWZKE.jpg
Personally, I'm not a big Drupal guy and I've researched the file permissions on the root directories (https://www.drupal.org/node/244924), but I honestly do not want to go around changing things without fully knowing the effect of a change.
If anyone can provide insight to the root of these errors and how I can potential resolve them, I would greatly appreciate it.
P.S. - Most of the environments in question are running on Drupal 6.33 (not 100% sure), but they do have one environment running on Drupal 7.23 (again, not 100% sure).
Make sure the web server's user/group owns the Drupal files, not root. Then follow the file permission instructions in INSTALL.txt.
Select a timezone in the Regional Settings of your Drupal site on AWS. If that doesn't do it, set the date.timezone in the php.ini file there.
So I have an existing opencart system with a vqmod extension on it. I'm trying to set this up locally to work on by can't get vqmod to create it's cache files. I'm using vagrant as the local environment.
I know vqmod has some crazy permissions requirements, I have it running on an external staging server but to get this to work I had to set the group to www-data all the way from server root right the way up to vqmod directory.
Am I missing something simple in vqmods permission requirements