[Olsr-dev] New plugin: telnet

[equinox]

Hi,

Am 2013-02-20 17:54, schrieb Hans of Guardian:
[...]
>> I'm not at all convinced that adding such a plugin is a good idea.
>> It might be but your mileage may vary: in general olsrd v1 is UNSUITED for dynamic configuration.
>> Some stuff might work, other stuff might not work.

That's why i asked you if you see any problems with the way the plugin 
interacts with the internal data structures.

>>
>> Also, it seem like we already have something of a telnet server, and it's called txtinfo.

Yes but it's read only... isn't it? Also for a telnet plugin it's imho 
missing a great deal of interactivity.

>> The amount of code duplication already is well above tolerance levels and people duplicating functionality is not doing anything good to it.
>>
>> I'm not particularly open to adding any more plugins to the tree until people make clear why the plugin must be added and why the functionality can't be added to any of the plugins already present in the tree.
>
No offense but i think that my plugin has much more reason to be inside 
olsrd than a  httpinfo/txtinfo/jsonfo. After all it's the first plugin i 
know which allows the user to update any of the olsrd's configuration at 
runtime. All those plugins listed above do more or less the same but 
with differnet output format. Don't get me wrong, i use them all and i 
think that they all are very useful.
Because there are so many plugins for this there is no 'route list' 
command inside telnet plugin. That's because plainly dumping info is not 
the use case for it. The focus is on changing parameters without the 
need to restart the daemon.

I don't want to step on anybodys feet but if you want to reduce the 
number of duplicate plugins, how about dropping the dyngw plugin(s) 
(which are - correct me if i'm wrong - the only reason for the 
dependency to pthread) and replacing it with the telnet plugin plus a 
small external programm...

>
> I am most interested in a simple, focused version of this plugin that would allow changing HNAs and adding/removing network interfaces.  Henning mentioned in the past that he thought this would be workable in olsrd v1, but I'm interested in hearing more opinions on that.  That is something that I would put to use right now in the various GUI clients I'm involved in (Android, GNOME NetworkManager, Mac OS X, and soon Windows). As far as I understand, having it in core, like Henning mentioned, is only needed in order for plugins to register new commands.
>
> Keeping it simple means it much easier to verify what the added security risks.  Having a telnet plugin that any plugin can add commands to is a lot more risky.

Sure we can drop the foreign command feature entirly but i think its not 
that risky. The feature can be disabled at compile time, it can be 
disabled at runtime (olsrd.conf), the native commands will always get 
precedence over foreign commands and last but not least if somebody can 
add callbacks to the foreign command table he/she is already inside the 
daemon (which runs as root...) and surely finds better ways to do evil 
things...
However i'm not too fixated on that feature and think the plugin is 
still usable without it.

regards
  christian