Re: enable/disable features in running configuration

Salut Vincent,

Will read this too. I have already a cli based on quagga code running.
Having a separate tool to run cli sound best... Will shoot that way.

A+
Alexandre




On Thursday, May 7, 2015, Vincent Bernat <[email protected]> wrote:

>  ❦  5 mai 2015 12:25 +0200, Alexandre Cassen <[email protected]
> <javascript:;>> :
>
> > 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).
> --
> 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