new ipxe entry

[6rilT]

Hello all.
I am working on fog 1.5.5 on CentOS, using it as a decomissioning server. I would like to make a few changes to it:

• I want to add the possibility to launch a capture from the client, as everyone is supposed to launch a capture from the server, I want to avoid that, so the least amount of people touches the server. No idea what type of command I need to type in in the parameters since partclone is hidden somewhere;
• The next step is to organize the pxe menu so the operations I want to make are available match my needs.
  Can anyone hellp?

[Sebastian Roth]

@6rilT said in new ipxe entry:

I want to add the possibility to launch a capture from the client, as everyone is supposed to launch a capture from the server, I want to avoid that, so the least amount of people touches the server.

If you let people to a capture from the menu they can do this on purpose to overwrite your image (will be lost then!). I am not sure if that is wise if you worry about those same people using your FOG server.

The next step is to organize the pxe menu so the operations I want to make are available match my needs.

We need more information to help.

[george1421]

I get the impression you are using the FOG server as some kind of backup tool. If you are doing that, there are better (free) tools out there than FOG, such as Veeam Endpoint Backup (free).

There are surely risks in proceeding with your plan. Uncontrolled disc consumption is one that comes to mind.

[jflippen]

@george1421 @Sebastian-Roth what about a compromise? Is it possible to have accounts for logging into the fog web UI that have limited access? Like only the hosts tab and image / capture from the list of clients. You can protect certain images from being written over already, so he can protect anything he doesn’t want modified and unlock as needed for his lower tier staff.

I think it was back in 1.4.x that FOG had limited user accounts that could deploy images, it seems they were removed though.

[george1421]

@jflippen I’ve been kind of background thinking about this all afternoon. What needs to happen is a deploy task needs to be created in the task scheduler then the target computer needs to reboot into a pxe boot.

FOG passes a kernel parameter to FOS during FOS startup in the variable called mode. A new mode value could be create like mode=autocap The master fog bash script would need to be updated to understand this new mode. this new mode could make a curl call back to the FOG server passing the target computer’s mac address to a php page on the FOG server. That php page would then enter the task into the task scheduler to capture an image. Finally after the curl call was made FOS would then reboot. Upon restart (since the capture task was scheduled) FOS would upload the image to FOG.

As a basic workflow that should work. Then a custom iPXE menu could be created to invoke FOS with that new kernel parameter mode=autocap.

The only missing/unknown bit is that a php page needs to be created to take the parameters passed by the curl call and update the task scheduler table on the FOG server.

[Sebastian Roth]

@6rilT @george1421 @jflippen Why not just use the AccesControl plugin as suggested in the other thread? If that is not yet suiting all the needs we might just modify that. It’s all there, why not use it instead of coming up with completely new things?

[6rilT]

@Sebastian-Roth in new ipxe entry:

@6rilT @george1421 @jflippen Why not just use the AccesControl plugin as suggested in the other thread? If that is not yet suiting all the needs we might just modify that. It’s all there, why not use it instead of coming up with completely new things?

This is amazing! Am looking into this just now.

@george1421 in new ipxe entry:

I get the impression you are using the FOG server as some kind of backup tool. If you are doing that, there are better (free) tools out there than FOG, such as Veeam Endpoint Backup (free).
There are surely risks in proceeding with your plan. Uncontrolled disc consumption is one that comes to mind.

Veeam Agent for Linux could be somewhat interesting, although I have to implement a DBAN in between backup and restore phases AND more importantly keep a log of what has been backed up and deployed, thanx to GDPR.

@jflippen in new ipxe entry:

@george1421 @Sebastian-Roth what about a compromise? Is it possible to have accounts for logging into the fog web UI that have limited access? Like only the hosts tab and image / capture from the list of clients. You can protect certain images from being written over already, so he can protect anything he doesn’t want modified and unlock as needed for his lower tier staff.
I think it was back in 1.4.x that FOG had limited user accounts that could deploy images, it seems they were removed though.

That sounds like a great idea only way, way, WAY beyond my knowledge and comprehension of the system. I am just an apprentice after all.
Thank you so much for your attention and leads!

[Tom Elliott]

I’m going to interject a little information here.

With 1.5.X, and forward, the “mobile” user status information was removed from the GUI. This was done because From 1.4.x and earlier, we were essentially managing 2 separate web GUI’s. One for Mobile, and one for Regular use. While, I imagine, most people just used the full fledged GUI and didn’t really know much about the Mobile interface, managing 2 web gui’s to interact with the same system is very problematic and error/bug prone.

While the “mobile” users were a limited capability user, these were also the only distinctions. Either a user was mobile, or they were admin. This isn’t, really, access control. The mobile GUI simply didn’t have the programming in it to schedule things like capture tasks. That said, however, if you knew enough of the URL you could still use the “mobile” user to do everything a normal administrative user could do.

This is where the AccessControl plugin was created. @Fernando-Gietz had a similar layout and programmed it to work for the newer versions of FOG. I assisted in making it functionally relevant where possible.

The AccessControl plugin, I think, is much more suited for what we need as it can actually limit the viewed items on the 1.5.x GUI, as well as ensure protected access in a semi-proper methodology.

Please remember, when FOG was originally created, it was not designed with limiting user access in mind. It was designed to enable Web based controls to an imaging platform. Then features were added. It became a behemoth of a system relatively quickly without thinking about proper user based controls designed within.

The AccessControl and Site plugins were made after quite a long time of FOG being in existence. It’s come a long way toward giving granular access, but it still has a long way to go. (Most likely never making it truly proper until our full rewrite is complete - which is going to take a long time.)

[6rilT]

@Tom-Elliott Thank you for pointing this out, I feel that this solution has an immense potential and I am only scratching the surface of it. Kudos to you and @Fernando-Gietz for working on such a thourough product!