Doing PXE without control over the DHCP server

[Niels Basjes]

Hi,

A long time ago I asked and later documented on Stack Overflow how to do
PXE if you do not have control over the central DHCP server.
http://serverfault.com/questions/53116/howto-setup-cobbler-with-pxe-if-yo...

A few months ago I got an email from someone stating he couldn't get the
above to work.  He also stated

    I sent an email about this issue to the cobbler mailing list and even
    Michael Dehaan, the cobbler creator, did not know about this
    possibility, so I think your input would be useful to many people.

So that is the purpose of this mail; It may be useful to you guys.

Turns out that I had done some fixing and changing of my own cobbler (long
time ago) that I had forgotten about.
So a few days ago I provided the crucial fix to the mainline
cobbler<https://github.com/cobbler/cobbler/pull/157> which
has now become part of the trunk.
https://github.com/cobbler/cobbler/pull/157
I also created some additional supporting
documentation<http://howto.basjes.nl/linux/doing-pxe-without-dhcp-control>
to
explain in broad terms how to use this.
http://howto.basjes.nl/linux/doing-pxe-without-dhcp-control

The mentioned fix also has another usecase which I have deployed several
times.
I can now define a MAC address, IP address, hostname combination in cobbler
and instruct it to install CentOS with a kickstart file that also installs
puppet.
Because with this fix the client gets a fixed hostname I can use puppet to
cleanly define what software needs to be installed.

In addition I can choose to omit the IP address and has a situation where
the client gets a fixed hostname in an environment where I leave the IP
addresses dynamic.
This last usecase is something I see as a viable scenario for deploying
roaming Linux desktops/laptops and maintaining control over the installed
software using a tool like puppet.

-- 
Met vriendelijke groeten,

Niels Basjes

[Dick Davies]

I might be misreading the links.

Our main DHCP server knows nothing about Cobbler, and we don't run
a dhcpd on the Cobbler host.
we use Cobbler to server the /pxelinux.0 (and associated gubbins) and the
rest of the kickstart stack
and just set next-server in the main DHCP server config
(which we don't control) to point at the Cobbler TFTP host.

That works fine; am I misunderstanding your setup (I'm still stocking up
on coffee)?

On 30 April 2012 09:27, Niels Basjes <cobbler(a)basjes.nl&gt; wrote:
>  Hi,
>
>  A long time ago I asked and later documented on Stack Overflow how to do PXE
>  if you do not have control over the central DHCP server.
>
> http://serverfault.com/questions/53116/howto-setup-cobbler-with-pxe-if-yo...
>
>  A few months ago I got an email from someone stating he couldn't get the
>  above to work.  He also stated
>
>      I sent an email about this issue to the cobbler mailing list and even
>      Michael Dehaan, the cobbler creator, did not know about this
>      possibility, so I think your input would be useful to many people.
>
>  So that is the purpose of this mail; It may be useful to you guys.
>
>  Turns out that I had done some fixing and changing of my own cobbler (long
>  time ago) that I had forgotten about.
>  So a few days ago I provided the crucial fix to the mainline cobbler which
>  has now become part of the trunk.
>  https://github.com/cobbler/cobbler/pull/157
>  I also created some additional supporting documentation to explain in broad
>  terms how to use this.
>  http://howto.basjes.nl/linux/doing-pxe-without-dhcp-control
>
>  The mentioned fix also has another usecase which I have deployed several
>  times.
>  I can now define a MAC address, IP address, hostname combination in cobbler
>  and instruct it to install CentOS with a kickstart file that also installs
>  puppet.
>  Because with this fix the client gets a fixed hostname I can use puppet to
>  cleanly define what software needs to be installed.
>
>  In addition I can choose to omit the IP address and has a situation where
>  the client gets a fixed hostname in an environment where I leave the IP
>  addresses dynamic.
>  This last usecase is something I see as a viable scenario for deploying
>  roaming Linux desktops/laptops and maintaining control over the installed
>  software using a tool like puppet.
>
>  --
>  Met vriendelijke groeten,
>
>  Niels Basjes
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>

[Alain Cochard]

Dick Davies writes:

>  and just set next-server in the main DHCP server config
>  (which we don't control)  
How do you do that if you have no access to that DHCP server?

>  to point at the Cobbler TFTP host. 
-- 
EOST (École et Observatoire des Sciences de la Terre) 
IPG (Institut de Physique du Globe) | alain.cochard(a)unistra.fr
5 rue René Descartes   [bureau 106] | Phone: [phone] 
F-67084 Strasbourg Cedex, France    | Fax:   [phone]

[Dick Davies]

Put in a ticket? :)

Yes it's a change but it only needs to happen once (per subnet/VLAN depending
on the DHCP implementation) - no need to populate it after that when making
changes on the Cobbler side of things.

