Centos 7 with cPanel loose network config

Today I have been struggeling with cPanel. I did install an Centos 7 server with cPanel WHM on it. I followed the instructions from tecmint and it was pretty straight forward! I have to admit, that was my thought all the way until I rebooted the server with an software update.

At firdst I didn’t know what happened. I thought it was a firewall issue etc. But I couldn’t find any issues. When I finally started to check the server more closely I discovereed when running ifconfig that there where no network card configured with the correct IP. I then moved further and tried to restarting the network service with the command:

systemctl restart network.service

When doing this I got an error message :
Job for network.service failed because the control process exited with error code. See “systemctl status network.service” and “journalctl -xe” for details.

Checking “systemctl status network.service” gave me the following error message:

Failed to start LSB: Bring up/down networking.

This led me out on a desperate google search that lasted for a couple of hours. I found alot of articles that could be helpful but none that helped me. Or I did, in the end but it still felt like forever. I had read something similear to the solution below on my google searches. But those articles only said I needed to touch the network file (just create an empty file). But according to the forum post below I needed to add the commands below to /etc/sysconfig/network file.


XXX.XXX.XXX.XXX represent the IP of the gateway for the CentOS server. When the file is edited I did a reboot and it all worked again! ūüôā I tried to restart the network.service but for some reason I had to do a complete reboot for it to work.

Forum post

Problems with NSM after schema upgrade.

The other day we upgraded the schema on our NSM server from 327 to 329. After the upgrade the devices was not able to connect to our NSM anymore. In the deviceDeamon I got the following error:

