Ok, after a tour through the REST console code as best as I can tell it *looks* like all your REST console does is wrap cli commands in XML and ship messages back and forth. I guess that sort of band-aids the need for a console remotely but there are whole sets of things that don't work. For instance if I want to do a "load oar" command how does the oar file get to the server and where does it need to live to get found? If I need to do some sort of out of band mechanism to achieve that how does that translate to a fully functional console?
In a case like this where I *personally* want a truly remote management interface for a server I'd strongly prefer a set of well documented remotely callable functions. They should fully capture the semantics for the operations involved (i.e. the load oar "function" specifies how the oar file is transported over the wire) so the interface is truly remotable. If you had that you could still implement a text based local console over the implementation interface but at least what remotely managing the server means is well defined. And programming against it means using a straightforward RPC call vs. XML mangling. Just my 2 cents. Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Melanie Sent: Sunday, September 06, 2009 9:27 PM To: [email protected] Subject: Re: [Opensim-dev] ConsoleClient -pass option Isn't this discussion a bit behind? After all, the console is fully implemented (and, yes, WITH remote command parsing/verification/help tree) using REST. Melanie Frisby, Adam wrote: > I have to second this motion - XMLRPC in my opinion is a lot better for > remote programming than "REST" which doesn't really define the wire formats > nor datatypes. > > The ICommander interface we are now using on the console really suits XMLRPC > well - since we already have a list of defined arguments available, and can > build nice remote-access documentation from them automatically. > > In addition, we can use the exact same format & arguments as the console > commands. > > Regards, > > Adam > >> -----Original Message----- >> From: [email protected] [mailto:opensim-dev- >> [email protected]] On Behalf Of Dickson, Mike (ISS Software) >> Sent: Friday, 4 September 2009 8:05 AM >> To: [email protected] >> Subject: Re: [Opensim-dev] ConsoleClient -pass option >> >> Thanks for the pointer Melanie. No I wasn't aware of it. I'll have a >> look. >> >> I'm pretty sure I don't agree however that a simple GET/PUT interface >> is somehow just better than (dated!) XML/RPC (or some other protocol >> where the on the wire data types are actually defined). That's creeping >> towards a religious discussion however so I'll drop it. Having the >> console functionality packages separate like this is the important >> "feature" IMO. >> >> Mike >> >> -----Original Message----- >> From: [email protected] [mailto:opensim-dev- >> [email protected]] On Behalf Of Melanie >> Sent: Friday, September 04, 2009 9:59 AM >> To: [email protected] >> Subject: Re: [Opensim-dev] ConsoleClient -pass option >> >> Have you ever looked at the REST console? That is precisely what it >> does, it removes the local console, enabling the process to run as a >> daemon, and allows remote connections from a console application. >> >> Only, it doesn't use the (dated) XMLRPC, it uses RESTful requests. >> >> XMLRPC admin is only available in region servers, and is too limited >> a tool even if "beefed up" to ever replace a console. >> >> Melanie >> >> Dickson, Mike (ISS Software) wrote: >> > Right. That gets around the issue. BTW, if the server is running >> SNMP or something that gives access to the process list this problem >> can leak outside the local machine. I don't for sure but I'm guessing >> you could have the same issue in Windows with WMI. >> > >> > IMO, the right answer is to dump the consoles, beef up the XML/RPC >> admin interface and if desired do a separate "console app" that parses >> and sends the XML/RPC to the server. I've been noodling on that but >> still struggling with a stable config with the new "BUST" architecture. >> > >> > Mike >> > >> > -----Original Message----- >> > From: [email protected] [mailto:opensim-dev- >> [email protected]] On Behalf Of Dr Scofield >> > Sent: Friday, September 04, 2009 3:19 AM >> > To: [email protected] >> > Subject: Re: [Opensim-dev] ConsoleClient -pass option >> > >> > >> > Dickson, Mike (ISS Software) wrote: >> >> I'd agree with Dave on this one. Just a simple long ps listing gets >> you the password if its on cleartext on the command line. At least the >> file can be locked down via permissions. A password on the command >> line is pretty much insecure. Might as well not have one. >> > >> > ...unless you rewrite argv (which is standard practise for stuff like >> that). >> > >> > DrS/dirk >> > >> >> >> >> Mike >> >> >> >> -----Original Message----- >> >> From: [email protected] [mailto:opensim-dev- >> [email protected]] On Behalf Of Melanie >> >> Sent: Thursday, September 03, 2009 10:02 PM >> >> To: [email protected] >> >> Subject: Re: [Opensim-dev] ConsoleClient -pass option >> >> >> >> It's choosing the lesser evil. >> >> >> >> Melanie >> >> >> >> >> >> Dave Coyle wrote: >> >>> On Thursday 03 September 2009 03:00:46 pm wrote: >> >>>> commit 6b70b5709913e9734f5864560e997b34dfd58b85 >> >>>> Author: Justin Clark-Casey (justincc) <[email protected]> >> >>>> Date: Thu Sep 3 20:00:18 2009 +0100 >> >>>> >> >>>> * Add extra warning about using -pass in >> >>>> OpenSim.ConsoleClient.ini.example >> >>>> >> >>>> <...> >> >>>> >> >>>> + ; Please be aware that this is not secure since the password >> is in the >> >>>> clear + ; we recommend the use of -pass wherever possible >> >>>> ;pass = secret >> >>> >> >>> Is the password not also in the clear, visible to any local user >> who does a >> >>> 'ps', if you use the -pass switch? Access to >> OpenSim.ConsoleClient.ini can at >> >>> least be restricted to specific user(s). I don't see how -pass is >> the lesser >> >>> of the two evils. >> >>> >> >>> -coyled >> >>> >> >>> >> >>> ------------------------------------------------------------------- >> ----- >> >>> >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> [email protected] >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> [email protected] >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> [email protected] >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
