Post4VPS Forum | Free VPS Provider

I've been quite busy over the last two days with a project to install a Web Server and a WordPress blog without a panel. Took a lot of study and learning, and in the end the only thing I couldn't sort out was the permissions for WordPress. The plugins didn't come up when I worked in the dashboard of my WP installation.

I installed a LAMP Stack on CentOS 7:

Webserver httpd
Disabled SELinux
MariaDB server
phpmyadmin
php 7.3
Ioncube
WordPress

Felt quite funny to be working from var/www/html instead of home/admin/web/..... The first part went OK. I was able to get a Website up easy.

Challenge came with Wordpress. I was happy I could get it up and running. Once installed, when the install windows came up promptly when I typed in my URL. With the database info I provided (installed with MariaDB from command prompt), WordPress was not too happy - it could not create the config file automatically but prompted me to create and upload it manually. And that worked out OK. Problem came with trying to download plugins. The plugins wouldn't come up for selection. I was able to install them manually through uploading zipped folders from my computer. But was unable to update them, or create new ones directly from WordPress. Something went wonky with the permissions.

In all of my previous installations all I had to do was to provide the following simple chown command after installation of WP so that plugins could be installed and updated from the dashboard:

chown admin -R *

However with the installation of Apache through command line, it can't find the user "Admin". So I now wonder what I need to do to be able to use:
chown admin -R *

I then Googled this to death - tried all kinds of other things - none of which helped:

chown apache:apache /var/www/html
chown -R apache /var/www/html/

I finally followed the suggestion in this recommendation - which I think broke my WP site in the end:
https://www.ryadel.com/en/set-file-syste...s-7-chmod/

Created a script file that I uploaded to the root of my var/www/html folder with this bash command:


And I think it broke the WordPress installation as I was no longer able to get in.

So does any one know what I need to do to get chown admin -R* to work? I.e. create admin?

I'm going back to VestaCP temporarily, so I can check the conf files.

I need some command for mariadb I think to make wordpress happy. Give it permissions. At least WP had a workaround with getting me to upload the wp-config.php manually. But that was the first hickup.

I also need a command for setting up admin to work with wordpress.

I believe the username and usergroup that Apache / httpd is running as is actually www-data (both user and group). Or maybe just www? I honestly don't remember what it was on CentOS.

You can identify it via multiple ways: https://www.cyberciti.biz/faq/unix-osx-l...ache-user/

It's been like ages since I used Apache / httpd. Usually using nginx all the way. Much faster and uses less resources.

If you find out the user you need to chown -R username:group /path/to/wp-installation-folder at your WP installation. That should be plenty enough. Always was at least. Works this way fine on Debian / Ubuntu with Nginx.

You will most likely have to run that chown command everytime you upload new stuff manually into the WP directory (through SFTP) to ensure ownership of all files and folders is correct.

Thanks . The info is most useful. There are so many places that changes will have to be made. For example the host name is post2host Dallas. I probably need to create a new user name and give it all of the privileges. I'll give the command line effort a go again tomorrow.

In the meanwhile it's pretty awesome how fast a panel works and the time it saves. I've been working through my VestaCP folders. The details are unbelievable, compared with my attempts earlier in the day to create everything from the command line.

I also figured out that with a panel their folders are put together different. There is an Admin folder in both VestaCP and WordPress. Whereas with command line, one works with var/www/html. Think my eyes are crossing. Now and then I have an "aha" moment. But ever since checking through VestaCP files and folders, I guess panels do have their uses. Sum total of loads of work.

As said, you will need to run chown so Apache is the owner of your /var/www/html folder, Wordpress is super fickle with this step and it’s rather painful down the road when you are trying to install themes, plug-ins and the like and keep running into permission errors.

sudo chown -R www-data /var/www/html

