hostname.php stays emtpy
-
I updated from 1.2.0 to trunk 5281. For now everything works fine, EXCEPT the hostnamechanger. when i call the url with the correct date in my browser it stays empty. Using an incorrect Macaddress i get an “invalid host” error.
If i am not mistaken it should show the Hostname + additional Information.
Everything else runs smoothly like a kitten.
-
If you’re putting an incorrect mac address, it would signify an invalid host and, if the mac address is not formatted properly (12 abcdef123456, 17 ab-cd-ef-12-34-56 or ab
ef:12:34:56) it should show up as “invalid mac address” though I could be wrong. -
The question is: The service tells me “Communication error” and would not change the Hostname, the Page stays empty with correct data, so why?
-
@christianu I think we need to see the error implicitely to further help.
Shooting in the dark isn’t going to get us anywhere, and not having any information (other than “Using an incorrect Macaddress i get an “invalid host” error.”) I can only give assistance on the information provided.
-
Yeah that is the point. This is the error message from the client service
------------------------------------------------------------------------------ --------------------------------HostnameChanger------------------------------- ------------------------------------------------------------------------------ 11.11.2015 12:30 Client-Info Version: 0.9.5 11.11.2015 12:30 HostnameChanger Running... 11.11.2015 12:30 Middleware::Communication URL: http://xxx.xxx.xxx.xxx/fog/service/servicemodule-active.php?moduleid=hostnamechanger&mac=E8:B1:FC:03:F7:CD|E8:B1:FC:03:F7:CE|54:EE:75:2D:AC:1F|E8:B1:FC:03:F7:D1||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0|94:87:B3:5B:56:5A&newService=1 11.11.2015 12:30 Middleware::Communication Response: Success 11.11.2015 12:30 Middleware::Communication URL: http://xxx.xxx.xxx.xxx/fog/service/hostname.php?moduleid=hostnamechanger&mac=E8:B1:FC:03:F7:CD|E8:B1:FC:03:F7:CE|54:EE:75:2D:AC:1F|E8:B1:FC:03:F7:D1||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0|94:87:B3:5B:56:5A&newService=1 11.11.2015 12:30 Middleware::Communication ERROR: Could not contact FOG server 11.11.2015 12:30 Middleware::Communication ERROR: Der Remoteserver hat einen Fehler zurückgegeben: (500) Interner Serverfehler. ------------------------------------------------------------------------------``` When i call the url manually with the browser its just empty. So there is an error but not really an error message. -
Server 500, or blank page is most typically an issue that I may have implemented (on accident). Whenever there is such an issue, please get your apache error logs.
I’m assuming ubuntu is your install?
the error logs are in:
/var/log/apache2/error.log
If you’re running redhat based (and arch I believe) the location of the error log is:
/var/log/httpd/error_log
-
Puh i was rly stupid - should have looked there too …
[Wed Nov 11 09:53:58.509286 2015] [:error] [pid 26265] [client xxx.xxx.xxx.xxx:49169] PHP Fatal error: Call to undefined method HostnameChanger::setAD() in /var/www/html/fog/lib/client/HostnameChanger.class.php on line 16``` -
@christianu said:
/client/
Can you re-update and reinstall?
The setAD method that that is referring to does not exist any more.
-
Okay will do - can i somehow deactivate the TFTP install stuff? I configured everything with ATFTP and everytime i reinstall fog it cleans everything up
-
Update Reinstall done - unfortunately now i get an
Invalid MAC Address! E8:B1:FC:03:F7:CD|E8:B1:FC:03:F7:CE|54:EE:75:2D:AC:1F|E8:B1:FC:03:F7:D1||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0|94:87:B3:5B:56:5Aerror
With the correct MAC
http://xxx.xxx.xxx.xxx/fog/service/hostname.php?moduleid=hostnamechanger&mac=54:EE:75:2D:AC:1F&newService=1address i get
#!ihcand without newSerivce=1 i´ll get this
#!ok=HOSTNAME #AD= #ADDom= #ADOU= #ADUser= #ADPass= -
Please update again, it should fix the invalid mac issue you are seeing.
-
Okay this is doing fine for now, unfortunately when i boot up the system now it asks me for the TFTP Server IP, i think the config was overwritten in one reinstall attempt.
We ran a “own” version with atftpd and not tftpd-hpa, so i would say moving this
pxelinux.0 -> pxelinux.0.oldback to
pxelinux.0 -> undionly.kpxeshould help. I will test everything tomorrow and will get back to you.
-
@christianu said:
unfortunately when i boot up the system now it asks me for the TFTP Server IP
That’s interesting! We have changed the iPXE embedded script lately and this might have to do with it. Is your client normal BIOS or UEFI? And more importantly where is your DHCP server/do you use proxy DHCP???
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth said:
@christianu said:
unfortunately when i boot up the system now it asks me for the TFTP Server IP
That’s interesting! We have changed the iPXE embedded script lately and this might have to do with it. Is your client normal BIOS or UEFI? And more importantly where is your DHCP server/do you use proxy DHCP???
Good mornin!
currently its still BIOS i will try to switch this to UEFI asap. We have proxy DHCP, so the FOG server is not the DHCP.
Aunt Edit: I just tested and entered the TFTP IP and hey - it still works, so i there is some things up with the CHAIN load. Can you give me a hint where to look for the fix?
-
@christianu said:
I just tested and entered the TFTP IP and hey - it still works, so i there is some things up with the CHAIN load. Can you give me a hint where to look for the fix?
Unfortunately there is no quick fix to this. I am sorry but we haven’t tested the embedded script for long enough and it turns out that it has an issue with proxydhcp. This is not a really big problem. We can fix this pretty soon. Stay tuned.
Another point for your setup: I guess you are using dnsmasq, right?? If yes then you probably won’t be able to pxeboot UEFI devices. Depends on the device but I haven’t seen any UEFI PC boot properly with dnsmasq yet. I’ve been playing with those things a lot lately. See here: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q1/009296.html
@Tom-Elliott My idea on checking {proxydhcp/next-server} isn’t working if we use cached DHCP information in iPXE. It is working if iPXE itself requests the information but not if relying on the cached infos from earlier PXE ROM. I am wondering if we should just always do
dhcp!? See Michael Brown’s comment here: http://forum.ipxe.org/showthread.php?tid=6911&pid=9168#pid9168I would strongly recommend that you do not under any circumstances use cached DHCP settings from the OEM PXE stack’s DHCP request. Allow iPXE to make its own DHCP request, and it should request everything that might be relevant.
Should we still try using cached DHCP info or bite the bullet (not sure if this really is a tough bullet) and send a DHCP request from iPXE? I am not sure if this has other side effects. Please think about it for a little. As well @Wayne-Workman what do you think?
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
Yeah i found the actual problem, i dont know why we did this
option tftp-server-name "xxx.xxx.xxx.xxx"This renders your variable “next-server” more or less useless.
Fixed it and its running like a charme.
And i have a update to the other issue (with the client) aswell. After reinstalling everything the hostname changer is working too
So thank you very much for your support guys! If you have any questions please contact me
-
@Sebastian-Roth I’ve removed the cached checking areas as I believe you are correct. While it maintains the IP of the pxe-received information, it does not know anything about the next-server/filename settings particularly when it’s being re-chained via proxyDHCP.
