Blink, anyone ?

[G_W_Albrecht]

The sk120193 Blink - Gaia Fast Deployment gives details and tools for easy deployment of cleanly installed Check Point R77.30 or R80.10 Security Gateways. Has anyone used this method already and what were the experiences with it, also compared to deployment with isomorpic ?

[Anat_Eytan-Davi]

With Blink you can deploy your gateway (including Jumbo HF) in ~5 minutes.

Images are available in the SK with or without the Jumbo HF.

Blinks also provides you the option to download the latest updates for Anti-Bot, Application control, URL Filtering and CPUSE Deployment Agent.

[G_W_Albrecht]

Thank you for the comment - but i would be very interested in feeedback from people who have used this new method in deployment already.

[AlekseiShelepov]

I'm waiting for someone to blink...

Actually, I would like to try it out soon during a replacement of gateways. Sound pretty good and easy. I just would like to read some more technical details about this whole process. Of course, the best way is just to try it myself, but I don't have spare appliances for now.

I wonder what happens with the installation files that I copy to the gateway during and after installation if I use --reimage --delete-old-partition keys. I thinking about the following scenario we received a new appliance with some image, maybe it was already initialized, I want to fully reinstall the image to R77.30+Take_292. So, I put all required files into /var/log/blink directory and start it with --reimage --delete-old-partition keys. As I understand it should fully reinstall the image, as if I started new installation from USB. It should delete old partitions and not leave any snapshot. So are the blink files transferred somewhere or just nothing happens to the whole /var/log directory? What happens to the initial and extracted files (/var/log/blink/launcher/files) after installation? There is information about new blink partitions (Remove blink new partition: lv_remove vg_splat lv_fcd_new), then what should happen with them after normal installation?

[DeletedUser · Accepted solution]

yeah, I'm not going to look at that youtube video, I would 😉

Assuming you create a new directory /var/log/MyDir, copy the files and run blink from there with the parameters --reimage --delete-old-partition, then it would extract the blink_image_<version>.tgz and blink_updates_<version>.tgz files to the /var/log/blink/launcher/files/ directory. When the BlinkInstaller engine runs it merges /var/log so you'll still have /var/log/MyDir and /var/log/blink/launcher/files at the end of  the run.

When blink is run without any flags, the default is to NOT create a snapshot. The --keep-old-partition flag overrides the default behavior. When blink is run with only the  --reimage flag, then it defaults to creates a snapshot which is shown as a partition (see highlight below). These are the snapshots after 3 blink runs.The final one with the the --reimage --delete-old-partition flag set didn't create a new snapshot and doesn't touch the previous snapshots.

# lvs
  LV                  VG       Attr   LSize  Origin Snap%  Move Log Copy%
  hwdiag              vg_splat -wi-a-  1.00G
  lv_Blink_R80.10_198 vg_splat -wi-a- 32.00G [from ./blink --keep-old-partition]
  lv_Blink_R80.10_373 vg_splat -wi-a- 32.00G [from ./blink --reimage]
  lv_current          vg_splat -wi-ao 32.00G
  lv_fcd_GAIA         vg_splat -wi-a-  6.00G
  lv_log              vg_splat -wi-ao 60.00G

hth,

bob

[G_W_Albrecht]

These details are very interesting - but i was interested more in user experience with blink and how it shines compared with isomorphic USB deployment .

[Noel_Taylor]

I plan to Try it in the lab tomorrow with same questions you have

Will let you know

[Tsahi_Etziony]

Until you have some feedback from other users, I can tell you that I have used both Blink and ISOMorphic many times, but I am biased since they are developed in my group 😉

I can shed some light about the differences between both:

ISOMorphic will format your HD and reinstall the ISO just like a new appliance. ISOMorphic works on all machine roles since it uses the same ISO for all installations.

Blink on the other hand creates a new partition with the new image already installed and customized as a GW. You cannot use Blink for any machine role other that a GW (for now), and the HD is not reformatted. Blink is much faster - it will take you ~5 minutes plus the reboot time, while ISOMorphic can take more than 30 minutes.