You're not bound to use any kind of defaults that come with software. /var/www is such a default that is commonly used by web servers as their default web root. However you can create yourself a folder somewhere and use that as your web root given you setup the permission correctly. You can use different web roots per vHost / each webpage. That is exactly what panels do. They use custom path for every user and their websites. Infact I did so with Nginx already in the past. Every website has had its own web root with sub folders for the website files, logs, certificates and etc. I made the vHost process for that website run under its own user and even created a dedicated PHP-FPM instance running under the same user just for that vHost. It's not that much work once you get it working and documented once. Panels do the same - they use preconfigured templates where just a few things corresponding to the website/user you create are changed. So behind a few clicks is a chain of commands and files that you would manually create when working without the panel.

Panels however are blackboxes. They might do things a lot different than you might do it. You however won't know how exactly everything is done without having to look at a lot of the source code and files. Moreover panels add another layer of security risk.

(05-12-2021, 10:35 AM)Mashiro Wrote: [ -> ]You're not bound to use any kind of defaults that come with software. /var/www is such a default that is commonly used by web servers as their default web root.

Apache2.x's default DocumentRoot on Linux systems is /usr/local/apache2/htdocs.

'/var/www' DocumentRoot is the path chosen by the Debian-based Linux distributions and the '/var/www/html' DocumentRoot is the path chosen by the RedHat-based ones. Other OSes have some other variations (MacOS: /Library/WebServer/Documents; NetBSD: /usr/pkg/share/httpd/htdocs; OpenBSD: /var/www/htdocs; etc...)

So, the choice is set by the distribution used; this is because Apache allow the fine-tuning of the installation path of its directories at compile-time:

(05-12-2021, 10:35 AM)Mashiro Wrote: [ -> ]However you can create yourself a folder somewhere and use that as your web root given you setup the permission correctly. You can use different web roots per vHost / each webpage. (...)

Yes!.. But in the case of RedHat-based systems, you need to let SELinux know of that change for that to work.

(05-12-2021, 11:27 PM)fChk Wrote: [ -> ]Yes!.. But in the case of RedHat-based systems, you need to let SELinux know of that change for that to work.

Most of the tutorials I've worked through ask for SELinux to be disabled.  Which obviously completely defeats the purpose.  But yes, SELinux can be a headache for a beginner.  If you have time for a tutorial one day, like the one for changing Port 22, it would be awesome.  

For now my easiest out has been to disable SELinux as part of setting up httpd.  

is correct with what he said.  Last night I studied the file setup of VestaCP.  var/www/http is empty.  The Websites are built under /home/admin/web/domain.tk/public_html.  One also finds detailed configuration in the /home/admin/conf/web sub-directory.  Each Website has a detailed configuration like this one:

Quote:VirtualHost 185.12*.**.**:8080>

   ServerName domain.tk
   ServerAlias www.domain.tk
   ServerAdmin [email protected]
   DocumentRoot /home/admin/web/domain.tk/public_html
   ScriptAlias /cgi-bin/ /home/admin/web/domain.tk/cgi-bin/
   Alias /vstats/ /home/admin/web/domain.tk/stats/
   Alias /error/ /home/admin/web/domain.tk/document_errors/
   #SuexecUserGroup admin admin
   CustomLog /var/log/httpd/domains/domain.tk.bytes bytes
   CustomLog /var/log/httpd/domains/domain.tk.log combined
   ErrorLog /var/log/httpd/domains/domain.tk.error.log
   <Directory /home/admin/web/domain.tk/public_html>
       AllowOverride All
       Options +Includes -Indexes +ExecCGI
       php_admin_value open_basedir /home/admin/web/domain.tk/public_html:/home/admin/tmp
       php_admin_value upload_tmp_dir /home/admin/tmp
       php_admin_value session.save_path /home/admin/tmp
   </Directory>
   <Directory /home/admin/web/domain.tk/stats>
       AllowOverride All
   </Directory>

   <IfModule mod_ruid2.c>
       RMode config
       RUidGid admin admin
       RGroups apache
   </IfModule>
   <IfModule itk.c>
       AssignUserID admin admin
   </IfModule>

   IncludeOptional /home/admin/conf/web/httpd.domain.tk.conf*

</VirtualHost>

When I click through some of the directories looks like they've been synced.  Last night for example I found this command for syncing one directory contents to another - not sure I'll use it as I have no idea of what it really means:

rsync -avP ~/wordpress/ /var/www/html/

