@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!
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).
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!
@Tom-Elliott Perfect! Thank you very much!
When I deploy all the snapins, the software creates one “Active Task” and as many “Active Snapins” tasks as snapins to be installed. Teorically, It’s possible to cancel the installation of one single snapin (one single task) and keep the installation of the rest of them, but when you do it, the whole job is canceled.
Thank you!
@Tom-Elliott Understood 
I will probably do a custom report to have the information about the images and their partition layout. Thank you again!
@Tom-Elliott Applied the patch, captured the image from a 300GB HD and ended with this parameters:
d1.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 2921472, type=7, bootable
/dev/sda2 : start= 2923520, size= 286721536, type=7
/dev/sda3 : start= 289645056, size= 335495680, type=7
d1.minimum.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 60416, type=7, bootable
/dev/sda2 : start= 2923520, size= 53114368, type=7
/dev/sda3 : start= 289645056, size= 235008, type=7
Then I deployed the image in debug mode to a 80GB HD. The captures of the partition process (deploy in debug mode)
There were no errors and seems that everything is working fine. Finally I’ve got three partitions with the right proportions (338MB, 36,69GB and 42,93GB).
Thank you very much for your help!
P.S.
I would be great in future releases to have information about the partition layout of the images in the “Image Management” section, and also to have the possibility of fixing the size of one partition there, without the need of editing the file d1.fixed_size_partitions
@Tom-Elliott That is exactly what happens. Now I’m trying to deploy the whole image into the computer with 80GB disk fixing the size of the second partition and then resize the partitions and capture again from that computer. That should guarantee that this deployment will work in disks of at least 80GB and above.
I will post the results.
Thank you
@Tom-Elliott Exactly. Partclone starts and deploy the first partition, but when it tries to deploy the second, throws the error.
In order to clarify if it’s a normal behaviour or a bug, I have repartitioned and checked the partition schema and sizes of the partitions.
The starting point is a computer with a 298GB HD with three primary partitions:
sda1: NTFS, System Reserved. Size: 1,38GB
sda2: NTFS, Boot. Size: 30,11GB with 3,74GB free space
sda3: NTFS. Size: 266,59GB with 266,43GB free space
After doing a “sysprep”, I captured the HD with fog and this are the content of the config files in the image directory:
d1.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 2921472, type=7, bootable
/dev/sda2 : start= 2923520, size= 63135760, type=7
/dev/sda3 : start= 66059280, size= 559078065, type=7
d1.minimum.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 60416, type=7, bootable
/dev/sda2 : start= 2923520, size= 52801536, type=7
/dev/sda3 : start= 66059280, size= 261120, type=7
When I try to restore this image into a computer with a smaller HD (80GB) that should be enough to fit the three partitions, it gives me the same error.
I made the deployment as a debug task and using the “ismajordebug=1” kernel argument. Here are the screen captures:
I hope this helps to clarify what is happening. Let me know if you need more tests.
Thank you very much
@Junkhacker @Tom-Elliott Now I’m rebuilding the whole partition schema in order to have all the information detailed. I will post it in less than an hour.
Thank you
There is an error when I try to deploy a image to a computer with a smaller HD than the one used to capture the image (280GB). I have tried with two different computers with 80GB and 180GB HD, with same error.
Here is a capture of the error screen in the 80GB HD:
And the contents of the image files:
d1.minimum.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 79872, type=7, bootable
/dev/sda2 : start= 2923520, size= 52866560, type=7
/dev/sda3 : start= 155704320, size= 308224, type=7
d1.partitions
label: dos
label-id: 0x849ae652
device: /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 2921472, type=7, bootable
/dev/sda2 : start= 2923520, size= 152780800, type=7
/dev/sda3 : start= 155704320, size= 821068288, type=7
Thank you very much!! Nice job!
@Tom-Elliott You’re welcome. Here are the results after the last modifications you have uploaded. Seems like there are no more errors. Now I’m making the whole deployment to see the final partition sizes in Windows enviroment.
Thank you very much!
@Tom-Elliott Perfect! I will try again and post the results
@Tom-Elliott I have downloaded those files and repeated the process. There is a minor error than you can see in the first capture, but it seems that the problem is solved. Tomorrow I will try a deployment with a physical machine and post the results.
Thank you very much for your help!
@Tom-Elliott It seems like it’s taking the d1.minimum.partitions as source to determine the proportion between partitions instead of the d1.partitions. In our example the sda3 partition is the bigger one in size but it’s almost empty.
@Tom-Elliott In the previous example the machine (Virtual) had a 60GB hard disk. Just for testing purposes I increased the size of the harddisk to 180GB and this are the results. As you can see there is no error this time with extended partitions but the sizes of the partitions still doesn’t have the right proportions.
@Tom-Elliott You are more than welcome. And yes, in our configuration all the partitions are primary, so we don’t have any extended partition.
Thank you very much
