Posts made by Tom Elliott

@MarkG Can you describe more?

Here’s what I see in dev-branch:

        $var_name = false;
        if (property_exists($vars, 'name')) {
            $exists = self::getClass($classname)
                ->getManager()
                ->exists($vars->name);
            $var_name = strtolower($vars->name);
            if (!$var_name) {
                self::setErrorMessage(
                    _('A name must be defined if using the "name" property'),
                    HTTPResponseCodes::HTTP_FORBIDDEN
                );
            }
        }

629 is the start of the self::setErrorMessage

@processor Don’t feel ashamed. Mistakes happen and that’s what we are all here for.

The example I was asking for was the output, but then it all clicked. You were doing a Get request

@mark29 The dynamic nature of images and systems FOG doesn’t track the IP address of systems, anymore. In really early versions it did track the IP address at least but hasn’t for quite some time.

That said, I think what you’re asking for is possible but it would require a Snapin to do so, and even that would be ugly. (If it truly must be static, this would be the best route in the end if you’re requiring only using FOG to manage this I think.)

You would create a Powershell scriptp that utilizes the Set-NetIPAddress statement and probably need a lookup to figure out which device needs to be using which IP address and all (that’s really the ugly part.)

The best case, though, I think, is to utilize DHCP reservations, as this would not require any special programming or even a snapin for that matter (another kink that can potentially not work appropriately.)

The DHCP server options of your AD controller, can be used to define specific IP’s in an automated way, rather than rely on a program to set the IP address.

@processor Can you provide example?

If you use cancel|remove|delete, the type shoudl be a DELETE request, you’re currently (from what I can see) doing a get request.

curl -X "DELETE" -sL -H "fog-user-token: [token]" -H "fog-api-token: [token]" http://10.0.0.1/fog/task/3001
# OR #
curl -X "DELETE" -sL -H "fog-user-token: [token]" -H "fog-api-token: [token]" http://10.0.0.1/fog/task/3001/cancel
# OR #
curl -X "DELETE" -sL -H "fog-user-token: [token]" -H "fog-api-token: [token]" http://10.0.0.1/fog/task/3001/remove
# OR #
curl -X "DELETE" -sL -H "fog-user-token: [token]" -H "fog-api-token: [token]" http://10.0.0.1/fog/task/3001/delete

@Tom-Elliott Router code should now expect a name item for the edit param if you’re passing in a name property as part of the json payload.

Basically

‘name’ = ‘’ will fail

A payload completely missing name should work just like it did before without the warning messages.

@MarkG The issue is if you change the name to another host that already exists:

SO let’s just use the example case here:

Say you have host named abc with id 1
Say you have a host named def with id 2

You are trying to edit id 2:

You decide to change the hostname to abc… Which thing should we do, delete the existing abc host, delete the existing host? Instead we error out.

That said, I believe I see and have pushed what I think will fix this issue for you.

Please repull dev-branch, and you shouldn’t be required to have the name value in the json payload.

The other piece, while it was a warning, it definitely wasn’t an issue.

Now when you add the name parameter, if you set as nothing it should fail, so I’m not sure if there is a host in yoru database with that name?

If so, please let me know. I suspect you now have 2 hosts in your host table, one with an empty name and one with the original name?

SELECT * from hosts where host in ('', '<original_hostname_here>');

From a MYSQL prompt. I will likely want to ensure a name field is properly set in the router code

@processor it does work.

@processor That deals with “FOGClient” which when you’re in a tasking would not do as you’re requesting.

@processor I apologize, I guess, for this free solution that provides help in the best way it can?

Sorry if I’m seeming rude, but we cannot possible fix all potentialities.

Yes there may be some “pain” points, but I would think what our utility provides in normal circumstances far outweighs the issues you’re finding with these occasional issues?

I’m not aware of any magical utility that could do exactly what you’re looking for:

• Boot to some different envirnoment in multicast.
• Look at if the multicast session is already running, but I’m not doing anything forcibly shut down the system.

@processor You have to tell the system to boot. If it’s starting after the fact, why not just physically power it off?

There wouldn’t be a nice way to do this from the web UI

@processor I’m not aware of it as it’s expecting to be loaded into the specific session you’re requesting to join. So you’d have to wait until the tasks are complete for all clients, and then reschedule it I think.

@gothikserpent What are the issues you’re seeing in the Single Disk resizable method?

I ask because while, from a purely technical standpoint, a resizable image would indeed be able to be on a slightly smaller disk (assuming your linux partition is in an EXT format, not LFS) the capture itself doesn’t change, just the restructuring of the partitions.

@pbriec I suppose, what kernel are you currently using?

@oelked I’m not sure I understand.

What is Persistent Groups plugin not doing that you’re hoping for?

Don’t get me wrong, a plugin building is a good time, as it helps you learn how to hook and event things in the FOG UI as well as potential interactions with other elements as possible. Just I don’t understand the scope of the problem you’re having that Persistent Groups couldn’t address.

@pbriec That is the correct place.

With that set, I wonder why it’s not passing the correct mac through.

There’s not really a reason why in debug mode it works, but out of debug mode, it doesn’t

Just thinking out loud.

@pbriec and you have the domacset flag set at the global level?

@deblpuw have you looked up the error code for Citrix? That error code you see didn’t come from the client but from the installing application

@michaeloberg I know this is an old topic, but there’s a piece that I noticed missing in all the instructions:

At registration time, the domacset flag isn’t set, so it would use the non-passed through device.

Please see this post:
https://forums.fogproject.org/post/154826

it should help as there is a “global” method to set domacset regardless of if the device is registered or not and I suspect that will FIX the problem for new devices.

I’m sure you’ve worked around this by now, but just wanted to make it informed.

@pbriec In the link I provided, @george1421 posted a different init.xz image file, I don’t know if that file is still available.

If you follow that post though, it should give enough direction to help provide the steps.

From your FOG Server

• Effectively, make a backup of your existing init.xz file:
  mv /var/www/fog/service/ipxe/init{,_orig}.xz
• Download the file
  curl -o init.xz https://drive.usercontent.google.com/download?id=1cFsPlkrqlwOjblHErCGr-OXHiKZd8jeZ&export=download&authuser=0
• Set the domacset=1 flag for all devices moving forward:
  • Goto FOG Settings and look for the “FOG_KERNEL_ARGS” element and add domacset=1 and save.
• Start a compatibility and see if the right mac address is now working

Hopefully it does

@aviel1540 Not sure I understand the question entirely.

• You deploy image to machine
• After machine deploys, create a capture task for the machine
• When machine boots, it does an upload of it’s image.
• Once uploaded, then it boots to the OS?

You can just tell the machine to shutdown after the tasks are complete, so that you don’t have to wait 5 seconds. Sure you would have to physically generate the capture task, but this way would prevent the system from booting to the Newly deployed image.