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
