1.5.7 Does not capture correctly
-
Will you look in /images/dev for a directory that matches the MAC address of the target computer you just captured? If its there then it appears that the linux service account
fogprojectis out of sync with the values stored in the web ui.Here is a tutorial that you should run through to resync all of the locations where that service account is defined to ensure the passwords are all correct.
https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password -
Worked through your instructions and in fact in the default storage part the fogproject password did not match.
Maybe useful for debugging:
Some parts of the password were the same, but 2 characters appeared to be Unicode characters. Unfortunately I did not take a screenshot to show what the password looked like.Four letters of the correct password are:
\^S;
I think, that in the incorrect password in the storage node, they were replaced by those unicode characters.Please let me know if you understand, what I mean.
The capture-task worked in the end.
-
@Tywyn Thank you for the feedback. What is the native language (codepage) defined on the FOG server. I assume it isn’t us-english. This sounds like a flaw in the fog installer script we should probably have the developers look at. Its pretty late in the game to get it into the 1.5.8 release, but surely if its fixable will make it into the next release.
It would be handy to know what it was set to vs what it should have been and what locations were incorrect. Was it just in the storage node configuration?
-
@george1421 said in 1.5.7 Does not capture correctly:
@Tywyn Thank you for the feedback. What is the native language (codepage) defined on the FOG server. I assume it isn’t us-english. This sounds like a flaw in the fog installer script we should probably have the developers look at. Its pretty late in the game to get it into the 1.5.8 release, but surely if its fixable will make it into the next release.
It would be handy to know what it was set to vs what it should have been and what locations were incorrect. Was it just in the storage node configuration?
LANG=de_DE.UTF-8
Yes, just in the storage node config. In the tftp-server part it was correctly mapped.
-
@Tywyn said in 1.5.7 Does not capture correctly:
LANG=de_DE.UTF-8
Yes, just in the storage node config. In the tftp-server part it was correctly mapped.@Developers ??
-
@Tywyn It would be really helpful if you’d remember some more detailed infos on this. What did the unicode characters look like?
@george1421 Without more details I am not even sure this is still an issue in latest dev-branch. You know that we have changed the random password generator since 1.5.7. Might be fixed already but I can’t be sure without more details.
-
Maybe I have a snapshot before I went through the list to resync the credentials. Will check tomorrow, when I am back in the office.
-
@Sebastian-Roth said in 1.5.7 Does not capture correctly:
@Tywyn It would be really helpful if you’d remember some more detailed infos on this. What did the unicode characters look like?
@george1421 Without more details I am not even sure this is still an issue in latest dev-branch. You know that we have changed the random password generator since 1.5.7. Might be fixed already but I can’t be sure without more details.
@Sebastian-Roth : Will send you the cleartext-password in a PN, if it helps to debug. Please let me know, if you need it.
In my previous posting I was wrong. The password in the storage section differed completely from the correct password.
BTW: Was not able to upload the png to the forum here, so I used an external Server: Message was:
Fehler: Beim auswerten der Serverantwort ist etwas schiefgegangen.which may translate intoError: Something went wrong while evaluating the server answer. -
@Tywyn Can’t make any sense of this so far. Maybe when you send me the password. But you said it was really different?!
-
Thanks to @Tywyn who provided the initial password I was able to figure out why this happened. The installer uses the password to update the storage node setting in a way that is prone to a URL encoding issue. I have to admit I didn’t know base64 encoding can actually produce strings that can cause such a problem:
$ echo -n 'as~ja$j2niau83j2' | base64 YXN+amEkajJuaWF1ODNqMg==The
+character is then miss-interpreted by the PHP code as space character and therefore breaking the base64 decoding of that string.I just pushed a fix to
dev-branchin hope if this fixing all cases that special characters could cause in that part of the code.
