So... thats fairly doable, the following basic structure should
associate the devices in a class:
class "myphones" {
match if (
(
(substring (option vendor-class-identifier, 0, 12) = "ciscophone1") or
(substring (option vendor-class-identifier, 0, 12) = "ciscomodel2")
) and
match if substring(hardware, 1,3) = 00:00:0C;
)
}
-greg
On Thu, Jun 7, 2012 at 2:54 PM, Daniel Ullfig <dan.u(a)grmcompany.com> wrote:
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 <jimi(a)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-n...
>
> 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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler