How to Fix Locale Font Issue with Odoo Qweb Reports

Issue

When looking at the html report in Odoo, locale fonts look ok, but if you download the Qweb report to print in pdf format, it prints gibberish. How to fix that?

Resolution

Odoo uses a templating engine for reporting called ‘Qweb’. Qweb can be used to generate two types of reports. One is HTML and the other is PDF. Odoo primarily uses Qweb engine to generate the HTML code. After that, it uses a tool called ‘wkhtmltopdf’ to convert the report to pdf and make it printable. Now when, we look at the HTML version of the report, fonts are shown based on Unicode supported browsers or the fonts you have installed on your computer. But when you try to convert this to PDF using wkhtmltopdf, that tool has to have exclusive access to those fonts to be able to convert them from HTML to pdf for you. As wkhtmlpdf command runs in the server you have installed Odoo, hence, you would need to install the font package in the server.

In my case, I required to install Bengali fonts. For CentOS, it is available under the lohit package, that contains several indian fonts including bengali. To install bengali font package in CentOS 7, use the following command:

yum install lohit-bengali* -y

Once done, your wkhtmltopdf should be able to read the bengali fonts from your html/qweb templates and able to convert them to PDF for you.

How to find wifi password from saved wifi connection in Windows 10

You may get the password from using ‘netsh’ windows command. First go to your windows 10 search box, and type ‘cmd’

Now, from the result, there should be an option called ‘Command Prompt’, right click on it, and ‘Run as administrator’. Now on the black command prompt, type the following:

netsh wlan show profile "your wifi name" key=clear

Replace the part “your wifi name” with your one. So, for example if you connect to a wifi connection that has a name ‘Mellowhost_Portable’, then the command should be like the following:

netsh wlan show profile "Mellowhost_Portable" key=clear

This shall show you the full profile of your wifi details, including the password. Password should be available under the ‘Security Settings’, inside the ‘Key Content’ section.

Hope it helps.

How to Speed Up Software RAID (mdadm) Resync Speed

mdadm is the software raid tools used in Linux system. One key problem with the software raid, is that it resync is utterly slow comparing with the existing drive speed (SSD or NVMe). The resync speed set by mdadm is default for regardless of whatever the drive type you have. To view the default values, you may run the following:

[[email protected] ~]# sysctl dev.raid.speed_limit_min
dev.raid.speed_limit_min = 1000
[[email protected] ~]# sysctl dev.raid.speed_limit_max
dev.raid.speed_limit_max = 200000

As you see, the minimum value starts from 1000 and can max upto 200K. Although, it can max upto 200K, but as min value is too low, mdadm always tries to keep the value below average to your speed available. To speed up, we would like to maximize these numbers. To change the numbers, you may run something like the following:

sysctl -w dev.raid.speed_limit_min=500000
sysctl -w dev.raid.speed_limit_max=5000000

Once done, you may now check the speed is going up immediately:

[[email protected] ~]# cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sdb5[1] sda5[0]
      1916378112 blocks super 1.2 [2/2] [UU]
      [===============>.....]  resync = 76.2% (1461787904/1916378112) finish=27.4min speed=276182K/sec
      bitmap: 5/15 pages [20KB], 65536KB chunk

md0 : active raid1 sdb1[1] sda1[0]
      1046528 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md2 : active raid1 sda2[0] sdb2[1]
      78576640 blocks super 1.2 [2/2] [UU]
      bitmap: 1/1 pages [4KB], 65536KB chunk

md1 : active raid1 sdb3[1] sda3[0]
      4189184 blocks super 1.2 [2/2] [UU]

unused devices: <none>

One thing to keep in mind is that, if you try to set the value too high, like we did, this might cause some handsome load on your system. If you see the load is unmanageable, you should focus on decreasing the number to something like 50k-100k for the min value.

Making The Sysctl Value Permanent

As we have established the kernel variable values on runtime, this would go back to default once we restart/reboot the server. If you want to persist the values, you need to put these values to /etc/sysctl.conf file. To make them persist, open the sysctl.conf file:

nano /etc/sysctl.conf

Add the following lines at the end of the file:

dev.raid.speed_limit_min = 500000
dev.raid.speed_limit_max = 5000000

