> Hello everyone!
>
> My name is Konstantin Orekhov with eBay. I'm evaluating Foreman
> Smart-proxies as separate tools to be used by our orchestration to provide
> RESTful interfaces to DHCP (ISC), TFTP and BMC services. After private
> email conversation with Ohad, he advised to post my questions and requests
> to this mailing list.
>
> I've started from DHCP one last week, and since I'm looking at it as
> replacement for existing functionality, I'm going through each of the
> existing use-cases and see what/how Foreman can do that for us and running
> into a lot of questions/concerns.
>
> * no global search by MAC or hostname - needs subnet, why?
main reason is that in theory (in sometimes in practice) the same mac can
exist in multiple subnets.
I dont mind to add a feature to the proxy to scan internally over all
subnets and return the lease info (afair, the code already supports that
and just need to expose it via the api).
> Unless I specify the subnet, I can't get the result although in
> dhcpd.leases itself there's no notion of the subnet, so this appears a
> internal Foreman requirement? To give a bit of context why we do that -
> during new node registration, IaaS does not know (or cares, for that
> matter) in which subnet the node is going to end up, it just needs to find
> its IP using BMC MAC address as a search string and ideally this should
> happen w/o going through all the subnets as this method could also be used
> by humans for troubleshooting efforts and I'd hate to have people to browse
> through hundreds (if not thousands) of subnets. The search very often
> happens on a hostname as well for the same reasons. Does this make sense to
> you?
>
> * Invalid IP issue -
> {"ip":"192.168.166.203","hostname":"blah","mac":"00:50:56:39:ac:40","filename":"pxegrub.0"}
> does not work even from RESTclients - I went through a bunch of posts by
> different people complaining that standard JSON input does not work for
> them from curl. Only the way Ohad described here
>
> https://github.com/ohadlevy/foreman-api-examples/blob/master/examples/proxy/curl_dhcp.shworks. What I also found is that I can't send the above string even through
> Simple RESTclient (in Chrome) or RESTclient in Firefox, all what I'm
> getting back is "Sinatra doesn¹t know this ditty. post '/dhcp/
> 192.168.166.0/192.168.166.203' do "Hello World" End". Any ideas?
>
Hmm… not sure, which version of sinatra are you using? there was a bug
with 1.3.2 (or similar afair), it should just work, and you can reuse the
proxy api binding found in foreman.
>
> * unused_ip does not honor pool/range… Is this by design?
it does, you just need to pass it (e.g. you define the stop-start range as
parameters).
> How does smart-proxy verifies that IP is unused?
it first excludes all reservations and leases, and then it tries to do
(afair) tcp and icmp pings, (we thought of adding arp ping later on but
never got to it), but if you already have a dhcp entry it would not even
try.
further, the proxy remembers the last offered ip address, so it would not
offer the same ip twice (unless there is only one left).
This functionality seems rather dangerous as it can pick up an IP that is
> non-responsive at the moment, but in reality used by some machine and
> statically configured. Just want to understand the underlying checks/safety
> measures. Also, when looking for a unused IP, wouldn't it make sense to
> honor dynamic pool/range defined in dhcpd.conf for a particular network (if
> defined, of course)? Come think of it - if pool or range is defined, DHCPd
> is limited to that range to give away for a reason, as the other IPs which
> could be managed in different way (statically assigned, etc.). IMHO,
> unused_ip should be constrained by that range just as well, however
> existing DHCP smart-proxy's capability to create reservations on any IP
> should stay, obviously.
>
it does respect the start-stop range, and afair, it can also accept a mac
address, so it would not offer a different ip for a host that already has a
lease.
>
> * nextserver is not honored (no record added) - this one seems like a bug
> to me, not sure if this was already reported to you.
> # curl -X POST http://dhcp:8443/dhcp/192.168.166.0 -d 'hostname=blah' -d
> 'ip=192.168.166.203' -d 'mac=00:50:56:39:ac:40' -d 'filename=pxegrub.0' -d
> 'nextserver=tftp.vip'
> # curl -X GET http://dhcp:8443/dhcp/192.168.166.0/192.168.166.203
>
> {"ip":"192.168.166.203","hostname":"blah","mac":"00:50:56:39:ac:40","filename":"pxegrub.0","subnet":"
> 192.168.166.0/255.255.255.0"}
>
not 100% sure, but it does work, as its used by all foreman users 
does
it show up correctly under the mini web ui (/dhcp)
> #
> As you can see above, no next-server added to the reservation 
>
> * no user-defined options accepted - this one is mostly used by us for
> Solaris installs, but there could be a lot of other uses, I'd assume. For
> example, Sparc machine would need something like this in their DHCP
> reservation:
>
thats actually a limitation of the isc implementation, for example the
windows native dhcp support that… I would be happy to extend the isc
provider to support that too.
>
> option SUNW.JumpStart-server "$JUMPSERVER:<path-to-profiles>/$PROFILE";
> option SUNW.sysid-config-file-server =
> "$JUMPSERVER:<path-to-profiles>/$PROFILE";
>
> x86 clients use pxegrub, but we redefine the location of menu.lst file as
> we keep pxeconfig filenames uniformly named, so we'd need to run something
> like this:
>
> curl -X POST http://dhcp:8443/dhcp/192.168.166.0 -d 'hostname=blah' -d
> 'ip=192.168.166.203' -d 'nextserver=tftp.vip' -d 'mac=00:50:56:39:ac:40'
> -d 'option="grubmenu pxelinux.cfg/01-00-50-56-39-ac-40"' -d
> 'filename=pxegrub.0'
>
> I'd say having an ability to specify "option":"blah-blah-blah" is useful
> thing to have regardless of what it is used for, wouldn't you agree?
>
> agree
> * what is the difference between "hostname" and "name" JSON string in
> createNewReservation?
>
its a left over for api compatibility, they are the same.
>
> * is this the most complete description of APIs provided by smart-proxies?
> API - Smart Proxy - Foreman
currently yes, improvements are welcomed.
>
>
> Not related to DHCP smart-proxy:
>
> * a lot of broken links (anchors) on theforeman.org/manual/1.1 - good one
> Foreman :: Manual,
> bad ones something like this -
> Foreman (manuals/1.1/index.html is
> missing)
>
thanks! <hint>patches are welcomed </hint>
>
> I'd much appreciate your feedback, folks!
> Thanks!
Welcome!
Ohad
···
On Tue, Apr 30, 2013 at 10:20 PM, Konstantin Orekhov wrote:Konstantin.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.