Author Archives: Kaven Gagnon


About Kaven Gagnon

System Engineer / Network Administrator

Linux : Error deleting domain in cPanel The subdomain does not correspond to domain.tld

Experiencing the following issue trying to delete a domain in your cPanel account?

The subdomain hostname_domain.tld does not correspond to domain.tld.

Have a look if the domain isn’t listed in “Addon Domains” or “Alias”. If the domain show up in either of those category, try deleting from there first.

In this case, it turned out that the domain was added as “Addon Domain”, deleting in that category worked out and is no longer listed in “Domains”.

JunOS : Port forwarding on Juniper SRX

A friend of mine who was used to the legacy and EOL SSG/ScreenOS platform and he just jumped into the new world of SRX/JunOS gave me the motivation to write this article. As the syntax is quite different between the two platform, it may be harder to get at first and the following example should help you out!

This tutorial will show the various steps of he configuration. I have used as much as possible “intuitive names” for the various elements while this example is about port forwarding a non-standard RDP port to the server

1. Define the target machine object name in the “address book” (this is a name alias for the target IP) :

2. Define the custom application protocol and port (this step is optional, to be used if your application isn’t listed in the default list) :

3. Define the destination NAT pool for the target machine :

4. Define the destination NAT rule for the target machine :

5. Define the firewall policy for the target server :

6. The configuration is now complete, you may now commit the change :

JunOS : fpc CMLC: Going disconnected; Routing engine chassis socket closed abruptly

Getting the following error on your Juniper EX/MX/QFX virtual chassis?

fpc1 CMLC: Going disconnected; Routing engine chassis socket closed abruptly

This message is informational and does not necessary indicate any serious issue, for example in a graceful Routing Engine switchover (GRES) context / if you flipped the routing-engine (RE) on purpose. However if this is message is printed repeateadly, without any virtual chassis (VC) topology change or manual intervention, this may indicate a more serious issue that worth investigating.

The most common issue is cabling between your VC members, and most likely to happen if the members are distant from each others connected with SFP+/QSFP+ and fiber rather than the short length DAC cables (it does not mean that no issue can happen with DAC cables, it is just that the elements and distance in the chain of even is reduced).

Here are the common symptom/possibilities on the vc-ports :

  • Defective SFP+/QSFP+ optic (dying optic, losing power transmission capability)
  • Fiber length too tight for the optic capability (check laser transmit/receive power)
  • Damaged fiber/connector, bad fusion point, dirty connector/optic (investigate with light testers, loopback, OTDR, clean the tips…)
  • Port flapping (can be caused by all the above)
  • If you are using DAC cables and observe CRCs, just swap it out with another one and monitor if there is any change in the situation.

OBSERVATION : When such issue occur and there is a lot of flaps/errors between VC ports members, you may observe a higher load on the CPU/RE than usual and some functionalities such as ICMP drop, SNMP polling issues. If your device is usually very busy and near capacity, more serious service impacting issues may occur on layer 3 services such as BGP and OSPF  as well (especially on EX series devices).

In most cases, you will observe Cyclic Redundancy Check (CRC) errors on the vc-port(s). You should check it out using the following command :

And investigate accordingly based on the tips provided above.

Here is an example output below of a VC with this behavior showing CRC errors (yeah… I knew the fiber that was delivered to me by the cabling technician was bad just by looking at it, I was told it has been tested – trust no one!) :

UniFi : Access point show disconnected immediately after adoption

I ran into a weird issue trying to adopt several Ubiquiti UniFi AP Mesh Pro access points on a newly created site within the UniFi controller lately. Here is the behavior encountered :

– Newly UniFi access point deployed showed up in the controller for adoption ;
– Clicking “Adopt” did started the provisioning process ;
– At the end of the provisioning (adoption), the access point show as “Disconnected”.

Additional information :

– APs were running firmware ;
– All three deployed APs ran into the same issue
– No filtering rules between APs and controller is blocking traffic.