Save the file, and run the following command:

sysctl -p

This should persist your values for those variables after the reboot as well as runtime.

-bash: smartctl: command not found

Error Details

When I try to check the S.M.A.R.T details of my drive, using the following command:

smartctl -a /dev/sda

I get an error:

-bash: smartctl: command not found

What can I do?

Solution

This error is appearing because you do not have the S.M.A.R.T tools installed on your system.

How to Install Smart tools on CentOS 7?

To install smart tools, you can run the following:

yum install smartmontools -y

Once done, you may run the smartctl command again, and it shall work:

[[email protected] ~]# smartctl -a /dev/sda
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1127.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Crucial/Micron BX/MX1/2/3/500, M5/600, 1100 SSDs
Device Model:     Micron_1100_MTFDDAK2T0TBN

Server Boots to Grub – OVH Servers – How to Fix

Error Details

After you have completed updating your yum, you saw the kernel got updated, and hence restarted the server to take the new kernel. But you find out that the server has never come online. Once you visit the KVM or Serial Console (SOL) of the system, you could see, your system is booted to ‘grub>’ console instead of booting from disk. How can you fix the system now?

Solution Intro

This specific issue can appear for any linux server, along with many reasons. Although, if you are running an server from OVH and had faced a similar issue, the boat I am going to show you can navigate to destination. Please note, in many other case of similar situation, you might end up fixing the grub with the same solution.

What and How the Problem Happened

OVH has an interesting strategy of booting. They follow everything through network PXE, even if it is not ‘netboot’, but just the local drives. For this to work out, you need PXE to take the latest grub details pushed once a kernel is updated. This is one reason why, OVH also supplies a custom kernel from a cusstom repo. Although, if you are using the stock kernel, you might come up with a situation, where the latest grub hasn’t been pushed to PXE and your system fails to boot from drives. It then puts you in the ‘grub’ of network.

How to Fix the Problem

Now, one thing is clear, after you completed a kernel update, your grub is broken due to the latest machine code is not available to the booting system. You can go and follow a regular grub repair method for Grub 2, to fix the situation. A couple of things to remember, as your system’s grub is failing to load, you have to use an independent rescue kernel to fix this, this could either be from a personal network repository or a rescue disk available from your datacenter’s location, like ovh has one. Another thing to remember, is that, if you are using CentOS 7 or Ubuntu with UEFI system, using mdadm or linux software raid, it is highly likely, your boot efi is placed in a non raid partition. Preferably in the first drive’s first partition. You can always verify this from your fstab file.

So the first job, is to boot your system into the rescue disk/cd/kernel. I assume you have done that with no difficulty. Once done, first mount your partitions. In OVH cases, it loads the mdadm automatically. In my case, it was /dev/md2.

mount /dev/md2 /mnt
# check what partition is used for /boot/efi
nano /mnt/etc/fstab
# in my case, it is /dev/nvme0n1p1 (It is a NVMe SSD, and the first partion is used for efi storage
mount /dev/nvme0n1p1 /mnt/boot/efi

Once we have mounted the partitions successfully, you may now chroot the system. Before chrooting, you want the dev, proc and sys to use the /mnt partitions respectively:

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

If these all goes well, now we can chroot the system:

chroot /mnt

Now you have successfully changed the root directory of the rescue kernel to the original drive’s root. All you need to do, is to remake the grub config, that will immediately generate the grub.cfg file and sync the machine code:

# we know grub.cfg is available in /boot/grub2/grub.cfg
grub2-mkconfig -o  /boot/grub2/grub.cfg
# once this is finished, we have to make sure, grub is also installed for both disks, for my case, these are /dev/nvme0n1 and /dev/nvme1n1
grub2-install /dev/nvme0n1
grub2-install /dev/nvme1n1

If you see the response is ‘No Error Reported’, then you are good go. You may now reboot your system back to hard disk, and can see your grub is able to load the latest kernel you installed from the original hard disk. Remember, for safety, you should umount all the partition, to avoid any data loss due to OS page cache:

# exit from chroot
exit
# unmount dev, proc, sys, /mnt/boot/efi, /mnt
umount /dev
umount /proc
umount /sys
umount /mnt/boot/efi
umount /mnt

Happy troubleshooting!

Error: Package: 1:ea-php74-php-cli-7.4.15-1.el7.cloudlinux.x86_64 (cl-ea4) – Requires: ea-openssl11 = 1:1.1.1h

Error Details

The error appears when you try to run easyapache or try to install PHP 7.4 on Cloudlinux 7.9, it puts you on the following error:

Error: Package: 1:ea-php74-php-cli-7.4.15-1.el7.cloudlinux.x86_64 (cl-ea4)
Requires: ea-openssl11 = 1:1.1.1h
Installed: 1:ea-openssl11-1.1.1i-1.el7.cloudlinux.x86_64 (@cl-ea4)
ea-openssl11 = 1:1.1.1i-1.el7.cloudlinux
Available: 1:ea-openssl11-1.1.1d-1.el7.cloudlinux.x86_64 (cl-ea4)
ea-openssl11 = 1:1.1.1d-1.el7.cloudlinux
Available: 1:ea-openssl11-1.1.1f-1.el7.cloudlinux.x86_64 (cl-ea4)
ea-openssl11 = 1:1.1.1f-1.el7.cloudlinux
Available: 1:ea-openssl11-1.1.1g-1.el7.cloudlinux.x86_64 (cl-ea4)
ea-openssl11 = 1:1.1.1g-1.el7.cloudlinux
Available: 1:ea-openssl11-1.1.1h-1.el7.cloudlinux.x86_64 (cl-ea4)
ea-openssl11 = 1:1.1.1h-1.el7.cloudlinux

Error Fix:

It is trying to look into a sub-sub version of openssl, which is 1h for PHP 7.4, but 1i is installed by default which is not an exact match with 1h, hence the error is appearing. To fix the problem, you can not just run yum update on openssl and fix this as you technically already have the latest version. To work with this, you need to first uninstall the ea-openssl rpm and install the require version. You may do this in the following way:

[[email protected] yum.repos.d]# rpm -qa|grep ea-openssl
ea-openssl11-devel-1.1.1i-1.el7.cloudlinux.x86_64
ea-openssl-1.0.2u-1.el7.cloudlinux.x86_64
ea-openssl11-1.1.1i-1.el7.cloudlinux.x86_64
[[email protected] yum.repos.d]# yum install ea-openssl11-1.1.1h-1.el7.cloudlinux.x86_64
Loaded plugins: fastestmirror, rhnplugin, universal-hooks
This system is receiving updates from CLN.
Loading mirror speeds from cached hostfile
 * cpanel-plugins: 185.125.185.32
 * cloudlinux-x86_64-server-7: xmlrpc.cln.cloudlinux.com
Package matching 1:ea-openssl11-1.1.1h-1.el7.cloudlinux.x86_64 already installed. Checking for update.
Nothing to do

Fix it with the following:

[[email protected] yum.repos.d]# rpm -e --nodeps ea-openssl11-1.1.1i-1.el7.cloudlinux.x86_64
[[email protected] yum.repos.d]# yum install ea-openssl11-1.1.1h-1.el7.cloudlinux.x86_64

Remember to use rpm uninstaller instead of yum remove, as yum also removes the dependencies, but with rpm you can skip the dependency uninstallation and patch it the above way.

How to Update PATH Variable in Linux

A PATH variable is a system variable that stores the information about the binary files location that you may run for commands. When you log in as an user, or use a custom control panel like Plesk/Cyberpanel/Cpanel, you might want to add some custom paths as a user to take binary commands. One of the example, could be to change the default php path, or a laravel command location from vendor folder. To do this, you need to extend/update the PATH variable for a specific user.

PATH variable extends with the “:”. If you type the following, in your shell, you may see the existing paths in the PATH variable:

[[email protected] ~]$ echo $PATH
/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

Now, if I want to extend this to take the php binary available in /opt/plesk/php/7.2/bin/php, then we can extend the PATH variable using the following:

PATH=$PATH:/opt/plesk/php/7.2/bin/

Now, if you check, the PATH variable again, you can see it is added:

[[email protected] ~]$ echo $PATH
/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/plesk/php/7.2/bin/
[[email protected] ~]$

