pre and post image scripts
-
Hi,
I’m wondering if there is any chance of executing two local scripts (at fog server) every time we deploy an image, one of them before the deployment and the other once it ends.
The idea is to automatize some tasks that need to be done at the server side each time an image is deployed.
Thank you! -
What? We already have pre-init scripts and postdownload scripts.
These are specific to the host being imaged though, not to the fog server itself as I’m understanding your request.
-
Thanks for your reply, Tom.
The question is that we are moving the server from a development environment to the production network and the people in charge of security are worried about the NFS service in the Fog server, that is widely open to everyone. So, we are thinking about to make some kind of patch, using the “exportfs” command at the server side so we can just allow the NFS service to the computer that is going to be deployed (pre) and remove that permission once the deployment is done (post). -
@michelsantana You can restrict the NFS mount to a specific IP subnet range if needed.
With the pre and post execution scripts. Those are executed from the target computer perspective and not from the FOG server perspective.
So it would be difficult to have the target computer turn on and off NFS as needed. The FOG server could do it but not the target. The other issue you might run into is if you are deploying to two different systems via unicast. What happens when the first one finishes but the second one is still deploying? The first one will be done so it shuts of NFS before the second one is finished?
-
@michelsantana From a security perspective, what are they trying to protect. The NFS share is only visible to *nix based computers. Windows (without additional services) are not able to reach out to this share.
I can see this open nfs share a security concern if you are using fog to “back-up” end user computers because these images may contain regulated data (PII and such). But in general a traditional deployment image will be clean from any PII.
The /images/dev share is open to world write capabilities. This is needed to upload images to the FOG server. The /images repository is read only. As I posted before if you know you will only access the fog server from a specific subnet you can restrict the NFS server to only respond to requests from that subnet.
The image files on the fog server are not encrypted (but probably could be made so). Getting access to the data while possible, is not easy. You would have to use the right unencryption program and then the right tool to extract the image. Moving the files to another fog server would be the easiest way to extract the image.
In the end you need to look at the risks involved with what you are protecting. What are the risks for having an open nfs share? Are there really intolerable risks (I can’t answer that for your organization) or are you just trying to tick all the boxes on a PCI compliance audit?
-
@george1421 said in pre and post image scripts:
Thank you very much for your replies. I think that the complexity of implementing this kind of security measure doesn’t worth the time. Perhaps just restricting access to several subnets is more than enough.
I will go that way.
Thanks!
