I'm looking further into this, and it seems that the biggest problem is
detecting that what you plugged in is a phone. Assuming you have DHCP turned
on on the phone, the dhcp message only contains a mac address, and a vendor
code. Not sure if this is enough to reliably detect that someone plugged in
a phone on the network. Or what phone model you plugged in.
-----Original Message-----
From: Greg Swift
Sent: Thursday, June 07, 2012 6:22 AM
To: cobbler mailing list
Subject: Re: [cobbler] Extending cobbler
On Thu, Jun 7, 2012 at 7:15 AM, James Cammarata <j...@sngx.net> wrote:
Hello everybody:
I’m new to the list, and I’m new to cobbler. I stumbled upon cobbler
looking for a solution to an idea I have. I’m working on a voip server
idea.
Mostly a front end to FreeSwitch. I think most voip systems handle new
phone
configuration backwards. You enter configuration information into the
system
before plugging the phone in, and then you plug the phone in. It seems
backwards to me.
What I want to do is the following:
1 – plug new IP phone into wall jack
2 – IP phone asks DHCP server for IP address
3 – DHCP server detects by the vendor code and/or MAC address, that
someone has plugged a new phone in
4 – DHCP server tells cobbler that there is a new phone attached
snip
You might consider looking into
http://theforeman.org/projects/smart-proxy/wiki, it should allow you to
configure dhcp/tftp via an rest API and could probably make it easy to
drive
the needed changes.
Whether you use foreman or cobbler makes no difference, the crux of
the question is whether ISC's dhcpd can trigger a script when a lease
request comes in. A quick search turned up this:
http://jpmens.net/2011/07/06/execute-a-script-when-isc-dhcp-hands-out-a-new-lease/
I haven't done it myself personally, but that looks like what you
want, and yes - cobbler would be able to handle it. You'd just need to
write to the XMLRPC API. I've considered moving cobbler to REST, but
frankly the XMLRPC API works fine and is not (in my opinion) any more
difficult to use.
So following through this I would approach it like this:
1: Create my overall profile(s) in Cobbler, not associating any systems with
it
2: In the dhcpd.template file I would setup the dhcp block with the
vendor code/mac matching classifier
3: I'd build the script to perform the initial creating of that phone
as a 'system' in cobbler attached to the profile (as per james
statement above)
The original step 5 is the sticking point for me. The script you
write in my #3 could create that template, but cobbler already
generates pxe configuration files so it might be easily patched to
support creating the phones configuration file.
I think using the python tftp server would probably be a good idea if
cobbler is patched to build the pxe config files, otherwise that will
require a cobbler sync. Which leads to the next thing to ask, would
the dhcp profile need to change for that system after initial
registration? because that would require a cobbler sync to rebuild the
dhcpd.conf file. Depending on how it all ended up functioning I would
probably leave the script to run everytime so that I didn't have to
change the dhcp profile.
-greg
_______________________________________________
cobbler mailing list
cobbler@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
_______________________________________________
cobbler mailing list
cobbler@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
