Capture registration steps when migrating from 4.0 to 4.1

The authentication methods have been modified in SkyLIGHT PVX 4.1 and there are some simple steps that you will have to perform in order to properly migrate your distributed SkyLIGHT PVX system.

Inventory of your distributed system in 4.0

By looking at your distributed nodes configuration on a 4.0 datastore, you should see a similar output from the Pulsar shell:

datastore# capture

Name:            datastore
Address:         localhost
Created the:     2016-08-10 11:26
Device ID:       55EAE076-C7F8-7245-979E-6C2E1E9E394A
Device md5:      44535c8b627a532e07ed3c6d6b379c6e
Time:            2016-08-10 11:35
SPV Version:     4.0.28-r1-internal
Sniffer status:  ok, pid 3434
Sniffer version: 4.0.28
License:         ok
Expiration:      2016-08-24 22:00 UTC
MTU:             System default
Is booting:      False
Location ID:     0
Location md5:    cfcd208495d565ef66e7dff9f98764da

Name:            capture
Address:         192.168.10.227
Created the:     2016-08-10 11:35
Device ID:       D0FD45EA-673D-FE40-AAF2-BD3E4D86FA4B
Device md5:      0a7583d16e5625f615d466ffbce9c783
Time:            2016-08-10 11:35
SPV Version:     4.0.28-r1-internal
Sniffer status:  ok, pid 3216
Sniffer version: 4.0.28
License:         ok
Expiration:      2016-12-31 23:00 UTC
MTU:             System default
Is booting:      False
Location ID:     0
Location md5:    cfcd208495d565ef66e7dff9f98764da

Here, we have one datastore and one capture that are both reachable and in the same 4.0.x release.

Warning

Once the 4.1 release has been applied on all of your nodes, any communication will be unsuccessful as the authentication scheme has changed to increase security.

Inventory of your distributed system in 4.1

The distributed system has been updated to 4.1 and we now clearly see that any previously registered capture has been disabled automatically:

datastore# capture

Name:            datastore (ACTIVE)
Address:         localhost
Created the:     2016-08-10 11:26
Device ID:       55EAE076-C7F8-7245-979E-6C2E1E9E394A
Device md5:      44535c8b627a532e07ed3c6d6b379c6e
Time:            2016-08-10 13:45
SPV Version:     4.1.0-r1-internal
Sniffer status:  ok, pid 3502
Sniffer version: nova/4.1.0
License:         ok
Expiration:      2016-08-24 22:00 UTC
Is booting:      False
Location ID:     0
Location md5:    cfcd208495d565ef66e7dff9f98764da


Name:            capture (DISABLED)
Address:         192.168.10.227
Created the:     2016-08-10 11:35
Device ID:       D0FD45EA-673D-FE40-AAF2-BD3E4D86FA4B
Device md5:      0a7583d16e5625f615d466ffbce9c783

Registering migrated captures in 4.1

One of the few changes in the 4.1 release is the revamped registration system.

To learn how new captures can be added on your 4.1 datastore, see How to configure a capture probe.

Capture listing on the datastore via the new Configuration > Settings > Nodes Management page after the 4.1 migration.

As described in the new registration guide, we first have to create a PIN code on the freshly updated capture (capture 192.168.10.227 on the previous example):

capture# register pin create
PIN: 6297
Fingerprint: e8:70:3d:e1:a3:ee:25:c4:ca:9e:c3:35:11:c6:f0:ea

The register command has been added in the 4.1 release and allow you to handle any authorized connection on your nodes.

The pin sub-command allow you to create, discard or show any PIN code you may have created. PIN codes are temporary and one-time use only.

Once the PIN code has been created on the capture, the datastore can use it to authenticate itself on the capture. From the pulsar on the datastore (localhost in previous example):

datastore# register authenticate 192.168.10.227 6297
Do you validate the remote host key fingerprint? e8:70:3d:e1:a3:ee:25:c4:ca:9e:c3:35:11:c6:f0:ea: yes
Successfully registered

The authenticate sub-command will register a datastore on a capture (its first argument) with a PIN code (its second argument).

To avoid any man-in-the-middle attack, you should closely verify the host key fingerprint (which will also be displayed to you when you try to connect to your node via the SSH protocol).

Now that the capture authorizes connections from the datastore, it can be marked as active. From the pulsar on the datastore (localhost in previous example):

datastore# capture activate 192.168.10.227
Capture '192.168.10.227' is now active.

In the 4.1 release your capture can be activated or deactivated at will (useful if you are moving the machines around, for example). The datastore won’t try to reach any deactivated capture and as such, won’t warn if any of them appears to be unreachable.

Newly registered capture can be activated on the datastore via the Configuration > Settings > Nodes Management page in bulk.

To verify the connection has been re-established to all of your captures, simply list them again. The datastore should be able to retrieve some information about each of them (like their new version):

datastore# capture

Name:            datastore (ACTIVE)
Address:         localhost
Created the:     2016-08-10 11:26
Device ID:       55EAE076-C7F8-7245-979E-6C2E1E9E394A
Device md5:      44535c8b627a532e07ed3c6d6b379c6e
Time:            2016-08-10 13:57
SPV Version:     4.1.0-r1-internal
Sniffer status:  ok, pid 3502
Sniffer version: nova/4.1.0
License:         ok
Expiration:      2016-08-24 22:00 UTC
Is booting:      False
Location ID:     0
Location md5:    cfcd208495d565ef66e7dff9f98764da

Name:            capture (ACTIVE)
Address:         192.168.10.227
Created the:     2016-08-10 11:35
Device ID:       D0FD45EA-673D-FE40-AAF2-BD3E4D86FA4B
Device md5:      0a7583d16e5625f615d466ffbce9c783
Time:            2016-08-10 13:58
SPV Version:     4.1.0-r1-internal
Sniffer status:  ok, pid 3215
Sniffer version: nova/4.1.0
License:         ok
Expiration:      2016-12-31 23:00 UTC
Is booting:      False
Location ID:     0
Location md5:    cfcd208495d565ef66e7dff9f98764da

After a couple of minutes, every capture should now be marked as online on the datastore‘s Configuration > Settings > Nodes Management page.