Re: enable/disable features in running configuration

2015-05-07 17:30 skrev Vincent Bernat:
> ❦  5 mai 2015 12:25 +0200, Alexandre Cassen <[email protected]> :
> 
>> my goal is really not to compete with Cisco or Juniper stuff :D the
>> intent here is to provide a better control/access to user against a
>> running Keepalived daemon.
> 
> Hey Alexandre!
> 
> When I have added a CLI to lldpd, I had similar requirements. Here are
> the solution that I used in case it could help you. Note that lldpd is
> ISC licensed so you can steal code if needed.
> 
> The communication between the CLI and the daemon is done through an 
> Unix
> socket. I don't think that telnet/ssh/login stuff is something that
> should be plugged in a daemon. If the user is root, it gets ability to
> modify the configuration, otherwise he can only query the local
> state. People building a router OS can work from here. Targeting a Unix
> socket makes the protocol simpler since we have message boundaries.
> 
> One goal of the CLI was to remove code from the daemon. All
> configuration parsing is done by the CLI. On start, lldpd enters a 
> pause
> mode, invoke the CLI to parse the configuration and transmit it through
> the Unix socket.
> 
> You can find more details here:
>  http://vincent.bernat.im/en/blog/2013-lldpd-0.7.1.html#client
> 
> For serialization, I didn't want to have functions copying internal
> structures to an exportable format (because I have a lot of nested
> structures). Too much code and I was trying to minimize it. Instead, I
> have some marshalling functions using annotations to know how to
> serialize a C structure. This works because I know that both the client
> and the server are ABI compatible. I am still a bit mixed with this
> approach. This is still a bit flaky but it is well tested an
> reliable. Maybe I would use some kind of C preprocessor to have less
> boilerplate.
> 
> I expose a library with some clean API (one .h, all functions prefixed,
> only opaque structures, pushing/pulling bytes is done by hook functions
> to support all use cases (synchronous byte push/pull is provided), lean
> error handling (most functions accept NULL to enable the user not
> checking error codes at each step)). I am quite happy with it. More
> details on the link above. Vyatta and Cumulus OS are using it.
> 
> For the CLI, I am using something very simple to parse. The tokenizer 
> is
> plain stupid (words and quoted words). The parser walk a tree with each
> token. Each node of the tree will take one token and validate it either
> with a static string or with a function. Each node has a documentation
> attached to it and you can execute a function when a token is accepted
> (to store it in some registry). It does basic completion (either tab or
> ?) and optionnaly use readline or a compatible library. Tool like
> yacc/bison are great to write a parser but adding completion on top of
> that is hard.
> 
> The commands are like this:
> 
>   configure ports eth1,eth2 med location coordinate latitude 4.356
> longitude 54.5 altitude 3 m datum WGS84
> 
> When executed, I have a registry with "ports=eth1,eth2",
> "latitude=4.356", "longitude=54.5", "altitude=3", "altitude_unit=m",
> "datim=WGS84" and the leaf of the tree will execute the function using
> all that to build the appropriate command to send back to the daemon.
> 
> Unfortunately, in the case of Keepalived, I assume you will have to 
> keep
> the current configuration format. What you could do is a function
> converting it to this simpler format. All the parsing code would be in
> the client. No more segfault due to the parser. :)
> I have no commit/rollback like on Juniper. For lldpd, such a feature is
> a bit useless. It would also be more complex to implement. It would be
> far more useful for Keepalived but I think this would be a too big 
> step.
> 
> You could also look at the code in Quagga for this part. It was the 
> best
> think I found when looking at build a CLI. Unfortunately, being GPL
> licensed was a problem for me.
> 
> In short, just use a Unix socket, people can layer on it. Use a library
> with some good API. This enables you to change the protocol whenever 
> you
> want (and people can be creative with new clients).

I think also that is best way to go, socket with a minimal api and a 
library.

Low level api can handle many request and reply in any order and must be 
full
reentrant & asynchronous style. Some atomic functions for locking 
semantic
needed as well. And non blocking call at socket level, reuse Alexandres 
fine scheduler for some
log, statistic feed via api layer.

Lib also take care of Bigendian/Littlendian if different platform for 
client/server.
That should be in library call functions and hide for applications 
layer.

First exercise should be to load Keepalived.conf with extern parser (and 
more robust syntax check) and get current running config all via api and 
it's socket.


Get config
Set config


> --
> Test programs at their boundary values.
>             - The Elements of Programming Style (Kernighan & Plauger)
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across 
> Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable 
> Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Keepalived-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel

-- 

mvh

/Jan Holmberg

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel