@christop Can you post your apache error log (or php-fpm www-error.log if redhat based) showing the message immediately after the HTTP 5xx Server Error.

@raul The -y parameter will allow that to go through. I use it all the time specifically for this one piece.

@SotY I know roughly when the error was introduced (1.5.10.1748) and I even know where it’s happening, what I don’t always know is the why.

It seems like the host anmed TEST was created/updated? I don’t see history showing it as successfully created, but maybe there’s just no history log of new host creation.

(Sorry there’s a lot of code and while I know a lot of it, it’s not all fully committed to memory lol)

@SotY Can you get into your mariadb/mysql and run:

select * from history;

I suspect there’s some inventory item expected thati"M just missing.

@Jamaal The client lives on the Machine itself. not on the fog server.

Those logs live on teh Windows machine I forget the exact path but something like:

c:\program files\fog client\fog-error.log or something like that?

@mfe Can you provide the FOG Client Logs?

@Gordon-Taylor Can you please install the dev-branch version?

The error (value min() issue you see) has been fixed in the latest dev-branch.

I hope this would fix the problem you’re seeing of course, but we won’t really know until that’s done.

1754 is the latest “stable” version, but dev-branch is a bit newer than the stable branch specifically in an attempt to fix other (and this) particular issue(s).

@Gordon-Taylor If you’re seeing an HTTP 5xx (doesn’t matter the exact number)

can you please provide your http error logs:

/var/log/php-fpm/www-error.log (on redhat based)
/var/log/apache2/error.log (on debian/ubuntu)

Also, can you get your mysql history:

sudo mysql -u root fog
select * from history;

Thank you!

@Clebboii Following up if you’d be willing to let us know?

Thank you!

@AUTH-IT-Center Please try the latest pull?

It addresses a potential security issue as well which partially what took me so long, my apologies

Placeholder

@AUTH-IT-Center Sorry moved these items to a new topic.

I want to get this addressed, but this is different from the double quotes issue:

Also:

please hit up your sql database:

SELECT * FROM fog.history;

likely it will see the latest entry of something along the lines if:

Task ID:  Name: Single Snapin Task - test321 has failed to save. Error: Save completed but no valid ID was assigned (insertId=0). Possible duplicate-key update or missing auto-increment.

This is what I’m seeing when I try to create a single snapin task (i’ve not tried with all-snapins yet, but one thing at a time. I am working to fix it, just trying to narrow down the why.

@AUTH-IT-Center I added another update but the error you’re seeing is a little strange because it should’ve bene addressed, I don’t know. The min() item is saying it requires a value and the approach I took was to check if there is data in the array, pass it to the min funciton otherwise set it to null (which should work if true)

Of course i don’t have much time to dig deep into this today, but my testing seemed to work without much issue.

Let me see if I can create a host without an image associated, tie a snapin and make a snapin task.

Okay thanks for that, that helped me fix that particular problem and address another elephant I didn’t realize still existed:

Non-Imaging tasks should not require an Image to create a task - which is partly (i believe) why you saw that error.

I’m only guessing here that this was a machine that did not have an image defined to it? If not there’s another rabbit hole I’m not sure I’m ready to dig into right away, but I did add corrections that non-imaging tasks shouldn’t require an image being set on the host level to create the tasking in the first place as well added some failsafes around that particular error:

$assocID = @min((array) $assocID);

Was the error it was hitting at line 496, basically with PHP 8, they made min function require a value and if assocID is empty (set just earlier) that’s why you were seeing an error. The assocID here specifically represented the image association on a storage group.

I corrected this specifically by setting assocID to null if there’s nothing in the returned assocIDs previously.

Apologies for the long winded answer.

@AUTH-IT-Center Since it’s writing a 500 can you provide the php-fpm www-error.log (if redhat based or apache2.log if debian)?

There’s likely some syntax issue I’m unaware of:

For the htmlspecialchars it’s only display representation:

When the HTML forms are built, we encode things which allows the fields to display correctly, and when you hit safe we decode them to ensure they’re stored in the DB correctly.

This leads me to believe this isn’t really the problem but there’s some other syntax issue that I may have missed/added unsuspectingly?

@The-Dealman Awesome thank you! and we did publish 1754 specifically due to this issue (manually running the automated processes just in case your org is worried at all )

@jmeyer As a matter of fact, the task requirement for storagegroupID has already been fixed it seems, I am on 2267 for working-1.6

Can you please try updating and see if you still have the same issue and if so, accurate/current screenshots of those errors please?

So thank you I can fix the requirement of the storagegroupID (likely meaning we can remove the need for the storagenodeID - which means I need to figure out a way to dynamically change required fields based on the task, but that’s not a major problem I can think through quickly.

If you can post actual screen shots/images of the error that goes a lot further because what you did made me just discard things because somehow you showed a 1.5.10.1688 image saying “it’s this problem” but that problem isn’t really true. Your issue is completely different (albeit from your side it may seem similar)

Context actually matters with these things otherwise I go down thinking “Yeah, no wonder it’s not working, they say they’re on working-1.6-beta.2262 but the image I see says totally different thing, that must be the issue.”

@jmeyer I’m seeing conflicting information. You say you installed working-1.6.0-beta.2262, but then your picture shows 1.5.10.1688.

I believe we just released 1.5.10.1754 but that shouldn’t matter if you’re running working-1.6.

The warnings you’re seeing in the logs seem unrelated and are just that, warnings, - they’re not directly breaking anything just a separate cause (which I realize may feel like they’re one in the same - just I know these specific things are not.)

Please get your mysql up and running and output:

SELECT * FROM history;

Most likely this will contain some information I may have missed in an attempt at better error and failsafe handling.

Particularly the the last few items that correspond to the time you see either of these issues.

The first thing I’d take a look at is why your FOG Server thinks its 1.5.10.1688 when you believe it’s working-1.6-beta.2262.

@alexamore90 I think you’re asking for something like this? https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins?_=1768874256297