2.4.1. ON Core Update
The update of the ON Core component will depend on the network architecture and the role it takes. We can distinguish it by no cluster, and the cluster roles.
Note
Remember you must have the credentials to access to OpenNAC Enterprise repositories. Refer to the Basic Configuration section for repository credentials details.
2.4.1.1. No cluster
To update the ON Core node in a no cluster architecture, we must execute the following steps:
Update all the packages:
dnf clean all && dnf -y update
Check and update the database:
/usr/share/opennac/api/scripts/updatedb.php
Check the configuration files.
After upgrading the packets is possible that some configuration files need to be checked in order to see if we need to manually apply some changes.
To check if the application.ini files need to be updated we can use the following script:
/usr/share/opennac/utils/scripts/post-install_no-move.sh
If the execution results in some files to change, we have two options to proceed:
3.1. If the installation have custom modifications in application.ini (such as ddbb passwords, queues, etc):abbr:
In this case we should have to move the files one by one and check before the move that we are maintaining all the parameters according to the installation needs. We can override directly with the “.sample” files if there aren’t any change or we can add manually the lines that differs from the original application.ini
Note
Is recommended to make a .bkp copy of the original application.ini files to recover it if there are any failure after the changes.
3.2. If the installation does not have any custom modifications in application.ini.
In this case, we can execute the following scripts in order to override the original application.ini files with the new ones:
/usr/share/opennac/utils/scripts/post_install.sh
Restart the ON Core services:
sh /usr/share/opennac/utils/scripts/restartOpenNACServices.sh
Warning
If the kernel has been updated, it is necessary to make a reboot.
If we are in a large architecture, we may want to avoid restarting redis. If so, it is necessary to comment redis in the restartOpenNACServices.sh script.
2.4.1.2. Cluster
In a cluster, we have more than one ON Core with different roles and we need to execute the following steps:
Go to ON Core as primary principal and stop the mysql and redis access for the other ON Core components:
We need to access the iptables file:
vi /etc/sysconfig/iptables
To stop the redis access, we need to comment the iptables that allow the different OpenNAC Enterprise components to connect to the redis on port 6379:
#-A INPUT -s <other_openNAC> -p tcp -m state --state NEW -m tcp --dport 6379 -j ACCEPT
To stop the mysql access, we need to comment the iptables that allow the different workers to connect to the mysql on port 3306
#-A INPUT -s <worker_ip> -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT
Restart the iptables
systemctl restart iptables
systemctl restart php-fpm
systemctl restart mysql
systemctl restart redis
We update the ON Core as primary principal:
Update all the packages:
dnf clean all && dnf -y update
We check and update the database:
/usr/share/opennac/api/scripts/updatedb.php
After upgrading the packets is possible that some configuration files need to be checked in order to see if we need to manually apply some changes.
To check if the application.ini files need to be updated we can use the following script:
/usr/share/opennac/utils/scripts/post-install_no-move.sh
If the execution results in some files to change, we have two options to proceed:
If the installation have custom modifications in application.ini (such as ddbb passwords, queues, etc):abbr:
In this case we should have to move the files one by one and check before the move that we are maintaining all the parameters according to the installation needs. We can override directly with the “.sample” files if there aren’t any change or we can add manually the lines that differs from the original application.ini
Note
Is recommended to make a .bkp copy of the original application.ini files to recover it if there are any failure after the changes.
If the installation does not have any custom modifications in application.ini.
In this case, we can execute the following scripts in order to override the original application.ini files with the new ones:
/usr/share/opennac/utils/scripts/post_install.sh
Restart the ON Core services:
sh /usr/share/opennac/utils/scripts/restartOpenNACServices.sh
Warning
If the kernel has been updated, it is necessary to make a reboot.
If we are in a large architecture, we may want to avoid restarting redis. If so, it is necessary to comment redis in the restartOpenNACServices.sh script.
Stop data services in ON Cores as principal secondary and in ON Cores as worker.
systemctl stop dhcp-helper-reader
systemctl stop snmptrapd
systemctl stop radiusd
Update the ON Cores as principal secondary and the ON Cores as worker
Update all the packages:
dnf clean all && dnf -y update
Check the configuration files. As a consequence of updating packages, some of their configuration files may contain new directives or other changes. You need to apply these changes using the post-install_no-move.sh script:
sh /usr/share/opennac/utils/scripts/post-install_no-move.sh
Check that the database in ON Cores as worker is correct.
Connect to mysql database:
mysql -u admin -p opennac
Note
The default password is “opennac”. We recommended you to change it.
When we are connected, we need to execute:
show slave status\G
Go to ON Core as primary principal and allow the mysql and redis access for the other ON Core components:
We need to access the iptables file:
vi /etc/sysconfig/iptables
To allow the redis access, we need to uncomment the iptables that allow the different OpenNAC Enterprise components to connect to the redis on port 6379:
-A INPUT -s <other_openNAC> -p tcp -m state --state NEW -m tcp --dport 6379 -j ACCEPT
To stop the mysql access, we need to uncomment the iptables that allow the different workers to connect to the mysql on port 3306
#-A INPUT -s <worker_ip> -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT
Restart the iptables
systemctl restart iptables
systemctl restart php-fpm
systemctl restart mysql
systemctl restart redis
Restart the radius service:
systemctl restart radiusd
Finally, we need to restart the service in ON Cores as principal secondary and in ON Cores as worker.
sh /usr/share/opennac/utils/scripts/restartOpenNACServices.sh
Note that this will only start the services that are running, if you want to restart all services, including those that are currently stopped, use the -f flag with the command. For example:
/usr/share/opennac/utils/scripts/restartOpenNACServices.sh -f
Options:
- -v: Enable verbose mode
- -f: Force restart in all services, even if they are stopped
- -s: Provide a custom services list (Example: 'redis httpd')
Warning
If the kernel has been updated, it is necessary to make a reboot.
If we are in a large architecture, we may want to avoid restarting redis. So it is necessary to comment redis in the restartOpenNACServices.sh script.
If we have an ON Core as proxy radius, we need to update it as follows:
Update all the packages:
dnf clean all && dnf -y update
Restart the radius service:
systemctl restart radiusd
Warning
If the kernel has been updated, it is necessary to make a reboot.
If the healthcheck file has been modified, you should update the changes. Navigate to the
healthcheck.inifile, and edit it to do so:
vi /usr/share/opennac/healthcheck/healthcheck.ini