Fix attempt :

1. Login to the AP using SSH and credentials (ubnt / ubnt) ;
2. Issue the command to inform the controller that a new access point is available :

This actually started the adoption and provisioning again, but still end up failing with “Disconnected” status.

So, what was the fix?

I did both steps mentioned above, but actually did the step two (2) repeatedly using the [up arrow] + [enter] key combination until I was kicked out from the SSH session (this meant that the provisioning process rebooted the AP to complete the adoption.

I believe this could have been caused by a bug in that particular firmware version that was on the APs initially.

Linux : Copy/Paste not working between VMware Workstation host and Debian guest

If you are wondering why copying text from your VMware Workstation host to your Debian guest VM isn’t working, it is most likely because you either do not have the virtualization tools installed or have the wrong one installed.

VMware does provide what is commonly called “VMware Tools”, however those need to be compiled from source. If you decide using this approach, it should be just fine, but the recommended approach with Debian would be using the binary packages from the APT repo.

If you are used to install them on your servers and did install “open-vm-tools” package, you probably found that most of host/guest operations are working from VMware Workstation, except the GUI related ones. This is because the virtualization package for workstation contains additional GUI related options that isn’t shipped with that package, but can be found in “open-vm-tools-desktop”.

Optional – If you had “open-vm-tools” installed, do the following step to remove the package :

Then reboot your Debian guest machine.

Here is the command that should be used to install the desktop version of the virtualization tools :

Note : Changes should technically be visible immediately, if any issue, try rebooting your guest VM.

Windows : Prevent Server Manager from opening at logon

As much as I love Windows Server 2016 compared to previous versions, there is nothing that annoy me more that the Server Manager opening when I logon. Fortunately, there is a way to disable it using Group Policy editor.

NOTE : If you are not within a domain group environment (Active Directory), there is an easy way to apply this change to a standalone server as followed.

In the Server Manager pane :

1. Click on “Manage” located in the upper right corner of the window ;

2. Then click on “Server Manager Properties” ;

3. Thick the box “Do not start Server Manager automatically at logon” ;

4. Click OK.

Here is the procedure with GPO / Active Directory :

1. Open the Group Policy editor :

a. If you want to apply this on a standalone server, use :

b. If you are within an Active Directory environment and intent to apply this to multiple servers :

And then edit the desired GPO where this should apply to.

2. Browse to the following tree :

Computer Configuration > Policies, Administrative Templates > System > Server Manager

3. Open the following object :

Do not display Server Manager automatically at logon (DoNotOpenAtLogon)

4. Set to “Enabled” and click “OK”.

NOTE : If you applied to a GPO, you’ll need of course to make sure the policy is enabled and either wait for it to apply or force the update using “gpupdate /force”.

JunOS : PoE devices suddenly losing power on Juniper EX4300-48p

If your Power over Ethernet (PoE) device(s) connected to an EX 4300-48p switch suddenly lose power unexpectedly after some time working just fine, you may be experiencing PoE controller software issue.

First of all, verify if you are not over your PoE power budget (this could be sometimes the case when you have a LOT of devices connected – this kind of situation occurs only if you have a lot of type 2 high powered PoE (IEEE 802.3at) devices connected to it) :

You should see a similar output like this :

You should look at the “Total PoE power consumed”. If you are equal or tight to the limit, it might be just your problem, you should disconnect a few devices/relocate them on another switch and see if there is any improvement.

In this particular situation, the output above was taken immediately after the “PoE outage” occurred. All devices were connected properly, but no power was injected by the switch and consumed by the devices. Down/Up the port(s) had no effect.

It then came to mind to have a look at the “PoE controller”

Here is an example of the output of this command :

As we can see, there is a notification that a new version of the PoE software is available. In my case, that was the issue, most likely a bug in the current version that I was running.

NOTE : It may be a good idea to validate first if you are running the recommended JunOS version by JTAC. If not, upgrading that first is recommended.

NOTICE : Before you continue, this upgrade need to be performed within a maintenance window, a minimum of 10 – 15 minutes will be required, as in addition of upgrading the PoE software, the switch will automatically reboot once completed. The switch may become unstable while performing the upgrade.

In order to perform the PoE software upgrade, do the following command :

NOTE : Please note that if you are running a virtual-chassis, the command will need to be performed for all unit and change the “fpc-slot” number matching the other units in the VC.

You will now notice the following output once you’ve issued the PoE firmware upgrade :

Once the switch(es) completed their upgrade and rebooted, the PoE injection should be stable and steady.

[This article may also apply to EX2200, EX3200, EX2300, EX3300, EX3400-p chassis as well]

Linux : apt-get Failed to fetch FailReason: ConnectionRefused

Experiencing the following issue trying to update your Debian distro using apt-get?

# apt-get update
Ign:1 stretch InRelease
Hit:2 stretch Release
Ign:3 stable InRelease
Hit:4 stable Release
Hit:5 stretch/updates InRelease
Ign:8 sarge InRelease
Hit:9 sarge Release
Err:11 stretch InRelease
FailReason: ConnectionRefused
Reading package lists… Done
W: Failed to fetch FailReason: ConnectionRefused
W: Some index files failed to download. They have been ignored, or old ones used instead.

In that particular case, the pgp key was revoked/changed on that particular apt repo ( To resolve this issue, you need to download the new key and import it as followed :

This should resolve the issue, you may issue the “apt-get update” command again to test.

JunOS : Configure DNS forwarders on SRX device

If you want your SRX firewall to handle DNS requests on your network, you need to configure the forwarders to make this possible, in addition to a few other parameters.

First, make sure you have no local forwarders set on the device itself as it cannot be used along with the dns-proxy service – if you have any configured, they should be all removed :

Then, follow the step-by-step procedure below :

1. Configure the DNS proxy setting on the desired interface(s) where it should listen for DNS requests :

2. Configure the DNS resolver(s) where the requests will be resolved from (aka your ISPs or any public DNS service) :

3. Allow DNS traffic on the security zone :

4. Apply the configuration (use “commit synchronize” if you are running HA) :

Here is a sample of how it would look like :

Windows : VMware Workstation VM fail to boot after crash with snapshot

Well this is embarrassing, my 11 years old workstation crashed while I had several VMware Workstation guests running (thanks for all those years of flawless runtime!).

All my VMs had auto-snapshots enabled, meaning that VMware Workstation was automatically taking snapshots of my development VMs every day. Guests VMs with snapshot does not react so well when hard crash occur – unfortunately this was my case.

Once I had my new computer up, connected my old data drives and attempted to start the VMs – Surprise! – The following error occurred :

The process cannot access the file because another process has locked a portion of the file

Cannot open the disk ‘X:\Path\To\VM\Guest-000001.vmdk’ or one of the snapshot disks it depends on.

Module ‘Disk’ power on failed.

Failed to start the virtual machine.

First of all, I copied all VMs to a safe location before attempting any further actions. Then, did the following attempts :

1. Remove all “*.lck” files/folders ;
2. Import the VM guest(s) to VMware Workstation ;
3. Take a new snapshot ;
4. Delete the oldest snapshot ;
5. [Optional step based on the state of your vDisk] VMware Workstation may complain about vDisk that require repair – if this is the case, using the Command Prompt. go to :

And run the following command to repair the vDisk :

6. Have a look in the Snapshot Manager if any snapshot remains – delete if required – if it fail, take a new one and delete ;
7. Start the guest VM.

Note : Step 3, taking a new snapshot before removing the existing ones did all the difference in my case, just deleting existing snapshots bricked the vmdk files, taking a new one first worked the magic!

At this point, your old guest(s) VM(s) should be starting without issue, hopefully!