[Olsr-dev] New plugin: telnet
Wed Feb 20 18:32:12 CET 2013
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
However i'm not too fixated on that feature and think the plugin is
still usable without it.
More information about the Olsr-dev