If you try the command on AlmaLinux 8

tail -f /var/log/messages

and got this error below

tail: cannot open ‘/var/log/messages’ for reading: No such file or directory
tail: no files remaining

Run following commands

dnf install rsyslog
systemctl start rsyslog
tail -f /var/log/messages

Run command below

dmidecode -s bios-version

Problem

In this article I will show how to fix CentOS 6 error: YumRepo Error: All mirror URLs are not using ftp, http[s]

When trying update CentOS 6 with yum update command getting error:

Loaded plugins: fastestmirror, refresh-packagekit, security
Setting up Update Process
Determining fastest mirrors
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/repo/arch combination/
removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/6/base/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: base

Cause

CentOS 6 reached end of life on the 30th November 2020. YUM attempting connect to deprecated repositories. So, we need update deprecated repositories URL’s and point to the vault.

Resolution

To fix this problem you edit /etc/yum.repos.d/CentOS-Base.repo and replace all mirrorlist

1. Go to /etc/yum.repos.d/ directory:

# cd /etc/yum.repos.d/

2. Make copy of original file:

# cp CentOS-Base.repo CentOS-Base.repo.old

3. Open and edit file with any text editor:

# vi CentOS-Base.repo

4. Replace mirrorlist‘s

Replace sections:

[base]
[updates]
[extras]

With following:

[base]
name=CentOS-$releasever - Base
# mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
# baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
baseurl=https://vault.centos.org/6.10/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

# released updates
[updates]

name=CentOS-$releasever – Updates # mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
# baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ baseurl=https://vault.centos.org/6.10/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 # additional packages that may be useful

[extras]
name=CentOS-$releasever – Extras # mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra
# baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ baseurl=https://vault.centos.org/6.10/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

5. Clean yum cache

# yum clean all

6. Run again yum update command:

# yum update

Now you can successfully update your CentOS 6.

Source: https://arstech.net/centos-6-error-yumrepo-error-all-mirror-urls-are-not-using-ftp-http/

Getting error The server selected protocol version TLS10 is not accepted by client preferences.

Solution:

1. Go to folder C:\Program Files (x86)\Java\jre1.8.0_291\lib\security In file java.security 
2. Find the option named jdk.tls.disabledAlgorithms
3. Delete wording TLSv1

All work with media such as templates for creating the virtual servers should be performed on the master server.

At first, upload the templates to the master node at:

• KVM: /home/solusvm/kvm/template/# ls -lahd /home/solusvm/kvm/template/drwxr-xr-x 2 root root 4.0K Jun 3 11:25 /home/solusvm/kvm/template/
• Xen: /home/solusvm/xen/template/# ls -lahd /home/solusvm/xen/template/drwxr-xr-x 2 root root 4.0K May 26 09:53 /home/solusvm/xen/template/
• OpenVZ: /vz/template/cache/# ls -lahd /vz/template/cache/drwxr-xr-x 2 solusvm solusvm 4.0K May 31 07:57 /vz/template/cache/

For OpenVZ 7 node, directory /vz/template/cache should be created and owned by solusvm:solusvm

mkdir -p /vz/template/cache

chown solusvm.solusvm /vz/template/cache/

Source: https://documentation.solusvm.com/display/BET/Uploading+the+templates+to+the+Master+Node

---

Adding OpenVZ EZ templates

1. Access OpenVZ 7 node via SSH and install required template with the command:Install required template

yum install centos-7-x86_64-ez

The template name always has the structure {distribution}-{release}-{arch}-ez. As an example centos-7-x86_64-ez

2. Access the master node via SSH and create a file under /vz/template/cache directory.
The file name should be a template name with tar.gz extension. In our example the name would be centos-7-x86_64-ez.tar.gz:Create a file

touch /vz/template/cache/centos-7-x86_64-ez.tar.gz

Or simply download from here:
https://www.whatuptime.com/downloads/openvz-virtuozzo-7-templates/

source: https://documentation.solusvm.com/display/BET/Adding+OpenVZ+EZ+templates

###Custom PHP.ini options