Hope this helps, and I am looking forward to hear some more feedback on this thread. 

Tsahi 

[Vincent_Bacher]

I always read about 5 minutes for installation.

And how long takes the preparation?

[Tsahi_Etziony]

It depends on how you plan to use the image. If you want to use a USB flash drive, the preparation will be just the time it takes to copy the image to the drive. If you want to copy the image to the machine, then the preparation will be the time it takes you to do that. 

In ISOMorphic you need to use the ISOMorphic tool to format the flash drive, but with Blink you don't need to do that. The flash drive option is just for storage of the image file.

[G_W_Albrecht]

Thank you, Tsahi - these are very interesting details indeed!

[G_W_Albrecht]

Still no one is discussing his practical experience here - what a pity...

[Vincent_Bacher]

Don't have practical experience yet

[Bryce_Myers]

Quick comment about practical experience --

I have used this tool on 10+ gateways in my environment and I found it super helpful.  This tool is a great way to image a box - especially if you don't have physical access to the gateway, and shipping/creating a usb stick at the site is a problem.

We have used this to "upgrade" R75.46 boxes as well as "upgrade" R77.20 boxes that had hotfixes that we couldn't remove cleanly. 

I think once this tool becomes more integrated with the rest of the management suite - CDT & Zero-touch - Gaia deployments and hardware replacements won't really require much attention.

[Ivan_Moore]

I have been playing around with Blink over the past few weeks getting ready to roll out our R77.30 -> R80.10 upgrade.   We have custom scripts and configurations that I want to preserve and also automate as much as possible so that it's a one-click type of deployment.  So, in my lab I extracted the the 80.10 image and dropped in the update file into the appropriate directory (per the SK).  Then I started building out the user_updates directory.  I dropped a .tgz file containing our custom scripts and created a pre script that would go gather various configuration bits including a clish save configuration.   

I use the --reimage flag then and install_content.sh will import that config back in when done.   I did a demo to one of our managers yesterday.  2.5 mins + 2 reboots + SIC + policy install and we have a gateway go from 77.30 to 80.10.  

The bits I"m working on next are more complicated upgrades where the gateway has non-standard CoreXL settings for example.  Also need to validate any other differences between 77 and 80 such as the cluster ID mechanism which changed again.  

However, blink in and of itself is pretty awesome so far.  

[Albert_Wilkes]

Sorry Guenther, hope I am not hijacking this as I haven't used Blink yet but Tsahi referenced this thread for any opinion about blink.

I would have liked to have a mechanism to quickly fire up lab firewalls which we'd run on open servers in virtualized environments. Alas, OpenServers are not supported by blink yet.

The Blink configuration mechanism seems to be a discontinuation of the previously used config_system syntax and the fact they're using different syntax is creating the need for us "users" to read into and decide to use one or the other and thus increases adoption efforts. 

In my dreams, I would have liked one unified configuration syntax that is compatible with clish, config_system and Blink and I can't see why this shouldn't have been possible. Now we've got three syntactic representations of first-time and ongoing configuration instructions that couldn't be more different even though they have got a huge overlap in terms of what they do.

PS: For anyone who like me wasn't quite clear about the different use cases/scenarios for both methods see these videos:

Overview of ISOmorphic and Blink and 

Check Point Deployment Tools; DIY Check Point security appliance images using ISOmorphic - YouTube  

[G_W_Albrecht]

If you like to quickly fire up lab firewalls which will run on open servers in virtualized environments, you better use VM templates 😉 Either build them yourself or get it e.g. here: R80.10 vSEC Virtual Edition (VE) Gateway in Network Mode - VMWare OVF template

[Albert_Wilkes]

Thanks for the response Günther, you've got a good point there and templates are invaluable for our labs. I am currently indeed using templates and linked clones (on an unsupported but working Proxmox because of VWware's webui which proved unstable to my colleagues and me) to keep the disk utilisation down, my most basic linked clone is at the first time wizard, the next "stages" of the linked clones are one reboot further where they are either a firewall cluster member or a manager with the latest jumbo take downloaded but not yet installed. 

However, creating linked clones from templates is all nice and good initially but it already gets clunky when it comes to try and include the latest JHFs, but it then falls short for me terribly where you want to customize your deployment in greater detail with network config, clusterIDs and the like. Saving a template for every desirable scenario is just not feasible and I currently work around this by clish- and bash-scripting the required changing of IPs, importing the required licenses, installing a new deployment agent etc. Very old-school approach unfortunately and I will now instead look at automating this with config_system. This thread is actually a very good motivation for me to overthink how to deploy machines and learn more. 

Did anyone happy to try what happens when you try to use Blink on OpenServer - for a lab only obviously? I wouldn't like to invest time in vain in learning more about "config_system" if "Blink" is the new "config_system".

[Tsahi_Etziony]

awilk99fbe18d-5cf1-4543-9936-535b8747c024 wrote:

Sorry Guenther, hope I am not hijacking this as I haven't used Blink yet but Tsahi referenced this thread for any opinion about blink.

I would have liked to have a mechanism to quickly fire up lab firewalls which we'd run on open servers in virtualized environments. Alas, OpenServers are not supported by blink yet.

The Blink configuration mechanism seems to be a discontinuation of the previously used config_system syntax and the fact they're using different syntax is creating the need for us "users" to read into and decide to use one or the other and thus increases adoption efforts. 

In my dreams, I would have liked one unified configuration syntax that is compatible with clish, config_system and Blink and I can't see why this shouldn't have been possible. Now we've got three syntactic representations of first-time and ongoing configuration instructions that couldn't be more different even though they have got a huge overlap in terms of what they do.

PS: For anyone who like me wasn't quite clear about the different use cases/scenarios for both methods see these videos:

Overview of ISOmorphic and Blink and 

Check Point Deployment Tools; DIY Check Point security appliance images using ISOmorphic - YouTube  

Blink is not a replacement for config_system. not at all. I understand that a different syntax for every deployment configuration method is confusing, and we'll work on improving this. That's a very good feedback.

config_system should be used for running the First Time Wizard configuration in command line - it can be used for all machine types and of course it does not reimage the machine with a different version. 

[Jose_Rivera]

We successfully started using Blink!

We did build some wrappers around it but with these wrappers, it has worked extremely well. The only issue, if you can even call it an issue, revolves around the original "factory image" remaining. Though we don't really see a need to "factory reset" a gateway any longer, since it can re-Blink'd at any time.

The wrappers we built:

1) Fresh re-image with R77.30 w/ basic pre-built clish commands (ie, password, snmp, ntp, etc..)

2) Fresh re-image with R80.10 w/ basic pre-built clish commands

3) Upgrade/re-image from R77.30 to R80.10 while re-applying clish statements dynamically.

We did need to build "two" sets of wrappers for each, as we needed to handle clusters vs single GW installs.

Our internal process already requires new or firewall replacements be built with option 1 or 2. 

For Option 3, we successfully proved this with a few remote site upgrades and plan to perform all upgrades using this method with Cavaets.

If you ever tried to fresh re-image a 2200 (via usbboot), run first-time wizard, then Jumbo HotFix, you will be happy to hear we have averaged Blink completing all these steps within 8 mins on this model. 

Cavaet: Our company best practice is to avoid any customization's of files in expert mode. Making it much easier for us to deploy or re-deploy firewalls using only the saved CLISH configurations. While we are using this method for upgrading from R77.30 to R80.10, keep in mind those expert mode customization's are not retained. 

[G_W_Albrecht]

Thank you for sharing your experience !

[Juan_Carlos]

Hello,

I have tested Blink in lab environment.

- it's working well and it's very fast (probably depending on hardware capabilities since Blink extracts into a new LV)

- I managed to upgrade a cluster in R80.10 from R77.30 in less than 15 minutes, including reboots (using Blink in addition to CDT). This way to proceed is not supported but shows that something is possible . I'm looking forward the day when our admins will be able to announce our customers a 30mins maintenance window to upgrade a cluster!