I found this at rackspace.  I got happy with this tutorial from rackspace which combines all of the commands in scripts for setting up a Web Server, until I tried the first script on the page and it didn't work out with mariadb.  I'm back now with a simpler Hostinger tutorial of how to build directories and give them the necessary privileges.

 You're absolutely correct.  It's at the root of the issue I had with WordPress not showing the plugins or allowing me to update and create new ones from the WP Dashboard. I learned that last night.  How important this is:

Code:

chown -R apache:apache /var/www/html/*

My mistake with my first attempt was to only chown -R apache:apache.  So hopefully with my next attempt things may work out better.  I've also learned about the importance of /etc/httpd/conf and /etc/httpd/conf.d.  

I've been so spoilt and used to panels, quite interesting to look at the root of things.  I'm now at number 10 plus reinstallations of the OS, but must say with every new try I'm learning more.

(05-13-2021, 02:11 PM)Mashiro Wrote: [ -> ]

Your progress looks good so far. Of course still a lot to learn for the case of really running everything without a control panel via the CLI.

Most important like with Windows is also with Linux that one usually focuses on a certain set of OSs. I'm the Debian / Ubuntu user while you seem to be a bigger fan of CentOS like .

Same with stuff like you using Apache while I would always recommend Nginx (unless Apache is really necessary). I know for a fact that Wordpress works very well with Nginx, too .

That is so true .  Except I've now moved away from CentOS.  After hours and HOURS of trying to make chown and chmod privileges work as well as trying to get to grips with rewrite settings, I've given up on LAMP stack.  Today I spent hours with trying to set up an OpenLightspeedserver (the free version of LightSpeedServer) on CentOS 7 as an alternative to Apache.  Same thing as I did with LAMP I worked through numerous tutorials to get the best version of instructions and ended up with the one below I thought should have worked - particularly because of the addition of a Cheat Sheet, but after hours of following all of the steps, I ended up with index.html getting a 400 error page  !

https://www.youtube.com/watch?v=urnHwEQ2eAE



What finally caused me to change to Debian was when I realized that possibly I'm a panel person only.  I had tried the Belgian fork of VestaCP that didn't work for me because of wanting me to install JAVA, but I hadn't tried the Debian fork yet since I had thought it would have been a drastic change in OS.  There was some learning involved with Debian but all of it went fast, and looks like I'm now on the Debian fork of VestaCP called myVestaCP.  Any one who is interested in a really great panel that works with Debian can check it out here:

https://www.myvestacp.com/#how-to-install

Dpeca also has a discussion forum here that is very well supported by him. From what I heard about his motivation for doing this is that he is running many servers and they are all on Debian and VestaCP works for him. So he decided to beef up the security of his servers by creating the fork:

https://forum.myvestacp.com/

I can't get over how much faster Debian is, or is it just a fluke?  Like two days ago while I was on CentOS 7, this was the result of my speed test.  



And this was with Debian today.



I know the speedtest is not really representative, but it's the difference between the two, as well as the faster running of the same script on Debian, the VPS running faster, and once in WordPress the plugins loaded like lightning.  Not that it was slow with CentOS, just much faster on Debian.

(05-13-2021, 02:11 PM)Mashiro Wrote: [ -> ]

My point simply was that there are default directories for applications that exist regardless of OS or software used. The second point was that you're not forced to use these default directories. Especially with web servers and vHosts it is easy to use custom directories (as an example or rather said the case of this thread). That is what control panels do in 100% of the time after all. Yes, of course different OS and software packages actually might have different defaults (like you said). I never said the opposite. If I said something wrong about default directories on CentOS I apologize. However I've not used CentOS for several years now and when I used it I never used any defaults. I'm using Debian / Ubuntu only most of the time since the last 3+ years.

There is absolutely no need to apologize!.. I have a tendency to intervene when I see something that needs to be :
> either corrected when false, in which case I generally use strike tags to cross the false part
> OR give more details on a highlighted quote when I feel that the language/formulation is prone to being misinterpreted by readers.

It's an old habit and people raeding my posts would know that by now.

Obviously the last case was the situation in my previous post here...