vi /etc/cl.selector/php.conf

###Add following lines
Directive = date.timezone
Default = Asia/Bangkok
Type = list
Range = Europe/London,Asia/Bangkok
Comment = To select timezone

Source: https://docs.cloudlinux.com/cloudlinux_os_components/#custom-php-ini-options

###Custom Global PHP.ini options

vi /etc/cl.selector/global_php.ini

###Add following lines
[Global PHP Settings]
date.timezone = Asia/Bangkok

###Execute command below to take the effect
selectorctl –apply-global-php-ini date.timezone

Source: https://docs.cloudlinux.com/cloudlinux_os_components/#configuring-global-php-ini-options-for-all-alt-php-versions

Introduction

SSH can handle authentication using a traditional username and password combination or by using a public and private key pair. The SSH key pair establishes trust between the client and server, thereby removing the need for a password during authentication. While not required, the SSH private key can be encrypted with a passphrase for added security.

The PuTTY SSH client for Microsoft Windows does not share the same key format as the OpenSSH client. Therefore, it is necessary to create a new SSH public and private key using the PuTTYgen tool or convert an existing OpenSSH private key.

Requirements

• PuTTY SSH client for Microsoft Windows
• Remote server accessible over OpenSSH

Install PuTTY And PuTTYgen

Both PuTTY and PuTTYgen are required to convert OpenSSH keys and to connect to the server over SSH. These two tools can be downloaded individually or, preferably, as a Windows installer from the PuTTY Download Page.

Once the PuTTY Windows installer is downloaded, double-click the executable in the Download folder and follow the installation wizard. The default settings are suitable for most installations. Both PuTTY and PuTTYgen should now be accessible from the Windows Programs list.

Use Existing Public And Private Keys

If you have an existing OpenSSH public and private key, copy the id_rsa key to your Windows desktop. This can be done by copying and pasting the contents of the file or using an SCP client such as PSCP which is supplied with the PuTTY install or FileZilla.

Next launch PuTTYgen from the Windows Programs list.

1. Click Conversions from the PuTTY Key Generator menu and select Import key.
2. Navigate to the OpenSSH private key and click Open.
3. Under Actions / Save the generated key, select Save private key.
4. Choose an optional passphrase to protect the private key.
5. Save the private key to the desktop as id_rsa.ppk.

If the public key is already appended to the authorized_keys file on the remote SSH server, then proceed to Connect to Server with Private Key.

Otherwise, proceed to Copy Public Key to Server.

Create New Public And Private Keys

Launch PuTTYgen from the Windows Programs list and proceed with the following steps.

1. Under Parameters, increase the Number of bits in a generated key: to a minimum value of 2048.
2. Under Actions / Generate a public/private key pair, click Generate.
3. You will be instructed to move the mouse cursor around within the PuTTY Key Generator window as a randomizer to generate the private key.
4. Once the key information appears, click Save private key under Actions / Save the generated key.
5. Save the private key to the desktop as id_rsa.ppk.
6. The box under Key / Public key for pasting into OpenSSH authorized_keys file: contains the public key.

Copy Public Key To Server

The OpenSSH public key is located in the box under Key / Public key for pasting info OpenSSH authorized_keys file:. The public key begins with ssh-rsa followed by a string of characters.

1. Highlight entire public key within the PuTTY Key Generator and copy the text.
2. Launch PuTTY and log into the remote server with your existing user credentials.
3. Use your preferred text editor to create and/or open the authorized_keys file:vi ~/.ssh/authorized_keys
4. Paste the public key into the authorized_keys file.ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQBp2eUlwvehXTD3xc7jek3y41n9fO0A+TyLqfd5ZAvuqrwNcR2K7UXPVVkFmTZBes3PNnab4UkbFCki23tP6jLzJx/MufHypXprSYF3x4RFh0ZoGtRkr/J8DBKE8UiZIPUeud0bQOXztvP+pVXT+HfSnLdN62lXTxLUp9EBZhe3Eb/5nwFaKNpFg1r5NLIpREU2H6fIepi9z28rbEjDj71Z+GOKDXqYWacpbzyIzcYVrsFq8uqOIEh7QAkR9H0k4lRhKNlIANyGADCMisGWwmIiPJUIRtWkrQjUOvQgrQjtPcofuxKaWaF5NqwKCc5FDVzsysaL5IM9/gij8837QN7z rsa-key-20141103
5. Save the file and close the text editor.
6. Adjust the permissions of the authorized_keys file so that the file does not allow group writable permissions.chmod 600 ~/.ssh/authorized_keys
7. Logout of the remote server.

