Console-less OpenSim - Revision history

Joe Radik: /* Background */

2013-10-09T14:07:05Z

‎Background

MakoBot: Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name

2012-03-04T06:18:15Z

Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name

MakoBot: Robot: Cosmetic changes

2012-03-04T02:54:00Z

Robot: Cosmetic changes

MakoBot: Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

2011-06-10T14:18:12Z

Removed 'Template:' prefix from template includings and/or changed external-link into internal-link

Ideia Boa at 13:55, 21 May 2009

2009-05-21T13:55:58Z

Phrearch at 12:30, 18 February 2009

2009-02-18T12:30:54Z

Phrearch at 12:28, 18 February 2009

2009-02-18T12:28:08Z

Phrearch at 12:23, 18 February 2009

2009-02-18T12:23:06Z

Phrearch: added new xmlrpc daemon method

2009-02-18T12:16:58Z

added new xmlrpc daemon method

Show changes

Dutchie: Added "screen" description

2008-09-27T08:59:48Z

Added "screen" description

@@ Line 3: / Line 3: @@
 <br />
 == Background ==
-OpenSimulator uses consoles for each service it's running. It was already possible to run the services(UGAIMR) in the background, while still being able to access the consoles. On Linux we used the convenient screen tool for this. The ideal situation would be though, to run most commands from an external source like a webportal. The region service has an XMLRPC interface, that's called remote admin. While remote admin offers controls to some extend, it's still impossible to let's say shutdown the region service, and restart it from a webpage. This would require a seperate xmlrpc daemon, which has control over the OpenSimulator services. In python, it's quite easy to make such a xmlrpc daemon as you will see below.
+OpenSimulator uses consoles for each service it's running. It was already possible to run the services(UGAIMR) in the background, while still being able to access the consoles. On Linux we used the convenient screen tool for this. The ideal situation would be though, to run most commands from an external source like a webportal. The region service has an XMLRPC interface, that's called remote admin. While remote admin offers controls to some extent, it's still impossible to let's say shutdown the region service, and restart it from a webpage. This would require a seperate xmlrpc daemon, which has control over the OpenSimulator services. In python, it's quite easy to make such a xmlrpc daemon as you will see below.
 == Concepts ==

@@ Line 3: / Line 3: @@
 <br />
 == Background ==
-OpenSimulator uses consoles for each service it's running. It was already possible to run the services(UGAIMR) in the background, while still being able to access the consoles. On Linux we used the convenient screen tool for this. The ideal situation would be though, to run most commands from an external source like a webportal. The region service has an XMLRPC interface, that's called remote admin. While remote admin offers controls to some extend, it's still impossible to let's say shutdown the region service, and restart it from a webpage. This would require a seperate xmlrpc daemon, which has control over the OpenSim services. In python, it's quite easy to make such a xmlrpc daemon as you will see below.
+OpenSimulator uses consoles for each service it's running. It was already possible to run the services(UGAIMR) in the background, while still being able to access the consoles. On Linux we used the convenient screen tool for this. The ideal situation would be though, to run most commands from an external source like a webportal. The region service has an XMLRPC interface, that's called remote admin. While remote admin offers controls to some extend, it's still impossible to let's say shutdown the region service, and restart it from a webpage. This would require a seperate xmlrpc daemon, which has control over the OpenSimulator services. In python, it's quite easy to make such a xmlrpc daemon as you will see below.
 == Concepts ==

@@ Line 2: / Line 2: @@
 {{Quicklinks}}
 <br />
-==Background==
+== Background ==
 OpenSimulator uses consoles for each service it's running. It was already possible to run the services(UGAIMR) in the background, while still being able to access the consoles. On Linux we used the convenient screen tool for this. The ideal situation would be though, to run most commands from an external source like a webportal. The region service has an XMLRPC interface, that's called remote admin. While remote admin offers controls to some extend, it's still impossible to let's say shutdown the region service, and restart it from a webpage. This would require a seperate xmlrpc daemon, which has control over the OpenSim services. In python, it's quite easy to make such a xmlrpc daemon as you will see below.
-==Concepts==
+== Concepts ==
 XMLRPC is a powerful, yet simple protocol that's supported by most scripting languages. From all scripting languages, python has the best options to actually create a standalone daemon, that can handle remote xmlrpc calls. With such a standalone daemon, it's simple to link systemcommands to xmlrpc calls. Each simulator would have such a daemon, allowing the controling webportal(like WiXTD) to issue commands to each daemon. This would allow total control from a webportal, like service rebooting, rolling restarts, rolling updates, ugaim on/off, etc. Currently the code below doesn't have any security, but it can be extended to be really secure(SSL, host-based dispatching). It's focussed on a linux platform at the moment, but can be easily modified to work on a windows platform as well.
