@mashina The history table issue’s I’m seeing appear to be legitimate:

You wouldn’t be able to deploy snapins to a host if the snapin isn’t associated to a host. That said, I don’t know exactly what deploy type, nor what actual “version”

while I can checkout the commit hash, it’s just a hash and not somethign I readily memorize.

your exact version of FOG would show on the bottom right of the UI when you login.

I believe your commit hash relates to working-1.6-beta.2273 or something like that.

That’s within 2 of the actual “current” but also notably it is within the save function rewrite. Which we definitely see in the history writing.

It appears like you’re trying to do a Multiple Snapin Task and this is failing?

@JGeear I don’t know if anything changed, just I wonder if someone was making an edit in the UI and accidentally changed the password in the UI. I’m having you start with where I know the system is getting the information. Make sure the username/password matches what is on that nodes /opt/fog/.fogsettings file. If they are the same, then I’d ask if you can use that same information and an FTP client to ensure at least connection is there. Then we can try to troubleshoot further.

@mashina Can you get select * from history; out of your database?

I’m having a sneaking suspicion the issue is likely part of a rewrite to substaintially make save our save to database functions, that has some repercussions on other things because so much had required things that shouldn’t have bene required.

Similarly, can you provide the exact version?

“Latest working-1.6” is a shifting target. like i’m pretty sure you were not on the latest since I made pushes today so pretty sure the error you are getting is not related to today.

@JGeear your FOG Storage Node -> username/password is where the ftp_login information comes from.

@mashina Similarly for you, but I call out about the “same message” becasue working-1.6 is using ssh unless you’re on an older (1 year or so ago) version of working-1.6?

@mashina Are you sure it’s giving ftp_login error?

@Redbob The username/password should match an authentication you use for the FOG GUI.

@Greg-Plamondon I’m going to try delving into this but I’ve been very busy with other things and just haven’t gotten around.

I do appreciate the patience and assistance.

The changes you were doing that fixed the problem, please implement them again and you should be back to functional

Once that is done, do you mind doing a diff between that file and the relevant file in the git repository side:

Files I think you changed were under: <path>/<to>/<installer>/packages/service/<servicename>/<servicefile>

I’m not seeing any issues on my test systems.

not really sure why it isn’t working either.

I believe you were editing the files in /opt/fog/service/<servicename>/<servicefile>

So you would do:

diff -u <path>/<to>/<installer>/packages/service/<servicename>/<servicefile> /opt/fog/service/<servicename>/<servicefile>

@xavier-duthilleul I suspect it’s your /etc/fstab is looking at a UUID instead of a physical medium.

The one drawback to the uuid method of bootloading (which is great to always ensure you get the same files) is that the UUID’s are not the same between systems.

@Greg-Plamondon I’m not sure I fully understand:

When I look at the dev-branch files I see that the sprintf method you are doing for PingHosts is what is happening for ImageSize/ImageReplicator

The code you’re changing is within the sprintf stanzas?

@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