Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Zoltan_Bogdan
Contributor

Need a working Isomorphic for unattended imaging 200+ Appliances

Jump to solution

Dear All,

 

I was looking for an easy way to provide customized base installations for 200+ 6k appliances.

- 80.40 Fresh installation

- Apply basic configuration (MGMT,Admin password, some Base services like NTP/DNS etc.)  and completing First Time Configuration Wizard utilizing a provided config_system script according to the respective gateways MAC address.

- Installing the provided Jumbo by previously updating the CPUSE Agent.

 

Unfortunately there's a bug/shortcoming interfering with installing the Jumbo isn't possible as anaconda thinks that there's not enough space as described in sk122014.

Has anyone managed to circumvent this by any means.

Where is that space actually missing? On the target HD? in Ramdisk?

Thanks in advance

Zoltan

 

0 Kudos
1 Solution

Accepted Solutions
Zoltan_Bogdan
Contributor

Maybe still the same root cause. I managed to work around the issue by unpacking the image, editing the respective appliances' patitioning defaults in  /system/base/appliance_configuration.xml
<appliance_partitioning>
<layout min_disksize="434000M">
<volume name="lv_current">32768M</volume>
<volume name="lv_log">196608M</volume>
<volume name="lv_fcd">8192M</volume>
<volume name="hwdiag">1024M</volume>

<volume name="max_swap">32768M</volume>
</layout>

and of cause repacking the image again:

 

genisoimage -U -r -v -T -J -joliet-long -V "CP_R80.40_GAIA_3_10" -volset "CP_R80.40_GAIA_3_10" -A "CP_R80.40_GAIA_3_10" -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -no-emul-boot -o ../CP_R80.40_GAIA_3_10.iso .

Sticks with that image work flawlessly with jumbos

View solution in original post

(1)
26 Replies
PhoneBoy
Admin
Admin

From what the SK is suggesting, a "factory default" partition is created that includes the base OS + JHF.
It looks like that partition is too small.
I presume we would have to increase the size of that partition as created in ISOmorphic, which may require an RFE.

Zoltan_Bogdan
Contributor

Dear PhoneBoy,

thanks for your reply.

As this SK is from 2017 I doubt that Engineering is going fix this in the near future so I hoped for some creative ways to have this fixed on my own.

What I think is rather irritating is  "some instances" in  "This causes the process to fail in some instances."
If the issue is to come from is a too small partition the process starts to fail from a certain Jumbo as the amount of data tends to grow from take to take.

I'm taking a closer look at Blink now but I miss some features:

-pruning of the HD including the log Partition

- I see how to install and configure a single machine but not how to auto provision a mass rollout and apply individual  config_system templates. I'm lacking something comparable to the possibility in isomorphic to tie template A to MAC address X and template B to MAC address Y or something the like.  

Is there a comparison of ALL those tools (Isomorphic/Blink/Zero Touch/CDT/LSA) and which use cases they where meant for?

Thanks & kind regards

Zoltan

0 Kudos
_Val_
Admin
Admin

AFAIK, there is no Blink image for 6k series

0 Kudos
Zoltan_Bogdan
Contributor
0 Kudos
_Val_
Admin
Admin

Blink is not supported on 6K, they have a special RAID. https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... - 6K series are not listed.

0 Kudos
Zoltan_Bogdan
Contributor

Ah, thanks for clarification; so I'm stuck with isomorphic anyway.

How long would a RFE take and how/where am I supposed to open it?

0 Kudos
Zoltan_Bogdan
Contributor

looks rather trivial at first glance:

there is a file in the iso called appliance_configuration.xml where every single appliance starting from the Nokia/early Check Point IP appliances are described.

increasing the "lv_fcd" from 8192 to 16384 might do the trick.

 

0 Kudos
PhoneBoy
Admin
Admin

Not sure that’s the right file to modify.
Maybe one of @Tsahi_Etziony ’s team can comment on this.

0 Kudos
Zoltan_Bogdan
Contributor