[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.
[Notice] [3078149840-connectionMgr.c:2318] Incoming TCP connection from SSH, device ip x.x.x.x
[Notice] [3078149840-connectionMgr.c:2329] SSH Protocol is not enabled -- DeviceBroker is not ready for incoming device connection.

I didn’t know that a simple schema upgrade could do something to the NSM that would not allow the devices to connect so I ended up contacting JTAC support. When I got a support engineer and explained him the issue he found another error message in the guiDaemon. The error was “DC not connected”.

After a while with troubleshooting the engineer discovered that the issue was the RSA key that is responsible for the communication between the NSM services  and the guiDaemon and devDaemon. The engineer then navigated to devSvr.cfg under /usr/netscreen/DevSvr/var and deleted the RSA keys (ourRsaPrivateKey and theirRsaPublicKey).

After that all the devices in some magical way connected again!

Secondary node locked when commiting

The other day I got a problem with one of my SRX clusters when I was running a commit. The commit was not able to complete and I got the following error:

srx1400# commit
error: configuration database modified
error: remote lock-configuration failed on node1

The reason for this error is some uncommited configuration on the secondary node. Earlier the same day I changed the primary for redundancy-group 0 and I guess that I didn’t commit all the config on node1 before changing to node0.

To solve this I had to go into the secondary node (node1) and rollback the uncommitted configuration. Normally you can use OOB to connect to the secondary node but I dont have it at this location. So I have to connect to the secondary node trough the primary node. This is done with the following command on branch devices (SRX650 and below):  request routing-engine login node 1
On High end devices like the one I’m working on (SRX1400 and above) you use:¬†rlogin -T node1

{secondary:node1}% rlogin -T node1
--- JUNOS 11.4R9.4 built 2013-08-22 06:24:21 UTC
root@srx1400> configure
warning: Clustering enabled; using private edit
error: shared configuration database modified

Please temporarily use 'configure shared' to commit
outstanding changes in the shared database, exit,
and return to configuration mode using 'configure'

As you can see from the error I have to use configure shared to be able to edit the configuration.

root@srx1400> configure shared
Entering configuration mode
The configuration has been changed but not committed

Before entering the rollback command you can check the uncommitted configuration by running show | compare. This will display all the uncommited configuration

root@srx1400# show | compare
[edit access profile unos clientjunos]
- pap-password "$9$2V4GDikP5T3fTrvLXwsz36C0B"; ## SECRET-DATA
+ pap-password "$9$jhHP5QF/CA09AxdsYGUp0BRyl"; ## SECRET-DATA

Now you can rollback the uncommited config, check that there is any uncommited config left and exit the configuration mode.

root@rx1400# rollback
load complete

root@srx1400# show | compare

root@srx1400# exit
Exiting configuration mode


Now you can close the session and try to commit the configuration from the primary node again. It worked for me! ūüôā

As a note I also know that alot of people has had a success of using just the command commit synchronize force on the primary node but it does not work for everyone.

dst-port error in NSM

I got a new error while updating a SRX650 from the Juniper Network and Security Manager. The error started after I upgraded the SRX650 to 12.1X47-D30. The error I got is shown below:

Error Code: 

Error Text:
   Update fails UpdateDevice Results
sanityCheckCmd Success.
lock Success.
GenerateEditConfig Failed .
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/12.1X47/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
      <error-message>syntax error</error-message>
      <error-message>syntax error</error-message>

unlock  Success .

Error Details:

              <destination-port operation="delete">
              <destination-port operation="create">

It’s saying that the destination nat section has problems setting the dst-port. For some reason it was deleting the value and creating it with a new command (dst-port).

I then checked the supported Junos versions on the NSM and I discovered that the last supported version was 12.1X47-D25. Did the downgrade and updated the OS in the NSM. Still the same error as before.

Spoke to JTAC and they informed me that this error was known and that it would help downgrading to D15. This was due to a changed command in Junos. I downgraded to D15 but still the same issue. Researched a bit myself and discovered that it was introduced between X46 and X47.

Earlier it had not been possible to downgrade the versions in NSM. But for some reason I was able to do it now. First from D30 to D25, and after that from X47D15 to X46D40. When I reached  X46D40 I was able to run the update and everything was working.

Could not connect to node1 : No route to host

Today I had some issues when working on a SRX650. We had to replace the Services and Routing Engine a few days ago. When I was supposed to get the cluster back online I got the following error message when trying to run a few of the commands on the device:

Could not connect to node1 : No route to host

I got this error when typing show interface ge-0/0/2. I also entered the command on the node1 so I felt it was a bit strange that node1 could not connect to node1.

The firewall was also saying that it was in a hold mode


So it was not showing as secondary or primary. It was keeping this status all the time and didn’t try to go to any other modes while the issue was occuring.

The reason for my issues was that I had not deleted all the default config from the new Service and Routing engine card that we got. My config was not correct for all the cluster ports since some of the ports in the cluster is dedicated to cluster services (on the SRX650 it is ge-0/0/0 (fxp0) and ge-0/0/0 (control plane)). These ports are not to be configured as network ports and that is the reason for my issues. When I deleted the config and set a default root authentication password everything was connected. When I did a commit from the primary node the config was correct on both devices and everything connected succesfully.

During my search on the internet I read that some people also forgot to set the reth-count and got the same error. The command to set the number of reth interfaces is:

set chassis cluster reth-count 4

A great source for more information is the following chapter of the book “Juniper SRX Series”¬†written by¬†Brad Woodberg and Rob Cameron.


Problems with HP Port Replicator 3005pr

I had some issues with the screens and usb devices after upgrading from Windows 8 to Windows 10 the other day. It was only one screen that was working and none of the USB devices where working.

When trying to update the driver for HP Port Replicator 3005 pr I got the following error message: “A previous uninstall of HP Port Replicator Software is not yet complete. Please reboot your computer and run this installer again to installation.”

I tried several solutions to solve the issue but none of the ones I found on the internet helped me. Most of the problems was solved with the compability mode but for some reason that was not good enough for me. After some troubleshooting I discovered that it failed during the update of the displaylink software. I then downloaded the Display Link software manually and tried to run the setup. I got a message saying that the installation had failed (I don’t have a screenshot or the correct words).

When I did the complete uninstall of the DisplayLink software I was able to install the port replicator driver. The uninstall software can be found here. The software is named “DisplayLink Installation Cleaner” and starts a command window where you will press enter to remove the old software.