Experimental Physics and Industrial Control System
|
At 9:51 AM +0200 2008/07/22, Ralph Lange wrote:
--allow
I feel quite uncomfortable with adding an easy way to create a
massive security hole. I thought the public read-only port was a
kind of compromise. Not enough. Hm.
I can see that it would be more liberal to have the users enforce
their security policies, though. Would a compile-time Makefile
configuration option (pro-actively enabling the "--allow"
functionality) be sufficient for west coast usage and still be
regarded safe enough?
Yes, and that would put the policy in the hands of the local builder,
rather than the casual user. So you are thinking of something like
"make -DALLOW_REMOTE_HOST"?
--watch
I don't fully understand what you're suggesting. ProcServ is not
starting the telnet session, you are. So -- how long should procServ
wait for a telnet session to be opened before starting the child? A
minute? A week? Until Election Day? How should it know that it's you
connecting first and not someone else? Should it start the child and
buffer the child's output until someone (possibly you) connects? How
long or how much? In memory or as a file? And play it back to the
first session only or to all future sessions?
Anything in this "dynamic wait" direction seems to make things odd
and complicated. Right now you can use the log file and/or debugging
mode to see everything from the initial command.
*Idea.* (Maybe this is what you meant in the first place, anyway.)
What about adding a "--wait" option instead, that starts the
procServ server, but keeps the child in "shut down" mode? You would
have to connect by telnet and start it manually whenever you like --
same situation as if you toggled autorestart, shut the child down,
and disconnected.
This would actually be straightforward and fairly easy to implement.
Yes, that is the way to do it...I wasn't thinking clearly about the
telnet session, the procServ process, and the child (IOC) process.
Steve Lewis wrote:
I finally got around to trying this out...it's amazing!
Congratulations to Dave and Ralph. Of course, I do have 2 small
suggestions, since it has been more than a week :-)
1. Add a flag (-a|--allow)" to allow non-'localhost' telnet
activity. I know there are add-ons like conserver to package the
procServ with ssh to enable one-stop shopping, but procServ is so
straight-forward, I prefer to use it alone with just some shell
aliases. I can deal with the security issues on an isolated
network--at least I want to set my own policy.
2. When you first invoke, say, "./st.cmd", you miss the output
until you have time to invoke the telnet. Of course, you can
scroll back to see what you missed; or even use ^R to force a
restart and watch from the beginning. So what I am suggesting is a
flag (-w|--watch) which invokes the telnet session early enough to
see the initial command at work.
- References:
- procServ soft IOC server - V2.3.0 released Ralph Lange
- Re: procServ soft IOC server - V2.3.0 released Steve Lewis
- Re: procServ soft IOC server - V2.3.0 released Ralph Lange
- Navigate by Date:
- Prev:
Re: procServ soft IOC server - V2.3.0 released Ralph Lange
- Next:
procServ soft IOC server - V2.4.0 released Ralph Lange
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: procServ soft IOC server - V2.3.0 released Ralph Lange
- Next:
Re: Atomic "check and reserve" question Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|