Question: When I try to send mail using a PHP script in Cpanel, it automatically switches the SMTP hostname to localhost, even if I use a remote relay like sparkpost or mailgun. How to fix this?
Solution:
The reason behind the behavior is, by default Cpanel doesn’t let your customers use remote SMTP using PHP. This is controlled using a feature called ‘SMTP Restriction’. Go to WHM, log in using root, from Security Center select “SMTP Restrictions” and now, disable this. Your script shall now be able to send mail using remote SMTP like sparkpost/mailgun/pepipost.
Question: How can I see if the drives behind the hardware raid card using LSI has any reported error or not?
Solution
First, to find out if your drive raid arrays are optimal or not, you may run the following command:
[[email protected] ~]# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -Lall -aAll
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :dr1
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 931.0 GB
Sector Size : 512
Mirror Data : 931.0 GB
State : Optimal
Strip Size : 64 KB
Number Of Drives : 2
Span Depth : 1
Default Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Enabled
Encryption Type : None
Default Power Savings Policy: Controller Defined
Current Power Savings Policy: None
Can spin up in 1 minute: No
LD has drives that support T10 power conditions: No
LD's IO profile supports MAX power savings with cached writes: No
Bad Blocks Exist: No
Is VD Cached: No
Virtual Drive: 1 (Target Id: 1)
Name :
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 465.25 GB
Sector Size : 512
Mirror Data : 465.25 GB
State : Optimal
Strip Size : 64 KB
Number Of Drives : 2
Span Depth : 1
Default Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Enabled
Encryption Type : None
Default Power Savings Policy: Controller Defined
Current Power Savings Policy: None
Can spin up in 1 minute: Yes
LD has drives that support T10 power conditions: No
LD's IO profile supports MAX power savings with cached writes: No
Bad Blocks Exist: No
Is VD Cached: No
Exit Code: 0x00
This shall result in a key called ‘State’, which would say ‘Optimal’ if the raid is healthy. Although, it is possible that your drives have reported a few errors which might indicate a potential drive failure, which hasn’t been picked up by the RAID state yet. These errors are available under the following command:
/opt/MegaRAID/MegaCli/MegaCli64 pdlist a0
The above command lists the drive details. There are 3 error/failure counts, which are important to notice are ‘Media Error Count’, ‘Other Error Count’, and ‘Predictive Failure Count’. If you are seeing the number is changing quickly a few sets of times, then you should look at the drive status closely, as it seems to be producing a hardware failure soon. I have seen several times in my life, that the raid state saying it is ‘Optimal’, but the Media error was reported, soon after, we found the drive was actually failing.
To find out error counts in one go, you may use the following:
Installing Odoo 15 along with the CentOS 7 and the latest PGSQL repo has changed pretty a lot. I will try to cover solutions to a few errors along with the straightforward steps on installing Odoo 15 in CentOS 7.
First Step First
Update your CentOS 7 installation and install Epel-release
yum update -y
yum install epel-release
Install Python 3.8
We will use Python 3.8 for Odoo 15. We will use Software Collection Repository or SCL to install our Python binary. You may find details of SCL here:
Once done, you can now install Python 3.8 using the following:
yum install rh-python38 -y
Also, install python38-devel as Python.h is used to compile psycopg2 and python-ldap package. From Odoo 15, you need this to get going:
yum install rh-python38-python-devel -y
Note: The above is used to resolve an error like the following
fatal error: Python.h: No such file or directory
Now, we will install a few prerequisites to install Odoo 15. One difference between the old version installed and the new is that you need to load GCC-c+ now along with the GCC compiler. Otherwise, you will see an error like the following:
gcc: error trying to exec ‘cc1plus’: execvp: No such file or directory
So, to install the pre-requisites, run the following:
Once done, now can you initiate the PostgreSQL and start the database server
/usr/pgsql-13/bin/postgresql-13-setup initdb
systemctl start postgresql-13.service
systemctl enable postgresql-13.service
# create the postgres user odoo
su - postgres -c "createuser -s odoo"
Brilliant, now, one more additional thing we need to resolve. With the latest Postgresql 13, you might still not be able to use the libpq. You need to install it manually. Otherwise, you will see an error like the following:
fatal error: libpq-fe.h: No such file or directory
To resolve this error, you need to install these libraries manually with the following command:
yum install libpq5 libpq5-devel -y
Remember to install libpq5-devel as the source of the libpq would be used to compile psycopg2.
Install Wkhtmltox
Now, let’s move to the next step of installing wkhtmltox. The version for wkhtmltox has remained the same for pretty long. The following shall work till now:
cd /opt
wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6-1/wkhtmltox-0.12.6-1.centos7.x86_64.rpm
yum localinstall wkhtmltox-0.12.6-1.centos7.x86_64.rpm
This specific tool is used to generate reports in Odoo, without this, you might not be able to use pdf/html reports using Qweb in Odoo.
Final Step: Install and Configure Odoo 15
We will here download the source from Github and install all the dependent packages. First, we switch to the user odoo
su - odoo
Now, clone the git repo for Odoo 15 to a folder odoo15 using the following:
Once done, now, we can enable python3.8 and create a virtual environment for our Odoo installation. First, enable the Python3.8 using scl:
scl enable rh-python38 bash
Now create a virtual environment for our Odoo15 installation:
cd /opt/odoo
python3 -m venv odoo15-venv
Activate the virtual environment we just created
source odoo15-venv/bin/activate
Now, we upgrade the pip and install wheel package:
pip install --upgrade pip
pip3 install wheel
Now, before we can install the requirements file using pip3 package installer, here is an error you will face when compiling psycopg2
Error: pg_config executable not found.
Now the problem is understandable, pg_config file is usually placed under the binary folder of pgsql which is:
/usr/pgsql-13/bin
For some reason, our installer fails to identify this. To solve the issue, we first, load this in the $PATH variable before running pip3 for requirements.
export PATH=/usr/pgsql-13/bin/:$PATH
Now, you can run the pip3 installer:
pip3 install -r odoo15/requirements.txt
This shall be complete without any error if you have solved the solutions I had given above. If any of them are missed, you should double-check all the mentioned errors above.
Now exit the venv:
deactivate && exit ; exit
Now, the first step for configuration, edit the /etc/odoo.conf file
nano /etc/odoo.conf
Paste the following:
[options]
; This is the password that allows database operations:
admin_passwd = set_the_password_to_create_odoo_database
db_host = False
db_port = False
db_user = odoo
db_password = False
addons_path = /opt/odoo/odoo15/addons
; You can enable log file with uncommenting the next line
; logfile = /var/log/odoo15/odoo.log
Replace ‘set_the_password_to_create_odoo_database’ with the one you want to use to allow odoo installer to create the database for you.
Odoo15 Service File
Now, we will create a service file to start/stop/restart our Odoo 15 installation.
Unable to connect to any wifi with NetworkManager due to error: Secrets were required, but not provided
The reason the above error is showing is that NetworkManager is trying to reuse an existing connection, which shouldn’t happen. You need to delete the connection first.
You might see the following set of errors with Cpanel
When trying to remove the redirect from Cpanel
Apache detected an error in the Rewrite config. <pre>httpd_ls_bak: Syntax error in -C/-c directive: Include/IncludeOptional: Could not open directory /usr/local/apache/conf.modules.d: No such file or directory </pre> Please try again.
/scripts/rebuildhttpdconf generates an error like the following:
httpd: Syntax error in -C/-c directive: Include/IncludeOptional: Could not open directory /usr/local/apache/conf.modules.d: No such file or directory
Resolution
Previously, we reinstalled apache24 to solve the issue like the following:
yum reinstall ea-apache24
Although you may also reinstall the apache config runtime extension, that shall fix the issue as well.
Make sure to replace ‘/home/yourdomain.com/public_html/yourdomain.com/’ with the path of your home directory and ‘yourdomain.com’ with the original domain. This will show something like the following once the retrieve is done
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/yourdomain.com-0003/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/yourdomain.com-0003/privkey.pem
Your cert will expire on 2022-03-12. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
The noticeable thing is the following:
/etc/letsencrypt/live/yourdomain.com-0003/
This ends with 003 because this is the 3rd time, it is getting a certificate from Let’s Encrypt for the same domain.
Now, first go to /etc/letsencrypt/live and change this folder to yourdomain.com, and then restart lsws like the following:
cd /etc/letsencrypt/live
mv yourdomain.com yourdomain.com_old_1
mv yourdomain.com-003 yourdomain.com
service lsws restart
Cyberpanel is a popular web hosting panel that utilizes Openlitespeed as a web server.
Root password for Cyberpanel MySQL is stored under the following file:
/etc/cyberpanel/mysqlPassword
You may find the password with the following:
cat /etc/cyberpanel/mysqlPassword
Now, if you want to avoid finding and typing the root password every time you run MySQL command, you may do the following
Login to your ssh using the root username.
Make sure you are in the root directory for the user root
# cd
Now create a file called .my.cnf with the following content
# nano .my.cnf
File Content
[client]
user=root
password="fydEAhdoMu9WKW"
Now save the file and try commands like the following:
mysqladmin proc stat
It shall work without asking for a password.
NB. Cyberpanel 2.1.2, they are populating .my.cnf automatically. Hence, you can also find your root password from this file using the following while logged in as root:
My CPU is reporting underclocked eg. 2200Mhz while the actual CPU frequency is much higher (eg 3700Mhz for Ryzen 5600x)
Resolution
This issue appears because by default OpenVZ 7 / CentOS 7 uses a conservative approach to save your power. This approach is implemented using a tool called ‘CPUFREQ’. In OpenVZ 7, you can access this using the command ‘cpupower’.
CPUFreq comes with a set of profiles. There are profiles like ‘conservative’ or ‘ondemand’ which saves power for you by underclocking your CPU, while there is other profile, like ‘performance’ that gives the full power of your CPU.
By default, cpufreq uses ‘conservative’ or ‘ondemand’ profile, which is why you usually see the clock is under the maximum power you have.
To see the available governors or profile you have on your system, you may use the following:
cpupower frequency-info --governors
To see the cpufreq settings, you may see them from:
/sys/devices/system/cpu/[cpuid]/cpufreq/.
Replace cpuid with the CPU number.
Now, to change the underclocking of your CPU to the regular CPU clock, you may use the following command to set the governors to performance:
My disk is full. When using du, I could see my MySQL log folder is taking up all the disk. These files are not mysql-bin files, instead, these are mysql-relay-bin files. How can I truncate or purge these files?
Answer
Mysql creates mysql-bin files which are called binary files for MySQL on the master side. It then streams the binary files to the replicas to reflect the changes. Mysql doesn’t really store the binaries on the replica side, hence it is safe to delete the relay-bin files. Although, there are other safe strategies to accomplish this or never fall into a situation of ‘out of space’.
Firstly, we need to understand, expire_log_days MySQL attribute doesn’t work for the replica. The reason is simple, it doesn’t store the binary files. Hence, using this is worthless for replicas. You can’t use ‘PURGE’ SQL command either for Replica log purging. Replica has a special attribute ‘relay_log_purge’ which purges the relay-bin logs periodically. You can also set replica to follow a specific size of the log file by using ‘relay_log_space_limit’ attribute.
Now at a very certain time, if you want to free up space, other than gross and brutal deleting relay-bin log files, what you can do is the following:
# start your mysql console session
mysql
# stop the slave
stop slave;
# reset the slave
reset slave;
# now start the slave again
start slave;
Now, once the slave is reset, it will start streaming the bin log from the “pos” it has in its queue to populate the pending jobs.
Once the sync is done, you may check the replica status using:
show slave status \G;
Make sure the following two are set to yes:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
If not, you should look at the ‘Last_SQL_Error’ or ‘Last_IO_Error’ section to find out why these are not pushing.
After installing cyberpanel, you see the below error from shell when running any command:
** (pkttyagent:8559): WARNING **: 02:28:34.621: Unable to register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Cannot determine user of subject
Error registering authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Cannot determine user of subject (polkit-error-quark, 0)
Resolution:
The error is appearing because cybepranel adds the following line in your fstab:
proc /proc proc defaults,hidepid=2 0 0
This is hiding the /proc from your shell that uses polkit. To fix this, keeping the above mount rule, you need to add a group for polkitd user and assign that group to to access /proc. You may do this using the following:
groupadd nohidepoc
usermod -a -G nohideproc polkitd
mount -o remount,rw,hidepid=2,gid=nohideproc /proc
systemctl restart polkit
systemctl restart polkit (do this twice)
Once done, you may edit your fstab, and comment the old line, add the following line:
# Edit your fstab:
nano /etc/fstab
# comment the following line :
from : proc /proc proc defaults,hidepid=2 0 0
to : # proc /proc proc defaults,hidepid=2 0 0
# add the following line
proc /proc proc defaults,hidepid=2,gid=nohidproc 0 0
