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

Proper place to put custom scripts

Jump to solution

Hi,

So, I wrote my own backup script for Security Management Server and I thought the proper place to put it in is /usr/local/sbin/

Well, I was wrong. When I upgraded server from R80.10 to R80.20 my script was silently deleted.

Where shall I place my scripts so that they are preserved between upgrades?

1 Solution

Accepted Solutions
Highlighted

Our recommendation is to use the Script Repository available in SmartConsole.

As Check Point Objects, they will survive all upgrades.

Later you can run that script on gateways by right-clicking them. You can also run them with the Management API referring to just the name of the Script object with the parameters "script-name", representing a title for the script, and "script", representing the script code.

View solution in original post

14 Replies
Highlighted
Admin
Admin

Somewhere under your home directory is probably the safest place to put it as it should not be affected by an upgrade.

Highlighted

Thank you, /home/bin/ it is then.

Highlighted
Champion
Champion
It depends. Check via set with paths are defined in your environment. I prefer /usr/local/bin


0 Kudos
Admin
Admin

I think he said that location got overwritten, thus why I suggested somewhere else.

0 Kudos
Highlighted

Yes, I just need a path that won't be touched by the upgrade scripts. I vaguely remember according to LSB, /usr/local/bin/ is the right one. Do not like to put executables in home dir but in this case I probably have no other choice.

Highlighted

The best would be to do deep pre-check before upgrade. Save all custom scripts and cron jobs outside of the machine to be available for all collegues and ready to be put back after upgrade. This is also valid for all .conf and .def files.

Kind regards,
Jozko Mrkvicka
Highlighted

Our recommendation is to use the Script Repository available in SmartConsole.

As Check Point Objects, they will survive all upgrades.

Later you can run that script on gateways by right-clicking them. You can also run them with the Management API referring to just the name of the Script object with the parameters "script-name", representing a title for the script, and "script", representing the script code.

View solution in original post

Highlighted

I like that the most, thanx Tomer. Only need to figure out how to invoke script from Job Scheduler using Management API. Shouldn't be that difficult...

0 Kudos
Highlighted
Advisor

In case you want to invoke job scheduler then I think it is still the best way put it to some /home/ directory and attach job to cron. Just attach it there via  WebUI or CLI commands:

HostName> set cron job JOB_NAME command ... 
HostName> set cron job JOB_NAME recurrence ...

In that case job stay to be scheduled in your configuration file. On the other hand you must still have the script itself backuped somewhere. 

For me personally it is not a bafd enchancement to have possibility to use Script repository and just schedule same script for example on different firewalls throuh console...

0 Kudos
Highlighted

Thanks for the information Tomer. I just created a new SecureKnowledge article with this information, sk140852.

Highlighted

Great idea, thanx! Just to mention, there is a small error in SK. Parameter name is "script" and not "script-body".

Highlighted

sorry about that, I made the mistake originally in this thread..

0 Kudos
Highlighted

Thanks. I just fixed the sk. The fixed version should be available within a few minutes.

0 Kudos
Highlighted
Advisor

If you like to share your exprience with running scripts thru the Scrpit Repository your are more than welcome to join my threat: SmartConsole Scripts Repository usecases and experience 

0 Kudos