hostname.php stays emtpy
-
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: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=
-
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.old
back to
pxelinux.0 -> undionly.kpxe
should 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???
-
@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?
-
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.