hostname.php stays emtpy

[christianu]

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.

http://xxx.xxx.xxx.xxx/fog/service/hostname.php?moduleid=hostnamechanger&mac=macaddresses&newService=1

If i am not mistaken it should show the Hostname + additional Information.

Everything else runs smoothly like a kitten.

[Tom Elliott]

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 abef:12:34:56) it should show up as “invalid mac address” though I could be wrong.

[christianu]

The question is: The service tells me “Communication error” and would not change the Hostname, the Page stays empty with correct data, so why?

[Tom Elliott]

@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.

[christianu]

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.

[Tom Elliott]

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

[christianu]

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```

[Tom Elliott]

@christianu said:

/client/

Can you re-update and reinstall?

The setAD method that that is referring to does not exist any more.

[christianu]

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

[christianu]

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:5A

error

With the correct MAC

http://xxx.xxx.xxx.xxx/fog/service/hostname.php?moduleid=hostnamechanger&mac=54:EE:75:2D:AC:1F&newService=1

address i get

#!ihc

and without newSerivce=1 i´ll get this

#!ok=HOSTNAME
#AD=
#ADDom=
#ADOU=
#ADUser=
#ADPass=

[Tom Elliott]

Please update again, it should fix the invalid mac issue you are seeing.

[christianu]

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.old

back to

pxelinux.0 -> undionly.kpxe

should help. I will test everything tomorrow and will get back to you.

[Sebastian Roth]

@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???

[christianu]

@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?

[Sebastian Roth]

@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#pid9168

I 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?

[christianu]

@Sebastian-Roth

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

[Tom Elliott]

@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.