Posts made by Claude Girard

@Tom-Elliott said:

@Claude-Girard Beyond that, what does the advanced menu show when you go to it in browser?

http://ip.of.fog.srv/fog/service/ipxe/advanced.php

It shows escaped codes

@Tom-Elliott said:

@Claude-Girard I’m still confused. What does the advanced menu have to do with snapins?

Nothing to do with snapins, but I understood when you reopened issue, that it was a similar problem than :
https://forums.fogproject.org/topic/5931/rev-4932-snapins-parameters-with-in-command-not-correct-in-database/9

Maybe I am wrong but isn’t it the same problem when you say:
“I’m pretty sure I added the same type of code sanitization to the run with, file, run with args fields as I do with printers.”

@Tom-Elliott said:

@Claude-Girard what’s the advanced file actually show? Does it display with the escaped code, or as the actual characters.

As you can see, && become &amp&amp in database, d’ become d&#039

If I modify directly in database and save it, in FOG Gui all seems ok, characters are ok.

But if I save PXE Menu from Gui, after that in database characters are with escaped code again

Bad screen capture in previous post

In database:

@Tom-Elliott said:

I have to double check, but I’m pretty sure I added the same type of code sanitization to the run with, file, run with args fields as I do with printers. I won’t solve this until I am certain. This does not mean all bad entries from before will automatically work, but it should be fixed after updating.

Hi Tom

I think it isn’t solved.
I don’t know if it’s like in:
https://forums.fogproject.org/topic/5931/rev-4932-snapins-parameters-with-in-command-not-correct-in-database/9

But in advanced pxe menu, when I write what you can see in screen captures, escape characters and accentued french characters are badly saved in database tables.

I think all these symptoms are linked, and caused by bad locales ? (my server is UTF8) or by escaped characters interpreted by PHP ?

Thanks again for your work.
Screen captures are from rev 5273

In FOG Gui:

In database:

@Tom-Elliott said:

This is now fixed. I don’t think it’s perfect, but it should work a bit better now.

Almost.

Really sorry Tom but now each time I click on update button without any change, one antislash is added in red areas in my screen capture (and two antislashes added in database for each click )
Only in “snapin run with arguments” (I hope …)

@Tom-Elliott Thank you but sorry, it doesn’t work.

After update, no modification of snapin, in database I had:
in snapin run with:
c:\\program files\\7-zip\\7z.exe
in snapin run with arguments:
e -y -o"E:\XPAresGACO1"

On display, I have:

If I delete and write again these lines:
Before validation:

After validation:

And in database, after validation:
in snapin run with:
c:\\program files\\7-zip\\7z.exe
(seems ok the same than at beginning)
in snapin run with arguments:
e -y -o\\\“E:\\XPAresGACO1\\\”
3 anti-slashes, then 2, then 3 !

And I understand that anti-slashes can disappear, but I don’t understand how number 7 can disappear from display

And from client:

In fog.log:

Real command in processes:

@Uncle-Frank said:

Missing/double back slashes…?

Yes back slashes are concerned.
Sorry for confusion but in my first message I wrote back slash between quotes and it disappeared from text.

You can see in screen captures:
Snapin run with: c:\program files\7-zip\7z.exe
That is before clicking update button.
In database, double back slashes

And after clicking update:
Snapin run with is transformed in: c:\program files-zipz.exe
Back slash and number 7 disappeared
And in database, only one back slash

@Claude-Girard said:

When arguments in snapins contains “”, they aren’t correctly saved in database.

Arghhh! I wrote \ but like in snapin it’s interpreted by HTML

A similar problem than described in https://forums.fogproject.org/topic/5917/git-r-4900-snapin-arguments-with-quotes-render-incorrectly

When arguments in snapins contains “”, they aren’t correctly saved in database.

Snapin before validation

Database before validation

Snapin after validation

Database after validation

@Jbob said:

