On 18/08/11 21:13, Kinkie wrote:
I don't personally really like save or backup type things unless there is
binary details unavailable from a simple dump/restore-from-dump. I guess
what I'm saying is that "save" should be dropped from mention. The "set"
should _all_ work immediately (caveat when necessary). And "show config",
like now should dump the entire config out for saving to a file somewhere.
I OTOH like a commit-like interface, where a set of changes is
prepared but then executed atomically.
It'd be nice to have both ways, via some "autocommit" switch in the
shell (which would implicitly save/commit after each command is
validated)
We are not really talking about the same concept there. I'm talking
about a save/restore process being nasty.
You are talking about more of a editor with batched updating process. I
completely agree batching is more efficient an all ways.
Restore when done that way too can even be good. It just should not be
distinctly separate from viewing the dump IMO. Dump and read the file,
or "show" and enable a way to pipe that display to a file.
I have an idea to use snmp to get statistic information and http to
change/put/get existing info
SNMP is read-only at present due to the library we use. We need a major
library change at some point to do updates or bulk transfers properly, but
out of scope for a shell project.
A problem lies in _finding_ such a library.. there are a few out
there, but most of them seem abandoned..
I know exactly what you mean. Been researching myself several times, and
not come across anything usable yet. Not even an updated version of our
current library by the documented copyright holders. :P
Kinkie, is working on merging cachemgr reports and SNMP reports. So you
should not need to worry about SNMP even for reads. It will all be provided
via the same cachemgr actions internally.
Yes.
My wish would be to enable reporting SNMP and CacheMgr using the same
internal interfaces.
So far all actions are at the global scope. But since components might be
disabled or simply missing from the build I think we need to consider
something like BusyBox shell does. With a "use" command to move 'into' a
component scope and the get/set/show commands become limited or expanded to
ones available only in that component.
I find JunOS' cli interface extremely powerful.
Not being a FOSS licensed CLI is a worry there. We need to be able to
copycat safely.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.14
Beta testers wanted for 3.2.0.10
