Inherited DNSMasq Issue
-
So I see the most recent topic is a similar issue to mine but I didn’t want to thread hijack.
So I inherited a FOG server from an old employee (never having imaged myself before)
The old setup was drastically changed when we received a network upgrade to new 10G switches, I began to build a new FOG server with RAIDED SSDs hoping to be able to image faster but in the transition the new network has its own DHCP whereas in the old setup there was a physical DHCP that I had control over. On the new FOG server I set a static IP and installed fog, I am able to tftp the undionly.kpxe file from the machine i’d like to image, but when actually trying to pxe boot it always fails.So my issue is the new network provides an existing value for option 66 and 67 and the networking engineers told me that I just just build my own DHCP (which I think is a waste, but I started doing anyways) because “they cant change those values”. I know they are full of it but I don’t have a permanent position yet(still a student worker).
Is it possible to overwrite the next-server and boot file options with DNSMasq I looked through Wikipedia PXE page and the UbuntuLTSP page but it does not specify if the PXE booting machine would use the ProxyDHCP’s offer or the real DHCP’s offer(with my experience it uses the ProxyDHCP but fails sometime after “configuring (mac add)”)I can provide a PCAP as well as screen shots later today if necessary but I think this one is pretty cut and dry.
Also I would like to be able to edit the Wiki if that’s possible (just to update the how to install on Ubuntu 12.04 (still has information from .34 version))
Thanks Guys!
-
Some have said that dnsmasq’s 066 and 067 offers override DHCP’s 66 and 67 offers - while others have reported that things changed and their setup no longer worked with dnsmasq.
I’d say just try it and see how it goes. There is a good example of how to configure it here: https://wiki.fogproject.org/wiki/index.php?title=Fedora_21_Server#dnsmasq_.28if_using_ProxyDHCP.29_setup
I know that’s from a Fedora article, but the configuration for dnsmasq is the same across distributions. -
Thanks for the response, I am here with the servers now and I’d like to figure out whats going on.
So I used that exact ltsp.conf and did what the instructions below said (cp undionly instead of symlinks) but I am getting the same error as I had with my old DNSMasq from : https://wiki.fogproject.org/wiki/index.php?title=Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#Setup_and_Configuration (the machine begins to pxe boot and then times out at “/default.ipxe… Connection timed out (http://ipxe.org/4c126035)”
followed by: “PXE-M0F: Exiting Intel Boot Agent”I am fairly certain that the fog server is configured properly but my old setup (that I have segregated from the network still working) it flys past /default.ipxe and connects to the server (exact same machine for both tests (both fog servers on 1.2) on the next line with its ip eg (http://10.72.40.48/fog/service/ipxe/boot.php… ok)
-
@500ghz there might be a symlink to something somewhere or another in your /tftpboot directory.
what is the output of
ls -lahRt /tftpboot
-
@Wayne-Workman I already removed all of the old symlinks but here it is anyways:
undionly.0 is a copy of unduonly.kkpxe and undionly.0.0 is a copy of undionly.kpxe -
Excuse my interruption, but I’m very lost. What’s going on?
DNSMasq was inherited?
What is the actual bootfile?
What’s the config look like? (ltsp.conf – can you post it here please?)
What’s the error?
Sorry to barge in, but it seems very convoluted to me right now.
-
@tom-elliott LOL the whole imaging server was inherited from an old employee that no longer works with us sorry for the confusion
On the old server the bootfile was undionly.kpxe (from our own win based DHCP)
on the new server I again used undionly.kpxe but the DHCP is cisco based run by the Networking department so I am attempting to use DNSMasq but their dhcp already has a next-server and bootfile paramaters for computers imaged by another dept.Here is the ltsp.conf:
The error I am getting is that the machine that is trying to be imaged hangs on /default.ipxe and then the connection times out.
-
@500ghz What’s in the /tftpboot/default.ipxe file? This shouldn’t cause the hang, but it is a bit strange.
Your boot-file= line should not have the .0 extension on it. Save yourself a few keystrokes, and confusion, just put undionly for both lines that need it:
Try this for the ltsp.conf file:
port=0 log-dhcp tftp-root=/tftpboot dhcp-boot=undionly,10.69.66.253 dhcp-option=17,/images #not really sure why this is needed dhcp-option=vendor:PXEClient,6,2b dhcp-no-override pxe-prompt="Press F8 for boot menu", 3 pxe-service=X86PC, "Boot from network", undionly pxe-service=X86PC, "Boot from local hard disk", 0 dhcp-range=10.69.66.253,proxy
If this is still giving issues after running
sudo service dnsmasq restart
, try commenting the port=0 (make it read as#port=0
) and restart the dnsmasq service again, does this help? -
@tom-elliott Tried both nothing changed here is my default.ipxe file (this is the output from a clean install of fog):
Here is a pcap from a win 7 machine on the same network that I used to view what bootfiles are getting pushed to the machine that is booting:
0_1455237685261_error1.pcapI dont know if that will help but I cant seem to find an issue with this setup.
Thanks
-
@500ghz said:
both fog servers on 1.2
I totally missed that information at first and started scratching my head when looking at the PCAP file - it seams pretty fine from my point of view. Client sends a DHCP discover and gets three answers. Your dnsmasq is answering the fastest (being on the same VLAN) and the answer looks alright to me. The answers from the Windows DHCP servers seam ok as well. So what’s wrong?
I guess that your clients don’t like the way we used to point to default.ipxe in FOG 1.2.0. The embedded iPXE script was pretty simple back then. Take a look!
This works on most machines but not all of them are happy. I think especially when DHCP and proxyDHCP come into play. The current iPXE binaries we have come with some checks and might work in your case. Move your current undionly.0 out of the way, download undionly.kpxe (or .kkpxe if .kpxe does not work) from here and name it undionly.0 again. Then boot up your client again. You’ll probably see “Duplicate option 66 (next server) from DHCP proxy and DHCP server…” but it should keep on booting after 5 seconds.
-
@Sebastian-Roth actually when I said both versions are 1.2 I meant that my old setup that is not on this network(and not connected at all, I connect to it to physically with an unmanaged switch to image right now) and the new server that is on 1.2 the other requests are coming from the dhcp and lead to an Altiris imaging server. I don’t think that matters but Ill try your solution and post real response tomorrow.
**Update ** this has been resolved using the new Undinoly.kpke from as instructed by Sebastian, Thanks you were 100% correct!
You can mark this as resolved if thats an option.
Thanks a bunch guys I just updated to trunk and am imaging my room right now.