@Claude-Girard
This is a bug that is fixed in my nightly builds (as seen by @Uncle-Frank 's link). For now you should be able to add a space infront of
“C:\tmp” in your “Snapin Arguments” field. Hopefully that should serve as a hot-fix.

I have already tried to add space before argument, but it is ignored, maybe because of html interpretation ?

@Tom-Elliott said:

To my knowledge no one else has been having this issue. Either that or they just haven’t reported it recently.

I have the same issue, but no way to determine a set of circumstances that can reproduce it.
Seams really random

@Wayne-Workman Yes, maybe.
But this command line is the one generated by new fog client.
I don’t know why this space is in bad place, but this command line, when executed in a terminal window, give an error.
with a space before C:\tmp, no more error.

@Jbob Sorry but another Fog user confirmed that no file is copied.
After capturing processes on clients, I think I have found what is causing the issue.
Here is the command line executed on client:

“c:\windows\system32\cmd.exe” /C copy /Y "C:\Program Files (x86)\FOG\tmp\activ-licences-labview-mp206.txt "C:\tmp

I think space is missing before snapin arguments

@Jbob said:

I cannot replicate this issue. I’ve replicated your snapin configuration and it works fine. According to the log you posted, the issue is with a configuration on your computer, not the client (the return Code 1). Try running the command on the machine manually (using a local copy of your license.dat file).

Yes manually it works.
And remember, I said that after uninstall new client and install legacy one, it works.
I’ll try debug utility, to see if I can find more informations.
I don’t know if it can help, but client is installed on Win 8.1, with French parameters (but I have no accented characters in files or directory names)

@Wayne-Workman said:

I think this feature would help your issue…

https://forums.fogproject.org/topic/5751/snapin-show-command-during-editing/1

Give that thread some love.

Yes it could help.
This feature is in rev 4738
Command seems to be correct.
On client, I can see the file appear in tmp directory under fog install directory, and disappear after snapin execution, but no copy in my target directory

Hopefully by the time i get in to work tomorrow I can put a solve setting on this thread.

Yes I think you can.
Hosts are still here !!!
I can’t reproduce group issue, during 1 hour I delete hosts from groups, include them in existing or new groups, modify by group image association, service settings, active directory, and snapins.
I lost 1 member in a group only one time, 66 members at start, and 65 after modifying settings in the group, not sure but I think after active directory settings.

I decided to do that because I thought that after this bug my database was in an inconsistancy state.

I sent these 3 requests to my database:
SELECT * FROM hosts WHERE hostID NOT IN (SELECT hmhostID FROM hostMAC)
Before update, I had a lot of rows in result, and growing. But now it’s ok.

SELECT * FROM hostMAC WHERE hmhostID NOT IN (SELECT hostID FROM hosts)
Never had result, was ok and is still ok

SELECT * FROM snapinAssoc WHERE saHostID NOT IN (SELECT hostID FROM hosts)
Returned a few rows in result, maybe not directly due to this bug, maybe this table was corrupted before.

I think that tables refer to hosts by Mac adresses, except snapinAssoc table. Is it right ?
So with these 3 requests, I can find bad hosts and bad snapin assoc, and I delete them from database.
But maybe I forgot one or several tables to check ?

Thank you for you job !

@Claude-Girard And good news:
My sql request:
SELECT * FROM hosts WHERE hostID NOT IN (SELECT hmhostID FROM hostMAC)
hours ago !!!
returns 0 rows since last fog update,

@Tom-Elliott said:

@Claude-Girard WHEW

Thank you,

While that is an issue on it’s own, at least the host’s (themselves) are still in tact.

Yes that’s the most important
No time today but tomorrow I’ll give more infos about group issue.
I’ll do more tests because after my restore, I prefered clean database by deleting some hosts and recreating them.
The ones that leave group were not.
I’ll try to delete them and see if after recreate problem pesist.

@Tom-Elliott said:

@Claude-Girard So what you’re saying is, everything was fine for nearly 2 hours, then they just started removing themselves? Do you have multiple nodes? If you do have multiples, are they all on the same revision?

No, hosts are presents and stay presents, but some groups are modified, hosts disappear from group members only