As a MSSP we are always looking for better ways to industrialize and shorten our operations. Beeing able to apply customized configurations (scripts, specific parameters, ...) at any step of our installation/upgrade/recovery processes is very important for us.

We have hundreds of gateways : less manual operations, the better. Blink may be a very good tool for such purposes in the future.

There are some limitations especially management servers deployments that are not supported yet but I heard that R&D is working on a Blink image for management servers.

In my opinion Blink, CDT and CPUSE can't be separated and I don't see any reason for Blink, CDT and CPUSE not to be merged in the future and I have not doubt that R&D is working on it!

[Network_Securi1]

Hello,

I used blink to build a couple of new gateways 13800 and 5900. I needed to install r77.30 + jumbo + 4 private hotfixes. Checkpoint provided a custom iso that contains all of them. So after only one reboot with blink, all was installed!

Basically, here is the steps I did, considering that I don't have physical access to the gateways:

- Make basic config (mgmt ip, routing, expert account, scp account, ...) via console

- Transfert blink and iso to gateway via scp

- Run blink

- Make basic config again (mgmt ip, routing, expert account, scp account, ...) via console

- Connect to web ui to run first time wizard

So it's very easy and time saving! Running blink needs less than 3 minutes!

Now some (not so critical) negative points:

- Depending on the model, the iso was different: here I had one iso for 13800, one for 5900. It could be better to have only one.

- First Time Wizard is only possible via web ui. In my case, https was not allowed so I was not able to continue. I think it could be better to perform the FTW via cli with a file (like "config_system –f xxx”)

- Basic config (ip, routes) has to be done again. It could be great to have an option to keep such config.

Now in my team we are working to use blink for RMA: it looks faster than CDT. Same for major upgrade : we are testing if blink is faster than CPUSE / CDT.

Greg

[Daniel_Collins]

Once I played around with it a bit, it worked well and did it's thing and completed both the image + initial configuration wizard.

Some things that are worth mentioning:

- When you specify the "answer.xml" it *has* to be "answer.xml" mine was "answers.xml" and it simply ignored it, provided no log that it was ignoring it and didn't complete the tasks set out in the XML file

- This does work on open-servers, as this is what I've been testing it on

- Having the answer.xml inside the image archive you need to extract first, is a bit cumbersome - can it not be included in the blink binary?

   - Tack that. Having it as part of new Gaia OS base images shipped on appliances would be super useful, especially since most appliances don't have USB configured by default.

[Tsahi_Etziony]

Thanks for this feedback Daniel. I have some replies for your comments:

• Blink does work on open servers. of course it is not a common use case because it requires a GAIA to be installed, but for reimaging of an existing open server GW it should work.
• You can keep the answers.xml outside of the Blink image, and you can specify its location and even a different name using the flag -a.
• Using -a with a specific name might help avoiding mistakes, and if the specific file will not be found, you'll get an error.
• We do not stop the process when answers.xml is not found because it is only optional. however, we will improve the logs so you'll have a better visibility of the process and whether a configuration file is found and will be used. 

[Daniel_Collins]

Thanks for your reply.

When I was using the tool, I was specifying the -a flag to indicate the file.. just thought It'd be worth mentioning.

[Tsahi_Etziony]

So it is probably a bug. I'll look into it. thanks!

[DeletedUser]

FWIW running blink with -a MyAnswers.xml works for me.

[Expert@MyGW:0]# ./blink -a MyAnswers.xml

But when I was first testing it, I also saw that my answers file was being ignored. Turned out to be a silly error on my part. To understand why, you can check the log /tmp/ftw_cli.log tor errors. 

Not sure if it is possible, but would like to see another flag added that verifies the answers.xml syntax, so we don't have to do a full blink run to see if there is a problem with the syntax though. Something like this....

[Expert@MyGW:0]# ./blink --verify -a MyAnswers.xml

thx, bob

[francismuzenda]

I did fresh upgrade with blink.  its sweet and fast.