| 00:00.12 | JeremyC- | nah, it's basically instant |
| 00:00.23 | JeremyC- | keep in mind this is within one or more datacenters |
| 00:01.19 | JeremyC- | if anything DHCP is too slow to use with REST ;) |
| 00:01.55 | JeremyC- | DHCP has frustratingly long timeouts while it tries to collect multiple responses to choose the "best" one |
| 00:02.06 | Nirkus | mh, from what i know, DHCP is quite basic and fast to interpret and built |
| 00:02.30 | JeremyC- | yes, it's not "slow" per se |
| 00:02.52 | JeremyC- | but my DHCP server answers within ms, and it waits usually 2-3 seconds collecting responses in the "SELECTING" state |
| 00:03.08 | Nirkus | yah, ok |
| 00:03.26 | Nirkus | but thats the specification ;) |
| 00:03.31 | JeremyC- | yeah :) |
| 00:04.06 | JeremyC- | Really though, the whole DHCP/PXE interactions are the *quickest* part of the boot process on HP DL servers, man they are slow to boot. |
| 00:04.59 | JeremyC- | Very frustrating when you have a 1-line bug in a DHCP response or PXELINUX menu or something, and you have to wait another 2 minutes for the server to get back to that spot |
| 00:05.45 | Nirkus | hihi |
| 00:06.15 | JeremyC- | we're generating pxelinux.cfg responses dynamically using PHP and mod_rewrite |
| 00:06.44 | Nirkus | uahhh...PHP |
| 00:06.48 | JeremyC- | coming through gPXE you get HTTP and DNS, so it works really well |
| 00:07.43 | Nirkus | so gPXE is bootable on any PXE capable NIC using PXE to load it? |
| 00:07.47 | Nirkus | intesting.. |
| 00:07.48 | JeremyC- | yes |
| 00:07.54 | JeremyC- | it's frakking awesome. ;) |
| 00:08.02 | Nirkus | hehe |
| 00:08.23 | JeremyC- | I have a custom module for the DHCP server that chain loads PXE -> gPXE -> PXELINUX |
| 00:08.40 | Nirkus | i tried to write a PXE server of my own |
| 00:08.45 | JeremyC- | you can also do that with ISC DHCP |
| 00:08.54 | Nirkus | but i dont have any free time |
| 00:08.59 | Nirkus | that really sucks.. |
| 00:09.20 | JeremyC- | basically you just send tftp info for gpxe.0, in our case: |
| 00:09.27 | JeremyC- | config_plugin=gpxe_tftp_server=10.99.48.10 |
| 00:09.27 | JeremyC- | config_plugin=gpxe_tftp_filename=gpxe.0 |
| 00:09.49 | JeremyC- | and then when you get a request coming from gPXE, you send it pxelinux.0 info: |
| 00:10.02 | JeremyC- | config_plugin=pxelinux_url=http://boot.example.com/pxelinux/pxelinux.0 |
| 00:10.29 | Nirkus | http://sourceforge.net/projects/pxecspd/ |
| 00:11.07 | JeremyC- | pxelinux.0 gets downloaded over http and executed, and then by default it looks back at the same path for its pxelinux.cfg, so it hits the http server again |
| 00:11.54 | JeremyC- | yeah, well PXE is just an extension of DHCP, so any "PXE server" is just a custom DHCP server :) |
| 00:12.30 | Nirkus | not quite |
| 00:13.01 | JeremyC- | this model is really nice for testing/debugging, you can just go to http://boot.example.com/pxelinux/pxelinux.cfg/01-00-1c-c4-c1-f6-52 and see the pxelinux instructions for a particular MAC |
| 00:13.10 | Nirkus | the PXE Client Server Protocol just uses the same message format, but has its own options and possibilites |
| 00:15.22 | Nirkus | JeremyC-: mkay, so you use HTTP & REST to replace config loading via TFTP and make the configs db driven |
| 00:15.25 | Nirkus | not bad |
| 00:16.29 | JeremyC- | pretty much the idea is |
| 00:16.53 | JeremyC- | do everything humanly possible over HTTP, since we can use hardware load balancing and our standard tool chain to deal with it |
| 00:17.36 | JeremyC- | test things in the browser, use curl/wget for debugging, and scale it up if necessary using multiple load balanced servers |
| 00:18.22 | JeremyC- | and provide redundancy using the load balancer as well |
| 00:18.29 | Nirkus | simplifies things a lot, id guess |
| 00:19.11 | JeremyC- | yeah, i really really hate tftp and all the failure modes it has :) |
| 00:19.19 | Nirkus | hihi |
| 00:19.55 | JeremyC- | i've seen a few projects to use e.g. fuse to dynamically generate pxelinux.cfg files, and... oy ;) |
| 00:20.17 | Nirkus | still having dns and http accessible via modules within grub2 would help a bigger community IMHO :) |
| 00:20.31 | Nirkus | fuse? oO |
| 00:20.53 | JeremyC- | using apache with mod_rewrite we just intercept the pxelinux.cfg/xxx and pass it into the script of our choice (index.php?request=xxx) |
| 00:22.48 | JeremyC- | yeah it would be nice, but honestly the gPXE stuff is not bad at all |
| 00:23.06 | Nirkus | JeremyC-: and after that, try using some nice framework and language like ruby on rails or django and python to get a real REST based app, that takes GET requests for like /machines/$mac/pxelinux.cfg and builds them on the fly from your db |
| 00:23.10 | Nirkus | :) |
| 00:23.31 | JeremyC- | Nirkus: THat is happening right now already, but in PHP/CodeIgniter :) |
| 00:23.56 | JeremyC- | It hits /api/dhcp/machine_lookup/<mac> |
| 00:24.11 | Nirkus | but using mod_rewrite and a URL of some PHP script with GET variables is not really REST ;-) |
| 00:24.30 | Nirkus | so, youre emulating REST using mod_rewrite? :) |
| 00:25.19 | Nirkus | yeah, the solution using gPXE has a big advantage: it's already available and working ^^ |
| 00:25.40 | JeremyC- | REST has more to do with URL structure and responses than how you pass the URL into the code |
| 00:26.06 | JeremyC- | via either GET parameters or PATH_INFO |
| 00:28.09 | Nirkus | JeremyC-: sure, but IMHO using a framework that will let you write youre app reflecting exactly the structure of classes, objects and ressources you have is more elegant than adding another abstraction layer to make your code accessable in a clean structure |
| 00:28.31 | Nirkus | but in the end, everyone needs to find his own solution and make it work |
| 00:28.41 | JeremyC- | hehe yeah |
| 00:29.52 | Nirkus | right now im working on an account & identity management interface for my companies LDAP directory using django & python. |
| 00:30.30 | Nirkus | the interesting part will be replacing the relational database logic with some LDAP backend |
| 00:30.33 | Nirkus | ;) |
| 00:30.37 | JeremyC- | ca. how many employees? |
| 00:30.51 | Nirkus | just > 100 atm |
| 00:31.17 | JeremyC- | what will it interface with? internal tools? |
| 00:31.31 | Nirkus | the LDAP directory |
| 00:31.40 | Nirkus | ah |
| 00:31.45 | JeremyC- | Hehe, no I mean on the other end :) |
| 00:32.07 | Nirkus | the other hand of that interface will be interacting with humans via web browsers :> |
| 00:32.22 | JeremyC- | Ah, I think I misread it a bit. Web interface to manage LDAP basically, eh? |
| 00:32.31 | Nirkus | yah |
| 00:33.04 | JeremyC- | primarily windows or linux? |
| 00:33.55 | Nirkus | the LDAP will be serving all of our services and linux, the account & group stuff will be synced into active directory for windows machines |
| 00:36.40 | JeremyC- | ah nice |
| 00:37.02 | JeremyC- | we are still suffering at the hands of AD being the authoritative source for internal apps auth etc. |
| 00:37.28 | Nirkus | yeah, but the only way to interface UNIX with LDAP is using this obscure 'NIS data in LDAP' schema, still |
| 00:37.32 | JeremyC- | using mod_authnz_ldap to talk to AD |
| 00:37.41 | Nirkus | yah, AD sucks |
| 00:37.49 | Nirkus | at least, the LDAP part of AD |
| 00:38.40 | Nirkus | when you get to see, how exchange saves resources, groups and contacts in AD, youll get sick |
| 00:38.46 | Nirkus | everything is a user |
| 00:39.08 | Nirkus | because we just didnt get whar objectClasses are intended for |
| 00:39.09 | Nirkus | :) |
| 00:39.26 | JeremyC- | hehe |
| 00:40.04 | JeremyC- | I know pretty little about the Windows side of things, but I know our conference rooms are "users" with Exchange accounts set to auto-accept invites... and that makes me sick enough :) |
| 00:40.20 | Nirkus | using AD as master ressource must be a real pain in the ass |
| 00:40.37 | Nirkus | yap :) |
| 00:40.56 | JeremyC- | the "everything is a hammer" approach ;) |
| 00:41.56 | Nirkus | hihi |
| 00:42.20 | JeremyC- | btw, re. posting docs etc., I did redraw the DHCP RFC's client state transitions diagram already |
| 00:42.21 | JeremyC- | http://jcole.us/files/DHCP%20Client%20State%20Transitions.png |
| 00:42.27 | Nirkus | if we cant beat you to death using on of the users, well just take on of your ressources |
| 00:42.30 | Nirkus | :) |
| 00:42.36 | JeremyC- | the ASCII one makes my eyes bleed. |
| 00:44.13 | Nirkus | hehe |
| 00:44.33 | Nirkus | did you have a look at DHCPv6? im still not sure whether i want to see it.. |
| 00:44.34 | Nirkus | :) |
| 00:44.42 | JeremyC- | no, haven't yet |
| 00:45.38 | Nirkus | mh, okay |
| 00:46.10 | Nirkus | is still hoping for some solid protocol since DHCPv6 does not need to handy address allocation |
| 00:46.13 | Nirkus | :) |
| 00:47.12 | Nirkus | i still think using a UDP protocol to allocate IP addresses is a twisted idea |
| 00:47.58 | JeremyC- | it's not that bad really, it's mostly broadcasts |
| 00:49.23 | Nirkus | yeah, but looking at the different network layer APIs systems have to provide for applications, having UDP sockets w/o IP addresses and broadcasting around with them is pretty twisted |
| 00:49.50 | JeremyC- | hehe yeah, it could be better perhaps :) |
| 00:50.16 | Nirkus | they should have just defined some protocol on the same layer as IP and some encapsulation using $whateverProtocolYouWant for forarding DHCP traffic |
| 00:50.42 | JeremyC- | Would be a bit harder to implement and maintain the servers then though |
| 00:50.53 | Nirkus | why? |
| 00:51.13 | Nirkus | systems just would have to provide DHCP protocol sockets for clients and servers |
| 00:51.28 | JeremyC- | yet another layer3 protocol |
| 00:52.16 | Nirkus | with the current solution servers have to listen for broadcasts on usual UDP sockets and answer using some form of raw socket, because a UDP socket wont allow those twisted broadcast pseudo ip packets |
| 00:52.29 | JeremyC- | and, once the initial lease has been made, renewals etc. are currently unicast |
| 00:52.37 | Nirkus | so what... it's not like DHCP would be a complex protocol |
| 00:52.56 | Nirkus | yeah, still doesnt eliminate the crucial first step |
| 00:53.40 | JeremyC- | hmm not sure what you mean, replies are just normal UDP |
| 00:55.00 | JeremyC- | my $dhcp_client = sockaddr_in($config->get("client_port"), INADDR_BROADCAST); |
| 00:55.21 | Nirkus | the initial DHCPOFFER has to be IP broadcast, but ethernet unicast, doesnt it? |
| 00:55.33 | JeremyC- | nope |
| 00:55.44 | Nirkus | so just broadcast |
| 00:55.45 | JeremyC- | in fact it can't be unicast |
| 00:55.54 | Nirkus | it can be ethernet unicast |
| 00:55.56 | JeremyC- | IP/UDP broadcast, Ethernet broadcast |
| 00:56.18 | JeremyC- | because listening for other server's DHCPOFFERs is used in multi-DHCP-server setups |
| 00:56.18 | Nirkus | you have the ethernet address of the client, so it can be unicast |
| 00:56.41 | Nirkus | ah, mkay |
| 00:57.09 | Nirkus | maybe my memories of hacking for that PXE servers have me confuse something here |
| 01:00.01 | JeremyC- | Hmm, PXE is the same, it's just DHCP with some fields set (sname, file) to provide tftp info |
| 01:00.30 | Nirkus | ok, as long as the reply is both IP and ethernet broadcast, its at least manageable |
| 01:01.09 | Nirkus | no, PXE is a series of messages in DHCP format. what you are referring to is BOOTP which can be used with PXE boot ROMs, also |
| 01:02.04 | JeremyC- | yeah, all packets are broadcast except for 2 types: DHCPACK in reply to a DHCPREQUEST from a "RENEWING" client, and replies to any DHCP requests which were forwarded from a relay and have giaddr set |
| 01:02.06 | Nirkus | a PXE server will provide an additional DHCPOFFER to PXE capable NICs containing no DHCP configuration, but a set of PXE defined DHCP options |
| 01:02.26 | JeremyC- | yes, i suppose that's true |
| 01:02.53 | JeremyC- | there are a bunch of DHCP options that can be provided |
| 01:03.20 | Nirkus | you have the capability of having a boot menu displayed on the client and connect different PXE services depending on the users choice w/o using anyting more than the PXE ROM of your NIC |
| 01:03.59 | Nirkus | after that, you can download a series of files with your PXE boot loader using only PXE and TFTP |
| 01:04.13 | Nirkus | there is even some propritary multicasting stuff defined in the PXE spec |
| 01:06.39 | JeremyC- | i do wonder actually, given the existence of gPXE if any of the crazy PXE extensions are even interesting :) |
| 01:06.55 | Nirkus | i used that part of PXE to have different boot choices in the same pool, we set up our stateless linux desktops |
| 01:07.06 | JeremyC- | now that you said that, i looked back and i remember reading through this stuff and realizing i didn't need any of it :) |
| 01:07.29 | Nirkus | JeremyC-: the only problem with the PXE spec was the lack of working implementations |
| 01:08.12 | Nirkus | i had to use a patched ISC dhcpd and red hats discontinued pxe service back then and was very limited in using that facilities |
| 01:08.24 | Nirkus | therefore i started designing my own PXE server |
| 01:09.09 | Nirkus | but i moved to the LDAP stuff just around that time and got caught in development of identity and account management stuff |
| 01:09.20 | Nirkus | that was a lot more intersting xD |
| 01:09.23 | JeremyC- | i think you could quite easily handle all this stuff within my dhcp server code |
| 01:09.36 | JeremyC- | all you need is a reasonably robust way to deal with DHCP options |
| 01:09.58 | Nirkus | yap |
| 01:10.17 | Nirkus | and some additional client state and boot menu state handling |
| 01:11.20 | JeremyC- | but i'm still not sure it's that interesting :) |
| 01:11.44 | JeremyC- | gPXE -> PXELINUX gives you all the menuing good with DNS and HTTP support to go with it :) |
| 01:11.47 | Nirkus | the more interesting part of having a real and working PXE server around would be if all those NIC manufacturers would fix there PXE ROMs to correctly handle all that PXE stuff ^^ |
| 01:12.25 | Nirkus | JeremyC-: of course, gPXE is like having some multi-capable pxe boot loader |
| 01:12.54 | Nirkus | a few years back there was only etherboot to flashh on your NICs or plain pxelinux w/o any fancy http or menus |
| 01:12.54 | JeremyC- | and PXELINUX especially with vesamenu.c32 gives you 640x480 VGA menus :) |
| 01:14.51 | Nirkus | yeah, all of that seems to have changed |
| 01:15.53 | JeremyC- | even if there was a decent PXE server, hitting an HTTP URL would always be infinitely easier :) |
| 01:16.17 | Nirkus | hm |
| 01:17.18 | Nirkus | one could define some REST api and build a machting DNS/HTTP capable grub2 module for that |
| 01:17.37 | Nirkus | that way, there would be a ready-to-develope for api to configure PXE clients |
| 01:18.23 | Nirkus | whatever, back to LDAP :) |
| 14:38.10 | *** join/##pxe mqueiros (n=mqueiros@217.70.75.170) |
| 21:48.21 | *** join/##pxe Haraken (i=ryuk@unaffiliated/haraken) [NETSPLIT VICTIM] |