Connect To Server With Private Key

Now it is time to test SSH key authentication. The PuTTYgen tool can be closed and PuTTY launched again.

1. Enter the remote server Host Name or IP address under Session.
2. Navigate to Connection > SSH > Auth.
3. Click Browse... under Authentication parameters / Private key file for authentication.
4. Locate the id_rsa.ppk private key and click Open.
5. Finally, click Open again to log into the remote server with key pair authentication.

Credit: https://devops.ionos.com/tutorials/use-ssh-keys-with-putty-on-windows/

For those who wants things to be done fast you can use the script:

cd ~
wget -O csf-bfm-install.sh https://raw.githubusercontent.com/poralix/directadmin-bfm-csf/master/install.sh
chmod 700 csf-bfm-install.sh
./csf-bfm-install.sh

For those who wants more control and do things manually please follow the guide below (the guide might miss certain updates, but the script will be updated whenever it’s needed).

A common method of gaining access over a server is to use a technique called a brute force attack, or dictionary attack. What the attacker will do, is use a script to try and login to an account with every possible password combination. This tends to require tens of thousands of login attempts, but eventually, the right combination will be found, and they can login normally.

To prevent this, we can use a brute force login detection system in DirectAdmin, so called BFM (Brute Force Monitor).

1. Install CSF/LFD if it’s not installed yet.

Run this as root if you unsure whether or not you have CSF/LFD installed:

csf -v

