hilbix / bootp Goto Github PK

It would be nice to have some autoconfiguration possible,
which uses the files stored in cache/*.ip.

However this should only trigger if something really was changed.

To need polling is not very nice and also to trigger when nothing updated is bad, too.

This trigger should be a script.

Why?

This way special needs for a VM can be expressed most easily.
If you change the config, just edit the snapshot.
DHCP then does the rest.

If there is no DHCP then the update must be triggered manually, though.

bootp must be run as root, of course, to be able to listen to the privileged ports.

However it should be able to run ./request.sh in an unprivileged manner.

Currently configuration must be on the snapshot.

However snapshots perhaps can have a performance penalty due to COW. Hence VMs without snapshots shall be supported, too. Config goes into the VM comment then (again, as it was at the very beginning).

request.sh now has walksnaps which is used by request/virsh.sh

simplify request/proxmox.sh with it as well.

bootp forks ./request.sh which runs request/proxmox.sh to fetch the DHCP-information out of the nearest parental Snapshot comment. However this takes time.

DHCP retries, but there seems to be a gap where the packet is not received.

At my side it is very likely that the timing is bad when the data is not found in the first (youngest) snapshot, as traversing the snapshot tree apparently takes too much time.

---

Solution: We need to do a bit of caching here.

• When the first request arrives, run ./request.sh. This then prepares the response packet. Send it out.
• In the meanwhile the first request times out on the client side and a retry happens.
• When the second (or third) retry times out another request is received. (Usually) This is identical to the first request.
• Now pull out the cached response and send that out. So the answer is given immediately.
• Afterwards the cache entry is invalidated to allow the next request to pull - perhaps - changed parameters.

However this is not enough. Because it may be that 2 systems are booted in parallel.

Such a single cache is easy to implement. We even can put N round-robin caches here (which then must be associated with N requests),
but regardless how many we give here, these might not be enough when running under high pressure.

Hence a second "timed cache" comes into play on ./request.sh level:

• ./request.sh caches output and returned parameters of request/*.sh for the MAC
• If called for a MAC which has cached information which is younger than, say, 1 minute, then the cached parameters are reused
• Then the cache information is removed.

---

The second cache alone already should fix our problem. So perhaps the first cache within bootp can be left away.

However being able to answer a retried request while ./request.sh is busy with something else might be worthwhile as well.

This means, bootp and the fork of ./request.sh can be decoupled as well.
(Currently bootp waits for ./request.sh to return until it accepts new packets.)

For some reason preseeding does not work with virsh based VMs at my side.

Perhaps it is a configuration error or something is interfering here.

This is a reminder for the need to investigate deeper.

It would be nice to be able to do PXE/TFTP.

It also should be easy, such that it can be done directly from the ISO,
without the need to unpack anything.

This way the VMs can be provisioned completely without manual steps.

• Create a VM
• Create Snapshot
• Enter configuration
  • Domainname usually needs configuration (if not part of the VM's name)
  • IP can be deducted from the VM's ID
  • Hostname can be taken from VM's name
• Start VM

It should be compatible to ProxMox and download-debian