I did a yum update on my Development server and it updated Nginx 1.12.2.3 to Nginx 1.16.1.1. Also in the process it wrote to the index.html file.
This is of concern as if updates are run on a production server it could cause problems in that it could make the website crash as nginx appear to be writing to the public folder.
Here is how the /usr/share/nginx/html looks before the yum update versus after.
-rw-r--r-- 1 root root 2811 May 10 2019 poweredby.png
-rw-r--r-- 1 root root 368 May 10 2019 nginx-logo.png
-rw-r--r-- 1 root root 3700 May 10 2019 index.html
-rw-r--r-- 1 root root 3693 May 10 2019 50x.html
-rw-r--r-- 1 root root 3650 May 10 2019 404.html
Here is how it looks after the YUM update and reboot.
lrwxrwxrwx 1 root root 20 Jan 24 18:28 en-US -> ../../doc/HTML/en-US
lrwxrwxrwx 1 root root 18 Jan 24 18:28 img -> ../../doc/HTML/img
drwxr-xr-x 2 root root 26 Jan 24 18:28 icons
lrwxrwxrwx 1 root root 14 Jan 24 18:28 poweredby.png -> nginx-logo.png
lrwxrwxrwx 1 root root 25 Jan 24 18:28 index.html -> ../../doc/HTML/index.html
So the question is why is YUM/NGINX writing files to the public folder? As I said this is a concern in that it could bring the whole website down. Any help, thoughts or suggestions would be welcome.
Regards,
Patrick
I have installed SilverStripe 4.0.3 on a webserver and at the end of the installation this message is displayed:
"After the install, the assets directory is the only directory that needs write access."
When I try to search for information on what kind of file permissions I should set manually (if any), I can't find anything.
This is how the permissions look like after the installation:
drwxrwxr-x 3 myuser myuser 4096 Feb 11 21:56 assets
-rw-rw-r-- 1 myuser myuser 907 Feb 11 21:49 composer.json
-rw-rw-r-- 1 myuser www-data 133925 Feb 11 21:49 composer.lock
-rw-rw-r-- 1 myuser myuser 1406 Feb 5 05:15 favicon.ico
-rwxrwxr-x 1 myuser www-data 535 Feb 11 21:53 index.php
-rw-rw-r-- 1 myuser www-data 1221 Feb 11 21:49 install-frameworkmissing.html
drwxrwxr-x 4 myuser myuser 4096 Feb 11 21:49 mysite
-rw-rw-r-- 1 myuser myuser 854 Feb 5 05:15 phpcs.xml.dist
-rw-rw-r-- 1 myuser myuser 1804 Feb 5 05:15 README.md
drwxrwsr-x 3 myuser www-data 4096 Feb 11 21:49 resources
drwxrwsr-x 3 myuser www-data 4096 Feb 11 21:49 themes
drwxrwsr-x 25 myuser www-data 4096 Feb 11 21:49 vendor
-rw-rw-r-- 1 myuser www-data 585 Feb 11 21:49 web.config
For example, is the file permissions on the "resources" folder wrong here?
Those permissions look fine. The installer tells you it needs those permissions just in case something went wrong when setting the permissions on the assets folder.
The message states it's the only directory that needs to be writable. It does not mean other folders shouldn't be writable.
I've got wordpress running on a AWS Linux instance.
I can create posts.
I can upload images.
But I can't upload themes.
Having messed about with the permissions this is where it currently stands:
-rwxr-xr-x 1 apache apache 418 Sep 25 2013 index.php
-rwxr-xr-x 1 apache apache 19935 Jan 2 2017 license.txt
-rwxr-xr-x 1 apache apache 7413 Dec 12 2016 readme.html
-rwxr-xr-x 1 apache apache 5447 Sep 27 2016 wp-activate.php
drwxr-sr-x 9 apache apache 4096 Jun 8 14:29 wp-admin
-rwxr-xr-x 1 apache apache 364 Dec 19 2015 wp-blog-header.php
-rwxr-xr-x 1 apache apache 1627 Aug 29 2016 wp-comments-post.php
-rwxr-xr-x 1 apache apache 2825 Jul 27 21:21 wp-config.php
drwxr-sr-x 5 apache apache 4096 Jul 28 11:53 wp-content
-rwxr-xr-x 1 apache apache 3286 May 24 2015 wp-cron.php
drwxr-sr-x 18 apache apache 12288 Jun 8 14:29 wp-includes
-rwxr-xr-x 1 apache apache 2422 Nov 21 2016 wp-links-opml.php
-rwxr-xr-x 1 apache apache 3301 Oct 25 2016 wp-load.php
-rwxr-xr-x 1 apache apache 34327 May 12 17:12 wp-login.php
-rwxr-xr-x 1 apache apache 8048 Jan 11 2017 wp-mail.php
-rwxr-xr-x 1 apache apache 16200 Apr 6 18:01 wp-settings.php
-rwxr-xr-x 1 apache apache 29924 Jan 24 2017 wp-signup.php
-rwxr-xr-x 1 apache apache 4513 Oct 14 2016 wp-trackback.php
-rwxr-xr-x 1 apache apache 3065 Aug 31 2016 xmlrpc.php
Any help greatly appreciated. Am I missing something obvious?
You need to check the permissions for the themes folder inside wp-content folder.
Try running the following commands if it's CentOS:
Changes ownership to Apache user and group
chowm -R apache:apache /path-to-wp/wp-content/
Change permissions and add setguid
cd /path-to-wp/wp-content/
find . -type d -exec chmod 2775 {} \;
find . -type f -exec chmod 664 {} \;
This should hopefully resolve the file permissions and fix the uploads.
I would like to move the RABBITMQ_BASE files to "/opt/rabbitmq"
I've attempted the following, but it appears that I'm making a mistake somewhere:
(while logged in as root)
mkdir -p /opt/rabbitmq
sudo chown -R rabbitmq:rabbitmq /opt/rabbitmq
sudo chmod 766 -R /opt/rabbitmq
here is the contents of my rabbitmq-env.conf
RABBITMQ_BASE=/opt/rabbitmq
export RABBITMQ_NODENAME=rabbit#localhost
export RABBITMQ_NODE_IP_ADDRESS=127.0.0.1
export ERL_EPMD_ADDRESS=127.0.0.1
export RABBITMQ_MNESIA_BASE=/opt/rabbitmq/MNESIA
I've checked the logs in /var/log/rabbitmq/startup_log:
BOOT FAILED
===========
Error description:
{error,{cannot_create_mnesia_dir,"/opt/rabbitmq/MNESIA/rabbit#localhost/",
eacces}}
Log files (may contain more information):
/var/log/rabbitmq/rabbit#localhost.log
/var/log/rabbitmq/rabbit#localhost-sasl.log
Stack trace:
[{rabbit_mnesia,ensure_mnesia_dir,0,
[{file,"src/rabbit_mnesia.erl"},{line,505}]},
{rabbit_node_monitor,prepare_cluster_status_files,0,
[{file,"src/rabbit_node_monitor.erl"},{line,101}]},
{rabbit,'-boot/0-fun-0-',0,[{file,"src/rabbit.erl"},{line,270}]},
{rabbit,start_it,1,[{file,"src/rabbit.erl"},{line,403}]},
{init,start_it,1,[]},
{init,start_em,1,[]}]
{"init terminating in do_boot",{error,{cannot_create_mnesia_dir,"/opt/rabbitmq/MNESIA/rabbit#localhost/",eacces}}}
The "/opt" directory is owned by root, but the permissions for the other directories are as follows:
ubuntu root#/opt $ ls -lah
total 48K
drwx------ 10 700 root 4.0K Jul 14 12:42 .
drwx------ 5 700 root 4.0K Jul 14 10:39 ..
drwx------ 13 700 root 4.0K Jul 12 10:16 anaconda
drwx------ 4 700 root 4.0K Jul 12 09:28 data
drwx------ 3 700 root 4.0K Jul 12 10:38 legacy
drwx------ 2 700 root 12K Jul 14 12:45 logs
drwx------ 3 700 root 4.0K Jul 12 09:47 mongodb
drwxrw-rw- 4 rabbitmq rabbitmq 4.0K Jul 14 13:05 rabbitmq
The solution which works for me is to disable SELINUX
I have problems running plone 4.3.2 after installation (in Fedora 18). I'm using the unified installer. I've already re-installed it several times with the same problem. I'm using the unified installed. I've used Plone 2 and 3 without problems so I'm not sure what's happening here. There seems to be some permission issue. The README seems to say that "plonectl start" should be called using plone_daemon. However the Plone folder is owned by plone_buildout. I've included the installation output and also a printout of the permissions of the Plone directory.
Can someone tell me what to do. Thanks.
[root#localhost Plone-4.3.2-UnifiedInstaller]# ./install.sh zeo --password=admin
Testing /usr/bin/python2.7 for Zope/Plone requirements....
/usr/bin/python2.7 looks OK. We'll try to use it.
Root install method chosen. Will install for use by users:
ZEO & Client Daemons: plone_daemon
Code Resources & buildout: plone_buildout
Detailed installation log being written to /home/student/Desktop/Plone-4.3.2-UnifiedInstaller/install.log
Installing Plone 4.3.2 at /usr/local/Plone
Using useradd and groupadd to create users and groups.
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
Creating mailbox file: File exists
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
Creating mailbox file: File exists
Creating python virtual environment, no site packages.
New python executable in /usr/local/Plone/Python-2.7/bin/python2.7
Also creating executable in /usr/local/Plone/Python-2.7/bin/python
Installing Setuptools..............................................................................................................................................................................................................................done.
Installing Pip.....................................................................................................................................................................................................................................................................................................................................done.
Compiling and installing jpeg local libraries ...
Unpacking buildout cache to /usr/local/Plone/buildout-cache
Copying Plone-docs
Setting /usr/local/Plone ownership to plone_buildout:plone_group
Copying buildout skeleton
Fixing up bin/buildout
Building Zope/Plone; this takes a while...
Buildout completed
#####################################################################
###################### Installation Complete ######################
Plone successfully installed at /usr/local/Plone
See /usr/local/Plone/zeocluster/README.html
for startup instructions
Use the account information below to log into the Zope Management Interface
The account has full 'Manager' privileges.
Username: admin
Password: admin
This account is created when the object database is initialized. If you change
the password later (which you should!), you'll need to use the new password.
Use this account only to create Plone sites and initial users. Do not use it
for routine login or maintenance.
- If you need help, ask the mailing lists or #plone on irc.freenode.net.
- The live support channel also exists at http://plone.org/chat
- You can read/post to the lists via http://plone.org/forums
- Submit feedback and report errors at http://dev.plone.org/plone
(For install problems, specify component "Installer (Unified)")
[root#localhost Plone-4.3.2-UnifiedInstaller]# sudo -u plone_daemon /usr/local/Plone/zeocluster/bin/plonectl start
sudo: unable to execute /usr/local/Plone/zeocluster/bin/plonectl: Permission denied
[root#localhost Plone-4.3.2-UnifiedInstaller]# cd /usr/local/Plone/
[root#localhost Plone]# ls -la
total 24
drwxr-sr-x. 6 plone_buildout plone_group 4096 Dec 25 14:59 .
drwxr-xr-x. 12 root root 4096 Dec 25 14:56 ..
drwxr-xr-x. 4 plone_buildout plone_group 4096 Mar 8 2011 buildout-cache
drwx------. 2 plone_buildout plone_group 4096 Dec 25 14:56 Plone-docs
drwxr-xr-x. 7 plone_buildout plone_group 4096 Dec 25 14:56 Python-2.7
drwx--S---. 8 plone_buildout plone_group 4096 Dec 25 14:59 zeocluster
[root#localhost Plone]# ls -la zeocluster/
total 128
drwx--S---. 8 plone_buildout plone_group 4096 Dec 25 14:59 .
drwxr-sr-x. 6 plone_buildout plone_group 4096 Dec 25 14:59 ..
-rw-------. 1 plone_buildout plone_group 424 Dec 25 14:59 adminPassword.txt
-rw-------. 1 plone_buildout plone_group 8765 Dec 25 14:56 base.cfg
drwx--S---. 2 plone_buildout plone_group 4096 Dec 25 14:59 bin
-rw-------. 1 plone_buildout plone_group 10525 Dec 25 14:56 bootstrap.py
-rw-------. 1 plone_buildout plone_group 6812 Dec 25 14:56 buildout.cfg
-rw-------. 1 plone_buildout plone_group 4399 Dec 25 14:56 develop.cfg
drwxr-sr-x. 2 plone_buildout plone_group 4096 Dec 25 14:56 develop-eggs
-rw-------. 1 plone_buildout plone_group 18297 Dec 25 14:59 .installed.cfg
-rw-------. 1 plone_buildout plone_group 815 Dec 25 14:56 lxml_static.cfg
drwxr-sr-x. 5 plone_buildout plone_group 4096 Dec 25 14:59 parts
drwx--S---. 2 plone_buildout plone_group 4096 Dec 25 14:56 products
-rw-r--r--. 1 plone_buildout plone_group 3469 Dec 25 14:59 README.html
drwx--S---. 3 plone_buildout plone_group 4096 Dec 25 14:56 src
drwxrws---. 7 plone_buildout plone_group 4096 Dec 25 14:59 var
-rw-------. 1 plone_buildout plone_group 9521 Dec 25 14:56 versions.cfg
-rw-------. 1 plone_buildout plone_group 1902 Dec 25 14:56 zopeapp-versions.cfg
-rw-------. 1 plone_buildout plone_group 1022 Dec 25 14:56 zope-versions.cfg
-rw-------. 1 plone_buildout plone_group 2518 Dec 25 14:56 ztk-versions.cfg
[root#localhost Plone]#
It definitely looks like a permissions problem. Probably having to do with a Fedora security policy.
In all honesty: there really is no reason to install Plone as root. Please continue with installing it as a normal (dedicated, but non-omnipotent) user account. That will ease a lot of your problems later.