-5

Recently I want to setup PXE boot server (i.e. DHCP server + TFTP server + syslinux software) for my company network in a LAN. I have read the setup details at here: http://www.linuxjournal.com/article/9963

However I don't have admin/access right to the existing DHCP server and I cannot change the settings. (you need to put the PXE server IP address in the DHCP server configuration file to make the PXE booting works).

I want to do the PXE boot in a good intention (make the new OS installation easier). Can I setup my own DHCP server (not 'legal' DHCP server) and use it with my PXE server to do the PXE boot? Is it possible?

If I cannot setup my own DHCP server, what is the working round for this problem? I really want the PXE boot to easy my batch installation process. thanks.

3
  • I do not understand why this question was down voted... May 1, 2012 at 16:46
  • 3
    @MirceaVutcovici, because he is asking how to do something that will likely seriously cause problems on the network he is connected to.
    – Zoredache
    May 1, 2012 at 16:59
  • From FAQ: ServerFault is not for questions about "...circumvention of security or policy"
    – user62491
    May 1, 2012 at 17:38

8 Answers 8

0

What you need is exactly what has been asked and described here: Howto setup Cobbler with PXE if you can't change the dhcp server?

There you see that it is very well possible to setup a ProxyDHCP server in a corporate environment. This essentially ONLY serves the PXE boot information and NOT the IP/subnet/gateway/etc information.

And just for the record, when done right this isn't a DHCP server.

2
  • I will verify your solution by giving it a try and thank you very much!
    – Xianlin
    May 6, 2012 at 16:21
  • I ran into some difficulties when trying to build the cobbler source code, could you please show me know how to compile the latest source code? You can put your answer here at stackoverflow.com/questions/10530011/… thank you!
    – Xianlin
    May 10, 2012 at 8:20
6

While you can set up a second DHCP server on a network, there is no reliable way to get a computer to prefer its responses.

More importantly, though, you should not be trying to circumvent your company's policy. This is unprofessional. If you need access to the DHCP server, make a case for it to your manager.

1
  • I learned a 2nd or rouge DHCP server may not work on the network with an existing DHCP server.
    – Xianlin
    May 3, 2012 at 5:54
4

You shouldn't be creating your own DHCP service at all without the permission of the network and system administrators, in fact doing so without their permission should be a firing offence. It's exactly this kind of behaviour which underlines why DHCP in anything but a client-only environment is dangerous.

So to reiterate - don't do this, it's wrong.

2

I did this kind of setup using an internal VM network.Internal VSwitch used for a DHCP/PXE

In this way you can test you configuration without disrupting the company network. Make sure that the DHCP server is listening only on the interface connected to the internal VSwitch.

VM1 runs the PXE stack (DHCP, TFTP...). In this configuration you can use this VM as a router to give access for VM2 to your company's network. VM2 is the VM that will boot from network.

If you want to be save use only the internal VSwitch and do not connect VM1 to the physical LAN.

5
  • This is the answer I accepted because setting up a rouge DHCP is NOT allowed but I need an alternative way to install OS to a bunch of computers on the network. Given the fact that I have the authority to disconnect/reconnect those computer's network connections so using my own switch (mobile small size switch + laptop running DHCP,TFTP server VMs maybe) to separate the network is a work around.
    – Xianlin
    May 3, 2012 at 5:53
  • Make sure that your switch in the same layer 2 network as the LAN of the company. May 3, 2012 at 15:14
  • Can you elaborate what do you mean? how to make sure my switch is in the same layer 2 network? thanks
    – Xianlin
    May 4, 2012 at 9:17
  • You just add a computer in the internal switch, then use a network sniffer and see if you see broadcasts from IPs that should be only in the company LAN. May 4, 2012 at 13:43
  • Another way is to connect to your internal VSwitch a computer that is using DHCP to configure the IP stack and let it get it IP configuration. Make sure your DHCP server is not started yet. If you get an IP and if the IP is frmo the company DHCP server, then they are in the same layer 2 network and you have to disconnect the internal VSwitch from the company LAN. May 4, 2012 at 13:45
1

There is a legitimate way to do this that does not involve touching your existing DHCP server configuration. In fact, you don't even need DHCP.

Though it may seem less than ideal - vs simply hitting F8/F12/etc. on boot and getting to a menu system directly over the network - you can use a very small (<1MB) iPXE ISO CD image to boot using any existing DHCP server. If you're booting VMs that are using DHCP - e.g., VirtualBox, VMware Workstation, VMware ESXi, etc. - it's even easier as you can simply mount the iPXE ISO and change your boot order to boot off the ISO.

Steps are as follows:

  1. From a Linux box with gcc and git installed, grab the iPXE source code:

    git clone git://git.ipxe.org/ipxe.git

  2. Create an embedded iPXE script that points to say your existing pxelinux.0:

Here is an example script:

#!ipxe
dhcp || goto enterip
goto bootit

:enterip
echo -n IP address: && read net0/ip
echo -n Subnet mask: && read net0/netmask
echo -n Gateway: && read net0/gateway
echo -n DNS server: && read net0/dns
goto bootit

:bootit
chain http://servernameoripaddress/pxelinux.0 

I believe a "chain tftp://" URI will also work if the server you already have pxelinux.0 on does not have a web server on it. You may want to consider using http as it's generally much faster than tftp. Just cp -R * whatever is in your current tftpboot folder into the DocumentRoot for your web server and you should be good to go using http for network bootstrapping via iPXE instead of tftp.

Save this script file off somewhere then build the iPXE ISO with the embedded script you just created:

cd ~/ipxe/src
make clean
make bin/ipxe.iso EMBEDDED_IMAGE=yourscript.ipxe
  1. Now boot off the ISO file - via VM with the ipxe.iso file mounted or write it to a blank CD and boot off the physical box with that CD.

This works a treat. There's so much power in iPXE I've been developing a service around it. Much of the scripting and build information represents hard-won information around this development process so hopefully it serves you well. You can look at netboot.me or the former boot.kernel.org (defunct now I believe since kernel.org was hacked a while back) to get a taste for how this might work over the Internet or your local network for that matter.

If you can get the admin of your DHCP server to eventually configure it to support network bootstrapping (PXE booting - DHCP options 66 and 67) then the same iPXE build process can generate a bootstrap file that will obviate the need for pxelinux.0. This looks like:

make bin/undionly.kpxe EMBEDDED_IMAGE=yourscript.ipxe 
cp ~/ipxe/src/bin/undionly.kpxe /webserverdocumentroot/ipxe.0

You can then bootstrap directly to this iPXE file over the normal PXE boot process - again, assuming your DHCP admin has finally enabled netbooting - and it will allow you to do all sorts of nifty network boot things on your network, no ISO file required.

Don't hesitate to let me know if you have questions.

2
  • ISO file booting is a great alternative and your explanation is very detailed. Thank you!
    – Xianlin
    May 6, 2012 at 16:16
  • your solution seems help me with the problem but I would like to try the "cobbler" server + company DHCP server method as another reply suggested. I Will let you know the outcome after giving it a try. If it didn't work, I will use your method. Thank you.
    – Xianlin
    May 6, 2012 at 16:25
0

Totally agree with the other guys, setting up your own DHCP server is almost always a bad idea.

Saying that, why do you want to do it? If it's for repeatable installs of software (and not diskless clients), you could setup a bootcd (or one for each server) and simulate the DHCP/tftpboot phase.

For example, we deploy Red Hat all over the enterprise and have a standard kickstart script which is run to configure new machines. When we're deploying somewhere remote from one of our DHCP servers, we boot from CD and tell anaconda to pull the appropriate kickstart and packages from a http server.

Of course this is no use if you're looking at a thin client solution.

0
0

I would not recommend setting up a 'rouge' DHCP server... even if we all here couldn't list all the things that could go wrong with this.

But, there are two (probably even more) possible workarounds:

1.) Make a portable pc/laptop, disconnected from the company network, with the boot images, dhcp server, and everything needed. When you need to do an OS install, physically disconnect the PC from the companies network, connect it to your 'instal box', do the install, and then reconnect the PC back to the companies network. This setup can be easily done even with an older laptop, and is portable, and reasonably safe (just don't connect the interface with the dhcpcd running to the internal network).

2.) Contact your network admins, and set up a special VLAN for OS installs, and then run your setup there. When you need to install an OS (probably not too often), contact them, to switch the desired port to your VLAN and run the install. After the install, just tell them to put the port back to the correct VLAN.

Running multiple DHCP servers where they don't all know about eachoter is not a thing I'd ever want to debug :D

1
  • yes, indeed another very good walk-around...thanks.
    – Xianlin
    May 6, 2012 at 16:01
0

You could set up a router with it's WAN interface plugged into your company lan, then operate a different subnet under your control so you can control DHCP for your machines without affecting the rest of the company's LAN while still accessing the company's resources.

However I would not suggest to do this unless you can obtain permission from the relevant persons as this will likely be a breach of some form of policy or contract that could land you in trouble.

0

Not the answer you're looking for? Browse other questions tagged .