@pecata As George said it can only be done of source and destination disk are identical in size (sector count!). To achieve what you requested you’d have to capture and deploy an image fully at least once. Then I’d advice you create another image definition in the web UI where you set it to capture only c:\ (take a look at windows disk management tool to see if it is partition number two - likely). Capture this from the same source PC as you did initially capture the full image. Now you are able to deploy this single partition image to other PCs.
@msi Well, this has nothing to do with FOG in general. Tell your DNS admins to add entries for the IP to name resolution within your local network and you will be able to use the name instead of IP for the web management. Though the clients will still use the IP but that doesn’t matter to you I reckon.
@zorderelda The info you are looking for, unfortunately doesn’t exist outside of the brains of the developers. And I agree we really need to get some documentation on this to grow the list of available plugins.
I’ve done some tweaking of a few plugins and I can say they are not difficult but also a pita at the same time.
I worked on / with 2 plugins the LDAP and the Persistent Groups.
The persistent groups was created by the developers to aid in installing a sql trigger that simulates persistent groups in FOG. It is the most simple one with no menus or outward appearance that it has been installed.
The ldap plugin is a bit more complex, but it also shows you how to create tables, hook into a process. It also has a display/editor page. I can tell you the graphics at the top are fonts based on the font awesome library http://fontawesome.io/
The fog application has and calls out hooks at certain functions and as a plugin programmer you can tie into those hooks to add function to fog.
That is about it from what limited knowledge I have.
@tom-elliott Thanks for the reply. This is from our main server. I just built that one and put it in place to test it. That FOG version is 1.4.4, running on the latest CentOS 7. We have a much older one running Ubuntu that I would like to replace.
But much to my horror, the FOG client will task restart the host when connected to Wi-Fi, which ends up in a boot-loop and a very concerned end-user.
So to avoid this, just don’t create imaging tasks for laptops unless they are hooked up to the network with a patch cable, and leave all your MACs enabled so you can still use snapins.
I don’t know what your setup looks like or how your operations go where you are, but the way I did laptops in great numbers was I hooked up an 8 port 1Gbps switch on a big table, hooked that up to the building network, setup myself some power strips and some laptop adapters, and I used my pre-made FOG Groups to queue all of the turned-off laptops for unicast imaging. Then I hooked up 8 at a time and powered them on. When one completed imaging & domain joining & snapins, I shut it down afterwards and hooked up another.
@Fernando-Gietz While, theoretically possible, the password in the db is there as nothing more than a show. The password is not encrypted. It’s hashed, and a hash cannot be brought back to the password. You would have to brute force until you found a match and even then we are checking if the type is valid. So it IS possible, but very very unlikely.
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.
yes I looked at fog transfert code too because I managed to connect glpi and fog but it’s not working further
and I’m not good enough with mysql to correct what’s wrong
anyway thanks for the tip of csv import