2. page content

Continuation

The description on the first page we have created a web account and database to run the website. On this page we will continue with the creation of the Shell user and finally install WordPress 5.2 CMS system.

Create a web account in the control panel

Create a Shell user

We could proceed instead of the Shell user FTP line as well, as is usual on a basic hosting, but since we are the system administrators, it is more appropriate to use a Shell user, which can be easily created by ISPConfig surface.

To create it, while staying in the Websites main menu, scroll down, then select the "Shell User" menu item on the left. The listing page will then appear, where we click on the usual green "New Shell User" button. Then the form comes in:

Fill in the fields:

• Website: Here, set the appropriate website/web account for which we want to create the shell user. This is important because the group and permissions are set accordingly, so files created/downloaded with the shell user will have the same linux user ID (UID) and group ID (GID) as the PHP-FPM also runs the PHP scripts. Thus, our created shell user and our website work together seamlessly.
• Username: Here, it is advisable to come up with a username that refers to the website. For example, I chose the same name as the database, which is a domain name as well. Also, if We have disabled the prefixing of usernames in ISPConfig, then the control panel prefixes are not placed in front of the username. If it's just us on the server, I think it's advisable to turn it off, because it's just annoying. If, on the other hand, there are other clients on the server, leave it on so that name conflicts do not occur in the system.
• Password: Enter your password. This is also indicated by its strength. If possible, choose a stronger password, especially when in use.
• Chroot Shell: The essence of Chroot is that it "locks" the user into a specific directory structure, which from then on becomes the root directory. So, for example, you can't exit there, and you can't see the structure above your own root directory, nor other users' stuff. If we create this user for ourselves, then turn it off, but if we create it for a client, then select here Jailkit option, which automatically performs a full chrooting of the user in the background. I'm creating the whole account for testing now, so I'm turning it off.
• Quota: Here you can set a storage limit for the shell user (not to be confused with the web hosting quota!). If you do not want a limit, leave it at -1.
• SSH-RSA Public Key (for key-based logins): If you have a public key for SSH, you can place its content here. But later we can set passwordless login on linux systems.
• Active: Pipe.

Now I won't go into detail about the settings under the Options tab, because we don't need to change anything there at the moment. But if we still want to find out about it, then I wrote about this in more detail here.

Finally, save the form and wait until the little red circle disappears.

Customize Command Line Environment (Optional)

This part is optional, but I tend to set some things for every shell user. For example, the command line addition, use of colors in the terminal, aliases, etc. That's about it most recently Ubuntu 18.04 LTS (Bionic Beaver) minimum server to my installation description at the end of the word. If we have already made these settings during the installation of the currently used server, it will be easier for us now, because we only need to copy the settings of the first user created when the server was installed to the profile of the newly created user. Again, this part is not mandatory, but it can make working in the terminal much more comfortable.

When installing this server, I created the first user with the name "linuxportal", so now I am copying the already set up from this user .bashrc file. Here, of course, we use our own user settings, provided we have done the above links.

Log in to the server with the new user (wordpress in my case) on the terminal, then run the following command:

cat /home/linuxportal/.bashrc > ~/.bashrc

With this, we copied the .bashrc file of the first created user (which we had previously set up) to that of the newly created user (which did not exist until now).

Then we source the .profile in the .bashrc our file to run on every login (login shell):

echo ". .bashrc" >> .profile

If we re-enter this user account made for WordPress, we are already greeted by the colorful prompt, aliases work, etc. But instead of logging in and out, it is enough to just source our .profile file (which also runs the .bashrc file):

. ~/.profile

I even ran a directory list here to see how the "l" alias command works.

All is good so far, but there is a little bit of a bug: in the prompt, our username is not what we created, but (for example, in my case) web1 @ ... This is because when we created the web account in ISPConfig, the control panel is automatically created also a linux user named web1, which actually manages the account, owns the permissions, etc., even after we have created our own shell user, which actually gets the same UID and GID as the system created user. To get a better view of this, log in as root on another terminal and open the / Etc / passwd file:

nano /etc/passwd

If we roll it to the bottom, we'll see it:

The solution to this is to simply interchanged the two lines in the /etc/passwd file (a you can read about the treatment of nano here for ease of use):

[...]
wordpress:x:5004:5005::/var/www/clients/client0/web1/home/wordpress:/bin/bash
web1:x:5004:5005::/var/www/clients/client0/web1:/bin/false

After saving the file, log out in the other window and log in again with our new user:

And the result speaks for itself: our prompt now starts with wordpress@. Furthermore, when we list our directories, the same user is displayed for our own subdirectories and files.

These things may seem small, but when there are already at least 5-6 websites on the server, and the prompts for all of them start with web1, web5, web3, and the same names are returned in the libraries, then you definitely get involved, especially if something needs to be done quickly.

Hosts file setup (optional)

If you are using a purchased domain name on a live storage, skip this section. However, if you are creating a test environment at home, you will still need to configure the hosts file to access the web pages on your virtual machine from our browser. I'm not going to waste time here, especially since I've made a little description of it. So by replacing the name of the web page you just created, let's do this little part.

If the file is set up correctly, the hosting and ISPConfig will be entered with the domain name of our choice, phpMyAdmin too. The following image shows the ISPConfig welcome panel:

Your browsers may not be found right after setup, so you may have to wait a while for that browser to refresh DNS the new data is also cached.

Now that we've got the hosting issue out of the way, let's download and install WordPress 5.2!

Install WordPress 5.2

Download

Use our shell user to access the document directory on the page tmp / subdirectory:

cd /var/www/wordpress.vm/tmp

In the tmp directory, execute the following wget download command using the link above:

wget https://wordpress.org/latest.tar.gz

This will download an 10,68 Mb packed file. Unpack the following:

tar -xvzf latest.tar.gz

A wordpress subdirectory will then be created, containing the extracted files. We copy these recursively into the web root directory of our hosting:

cp -r /var/www/wordpress.vm/tmp/wordpress/* /var/www/wordpress.vm/web

Installation

If we have successfully copied the entire file structure to the web root, open the following link with our browser:

http://wordpress.vm/wp-admin/setup-config.php

Of course, we use our own domain name!

The WordPress installer will then start:

Let's set our language. Then an informational window appears, that the system will request some data from us, such as database access parameters, etc., and that it will try to set this in the config file:

Originally, this data could have been set manually in the configuration file with an editing program, but after not finding such a set file, the installer will fill it in for us. So let's click here On! labeled button.

In the following panel you will be asked for database information:

• Database name: Enter the name of our database created when creating the storage space. I have "wordpress"
• Username: Enter the username associated with the database here. I have "Wordpress"
• Password: You are prompted for the password you created when you created the database user. For me, what ISPConfig generated.
• Database Server: We'll leave this on localhost.
• Table prefix: If you want to run several instances of Wordpress in the same database, you can use the prefixes to distinguish the system's database tables. If we only plan one copy, leave it at the given value. Of course, further installations can also be numbered later, for example, if necessary.

Click the send button.

If all the details are correct, we will receive the following information:

Click on Run Setup button.

Then the 5 minute installer comes in:

• Website Name: Here we can enter anything, this will be the name of our website. It is not related to the domain name or other names previously entered.
• Username: This is the primary username, I set admin here. By default, the database offered a username. Or maybe it's just a coincidence ...
• Password: Well, by default, it also offers the password of the database. What I don't think is a very secure solution is to use the same username-password pair on the web as for the database connection. So I copied a few characters in the entered password here. This is a bit interesting, from a WordPress system. You should have generated a completely new password here...
• His e-mail address: In case of live use, enter the email address created for the domain name that we created for this page. In the case of a home test environment, anything can be specified. I followed the username@domain.tld scheme.
• Search engine visibility: With this option, we can block search robots from the page. In this case, the system tells the robots in the robots.txt not to index the pages. This is obviously not our goal for live use, unless we intend to create a page for internal use. But robots.txt is not considered by all robots. In a test environment, it is irrelevant, the robots will not reach our home machine anyway, especially if NAT we are behind the network.

When you're done, click on Install WordPress button.

If all goes well, we will get a "Success" panel again:

Click on Login button.

This will take us to the WordPress landing page.

Log in

After logging in, you will find yourself in the admin control panel:

Here you can start customizing the page, installing updates and add-ons, etc.

If you click on the small house icon on the top left or simply enter the URL of the website, you will be taken to the home page.

Home

Here we can see that we are still dealing with a completely raw WordPress system, which is waiting for us to start customizing it and filling it with content.

Conclusion

So this would be the creation of a dedicated hosting and the installation of the WordPress 5.2 CMS system designed for this purpose. In terms of proportions, we dealt with the shaping of the hosting, which was not accidental, as the essence of this description is to walk the path to a working, turnkey CMS content management system from the point of view of an administrator. So from here, we have a WordPress 5.2-based website ready to go, with which we can start publishing our content or just launching a web store.

Navigation