Re: SquidShell is already in progress

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