Re: SquidShell is already in progress

 On Wed, 17 Aug 2011 09:57:19 -0700 (PDT), Arthur Tumanyan wrote:
> Hello,i want to inform you that SquidShell is already in
> progress.Currently
> I'm working around command line interface and the main part of it is
> done.
> Please look at text below and feel free to advice/correct me,if so.
> The command line interface will look like this:
>
> SquidShell>* connect proxy.domain.com:port using http *
> /Connection ok [or failed] /
> SquidShell>*show active connections *
> /List of active connections /
> SquidShell>*get visible_hostname*
> /visible_hostname = "GyadjiXut" (just example)
> Note: This will active until next reconfigure
> Type 'save' to save current configuration /
> SquidShell>*set visible_hostname "MyCoolProxy"*
> SquidShell>*get visible_hostname *
> /visible_hostname = "MyCoolProxy" /
> SquidShell>*close *
> Connection to proxy closed
> SquidShell>

 Thank you for this example. It reminds me about data validation checks.

 Are you using shell app validation? or the squid internal parser
 checks?

 How are the parse validation WARNING: / ERROR: / FATAL: messages
 getting back to the shell?
  (Would be a good idea to replace debugs() with a configWarning()
 system, but nobody has done it yet).

 What thoughts on the validation which is currently done by
 parseDoConfigure() at the end of parsing? the details being checked
 there are interdependent with other config settings in sometimes complex
 ways.

 I'm of the opinion we should limit this "set" command (for now) to only
 allowing the single-value or toggle config items to be changed.

 Your example mentions "save". Does the lack of it later in the shell
 mean that the visible_hostname was reverted on "close" or not?

 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 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.
 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.

> It seems , I have to concretize the commands list and their
> functionality to
> continue work

 Also, for "set" when accessing from remote machines there is some form
 of login to consider.

 Stuff to consider:
  Over TLS?
  Kerberos credentials? or others?
  credentials once per session? or with every command message?

 Something else to think about when deciding the commands list:
 component scoping.

  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.

 Correlation from that scoping thought, "get" and "show" become
 overlapped. "get X" vs "show config X" are identical. So "get" can
 probably be dropped. Its not actually moving or copying the data into
 some shell state is it?

 I'm hoping we can add this scoping to the cachemgr web interface as
 well via a menu system. Still thinking through the consequences and
 design there though. The actions would be using the '/' path syntax of
 URLs for that. ie action "icap/config" to just show the icap specific
 configuration object dump.

 Also, how to shell into a specific worker when they share the http
 port?
  "use worker $N" ?

 My initial thoughts are:
  show [$component_name] $value
  set $config_line
  use $component_name

 maybe also:
  login $username
  quit / bye / logout / close / exit / Ctrl+C. ** accepting all these
 as aliases for exit is good for UI simplicity.

 Amos
Received on Thu Aug 18 2011 - 00:57:02 MDT