On 30 April 2012 10:55,  <alain(a)geophysik.uni-muenchen.de&gt; wrote:
>  Dick Davies writes:
>
>   > and just set next-server in the main DHCP server config
>   > (which we don't control)
>
>  How do you do that if you have no access to that DHCP server?
>
>   > to point at the Cobbler TFTP host.
>
>  --
>  EOST (École et Observatoire des Sciences de la Terre)
>  IPG (Institut de Physique du Globe) | alain.cochard(a)unistra.fr
>  5 rue René Descartes   [bureau 106] | Phone: [phone]
>  F-67084 Strasbourg Cedex, France    | Fax:   [phone]
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler

[Niels Basjes]

On Mon, Apr 30, 2012 at 12:39, Dick Davies <rasputnik(a)hellooperator.net&gt;wrote:

>  Put in a ticket? :)
>  
Back then I tried putting in a ticket ... the rest is history :)


>  Yes it's a change but it only needs to happen once (per
> subnet/VLAN
>  depending
>  on the DHCP implementation) - no need to populate it after that when making
>  changes on the Cobbler side of things.
>  
Almost right.
In some cases I want to deploy Windows or memtest ... which requires
loading a different boot file.

-- 
Met vriendelijke groeten,

Niels Basjes

[Alain Cochard]

Dick Davies writes:

>  Put in a ticket? :) 
Incidentally, if you could tell me what "put in a ticket" means, I
could then laugh together with Niels and you :-)
-- 
EOST (École et Observatoire des Sciences de la Terre) 
IPG (Institut de Physique du Globe) | alain.cochard(a)unistra.fr
5 rue René Descartes   [bureau 106] | Phone: [phone] 
F-67084 Strasbourg Cedex, France    | Fax:   [phone]

[Niels Basjes]

Hi,

On Mon, Apr 30, 2012 at 16:25, <alain(a)geophysik.uni-muenchen.de&gt; wrote:

>  Dick Davies writes:
>
>   > Put in a ticket? :)
>
>  Incidentally, if you could tell me what "put in a ticket" means, I
>  could then laugh together with Niels and you :-)
>  
It's the generic way of putting in a "request for change" into a ticketing
system (=change request tracking).

-- 
Met vriendelijke groeten,

Niels Basjes

[Niels Basjes]

Hi,

On Mon, Apr 30, 2012 at 11:45, Dick Davies <rasputnik(a)hellooperator.net&gt;wrote:

>  I might be misreading the links.
>
>  Our main DHCP server knows nothing about Cobbler, and we don't run
>  a dhcpd on the Cobbler host.
>  we use Cobbler to server the /pxelinux.0 (and associated gubbins) and the
>  rest of the kickstart stack
>  and just set next-server in the main DHCP server config
>  (which we don't control) to point at the Cobbler TFTP host.
>
>  That works fine; am I misunderstanding your setup (I'm still stocking up
>  on coffee)?
>  
Apparently you got to set the next-server setting in the DHCP server. So
you had enough control to do it that way.

I faced the situation where there was no option of adding any settings at
all to the DHCP reply. So I was "forced" to find a solution. (and this is
it)

I found that there are two common reasons this may happen:
1) The central sysadmin is not willing, capable, able or allowed to make
the change.
2) The currently deployed DHCP server does not have the option to set the
required options. I see this a lot with ISP provided home routers.

Does this clarify it for you?
-- 
Met vriendelijke groeten,

Niels Basjes