You’ve got it installed if you see output similar to this (go to step #2 in this case):

# csf -v
csf: v8.22 (DirectAdmin)

You’ve got to install it if you see output similar to this:

# csf -v
bash: csf: command not found

First download and unpack it:

cd /usr/local/src
wget https://download.configserver.com/csf.tgz
tar -zxvf csf.tgz
cd ./csf

Now it’s the right time to test whether or not your server is ready to run CSF/LFD:

# ./csftest.pl
Testing ip_tables/iptable_filter...OK
Testing ipt_LOG...OK
Testing ipt_multiport/xt_multiport...OK
Testing ipt_REJECT...OK
Testing ipt_state/xt_state...OK
Testing ipt_limit/xt_limit...OK
Testing ipt_recent...OK
Testing xt_connlimit...OK
Testing ipt_owner/xt_owner...OK
Testing iptable_nat/ipt_REDIRECT...OK
Testing iptable_nat/ipt_DNAT...OK

RESULT: csf should function on this server

If an output in your console differs much, you’d rather not install CSF and try another way of protecting your server.

Install it:

./install.directadmin.sh

And enable it. Update /etc/csf/csf.conf:

TESTING = "0"

Start it:

service csf start

Additionally you are advised to disable Login Failure Blocking in CSF/LFD as it will be Directadmin to care of it:

LF_TRIGGER = "0"
LF_SSHD = "0"
LF_FTPD = "0"
LF_SMTPAUTH = "0"
LF_EXIMSYNTAX = "0"
LF_POP3D = "0"
LF_IMAPD = "0"
LF_HTACCESS = "0"
LF_MODSEC = "0"
LF_DIRECTADMIN = "0"

2. To make Directadmin’s BFM compatible with CSF you should do the following:

cd /usr/local/directadmin/scripts/custom/
cp block_ip.sh block_ip.sh.bak
cp unblock_ip.sh unblock_ip.sh.bak

It’s OK if you have no block_ip.sh and unblock_ip.sh, and the previous step might fail with a warning:

cp: cannot stat `block_ip.sh’: No such file or directory
cp: cannot stat `unblock_ip.sh’: No such file or directory

Now fetch the files:

cd /usr/local/directadmin/scripts/custom/
wget -O block_ip.sh http://files.plugins-da.net/dl/csf_block_ip.sh.txt
wget -O unblock_ip.sh http://files.plugins-da.net/dl/csf_unblock_ip.sh.txt
wget -O show_blocked_ips.sh http://files.plugins-da.net/dl/csf_show_blocked_ips.sh.txt
chmod 700 block_ip.sh show_blocked_ips.sh unblock_ip.sh

Create the empty block list and exempt list files:

touch /root/blocked_ips.txt
touch /root/exempt_ips.txt

This last step is optional and should only be used after you’ve tested the above setup for a while to get comfortable that you’re not going to block yourself. The block_ip.sh is only used for an active “click” by the Admin, it does not automate blocking. To automate blocking, install the following script:

cd /usr/local/directadmin/scripts/custom
wget -O brute_force_notice_ip.sh http://files.directadmin.com/services/all/brute_force_notice_ip.sh
chmod 700 brute_force_notice_ip.sh

3. Update Settings in Directadmin

To make sure that BFM is enabled login as admin into the hosting panel, go to “Administrator settings” and bring the values to the following state (or similar):

IMPORTANT! Parse service logs for brute force attacks should be set to “Yes“! The other settings might be changed to meet your needs.

Save changes, and give a minute or so to changes to take effect. Now you’ve got Directadmin which will automatically block IPs of attackers with CSF.

4. Disable iptables (optional):

That was reported that raw iptables in some cases might overwrite existing rules loaded by CSF/LFD. To avoid it we’d recommend to disable iptables and ip6tables from being loaded at boot time:

CentOS 5, 6:

chkconfig iptables off
chkconfig ip6tables off

mv /etc/init.d/iptables /etc/init.d/iptables~moved
echo -e '#!/bin/bash\nexit 0;' > /etc/init.d/iptables
chmod 755 /etc/init.d/iptables

4. Disable firewalld (optional):

CentOS 7:

systemctl disable firewalld
systemctl stop firewalld

5. Suppress BFM messages (optional):

If you trust your software and security settings, then you will probably want to hide all those numerous emails about found Brute force attacks. And here is how you can achieve it:

echo "hide_brute_force_notifications=1" >> /usr/local/directadmin/conf/directadmin.conf

Restart directadmin.

6. The block_ip.sh script specs (for better understanding):

An IP of an attacker will be blocked with iptables via CSF if the following requirements are met:

1. BFM support is enabled in Directadmin and properly configured
2. CSF/LFD installed together with the aforementioned scripts to allow Directadmin to communicate with CSF.
3. IP exceeded max allowed number of login failures on any account.
4. IP is missing in brute force skip list (/usr/local/directadmin/data/admin/brute_skip.list).
5. IP is not white-listed in CSF permanently (/etc/csf/csf.allow). Any mention of an IP in the csf.allow will protect the IP from blocking.
6. IP is not temporary in allowed list of CSF (/var/lib/csf/csf.tempallow).

An IP can be blocked from accessing either any port on the server or only a list of ports of an attacked service. A switcher USE_PORT_SELECTED_BLOCK can be found in /usr/local/directadmin/scripts/custom/block_ip.sh. The default value is 1.

USE_PORT_SELECTED_BLOCK=1;  # SET TO 1 OR 0
                            # 1: TO BAN ACCESS ONLY TO A PORT WHICH
                            #    WAS BRUTEFORCED
                            # 0: TO BLOCK ACCESS TO ALL PORTS
                            #
                            # NOTICE: MANUAL TRIGGER FROM DIRECTADMIN
                            # WILL STILL BLOCK ACCESS TO ALL PORTS
                            # FOR AN IP

Used links:

• http://help.directadmin.com/item.php?id=380
• http://help.directadmin.com/item.php?id=404
• http://help.directadmin.com/item.php?id=1332
• https://help.poralix.com/articles/how-to-block-ips-with-csf-directadmin-bfm

Why is it so?

If Directadmin on your Linux server fails to create users on a remote or locally installed MySQL 5.7+ with an error “Unable to add access host”, an example of which is shown below:

Unable to add access host:

Details

Error executing query: Unknown column 'password' in 'field list'
Unable to find user='admin' and host='localhost'
Error executing query: Unknown column 'password' in 'field list'
Unable to find user='admin_test2' and host='localhost'
Error executing query: Unknown column 'password' in 'field list'
Unable to find user='admin_testdb' and host='localhost'

here you can learn on how to fix it.

In MySQL 5.7, the `password` field in `mysql`.`user` table was removed, and now the field name is `authentication_string`. Hence Directadmin drops the errors when it’s not informed that it’s connected to MySQL 5.7+ server, which is actual for our case since it’s installed remotely.

More details can be found here: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-6.html

How to solve it?

For MySQL 5.7, it should be using this: https://directadmin.com/features.php?id=1840

mysql_milestone_16=1

to swap the password column with authentication_string for password storage.

CustomBuild 2 should be doing that during the update when you install MySQL 5.7+ locally, so just double check it’s set in the /usr/local/directadmin/conf/directadmin.conf.

If MySQL 5.7 is remote, that might be why CustomBuild 2 didn’t notice.  In which case, using mysql_milestone_16=1 in the directadmin.conf should let DA swap the field correctly.

echo "mysql_milestone_16=1" >> /usr/local/directadmin/conf/directadmin.conf
service directadmin restart

That’s it.

Credit: https://help.poralix.com/articles/directadmin-unable-to-add-access-host-with-mysql-5-7

Symptoms

From time to time it is necessary to check the filesystem of a container in ploop format.

Cause

Due to various reasons, mainly because of a system crash or an incorrect replication level, the filesystem can became corrupted. As the result, the number of minor filesystem errors grows with time.

It can become necessary to check the filesystem in a ploop image for consistency to avoid data loss.

Resolution

To run fsck, follow the following steps:

1. Ensure the container is stopped:

   ~# vzctl stop 101
   ~# vzlist 101
   CTID      NPROC STATUS    IP_ADDR         HOSTNAME
   101          - stopped   10.10.10.11     fsck.test
   

   Note: Do not perform fsck when the container is running or mounted.

2. Mount the container’s ploop image. This allocates a ploop device on the host:

   ~# ploop check -F /vz/private/101/root.hdd/root.hdd
   ~# ploop mount /vz/private/101/root.hdd/DiskDescriptor.xml
   add delta dev=/dev/ploop12345 img=/vz/private/101/root.hdd/root.hds (rw)
   

3. Run fdisk -l for the /dev/ploopX device reported by the previous command. You will need to let the system fetch a list of partitions on /dev/ploopX:

   ~# fdisk -l /dev/ploop12345
   WARNING: GPT (GUID Partition Table) detected on '/dev/ploop12345'! The util fdisk doesn't support GPT. Use GNU Parted.
   Disk /dev/ploop12345: 10.7 GB, 10737418240 bytes
   255 heads, 63 sectors/track, 1305 cylinders
   Units = cylinders of 16065 * 512 = 8225280 bytes
   Sector size (logical/physical): 512 bytes / 512 bytes
   I/O size (minimum/optimal): 512 bytes / 512 bytes
   Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
   /dev/ploop12345p1               1        1306    10485759+  ee  GPT
   

4. Perform a file system check for the partition reported in the previous command’s output (note p1 at the end):

    ~# e2fsck -y /dev/ploop12345p1
   e2fsck 1.41.12 (17-May-2010)
   /dev/ploop12345p1: clean, 22404/655360 files, 238012/2620923 blocks
   

   Note: You may add more options to e2fsck, check the manual pages if needed.

   -p - Automatically repair the file system without any questions.
   -y - Assume an answer of `yes' to all questions.

5. Unmount the ploop image:

   ~# ploop umount -d /dev/ploop12345
   Unmounting device /dev/ploop12345
   

6. Start the container:

   ~# vzctl start 101

    

Credit: https://virtuozzosupport.force.com/s/article/000013760