You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/08/07 18:18:51 UTC
Console facility in the making
Gang,
I was a bit tired of the Http Facility so I moved on to looking at a Console
facility. The idea is to allow for a telnet interface into Merlin's
internals, so that we can do stuff like;
* Hot-deploy of blocks.
* Reloading of containers with new classes
* Check security settings.
* Restart Merlin remotely.
* Remote troubleshooting
And what else we may come up with.
Currently though, I have only implemented
* List which threads are running.
* Traversal of the model
* List children in a 'node' of the model (like 'dir')
* Print out the entire structure under a node.
* Plus 'login', 'dummy', 'echo' and 'help'
This can either be deployed as a normal facility, or inside the Kernel root
container, which allows any part of the application container to be fully
manipulated.
The code so far exists in planet/facilities/console, and the interesting stuff
is in the commands/ project.
If you want to try, check out the code, and go to planet/facilities/console,
and run;
ant
then start merlin;
merlin
blocks/default/target/deliverables/blocks/avalon-console-default-SNAPSHOT.block
Login into it via
telnet localhost 3333
and the password is
yabadabadoo
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Console facility in the making
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 11 August 2004 00:57, Stefano Mazzocchi wrote:
> make sure the interface connects to localhost only or sysadms will
> scream about having non-crypted ports open.
1. Without 'additional config' only localhost is accepted as the remote host.
2. Most Linux distros nowadays seems to default to disallow everything.
> I personally think that a simple CLI would be a much more friendly way
> to do stuff, mysqladmin style as sysadmins trust SSH more than anything
> else.
Ok, the SSH to host and telnet in. Or be fancy and do a SSH tunnel (it is a
marvel of invention!!).
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Console facility in the making
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> Gang,
>
> I was a bit tired of the Http Facility so I moved on to looking at a Console
> facility. The idea is to allow for a telnet interface into Merlin's
> internals, so that we can do stuff like;
>
> * Hot-deploy of blocks.
> * Reloading of containers with new classes
> * Check security settings.
> * Restart Merlin remotely.
> * Remote troubleshooting
>
> And what else we may come up with.
>
> Currently though, I have only implemented
>
> * List which threads are running.
> * Traversal of the model
> * List children in a 'node' of the model (like 'dir')
> * Print out the entire structure under a node.
> * Plus 'login', 'dummy', 'echo' and 'help'
>
> This can either be deployed as a normal facility, or inside the Kernel root
> container, which allows any part of the application container to be fully
> manipulated.
>
>
> The code so far exists in planet/facilities/console, and the interesting stuff
> is in the commands/ project.
> If you want to try, check out the code, and go to planet/facilities/console,
> and run;
> ant
> then start merlin;
> merlin
> blocks/default/target/deliverables/blocks/avalon-console-default-SNAPSHOT.block
>
> Login into it via
> telnet localhost 3333
>
> and the password is
> yabadabadoo
make sure the interface connects to localhost only or sysadms will
scream about having non-crypted ports open.
I personally think that a simple CLI would be a much more friendly way
to do stuff, mysqladmin style as sysadmins trust SSH more than anything
else.
--
Stefano.
Re: Console facility in the making
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Sunday 08 August 2004 01:29, Alexis Agahi wrote:
>
>
>>IMO you should split telnet/ssh facility from console shell.
>>One should be able to run the shell from command line (without having
>>remote connection).
>
>
> sorry, I gently disagree... Having a network socket is so much more natural,
> then trying to 'redirect Merlin output' elsewhere, get hold of System.in and
> be limited to a single user. Also doesn't help me much in background ops.
>
> telnet localhost <port> is IMO, the most natural way to deal with this;
>
> * SSH tunnelling is possible, to secure the connection.
> * Can combine that with a "allow"/"deny" feature for incoming connections,
> to 'force' secure transport.
>
> As for HTTP access, I am sorry to say that people are 'nuts' in respect to
> http.
> IP = stateless
> TCP = stateful
> HTTP = stateless
> MyStuff = stateful
>
> so why on earth go through this state-emulation once more?
> If the port80 is the issue, then do a SSH tunnel over port80... voila!
>
> Don't expect me to add anything in this area, as I find it a stupid way to do
> things.
>
>
>>This remind me that we should (maybe I'm completly offtopic) think about
>>having user management/JAAS service to manage user authentification ? :)
>
>
> It is somewhat related, since I can imagine that a Merlin instance is used by
> a bunch of developers, each only authorized to some containers, and perhaps
> only to certain operations. So yes, it is related... But instead of digging
> into this at the moment, I decided to get something running quickly, as I
> have an immediate need.
I learned the hard way that it is naive to think that sysadmins behave
rationally.
--
Stefano.
Re: Console facility in the making
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 08 August 2004 15:34, Alexis Agahi wrote:
> sometime tunnelling over 80 is not possible (especially with transparent
> proxy breaking the stream)
I am a tired developer, who is no longer interested in trying to 'outsmart'
the paranoid network admins. If they have decided that you are only trusted
to transfer HTML pages free of scripts and images that doesn't contain more
than 30% of skin color range, then let them get their wish.
They want to stop the users. Fine. Let them do that. This 'race' is absurd,
and should never have started in the first place, but that is too late now.
If the user are developer of an app server that sits in the DMZ, you yell at
them and make them open an outgoing port for God sake. This is not user
functionality, and by no means a requirement to 'outsmart' any
un-influencable netadmin out there.
All in Gentle opinion, of course :o)
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Console facility in the making
Posted by Alexis Agahi <al...@users.sf.net>.
Niclas Hedhman wrote:
> On Sunday 08 August 2004 01:29, Alexis Agahi wrote:
>
>> IMO you should split telnet/ssh facility from console shell.
>> One should be able to run the shell from command line (without having
>> remote connection).
>
> sorry, I gently disagree...
As long as it is gently ;)
> Having a network socket is so much more
> natural, then trying to 'redirect Merlin output' elsewhere, get hold of
> System.in and be limited to a single user. Also doesn't help me much in
> background ops.
I was just trying to suggest an unix architure (inetd, telnetd, shell, tty,
syslog).
> telnet localhost <port> is IMO, the most natural way to deal with this;
>
> * SSH tunnelling is possible, to secure the connection.
> * Can combine that with a "allow"/"deny" feature for incoming
> connections,
> to 'force' secure transport.
>
> As for HTTP access, I am sorry to say that people are 'nuts' in respect to
> http.
> IP = stateless
> TCP = stateful
> HTTP = stateless
> MyStuff = stateful
> so why on earth go through this state-emulation once more?
> If the port80 is the issue, then do a SSH tunnel over port80... voila!
sometime tunnelling over 80 is not possible (especially with transparent
proxy breaking the stream)
> Don't expect me to add anything in this area, as I find it a stupid way to
> do things.
np
> It is somewhat related, since I can imagine that a Merlin instance is used
> by a bunch of developers, each only authorized to some containers, and
> perhaps only to certain operations. So yes, it is related... But instead
> of digging into this at the moment, I decided to get something running
> quickly, as I have an immediate need.
np
--
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Console facility in the making
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 08 August 2004 01:29, Alexis Agahi wrote:
> IMO you should split telnet/ssh facility from console shell.
> One should be able to run the shell from command line (without having
> remote connection).
sorry, I gently disagree... Having a network socket is so much more natural,
then trying to 'redirect Merlin output' elsewhere, get hold of System.in and
be limited to a single user. Also doesn't help me much in background ops.
telnet localhost <port> is IMO, the most natural way to deal with this;
* SSH tunnelling is possible, to secure the connection.
* Can combine that with a "allow"/"deny" feature for incoming connections,
to 'force' secure transport.
As for HTTP access, I am sorry to say that people are 'nuts' in respect to
http.
IP = stateless
TCP = stateful
HTTP = stateless
MyStuff = stateful
so why on earth go through this state-emulation once more?
If the port80 is the issue, then do a SSH tunnel over port80... voila!
Don't expect me to add anything in this area, as I find it a stupid way to do
things.
> This remind me that we should (maybe I'm completly offtopic) think about
> having user management/JAAS service to manage user authentification ? :)
It is somewhat related, since I can imagine that a Merlin instance is used by
a bunch of developers, each only authorized to some containers, and perhaps
only to certain operations. So yes, it is related... But instead of digging
into this at the moment, I decided to get something running quickly, as I
have an immediate need.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Console facility in the making
Posted by Alexis Agahi <al...@users.sourceforge.net>.
On Saturday 07 August 2004 18:18, Niclas Hedhman wrote:
> Gang,
>
> I was a bit tired of the Http Facility so I moved on to looking at a
> Console facility. The idea is to allow for a telnet interface into Merlin's
> internals, so that we can do stuff like;
>
> * Hot-deploy of blocks.
> * Reloading of containers with new classes
> * Check security settings.
> * Restart Merlin remotely.
> * Remote troubleshooting
IMO you should split telnet/ssh facility from console shell.
One should be able to run the shell from command line (without having remote
connection).
And it would be great to be able to link a facility (telnet/ssh, http or IM)
to the shell.
> And what else we may come up with.
>
> Currently though, I have only implemented
>
> * List which threads are running.
> * Traversal of the model
> * List children in a 'node' of the model (like 'dir')
> * Print out the entire structure under a node.
> * Plus 'login', 'dummy', 'echo' and 'help'
> This can either be deployed as a normal facility, or inside the Kernel root
> container, which allows any part of the application container to be fully
> manipulated.
>
>
> The code so far exists in planet/facilities/console, and the interesting
> stuff is in the commands/ project.
> If you want to try, check out the code, and go to
> planet/facilities/console, and run;
> ant
> then start merlin;
> merlin
> blocks/default/target/deliverables/blocks/avalon-console-default-SNAPSHOT.b
>lock
>
> Login into it via
> telnet localhost 3333
>
> and the password is
> yabadabadoo
This remind me that we should (maybe I'm completly offtopic) think about
having user management/JAAS service to manage user authentification ? :)
I'm going to play with it right now ;)
--
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org