Vreman, Peter - Acision wrote:
>>> The live CD you mention could use this.
>>>
>>> As I mentioned earlier, due to security reasons, we'd want this off by
>>> default.
>>>
>>> Ideally I think we want a setting like:
>>>
>>> extended_registration_enabled: 1
>>>
>>> And we could obsolete the existing "register new MACs"
functionality as
>>> this would be more feature-rich.
>>>
>>> It's a slight weakness in that this would create an API that could
>>>
> allow
>
>>> data in cobbler to be manipulated without access (like the RAM amounts
>>> as we indicate above), though we do it right it should be reasonably
>>> feature rich.
>>>
>>> We could think about requring usernames and passwords but since this is
>>> in a provisioning context those credentials would be exposed anyway, so
>>> it's not that useful to do so.
>>>
>>> I've also thought about doing something like this through Func, though
>>> I'm not sure everyone would want to adopt Func for this so something
>>> self contained might be better.
>>>
>>>
>>>
>> Hi all,
>>
>> I'm interested in this functionality, has work started on this yet, or
>> is it still in the "good idea" state? :)
>>
>>
> Nothing has started on this one yet, so it's fair game should someone
> want to take it.
>
> Really the more things we do that allow writing to cobbler's state
> remotely, the more we do need something to ensure credentials and
> that the system is who it says it is, and that it can't modify other
> records.
>
> This may really lead down the Func route entirely, in which case it's a
> script to populate cobbler from Func that speaks cobbler's Python API.
>
>
I didn't start development for this yet. But it looks like Eric Raymond
[ecraymond(a)gmail.com] has started creating a "Live Agent" that is similar. See
the thread "XMLRPC definitions". Maybe you can contact him for his work on the
"Live Agent".
Regards,
Peter
Yep, I remember Eric.
Have a link to the thread archives? It was on this list?
--Michael