Expanding / partition in Linux operating system live with no downtime

I had a disk that was not fully expanded. It only partitioned 4.8GB to the /. So I wanted to expand it live, with no downtime, or data loss. Either way, I would ALWAYS back up the data before doing this even you care about it at all. Either way you should have backups if you want to keep it regardless. I tested this just now with Almalinux 8, but I imagine it would work for a slew of other operating systems, as you only need fdisk and resize2fs, which all come with most operating systems.

I will say it one more time before we start, BACK UP YOUR DATA, always. And test those backups.

df -h to check current disk size or fdisk -l /dev/vda1

[root@72 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.8G     0  3.8G   0% /dev
tmpfs           3.8G     0  3.8G   0% /dev/shm
tmpfs           3.8G  395M  3.5G  11% /run
tmpfs           3.8G     0  3.8G   0% /sys/fs/cgroup
/dev/vda1       4.8G  3.8G  774M  84% /
tmpfs           777M     0  777M   0% /run/user/0

You will notice your mount pount/partition is tight or 100% used up. Expand that partition via KVM, VMWARE, Cockpit, Proxmox, etc. That is outside the scope of this article. It is technology dependent how you want to expand your disk. Once you’ve done that, you can reboot, or try running a rescan.

echo 1 > /sys/block/vda/device/rescan

Once that is done and you’ve expanded your disk, we can expand it. Drop into fdisk:

[root@72 ~]# fdisk /dev/vda

Welcome to fdisk (util-linux 2.32.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Then we will run through deleting the primary partition, and recreating it with the entire disk you now have. Here is the combo of letters to get through the prompts. I will follow it up with text I ran, as I prefer to see it in console. p, d, 1, n, p, 1 and then hit enter for default first and last sector. Then n to NOT remove the signature, and w to write it out.

Command (m for help): p
Disk /dev/vda: 250 GiB, 268435456000 bytes, 524288000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x318ba904

Device     Boot     Start       End   Sectors  Size Id Type
/dev/vda1  *         2048 507508351 507506304  242G 83 Linux
/dev/vda2       507508352 524285567  16777216    8G 82 Linux swap / Solaris

Command (m for help): d
Partition number (1,2, default 2): 1

Partition 1 has been deleted.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1,3,4, default 1): 1
First sector (2048-524287999, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-507508351, default 507508351):

Created a new partition 1 of type 'Linux' and of size 242 GiB.
Partition #1 contains a ext4 signature.

Do you want to remove the signature? [Y]es/[N]o: n

Command (m for help): w

The partition table has been altered.
Syncing disks.

Now that is done you can resize to expand it with resize2fs and run df -h once again to see the expansion complete.

[root@72 ~]# resize2fs /dev/vda1
resize2fs 1.45.6 (20-Mar-2020)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 31
The filesystem on /dev/vda1 is now 63438288 (4k) blocks long.

[root@72 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.8G     0  3.8G   0% /dev
tmpfs           3.8G     0  3.8G   0% /dev/shm
tmpfs           3.8G  395M  3.5G  11% /run
tmpfs           3.8G     0  3.8G   0% /sys/fs/cgroup
/dev/vda1       239G  3.8G  225G   2% /
tmpfs           777M     0  777M   0% /run/user/0
[root@72 ~]#

Boom, enjoy.


Setting up openVPN client on your pfSense (Surfshark)

Surfshark provides a cheap VPN service that allows unlimited number of devices with ad blocking. In this tutorial we are going to configure pfSense with Surfshark and assign an interface to it so that we can route it to other services.

Surfshark information

The first step is getting your Surfshark credentials. Go to the login page at  and log in. Next, go to Advanced >> Devices >> Manual, scroll down to the bottom of the page and take note of your service credentials.

On the same page of your account, you will find the list of all configuration files and domain name of their servers grouped by country/continent. Take this opportunity and copy the domain URL of the locations you want to use later on.

pfSense configuration

Once you are logged in on your pfSense, go to System >> Cert. Manager >> CAs and click on Add to create a new Certificate Authority as follows:

Descriptive Name: Surfshark_VPN
Method: Import an existing Certificate Authority
Certificate data:


Once you are done, click on Save.

The next step is creating the VPN client connection. Navigate to VPN >> OpenVPN >> Clients and press Add.

General Information

Disable this client: leave unchecked
Server mode: Peer to Peer (SSL/TLS)
Protocol: UDP on IPv4 only (you can also use TCP)
Device mode: tun – Layer 3 Tunnel Mode
Interface: WAN
Local port: leave blank;
Server host or address: The server address that you want to connect (e.g.
Server port: 1194 (use 1443 if you use TCP)
Proxy host or address: leave blank
Proxy port: leave blank
Proxy Authentication: None
Description: Any name you like (e.g. Surfshark US Seattle)

User Authentication Settings

Username: Username from Surfshark account
Password: Password from Surfshark account
Authentication Retry: unchecked

Cryptographic Settings

TLS Configuration: Check
Automatically generate a TLS Key: Uncheck
TLS Key:

-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----

TLS Key Usage Mode: TLS Authentication
Peer certificate authority: Surfshark_VPN
Peer Certificate Revocation list: do not define

Client certificate: webConfigurator default
Encryption Algorithm: AES-256-GCM
Enable NCP: Check
NCP Algorithms: AES-256-GCM and AES-256-CBC
Auth digest algorithm: SHA512 (512-bit)
Hardware Crypto: No hardware crypto acceleration

Tunnel Settings

IPv4 tunnel network: leave blank
IPv6 tunnel network: leave blank
IPv4 remote network(s): leave blank
IPv6 remote network(s): leave blank
Limit outgoing bandwidth: leave blank
Compression: Omit Preference (Use OpenVPN Default)
Topology: Subnet – One IP address per client in a common subnet
Type-of-service: leave unchecked
Don’t pull routes: checked
Don’t add/remove routes: checked

Ping settings

Inactive: 0
Ping method: keepalive
Interval: 10
Timeout: 60

Advanced Configuration

Custom options: paste the contents below

tun-mtu 1500;
tun-mtu-extra 32;
mssfix 1400;
reneg-sec 0;
remote-cert-tls server;

UDP FAST I/O: leave unchecked
Send/Receive Buffer: Default
Gateway creation: IPv4 only
Verbosity level: 3 (recommended)

Press Save at the bottom of the page and Apply changes at the top of the page. Navigate to Status >> OpenVPN to verify your VPN Client is working. Check Client Instance Statistics and verify your new VPN Client connection is listed and that the Status is up.

Using mssfix 1450 as recommended by Surfshark caused constant connection drops. In this post we also checked both Don’t pull routes and Don’t add/remove routes boxes and created manual firewall rules to fit our scenario with multiple LANs, VLANs, etc.

Assigning interface to the VPN client connection

Navigate to Interfaces >> Interface Assignments and Add Surfshark VPN interface.

Press on the OPT1 to the left of your assigned interface and fill in the following information:

Enable: check
Description: Surfshark VPN
MAC Address: leave blank
MTU: leave blank
MSS: leave blank

Do not change anything else. Just scroll down to the bottom and press Save and Apply Changes.

Configuring DNS

This section will assume your DNS is already configured through a previous post. The next steps are just additional setting to include the VPN client on a working DNS Resolver instance.

Navigate to Services >> DNS Resolver >> General Settings and make sure that at Outgoing Network interfaces you either select All or also append your new VPN client interface as an outgoing interface. Do not remove any other interface from this list!

Enable: must already be checked
Outgoing Network Interfaces: Surfshark VPN
Register connected OpenVPN clients in the DNS Resolver: checked

Click Save and Apply Changes.

Configuring NAT

Navigate to Firewall >> NAT -> Outbound and select Hybrid Outbound NAT rule generation. (Automatic Outbound NAT + rules below). Press Save and Apply Changes. Now we can create our rules for the new VPN client by clicking on Add (down arrow):

Edit Advanced Outbound NAT Entry
Interface: SurfsharkVPN or whatever you called it
 your LAN network (e.g.
Description: A nice name, such as NAT outbound for Surfshark US Seattle

Press Save and Apply changes.
Now click on Add (down arrow) again to create one more rule for ISAKMP IPsec VPN traffic:

Edit Advanced Outbound NAT Entry
Interface: Surfshark VPN or whatever you called it
 same LAN network from previous rule (e.g.
Destination >> Port or Range: 500
Port or Range >> Static Port: checked
Description: A nice name, such as Manually created for ISAKMP – Surfshark US Seattle

Press Save and Apply changes.

Note that if you have multiple LANs, like me, you will need to repeat this process for each one.

Configuring Firewall

Navigate to Firewall >> Rules page and click on the Interface name you created in the previous steps. Next, click on Add to create a new firewall rule that allows any traffic to go through:

Action: Pass
Address Family: IPv4 (I am not using IPv6 on my homelab yet)
Protocol: Any
Destination: Any

Press Save and Apply changes.

You can repeat the steps above for different Server locations from Surfshark.

Now that everything is done, let’s test it. Navigate to Diagnostics >> ping:

IP Protocol: IPv4
Source Address: Select the VPN Client interface
Maximum number of pings: 3

Click Ping and check the results. Should be something like

PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=120 time=1.978ms
64 bytes from icmp_seq=1 ttl=120 time=2.670ms
64 bytes from icmp_seq=2 ttl=120 time=1.940ms

--- ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.940/2.196/2.670/0.336 ms

Passing traffic through the VPN

At this point, your VPN connection is up and running, but not really in use by pfSense. There are a couple options in how to start using the VPN. In this post I will cover how to:

  1. Configure the VPN connection as the default gateway, so all traffic from your home goes through it
  2. Configure the VPN connection for specific IPs, so that only these ones goes through the new VPN client connection

Option 1: Using VPN connection as your default gateway

Navigate to Firewall >> Rules >> LAN and edit the default IPv4 rule, that is the rule that allows all traffic on your network. Its description will probably be something like Default allow LAN to any rule.

Scroll down to the bottom and press on Display Advanced at the Extra Options tab. Change Gateway to Surfshark VPN and click Save followed by Apply Changes.

Option 2: Configuring specific IPs to use the VPN

In order to use this approach, you need to reserve IP for the device(s) you want to route through the VPN. Navigate to Services >> DHCP Server >> LAN scroll down to DHCP Static Mappings for this Interface, click on Add and do as follows:

Static DHCP Mapping on LAN

  • MAC Address: xx:xx:xx:xx:xx:xx
    • You can find this at Status >> DHCP Leases page
  • Client identifier: The name that will show up in the DHCP lease page
    • You can use the hostname
  • IP Address: The static IP to use (e.g.
  • Hostname: The device host name
  • Description: A friendly description to identify the device

Click Save and Apply changes. Next, disconnect and reconnect the network cable of this device so that it can take the new IP. Repeat this steps for each device you want to put under the VPN.

Now that your devices have a static IP, navigate to Firewall >> Aliases >> IP and click on Add and do as follows:


  • Description: Devices which are required to go through a USA OpenVPN client connection
  • Type: Host(s)


  • IP or FQDN: <IP you want to put under the VPN> (e.g.
  • The hostname or description to help identifying the device

If you want to add more devices (hosts), click on Add Host and add the IP/FQDN + a description for each device.

When you are done, click on Save and Apply changes.

If you don’t have an alias called RFC1918 or Private_IPv4s created in previous posts, you will need to create it now. The goal for it is to help us identify what networks/IPs belong to your LAN and which belong to Internet (aka those not listed in RFC1918 or Private_IPv4s alias). Click on Add again and do as follows:

  • Properties
    • NameRFC1918 or Private_IPv4s
    • Description: All private IPv4 networks
    • Type: Networks
  • Network(s)

Press Save and Apply changes.

Lastly, we need to update the firewall rule so that it redirects clients to the VPN based on the alias we just created. The current rule must be something like “accept any connection coming from any device going to any destination and use the default gateway (your WAN connection) for them”. What we want is: If the incoming devices belong to the alias we created, use the VPN as gateway. Otherwise, use the default gateway. Note we need two rules and they must appear in this order.

Go to Firewall >> Rules >> LAN and click on copy icon of the default IPv4 rule, that is the rule that allows all traffic on your network to for from * (any) to * (any). Its description will probably be something like Default allow LAN to any rule.

A new window will open with the same settings as the rule used as base, which you need to change the following:


  • Invert match: unchecked
  • any: change it to Single host or alias
  • Source address: VPNCLIENT_USA_DEVICES (this is the first alias name)


  • Invert match: checked
  • any: change it to Single host or alias
  • Destination address: RFC1918 (this is the second alias name)

Extra Options

  • Description: Allow VPNCLIENT_USA_DEVICES to Internet rule through VPNClient_USA (assuming this is how you named your VPN interface)
  • Click on Display Advanced.

Advanced Options

  • Gateway: Select the interface you assigned to your VPN client connection

Click on Save. You probably have to move (drag and drop) the new rule before the one you copied it from. The rule that redirects traffic to the VPN must come before the default rule. Click on Save and Apply changes.

Optional: Using Surfshark’s DNS servers

As an additional step to protect your network, you can use Surfshark’s DNS server. For such, go to System >> General Setup >> DNS Server Settings and fill in:

DNS Server 1:
DNS Hostname: empty
Gateway: empty

DNS Server 2:
DNS Hostname: empty
Gateway: empty

Click Save and you are good to go. Test your anonymity by visiting and have fun!

ps: If DNSSec support is enabled on your DNS Resolver configuration, you may have a false DNS leak report. You can disable DNSSec support, do the test and re-enable later.

This is shamelessly taken from, but because his website kept going down I copy and pasted it so I can reference it here and share his lovely writeup.


librenms and oxidized plugin SSH issues

I was setting up LibreNMS (version 22.2.1 at time of writing) and found out that it also has a plugin called oxidized (version 0.28.0 at time of writing) that allows you to do back ups of configuration files. So I figured why not, let’s replace my dated rconfig setup. In my opinion oxidized is a bit archaic, but it seems to be based on an old tool called RANCID. So long story short, it is a bit on the YAML heavy side, it takes some manual configuration in shell. My oxidized config looks like this, for example:

# - keyboard-interactive

groups: {}
models: {}
pid: /home/oxidized/.config/oxidized/pid
  default: ssh
  debug: false
    secure: false
  default: file
    directory: /home/oxidized/.config/oxidized/configs
  default: csv
    file: /home/oxidized/.config/oxidized/router.db
    delimiter: !ruby/regexp /:/
      name: 0
      ip: 1
      model: 2
      username: 3
      password: 4
      ssh_kex: 5
      ssh_host_key: 6
      ssh_hmac: 7
      ssh_encryption: 8
      enable: 9
    gpg: false
  cisco: ios
  juniper: junos
  asa: asa

I kept getting KEX errors for my ASA when it was trying to log in:

raised Net::SSH::Exception (rescued RuntimeError) with msg "could not settle on kex algorithm"

My ASA router.db line looked like this (replacing xxxxx with actual passwords):


I knew this was a good KEX (diffie-hellman-group1-sha1), as I forced it via the ASA, and SSH worked via putty, or other switches on the network. It also worked for my cisco switches via oxidizer. For reference, my ASA is running 9.16(2)14 ASA and ASDM 7.17(1)152. I wanted to see what other options exist, so I ran show ssh:

madfw5# show ssh
Idle Timeout: 60 minutes
Version allowed: 2
Cipher encryption algorithms enabled: aes256-ctr aes256-cbc aes192-ctr aes192-cbc aes128-ctr aes128-cbc
Cipher integrity algorithms enabled: hmac-sha2-256

and my KEX checked my KEX:

madfw5#  sh run ssh
ssh stricthostkeycheck
ssh timeout 60
ssh version 2
ssh key-exchange group dh-group14-sha256

But I kept getting the error. Doing some digging, I saw oxidizer uses NET:SSH perl module, and their GIT is pretty updated, and it showed what algorithms were currently supported:

I saw ecdh-sha2-nistp256 was allowed and supported, which worked on the ASA, by tabbing out the option:

madfw5(config)# ssh key-exchange group ?

configure mode commands/options:
  curve25519-sha256   Diffie-Hellman group-31-sha256
  dh-group1-sha1      Diffie-Hellman group 2 (DEPRECATED)
  dh-group14-sha1     Diffie-Hellman group-14-sha1
  dh-group14-sha256   Diffie-Hellman group-14-sha256
  ecdh-sha2-nistp256  Diffie-Hellman group-19-sha256

Then forced it by finishing out the command in configure terminal mode:

madfw5# conf t
madfw5(config)# ssh key-exchange group ecdh-sha2-nistp256

so now it shows:

madfw5(config)# sh run ssh
ssh stricthostkeycheck
ssh timeout 60
ssh version 2
ssh key-exchange group ecdh-sha2-nistp256

good to go, now the ASA is backing up and running oxidizer, huzzah! I am still learning what else oxidizer can do. My next step is to enable git, so it will automatically upload new versions of the configuration files it backs up.


How to Install or Update PHP to 7.4 with ioncube on CentOS 7

I needed to upgrade my WHMCS host server to utilize PHP 7.4. I am coming from PHP7.3 and found it pretty straight forward of an upgrade. Also, 7.3 is end of life and only on security updates right now.

Step 1: First thing I would do is back up your server you are updating. If you can, do a snapshot.

Step 2: Update your server

yum install epel-release yum-utils -y
yum update -y

Step 3: Check the version of the PHP that is currently running.

php -v

Step 4: List all the PHP packages you have installed into a file, so you can refer to it to install all those packages in PHP 7.4

rpm -qa | grep php > /home/php_rpm_originals.txt

Step 5: Remove all the installed PHP packages

yum remove "php*" -y

Step 6: Install the updated Remi repository if it is not already installed.

yum install -y

Step 7: Enable the PHP 7.4 repository, install the core and required PHP packages. You can also refer to step 4 for the previously required packages.

yum --enablerepo=remi-php74 install php php-pdo php-fpm php-gd php-mbstring php-mysql php-curl php-mcrypt php-json php-bcmath php-tidy php-tcpdf php-xmlrpc -y

Step 8: Check the updated PHP version.

php -v

PHP 7.4.27 (cli) (built: Dec 14 2021 17:17:06) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
Step 9: Restart Apache to use the newly installed PHP 7.4

systemctl restart httpd

Step 10: Check what architecture you are running – in my case it was 64bit

uname -a

Linux 3.10.0-1160.53.1.el7.x86_64 #1 SMP Fri Jan 14 13:59:45 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Step 11: Download your version of the ioncube loaders

——————– For 64-bit System ——————–

cd /tmp


——————– For 32-bit System ——————–

cd /tmp


Step 12: unzip and move into the directory

tar -zxvf ioncube_loaders_lin_x86*
cd ioncube/
ls -ltrh

Step 13: Obtain your PHP location for modules.

php -i | grep extension_dir

extension_dir => /usr/lib64/php/modules => /usr/lib64/php/modules
Step 14: Copy the files you need, in our case it was 7.4.

cp /usr/lib64/php/modules

Step 15: Modify your php.ini file to include ioncube. I added mine at the top right below [PHP]. The line you want to add is:

zend_extension = /usr/lib64/php/modules/

vi /etc/php.ini

Once done editing, hit ESC and then type in :X and hit ENTER

Step 16: Restart apache or nginx/php-fpm servers
——————– Start Apache Web Server ——————–

systemctl restart httpd

——————– Start Nginx + PHP-FPM Server —————-

systemctl restart nginx
systemctl restart php-fpm

Verify install:

php -v

PHP 7.4.27 (cli) (built: Dec 14 2021 17:17:06) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with the ionCube PHP Loader + ionCube24 v11.0.1, Copyright (c) 2002-2022, by ionCube Ltd


Writing multiple lines of code to a file in linux

Sometimes it’s needed to create multiple files, repeatadly with linux. This should work with any of the major distros: CentOS, Ubuntu, Fedora, Debian, etc.

This also assumes the file does not exist already, if it does exist, it will append this info to the end of the file that already exists.

cat >> ifcfg-eth0 << EOF

You can now type cat ifcfg-eth0 and it will output the 4 lines above.

If that is not to your liking, you could always use something like echo with append statements. Like this:

echo "TYPE=Ethernet" >> ifcfg-eth0
echo "DEVICE=eth0" >> ifcfg-eth0
echo "BOOTPROTO=none" >> ifcfg-eth0
echo "ONBOOT=yes" >> ifcfg-eth0

The >> option appends the echo information into a file name. But if you do > it will overwrite all lines in the file.



CentOS 7 multiple VLANs on one interface

OK, so this was something I needed to do with CentOS 6:

This is how to do it in CentOS 7. There are some slight changes required compared to CentOS 6, but they’re nominal. It’s possible it will work for CentOS 8, but it is untested. Where there is a command like vi bla/bla/file you will enter the following information in the line.

vi /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.default.accept_source_route = 1
net.ipv4.conf.all.accept_source_route = 1

cd /etc/sysconfig/network-scripts/

vi ifcfg-em1

vi ifcfg-em1.29

vi ifcfg-em1.33

vi ifcfg-em1.35

vi ifcfg-em1.29-range

vi ifcfg-em1.33-range

vi ifcfg-em1.35-range

echo ‘default via dev em1.29 table 1’ > route-em1.29
echo ‘default via dev em1.33 table 2’ > route-em1.33
echo ‘default via dev em1.35 table 3’ > route-em1.35
echo ‘from tab 1 priority 500’ > rule-em1.29
echo ‘from tab 2 priority 501’ > rule-em1.33
echo ‘from tab 3 priority 502’ > rule-em1.35
echo ‘from table 1’ >> rule-em1.29
echo ‘from table 2’ >> rule-em1.33
echo ‘from table 3’ >> rule-em1.35
ip route add default via dev em1.29 table 1
ip route add default via dev em1.33 table 2
ip route add default via dev em1.35 table 3
ip rule add from tab 1 priority 500
ip rule add from tab 2 priority 501
ip rule add from tab 3 priority 502
ip rule add from table 1
ip rule add from table 2
ip rule add from table 3
ip route add default via
echo 'default via' > route-em1.15

cPanel absolute path for SFTP back up

My back up server uses keys, and SSH to allow for backups. By default, in my cPanel server running CENTOS 7.7 with v86.0.18 of cPanel, you really only have the option to do a path related to the SSH user’s home log in directory. My back up server has a mount point outside of /home/user/ so I needed to find a way to force it to go to /data/madhost613/ as an example.

Once you create your SFTP back up options under “backup settings” in the cPanel GUI, you can create an “additional destinations”. This will allow your back ups to be sent somewhere else.

I would advise using key based authentication when you set up SFTP as a destination. It is far more secure then password based authentication. Once you set up your SFTP and have validated it, SSH into your SOURCE server running cPanel to make the change to the validation configuration file. It should be in: /var/cpanel/backups/ The file itself will look simliar to this: backups_link_data_drive_UID_vxxxxxxxxxxxxxxxxxxxxxx Once you found it, edit it with your favorite editor. Which should be vi ;). In that configuration file is a path line, go ahead and modify it to your aboslute path. Mine now reads: path: /data/madhost613/ Some caveats with this, the SSH user must have r/w on that destination server. Once you make this change, you can run the validation in cPanel, and if successful, your back ups will be sent to that directory now.

cPanel informed me this should be an added feature at some point, but currently unknown when. But this work around works fine.


Upgrading CentOS 6 to CentOS 7

I am shamelessly stealing this from:

I wanted to keep this information around if their site goes tits up. I did this on a newly installed Cent OS 6.10 upgrade as of this morning and it worked fine. I had not tried it with odd packages installed, or abnormally outdated packages, so your mileage may vary. Good luck, and as always, no one “supports” this procedure, the best option to upgrade is a CLEAN install to CENTOS 8. At this point 8 is tried and true and will keep your server supported longer.


There are some tasks you can do to prevent from unwanted results. Like:

  • Disable selinux
  • Remove unnecessary repositories
  • Take a recent backup!


Create a new centos repository:

cat > /etc/yum.repos.d/centos-upgrade.repo <<EOF


First install the openscap version from

# yum -y install

then install the redhat upgrade tool:

# yum -y install redhat-upgrade-tool preupgrade-assistant-*


# rpm --import


to bypass errors like:

Downloading failed: invalid data in .treeinfo: No section: ‘checksums’

append CentOS Mirror under mirrorlist:

mkdir -pv /var/tmp/system-upgrade/base/ /var/tmp/system-upgrade/extras/ /var/tmp/system-upgrade/updates/

echo >> /var/tmp/system-upgrade/base/mirrorlist.txt
echo >> /var/tmp/system-upgrade/extras/mirrorlist.txt
echo >> /var/tmp/system-upgrade/updates/mirrorlist.txt


preupg is actually a python script!

# yes | preupg -v
Preupg tool doesn't do the actual upgrade.
Please ensure you have backed up your system and/or data in the event of a failed upgrade
that would require a full re-install of the system from installation media.
Do you want to continue? y/n
Gathering logs used by preupgrade assistant:
All installed packages : 01/11 ...finished (time 00:00s)
All changed files : 02/11 ...finished (time 00:18s)
Changed config files : 03/11 ...finished (time 00:00s)
All users : 04/11 ...finished (time 00:00s)
All groups : 05/11 ...finished (time 00:00s)
Service statuses : 06/11 ...finished (time 00:00s)
All installed files : 07/11 ...finished (time 00:01s)
All local files : 08/11 ...finished (time 00:01s)
All executable files : 09/11 ...finished (time 00:01s)
RedHat signed packages : 10/11 ...finished (time 00:00s)
CentOS signed packages : 11/11 ...finished (time 00:00s)
Assessment of the system, running checks / SCE scripts:
001/096 ...done (Configuration Files to Review)
002/096 ...done (File Lists for Manual Migration)
003/096 ...done (Bacula Backup Software)
/bin/tar: .: file changed as we read it
Tarball with results is stored here /root/preupgrade-results/preupg_results-180508202952.tar.gz .
The latest assessment is stored in directory /root/preupgrade .
Summary information:
We found some potential in-place upgrade risks.
Read the file /root/preupgrade/result.html for more details.
Upload results to UI by command:
e.g. preupg -u -r /root/preupgrade-results/preupg_results-*.tar.gz .
this must finish without any errors.


We need to find out what are the possible problems when upgrade:

# centos-upgrade-tool-cli --network=7 --instrepo=

Then by force we can upgrade to it’s latest version:

# centos-upgrade-tool-cli --force --network=7 --instrepo= --cleanup-post


setting up repos...
base | 3.6 kB 00:00
base/primary_db | 4.9 MB 00:04
centos-upgrade | 1.9 kB 00:00
centos-upgrade/primary_db | 14 kB 00:00
cmdline-instrepo | 3.6 kB 00:00
cmdline-instrepo/primary_db | 4.9 MB 00:03
epel/metalink | 14 kB 00:00
epel | 4.7 kB 00:00
epel | 4.7 kB 00:00
epel/primary_db | 6.0 MB 00:04
extras | 3.6 kB 00:00
extras/primary_db | 4.9 MB 00:04
mariadb | 2.9 kB 00:00
mariadb/primary_db | 33 kB 00:00
remi-php56 | 2.9 kB 00:00
remi-php56/primary_db | 229 kB 00:00
remi-safe | 2.9 kB 00:00
remi-safe/primary_db | 950 kB 00:00
updates | 3.6 kB 00:00
updates/primary_db | 4.9 MB 00:04
.treeinfo | 1.1 kB 00:00
getting boot images...
vmlinuz-redhat-upgrade-tool | 4.7 MB 00:03
initramfs-redhat-upgrade-tool.img | 32 MB 00:24
setting up update...
finding updates 100% [=========================================================]
(1/323): MariaDB-10.2.14-centos6-x86_64-client.rpm | 48 MB 00:38
(2/323): MariaDB-10.2.14-centos6-x86_64-common.rpm | 154 kB 00:00
(3/323): MariaDB-10.2.14-centos6-x86_64-compat.rpm | 4.0 MB 00:03
(4/323): MariaDB-10.2.14-centos6-x86_64-server.rpm | 109 MB 01:26
(5/323): acl-2.2.51-12.el7.x86_64.rpm | 81 kB 00:00
(6/323): apr-1.4.8-3.el7.x86_64.rpm | 103 kB 00:00
(7/323): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:00
(8/323): apr-util-ldap-1.5.2-6.el7.x86_64.rpm | 19 kB 00:00
(9/323): attr-2.4.46-12.el7.x86_64.rpm | 66 kB 00:00
(320/323): yum-plugin-fastestmirror-1.1.31-24.el7.noarch.rpm | 28 kB 00:00
(321/323): yum-utils-1.1.31-24.el7.noarch.rpm | 111 kB 00:00
(322/323): zlib-1.2.7-13.el7.x86_64.rpm | 89 kB 00:00
(323/323): zlib-devel-1.2.7-13.el7.x86_64.rpm | 49 kB 00:00
testing upgrade transaction
rpm transaction 100% [=========================================================]
rpm install 100% [=============================================================]
setting up system for upgrade
Finished. Reboot to start upgrade.


The upgrade procedure, will download all rpm packages to a directory and create a new grub entry. Then on reboot the system will try to upgrade the distribution release to it’s latest version.

# reboot

Linux Software

423 locked file when trying to update in owncloud

Client = windows 10 64bit, running 2.4.0 owncloud client.
Server = Cent OS 7 running owncloud 10.4.0 server

When I deleted a file in the sync directory, it is throwing an error on the client:

2/3/2018 9:24:58 PM,tools-keys-etc/software/CISCO VPN/vpnclient-winx64-msi-,E:\DUDES\backups-resume-drivers,Server replied “423 Locked” to “DELETE VPN/vpnclient-winx64-msi-”

Everything else is going fine. I also noticed though, that I deleted a directory on the client, and it would not sync, also threw an error, but I ignored it, and just removed it from syncing in the interface.

I do have encryption on the server enabled, for whatever that’s worth. I also have been using this instance since 7.x I think, before the merger, and beyond, haha. It’s worked great up to this point.

Looks like my cron jobs may have never ran. So I ran it manually.

I dumped myself into the apache user:

su -s /bin/bash apache

then ran the cron job script, which took about 30 minutes or so.

php -f /var/www/html/owncloud/cron.php

I then added it to crontab for apache:

crontab -e -u apache
*/15 * * * * php -f /var/www/html/owncloud/cron.php

camera Electronics pfsense

FDT 1080P HD FD8901 Review vs Motorola baby monitor

I purchased two of these guys for my two lil kiddos, as the second came, I did not want to pay $100+ for another camera in my Motorola baby cam setup.

What I like:
Picture quality is great
local recording on movement works great
360 degree angles are awesome
Night version works great
movement + audio alarms work great using Tinycam pro

I have a few issues:
The web app for moving the camera does not work well at all.
I cannot get two way working, even in the tinycam pro app.
I wish it had 5ghz, 2.4ghz is pretty saturated, and N just isn’t that fast.

I still prefer it over my Motorola baby monitor, much more versatile, and quality picture. I bought a Amazon Fire to use as a 24/7 baby cam, and it works great. It will vibrate on movement/noise.

I also have all traffic blocked going out to the internet, and coming in. I do have DNS and NTP protocols open to keep the time in sync on my firewall. Because of this though, I am also logging ANY traffic the FDT tries to reach out with, and so far they have not tried reaching out, it has been about 4 months too. I was slightly worried with all of the Chinese cameras that have been known to reach out and call home.