We have successfully modified the PATH variable, but only for the existing session. If you want to persist the changes, then, you need to add the command in .bashrc/.profile/.bash_profile file depending on your shell type and OS. You can add to either of the file and test with the following command:

[[email protected] ~]$ echo "PATH=$PATH:/opt/plesk/php/7.2/bin/" >> .profile

Replace .profile with .bashrc or .bash_profile depending on the file that works for you. You may logout and relogin, and then run the echo command again to see if the $PATH is persisting or not.

How to Copy a Disk Over SSH?

First, let’s see why do we need to copy a disk over SSH. One is of course for backup. For example if you have a VM on a LVM partition. You want to keep a copy of the block level backups, you prefer to create a snapshot of the lvm partition and then copy the disk as an image to your backup server. The other being quite the same, but for different purpose. What if you want to migrate a VM that you have created on an LVM partition, and then you want to migrate it as a raw file to another server? Or a LVM partition to another server? For those cases, the technique is pretty awesome.

Copy The Disk to a RAW Image

First, let’s learn how can copy a disk as raw image.

For example, you are sitting in your backup server. And you want to copy a disk or lvm partition or a partition of a disk, from a remote server to your backup server. And you want to keep the copy of the image, then you may run dd command as following from your backup server:

ssh [email protected] "dd if=/dev/vg0/v1092-kdkdksjuekksq" | dd of=/backup/v1092.raw

In our case, 10.10.10.10 is the IP of the server, that partition/disk currently reside. We are trying to copy a LVM partition namely: /dev/vg0/v1092-kdkdksjuekksq, just replace this one with the one your desired lvm partition. You may also do this for a disk like /dev/sda, the command would be like the following then:

ssh [email protected] "dd if=/dev/sda" | dd of=/backup/v1092.raw

Now as you have copied the disk/partition, you may look at what the partition holds by checking the data inside it. To know, how to mount a raw disk image, you may check the following:

How-to-Mount-raw-VM-disk-images-KVMorXenorVMW

Copy The Disk To Another Remote Disk over SSH

You may either copy the disk directly to a secondary disk you have on the backup/migrated server or dump the image that you copied to another disk/partition of same size or bigger. To copy directly a partition /dev/sda from another server, to a backup server with the secondary disk /dev/sdb, you may do the following:

ssh [email protected] "dd if=/dev/sda" | dd of=/dev/sdb

This would backup /dev/sda from 10.10.10.10 and restore to /dev/sdb drive you have on the server that ran the command.

To just dump the image file, that copied earlier on the other example to /dev/sdb, you may do the following:

dd if=/backup/v1092.raw of=/dev/sdb

Hope this helps.

How to reset root password in CentOS 7

Resetting admin password in CentOS 7 is different than of CentOS 6, as CentOS 7 utilized Grub 2 and has a different procedure to access Single User Mode. First, boot your system in Single User Mode to reset the root password by following the below tutorial:

Once done, now, you may first chroot the system:

chroot /sysroot

Now, you may reset the password using the following:

passwd root

You should be done. If you are using SELinux, then you need to relabel accordingly:

touch /.autorelabel

Then, exit chroot and reboot the system:

exit && reboot

You should be done now.

How to boot CentOS 7 in Single User Mode

Booting CentOS 7 in single user mode is total different than of CentOS 6 as it uses a different version of Grub. We will go step by step to boot into single user mode in CentOS 7.

  1. First, boot the screen and press an arrow key while the timer comes on this screen to stop the timer

    CentOS 7 Boot Screen

  2. Press ‘e’ on the selected default CentOS version. That will take you to the following screen

    CentOS 7 Boot Edit Screen

  3. These are grub commands that the bootloader is using to boot you to the system. Arrow down in this window to the line, that starts with linux16. Now take the right arrow on the keyboard to take your cursor to the word that says ‘ro’ as shown in the image

    Linux16 Command Boot

  4. Now replace ro with rw init=/sysroot/bin/sh as shown below

    CentOS 7 Boot Sysroot

  5. Now press Ctrl + x to start Single User Mode

    Boot in Single User Mode CentOS 7

You should be done now, you are on the single user mode console. If you would like to use the main system, you may chroot as the following:

chroot /sysroot

Now, if you are trying to reset the root password, after booting into the single user mode, you may follow the following to reset the root password: