[Beowulf] Re: OT: PXE boot with no control over DHCP?

[Robert G. Brown]

Brian R Smith writes:

> What does your dhcpd.conf file look like and what does your campus
> network look like e.g. subnet and address range?  Feel free to obfuscate
> any info you don't really want publicized.  
> 
> Also, what type of firewall rules did you use to punch your hole?  I
> found that I actually had to shut off iptables for the 5 minutes it took
> the nodes to PXE install.

One wonders if something like ssh port forwarding might help.  With it
you might well be able to drill a hole through the campus intermediary
layers that they cannot intercept or interfere with.  I have never used
it for pxe or dhcp (and somebody at Duke did work to solve exactly this
problem in their own domain -- how to manage pxe installs and so on
without proper control over dhcp -- without notable success that I
recall) but I have used ssh port forwarding to circumvent all sorts of
uncontrolled intermediary layers with nothing but a firewall hole for
port 22.  To install duke-only software from home without using a vpn or
proxy connection, for example -- I just tunnel rsync on through.

If dhcp and pxe are tcp/udp level broadcasts, then I think that Brian is
right -- a faster local server should win, and once you've one you
SHOULD be able to tunnel the associated traffic through anything in
between at some cost in efficiency via ssl tunnels or ssh tunnels (for
example).

A final possibility is to create a very simple local install agent that
manages the initial install on the workstations, which then finish off
via yum from your central repo.  Something like warewulf, for example --
boot in the LAN into a warewulf image that then runs a yum chroot
install from your repo.  A bit ugly and definitely would require work,
though, but is SHOULD work.

   rgb

> 
> -Brian
> 
> On Wed, 2005-09-21 at 15:11 -0700, David Mathog wrote:
>> 
>> > 1) Set up your own dhcp server and make sure you have all the mac
>> > addresses for your hosts so that your server only offers addresses to
>> > your clients and no one else.
>> 
>> Did that.  Also punched holes in the firewall for dhcp and tftp.
>> 
>> > 
>> > 2) Make sure these hosts are on the same router or switch as your dhcp
>> > server so your server manages to offer an address first, before the
>> > campus dhcp that you don't manage.
>> 
>> Here's where things go south.  I don't see any evidence
>> of the dhcp packets from the booting workstation reaching
>> the server.  Even with the firewall turned off nothing
>> shows up in the log files and the workstation client times out.
>> I also tried booting knoppix on the machine, because
>> it uses dhcp to find it's IP address, but the one it came up
>> with was from the campus DHCP server and not my DHCP server.
>> 
>> Perhaps I have something wrong in the dhcpd.conf. Other than
>> a typo this is fairly unlikely, it was modified from the working
>> version that runs on the private subnet. Moreover the config
>> eliminated the "Ignoring requests on eth0" message starting dhcp
>> used to elicit, so the dhcpd does seem to have been ready to
>> handle a request, if it ever saw one.  It seems that the
>> campus network may really by blocking at the switch dhcp
>> requests from reaching any but their servers. 
>> 
>> The workstations in question have an MBA which offers
>> 4 network boot options: PXE, tcp/ip, netware, and RPL.  
>> PXE seems to be out and I'd rather not start a netware
>> transport on the main server just for  this purpose (assuming
>> it's even possible.)  That leaves tcp/ip
>> (presumably bootp?) and RPL (which I've never even heard of
>> before).  Any thoughts on getting one of those two to work with DHCP
>> blocked?  
>> 
>> Thanks,
>> 
>> David Mathog
>> mathog at caltech.edu
>> Manager, Sequence Analysis Facility, Biology Division, Caltech
> -- 
> Brian R. Smith
> HPC Systems Administrator
> Research Computing Core Facility, USF
> Phone: 1(813)974-1467   Cell: 1(813)230-3441
> Address: 4202 E Fowler Ave LIB 608
>          Tampa, FL 33620
> Web: http://rccf.acomp.usf.edu
> 
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20050922/cc785146/attachment.sig>