Multicasting stuck on starting to restore image

[Tom Elliott]

@Wayne-Workman this will not fix the issue because the files and data are not read using that password, it’s the information of the storage node that is in use. I will attempt to see if I can replicate the issue as described pertaining to the password updating but @arainero is correct that this is not the issue with multicast or any of the services (besides the replicators maybe) failing.

[Quazz]

@Wayne-Workman

The Storage Node password update thing seems to have trouble whenever you save the password of the WebGUI login (at least it does for chrome, not sure for other browsers)

It will overwrite the password in the field with the WebGUI password.

[Tom Elliott]

@Quazz This sounds like autofill to me.

[Quazz]

@Tom-Elliott You’re correct, but under normal circumstances if you alter the data after it autofills, it will accept and store the new data. It does not for the storage node login information, however.

[Tom Elliott]

@Quazz No, that’s what autofill does Quazz. It tries to guess what you want in that particular field, and the username/password you most commonly use will likely be there.

Now what version of FOG are you running? I’m fairly sure I’ve add a false input field specifically so that it would be prepopulated with the autofill data, so this issue would not occur. Then again, I can’t fix the browser’s coding.

[Quazz]

@Tom-Elliott I think I may not have made myself clear.

The fields are indeed prepopulated. But when you then alter the data (aka you go into the field and manually change it) it will display these changes to you, but then when you go to save it it will save the prepopulated data, rather than the data you deliberatily filled in.

[Tom Elliott]

@Quazz I don’t think you’re correct.

Have you checked in the actual Database? The form only uses request data as it’s filled in, and the fields are only whatever is in the field during post. Unless I’m missing something, I’m pretty sure what you’re seeing after the save is the same autofill that prepopulated it before.

[Quazz]

@Tom-Elliott Ahhh, can’t believe I was that stupid, you are right of course. I was led to thinking this when I installed the server in a VM and imported the database but obviously forgot to update the storage password.

My bad, sorry for taking up your time with my nonsense.

[Tom Elliott]

@Quazz Nah, you’re fine, I have seen this question time and time again though.

One of the things I still have a hard time with is the autofill by itself. I now have fake fields that should take the autofill so that it’s out of the question, and I have the form field’s autocomplete=“off” specified. Chrome is now making it’s own decisions? GRRRRRRRRRRR

I know it’s not your fault, but it also is not my fault. I’m sorry we have to hack this with a fake field to begin with, why not have the browser actually listen to the autocomplete setting in the first place? It’s what it was designed for anyway.

[arainero]

@Tom-Elliott Since we can rule out password mismatch not being the problem here, is there anything else you recommend to try next?

Thank you.

[Wayne Workman]

@Tom-Elliott said:

@Wayne-Workman this will not fix the issue because the files and data are not read using that password, it’s the information of the storage node that is in use. I will attempt to see if I can replicate the issue as described pertaining to the password updating but @arainero is correct that this is not the issue with multicast or any of the services (besides the replicators maybe) failing.

I was re-reading your post and just realized lol… Yes you are right. That previous post is wrong.

You can set the FTP password used on the storage node by looking into the storage node table and modifying the password for the correct node in there.

[Sebastian Roth]

@arainero Did you get this solved?

[arainero]

@Sebastian-Roth No, I do not know what to do next. I was waiting to see if anyone had any thoughts.

[Sebastian Roth]

Updated to the latest trunk? Do you still see errors when rebooting? Please check your apache error log and let us know about errors you see in there.

[arainero]

@Sebastian-Roth I just updated to the latest trunk and attempted a multicast. The multicast failed and this was in the apache error log. I no longer have a multicast log from the drop down menu in the Log Viewer.

[Fri Nov 20 16:06:55 2015] [error] [client 192.168.1.2] Directory index forbidden by Options directive: /var/www/html/
[Fri Nov 20 22:20:30 2015] [notice] caught SIGTERM, shutting down
[Fri Nov 20 22:20:46 2015] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri Nov 20 22:20:46 2015] [notice] Digest: generating secret for digest authentication ...
[Fri Nov 20 22:20:46 2015] [notice] Digest: done
[Fri Nov 20 22:20:46 2015] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.6.15 mod_ssl/2.2.15 OpenSSL/1.0.1e-fips configured -- resuming normal operations
BFD: /var/www/html/fog/service/ipxe/bzImage: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .bss
BFD: /var/www/html/fog/service/ipxe/bzImage32: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .bss```

[Tom Elliott]

@arainero are you still getting the getBanner message too?

[arainero]

@Tom-Elliott Yes, after doing a multicast service restart I get:

[root@fogserv bin]# PHP Fatal error:  Call to undefined method MulticastManager::getBanner() in /opt/fog/service/FOGMulticastManager/FOGMulticastManager on line 14

[Sebastian Roth]

Well I guess the Multicast service is crashing and that’s why you never see clients start a multicast session. But I really wonder why you have this error. Do you have enough free space on your disk df -h? Did you see any errors when updating to the latest version?

[arainero]

@Sebastian-Roth There is enough space and I don’t notice any errors while updating.

[Tom Elliott]

@arainero I believe I know the problem but I may need a teamviewer session to verify and help fix.