Somethings seem to work because if I break the syntax (I've written 16.384 instead of 16384) no partitioning takes place an the anaconda partitioning tool throws an error. 

Writing the ISO file anyway seems to loose some data because the written file is always way smaller than the original mounting/comparing those files shows quite some missing files.

I'd very much appreciate @Tsahi_Etziony to have a look at this. 

0 Kudos
Dov_Fraivert
Employee
Employee

Hi @PhoneBoy @Zoltan_Bogdan @_Val_ 
We have blinks  for 6K.
You can see details at the following link:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Regarding isomorphic, from R81.10 we made a change so that Jumbo would be copied straight to the current partition and would not be saved in FCD partition.
This should solve the problem of the partition size.

_Val_
Admin
Admin

Good news. The main Blink SK should be adjusted then, @Dov_Fraivert 

0 Kudos
genisis__
Advisor

It would be great if Checkpoint implemented this fix on the ISO images so customers are not forced to just use blink images.

I take it, this should be a relatively easy thing to do?

0 Kudos
Dov_Fraivert
Employee
Employee

Yes, we will update the SK,

0 Kudos
Zoltan_Bogdan
Contributor

Dear @Dov_Fraivert 

<edit>

Great news, thanks for sharing, so I'take Blink into consideration again:

Concerning  isomorphic sounds good, but I encounter the issue anyway.

I missed the 81 in 81.10 - sorry. Is there some kind of backport possible?

</edit>

I'm using isomorphic build 187 to make 80.40 installations with the latest Jumbo (T118) alongside DA (Build 284) applied.

As the error anaconda throws during installation is exactly the one described in  sk122014, the Fix somehow doesn't seem to work.

Any suggestions (take a sooner build/another image etc.)?

0 Kudos
Dov_Fraivert
Employee
Employee

Since the correction is only from R81.10. For R80.40, if there is a problem with size of the partition, the recommendation is to create isomorphic with iso only and install JHF after that.

@Zoltan_Bogdan I would be happy if you would send me privately more details about the installation you need to do. Maybe we can use other tools we have like Octo or Zero Touch.

0 Kudos
genisis__
Advisor

If it helps I've tried to get a RFE raised, only to be faced with "Whats the financial justification, or something along these line".

Checkpoint, very simply get it fixed please; its the right thing to do.  Why wait for customers to complain when you know there is a problem. 

0 Kudos
PhoneBoy
Admin
Admin

It sounds like we've fixed the issue in R81.10 (if I'm understanding @Dov_Fraivert 's comments correctly).
For earlier releases, it looks like you have a workaround now 🙂

0 Kudos
genisis__
Advisor

It would be nice if this could also be adjusted for the R80.40 and R81 images.

0 Kudos

A workaround ... as long as you know about the issue. This problem bit me last week when trying to upgrade some firewalls from R77.30 to R80.40. There's no warning in the ISOmorphic documentation to not apply large hotfixes like a jumbo. The demonstrative screenshots even use R80.40. This is definitely a documentation bug, which should be trivial to fix.

There's no warning in ISOmorphic itself that it's about to create installation media which will wipe your box but won't actually install the new version. No warning after the media is created, either. While I get that changing the partition sizes would require releasing a new ISO image for older products, ISOmorphic not warning us is definitely a bug in that tool.

0 Kudos
genisis__
Advisor

When I raised the TAC case (ages ago), I pointed out the same observations and suggested that safety checks where put in place to stop the rebuild as a result of this issue.

0 Kudos
genisis__
Advisor

I'm pretty sure I done this a very long time ago and also ask TAC via an old case for this be be done.  

Either why this is not a specific customer requirement this is a requirement in general as clearly the partition sizes need adjust to account for the size of Jumbos.

0 Kudos
genisis__
Advisor

I've had the same issue, and in fact raised a TAC case about this, suggesting to Checkpoint that this seems to be an issue in the build process ie not enough space allocated.

I've also had the same issue when mounting any ISO via LOM.

0 Kudos
Zoltan_Bogdan
Contributor

Dear @genisis__ ,

"I've also had the same issue when mounting any ISO via LOM."

=> That's a little strange. That has always worked for me.

From when is your TAC case?

0 Kudos
genisis__
Advisor

I believe its another know issue.  I should point out that I've not had this issue building R81 using the ISO image over iDRAC. 

Now remember when going over iDRAC I'm just using the standard ISO image, no Jumbo's etc integrated. 

0 Kudos
Zoltan_Bogdan
Contributor

Maybe still the same root cause. I managed to work around the issue by unpacking the image, editing the respective appliances' patitioning defaults in  /system/base/appliance_configuration.xml
<appliance_partitioning>
<layout min_disksize="434000M">
<volume name="lv_current">32768M</volume>
<volume name="lv_log">196608M</volume>
<volume name="lv_fcd">8192M</volume>
<volume name="hwdiag">1024M</volume>

<volume name="max_swap">32768M</volume>
</layout>

and of cause repacking the image again:

 

genisoimage -U -r -v -T -J -joliet-long -V "CP_R80.40_GAIA_3_10" -volset "CP_R80.40_GAIA_3_10" -A "CP_R80.40_GAIA_3_10" -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -no-emul-boot -o ../CP_R80.40_GAIA_3_10.iso .

Sticks with that image work flawlessly with jumbos

(1)
genisis__
Advisor

Awesome!

where did you get the various file to do the above?  Have you tried this on R81.x images at all?

One other thing,  realistically we should not be doing this as Checkpoint could turn around and not support the installation as you have modified the original ISO (Checkpoint should really know this does not work as many people have logged TAC cases,  and it just looks like that age old thing, they cannot be bother update the ISOs)

0 Kudos