-==MooRPC==
+== MooRPC ==
 This code is part of the moo-package on the forge. The script depends on the following custom libraries: [http://pycurl.sourceforge.net/ pycurl], [http://twistedmatrix.com/trac/ twisted], [http://www.jejik.com/articles/2007/02/a_simple_unix_linux_daemon_in_python/ daemon] and [http://www.voidspace.org.uk/python/configobj.html confObj]. It also uses linux-commands, screen and the directory-structure from Moo currently. You're free to modify the code.
-==Source==
+== Source ==
 <source lang="python">
 #!/usr/bin/python
@@ Line 21: / Line 21: @@
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions are met:
-#     * Redistributions of source code must retain the above copyright
+# * Redistributions of source code must retain the above copyright
-#       notice, this list of conditions and the following disclaimer.
+# notice, this list of conditions and the following disclaimer.
-#     * Redistributions in binary form must reproduce the above copyright
+# * Redistributions in binary form must reproduce the above copyright
-#       notice, this list of conditions and the following disclaimer in the
+# notice, this list of conditions and the following disclaimer in the
-#       documentation and/or other materials provided with the distribution.
+# documentation and/or other materials provided with the distribution.
-#     * Neither the name of the <organization> nor the
+# * Neither the name of the <organization> nor the
-#       names of its contributors may be used to endorse or promote products
+# names of its contributors may be used to endorse or promote products
-#       derived from this software without specific prior written permission.
+# derived from this software without specific prior written permission.
+#
 # THIS SOFTWARE IS PROVIDED BY <OS-Networks> ``AS IS'' AND ANY

@@ Line 1: / Line 1: @@
 __NOTOC__
-{{Template:Quicklinks}}
+{{Quicklinks}}
 <br />
 ==Background==

← Older revision		Revision as of 13:55, 21 May 2009
Line 1:		Line 1:
		+	__NOTOC__
		+	{{Template:Quicklinks}}
		+	<br />
	==Background==		==Background==
	OpenSimulator uses consoles for each service it's running. It was already possible to run the services(UGAIMR) in the background, while still being able to access the consoles. On Linux we used the convenient screen tool for this. The ideal situation would be though, to run most commands from an external source like a webportal. The region service has an XMLRPC interface, that's called remote admin. While remote admin offers controls to some extend, it's still impossible to let's say shutdown the region service, and restart it from a webpage. This would require a seperate xmlrpc daemon, which has control over the OpenSim services. In python, it's quite easy to make such a xmlrpc daemon as you will see below.		OpenSimulator uses consoles for each service it's running. It was already possible to run the services(UGAIMR) in the background, while still being able to access the consoles. On Linux we used the convenient screen tool for this. The ideal situation would be though, to run most commands from an external source like a webportal. The region service has an XMLRPC interface, that's called remote admin. While remote admin offers controls to some extend, it's still impossible to let's say shutdown the region service, and restart it from a webpage. This would require a seperate xmlrpc daemon, which has control over the OpenSim services. In python, it's quite easy to make such a xmlrpc daemon as you will see below.

← Older revision		Revision as of 08:59, 27 September 2008
Line 1:		Line 1:
		+
	normally opensim will only run in console mode: whenever you start OpenSim you will end up at a prompt inside OpenSim's very own console — which is very convenient if you want to manage it that way. it is rather inconvenient if you want to start OpenSim as a daemon in the background (e.g., from <code>/etc/init.d/opensim</code>) and control it via the <code>RemoteAdminPlugin</code>, for example.		normally opensim will only run in console mode: whenever you start OpenSim you will end up at a prompt inside OpenSim's very own console — which is very convenient if you want to manage it that way. it is rather inconvenient if you want to start OpenSim as a daemon in the background (e.g., from <code>/etc/init.d/opensim</code>) and control it via the <code>RemoteAdminPlugin</code>, for example.
		+
		+	As the suggested backgrounding below doesn't work for everyone, the option of using the package screen is a great alternative. Once screen is installed, use the following command to start the simulator:
		+
		+	screen -S OpenSim -d -m mono OpenSim.exe
		+
		+	Once started, you can view the active session(s) listed with <code>screen -ls</code>. To attach a screen, use <code>screen -r Name</code>. From the example above that would be <code>screen -r OpenSim</code>. Once in the screen session, you can detach it by using Ctrl-A,D.
		+
		+	Killing a session without attaching it can be achieved by issuing:
		+
		+	screen -S OpenSim -r -m -X quit
		+
		+	{{obsolete}}

	as of OpenSim's subversion release r4400 the basic support for running OpenSim without such a console is in the code base and all you need to do is invoke OpenSim with the <code>-background True</code> commandline parameter:		as of OpenSim's subversion release r4400 the basic support for running OpenSim without such a console is in the code base and all you need to do is invoke OpenSim with the <code>-background True</code> commandline parameter: