Compatibility with ole PXE
-
I have central DHCP server in my organization which I do not manage. It is set up to work with the old PXE boot system in FOG, i.e. it asks for the file pxelinux.0.
Fog 1.0.0 uses iPXE and the file name is now named undionly.kpxe
In this forum I am told all I have to do is to rename undionly.kpxe to pxelinux.0. This works but I have to do this each time I upgrade FOG. Could there be a setting to turn on/off some dhcp-compatibility-mode?
Could be solved in the install script by checking if the file pxelinux.0 exists. If it exists installer could ask if user want to keep compatibility with old dhcp settings. if YES rename the file. Thoughts?
-
[quote=“pmonstad, post: 26761, member: 17422”]I have central DHCP server in my organization which I do not manage. It is set up to work with the old PXE boot system in FOG, i.e. it asks for the file pxelinux.0.
Fog 1.0.0 uses iPXE and the file name is now named undionly.kpxe
In this forum I am told all I have to do is to rename undionly.kpxe to pxelinux.0. This works but I have to do this each time I upgrade FOG. Could there be a setting to turn on/off some dhcp-compatibility-mode?
Could be solved in the install script by checking if the file pxelinux.0 exists. If it exists installer could ask if user want to keep compatibility with old dhcp settings. if YES rename the file. Thoughts?[/quote]
This is a personal setting, I do not see many benefiting from. You may not know this but FOG gains flak for it’s install script. At a certain point we need to stop accommodating every user and they need to learn some linux.
You could make a script that every time you upgrade fog it checks to see if your pxelinux.0 file exists and if not it will copy and rename it. I would recommend something else, please keep reading.
While I know this isn’t the answer you want to hear, You can simply symlink the file, or you can rename it. I recommend a symlink, you can do so like this:
[code]
sudo ln -s undionly.kpxe pxelinux.0[/code]Now if you check the folder you will find that both the files exist. This is particularly useful when you need to reference the same file in multiple folders but you don’t want to have to edit ALL of them!
-
Hi! I agree this is not a problem for those of us who understand Linux. I just thought this could be a good idea for all those less Linux experienced out there starting to upgrade from 0.32 to 1.0.0. If they dont run their own dhcp server the central dhcp server needs to be updated to reflect the new PXE filename, which is often a job for some external IT department. I also know that involving IT departments around in large organisations is a pain. The less we have to involve them the better is my experience.
If there was an option as suggested I think we could avoid some questions in the forum. I have not said this necessarily is a good idea, I just want to start a discussion about it
If no one else think this could be a good idea I can of cource live with my cp command in Linux. -
It’s nice to always leave a note of your findings. We will see if others feel it is necessary to include this as part of the installer script. It will depend on the amount of confusion with reading the installer script when it tells you to insert information into the dhcp server.
There’s also a service recommended for those that have trouble with inserting or editing the dhcp server, but it’s not part of the installer script. While I recommend it every chance I can when I think it will resolve the issues a particular user has, I feel that the forums are suffice enough to get information to those that needed it. 90% of the people coming to the forums have questions about FOG during installation or after, some prepare before but that is few and far between.
Only time will tell, but I am hoping that FOG is stirring a caliber of individual that will be able to solve their own linux woes instead of being hand fed scripts.
-
There is a reason we do not name the undionly.kpxe file pxelinux.0 and it is because they have nothing to do with each other.
If a user sees that the file is named pxelinux.0, then they can assume, or a quick google search will tell them, that it is based on pxelinux of the syslinux project. At that point, they will have a lot of information at their disposal on how it works and how to configure it’s boot menu. All of that information will be wrong for their actual situation.
Keeping the file named undionly.kpxe prevents that confusion and only requires a minor DHCP reconfiguration for people who already have their server set up with pxelinux.0. -
IF you were able to have the server configured for pxelinux.0 in what situation would a user not be able to get it updated to undionly.kpxe?? I don’t know of any organization that locks out their DHCP server, and if they did I doubt they would have the ability to use FOG as a PXE server to begin with.
There is always SOMEONE who can access and change the DHCP server, if not, you have bigger problems to worry about than the FOG install script.
-
[quote=“BPSTravis, post: 26772, member: 22444”]IF you were able to have the server configured for pxelinux.0 in what situation would a user not be able to get it updated to undionly.kpxe?? I don’t know of any organization that locks out their DHCP server, and if they did I doubt they would have the ability to use FOG as a PXE server to begin with.
There is always SOMEONE who can access and change the DHCP server, if not, you have bigger problems to worry about than the FOG install script.[/quote]
Organizations that have strict change management protocols make this difficult… In our case the actual FOG servers are managed by the local operations teams - so upgrading to 1.0 is easy, but any changes to server infrastructure including DHCP have to go through a drawn out change management process
-
So you don’t have any rights to login to the DHCP server? …opps someone left the door open or the old credit card tricks are no good? No way you can remote desktop in or ssh?
-
[quote=“pac1085, post: 27126, member: 144”]Organizations that have strict change management protocols make this difficult… In our case the actual FOG servers are managed by the local operations teams - so upgrading to 1.0 is easy, but any changes to server infrastructure including DHCP have to go through a drawn out change management process :([/quote]
There is a way to get around your problem, there is a service call DNSMASQ that allows you to proxy serve information while pxe booting so that machines can resolve to the tftpboot server and the file name. This service is recommended to anyone with an UNMODIFIABLE DHCP SERVER, please look here
[url]http://fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server[/url]This will allow your techs the ability to edit or change the dhcp boot information at a building level and they will be able to update methods in the future as everything will be local to the server, or able to be edited simply by remote desktop/vnc or ssh into the server to make changes. YOU could also be the one to make these changes for them remotely if you didn’t want to drop that in their laps.
-
As all the others state,
The filename doesn’t matter from a system perspective, but when it comes to tracking bugs or finding potential issues, searching on google deter’s to the “assumed” default of the files. Meaning, if we relabel undionly.kpxe during install to pxelinux.0, and you were having problems, people would likely search for pxelinux.0 which would not return the information you need properly. It would become extremely difficult to track down issues.
