Get iPXE to get results from web page

[sdlewis]

Hi

Does anyone know if there is anyway in which you can get iPXE to connect to a web page. I wanted to pass ${uuid} as a parameter to a web page as a SOAP call, that would in turn look up the GUID in Active Directory and return a true or false as to it's existence. True the ipxe routine would continue loading ipxe menus, if not it would continue to boot startrom.com and a WDS oschooser.

If ipxe does not do this, is there a way we can write one and where would we place the routine?

Thanks

Simon

[MultimediaMan]

Nothing using SOAP, but you can use PHP script to do the same thing.

[sdlewis]

Thanks for the reply. I assume I'll have to use chain to the php and process the return values with || and &&? Or am I way off the mark here. Guess I best go and learn php.

[MultimediaMan]

(2013-09-18 09:12)sdlewis Wrote:  Thanks for the reply. I assume I'll have to use chain to the php and process the return values with || and &&? Or am I way off the mark here. Guess I best go and learn php.

Basically yes, but you can also return an answer script (*.ipxe file)... remember that a PHP script, with appropriate service permissions, can do quite a lot.

iPXE by itself is pretty neat.

iPXE with PHP is darn near magic.

[sebastian]

One thing you can do, is to have your PHP script Query the lease table of the DHCP server and use that information to decide which iPXE script you want to boot. Then every computer boot the same iPXE script (http://server.com/boot.ipxe) - that is then linked to like (http://server.com/cgi-bin/ipxe.php), this script queries the lease table of the IP who did the request ($_SERVER['REMOTE_ADDR']), lookup MAC in ActiveDirectory, and then return a suitable iPXE script tailored for just that computer.

This means its also easy to implement access Control, so the web server can deny access to boot images that the computer in question are not allowed to boot according to iPXE script, preventing bypass of your system.

Such system would in fact pretty easy. Just use a suitable HTTP client module in PHP to automate requests to your router or switch web interface, to download the lease table.
If you have some sort of Telnet/SSH access, it would propably be easier to 'cat' the lease file directly from dhcpd run folder and parse that (using some Telnet/SSH library).
if security of the router/switch is Paramount even if "boot" web server is completely owned, you could set up a account in your router or switch that only have read-only access to the lease file and nothing else.
To avoid a Heavy load, you could cache records from the lease file into a local cache using their lease time as TTL.

[MultimediaMan]

(2013-09-19 03:47)sebastian Wrote:  One thing you can do, is to have your PHP script Query the lease table of the DHCP server and use that information to decide which iPXE script you want to boot. Then every computer boot the same iPXE script (http://server.com/boot.ipxe) - that is then linked to like (http://server.com/cgi-bin/ipxe.php), this script queries the lease table of the IP who did the request ($_SERVER['REMOTE_ADDR']), lookup MAC in ActiveDirectory, and then return a suitable iPXE script tailored for just that computer.

This means its also easy to implement access Control, so the web server can deny access to boot images that the computer in question are not allowed to boot according to iPXE script, preventing bypass of your system.

Such system would in fact pretty easy. Just use a suitable HTTP client module in PHP to automate requests to your router or switch web interface, to download the lease table.
If you have some sort of Telnet/SSH access, it would propably be easier to 'cat' the lease file directly from dhcpd run folder and parse that (using some Telnet/SSH library).
if security of the router/switch is Paramount even if "boot" web server is completely owned, you could set up a account in your router or switch that only have read-only access to the lease file and nothing else.
To avoid a Heavy load, you could cache records from the lease file into a local cache using their lease time as TTL.

These are some good thoughts. But let's take them apart to see if they can be made better or more logical. I see some problems with some of this things, but there are too many good ideas and use cases to quash this out of hand.

Quote:One thing you can do, is to have your PHP script Query the lease table of the DHCP server and use that information to decide which iPXE script you want to boot.

Why would you want to create a PHP script to do this when the iPXE client itself is perfectly capable of doing this? An iPXE Client can supply it's own MAC address as part of the embedded script "echo ${net0/mac:hexhyp}"

Quote:Then every computer boot the same iPXE script (http://server.com/boot.ipxe) - that is then linked to like (http://server.com/cgi-bin/ipxe.php), this script queries the lease table of the IP who did the request ($_SERVER['REMOTE_ADDR']), lookup MAC in ActiveDirectory, and then return a suitable iPXE script tailored for just that computer.

You can do this, but it seems to me it would be easier to write a generic script that does most of the latter and all of the former quotes above with a lot less trouble into a client-side embedded script. I'll expand on this reasoning later in my post. Remember that PHP can parse databases, and PHP and MySQL can be setup with an account to allow LDAP lookups and lookups from other data sources. But PHP, for all of it's features, it still a server side script, and you should push off to the clients whatever you can to lower overhead.

Quote:This means its also easy to implement access Control, so the web server can deny access to boot images that the computer in question are not allowed to boot according to iPXE script, preventing bypass of your system.

Now you're thinking good. The beauty of PHP is the ability of the engine to use what amounts to perl scripts, and from there, hook into a database: like LDAP, for instance. iPXE is a great way to leverage this.

Example: If you built an embedded script into iPXE binary which focused on client uniqueness (UUID, ASSET and SERIAL, etc..) and presented them to the PHP engine you could do the following:

Use Case 1: Enrollment of a unknown system (auto-discovery): A system boots into iPXE and present it's system characteristics to the PHP engine. The PHP engine could then lookup all of those variables and log both the query and the results for them, and entered into a ticketing system; the client could be put in a boot loop, or simply exit out of iPXE until the ticket was resolved (Approve, Deny, Destroy).

Use Case 2: Pre-Enrollment. You have a new shipment of machines. You scan or enter in the UUIDs, serial numbers or asset tags of the news systems into the database. Upon a match of these values, the PHP would point iPXE to the correct boot scripts (or generate them dynamically) for the client system in question on demand.

Use Case 3: Agentless client problem detection. A known client system is stuck in a boot loop. The PHP notices this client system requesting iPXE files repetitively and creates a ticket in the ticketing system, alerting support staff.

The neat thing is, the embedded boot script is the same in all cases. PHP is only used where needed (queries, lookups and logging), and the DHCP server requires no customization past an ordinary PXE configuration.

I would counsel against using DHCP reservations or classes of any kind for specific clients: it doesn't scale very well, and with the coming IPv6 world, it's almost irrelevant. Managing a few reservations in a single subnet, is no big deal. But when you need to scale out, managing reservations rapidly becomes a problem... especially if your guests can migrate between subnets or DHCP servers.

By the same token, I would think about relying heavily on DNS and Dynamic DNS (DHCP Server updates, not client updates) systems when writing both Embedded and Server-side scripts.

[sdlewis]

Hi

Thanks for your replies, I managed to get my menus to chain to IIS and an asp page that allows me to look up th existence of the UUID and return true or false. Might go one stage further as you have suggested and create dynamic menus.