Date: Fri, 15 Apr 2011 09:57:07 +0200 In my experience this way is more widely used. Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> --- • wording in commit summary: Use explain or describe? • Maybe the example file should be put in a separate file `cups-x2go.conf.example`? --- README.Multi-CUPS-Servers | 20 ++++++++++---------- cups-x2go.conf | 13 +++++++------ 2 files changed, 17 insertions(+), 16 deletions(-) diff --git a/README.Multi-CUPS-Servers b/README.Multi-CUPS-Servers index 4041840..885d8bf 100644 --- a/README.Multi-CUPS-Servers +++ b/README.Multi-CUPS-Servers @@ -91,36 +91,36 @@ like this (this example includes sample customizations): # Used when this print server must service multiple X2Go Servers # This requires a single database for all X2Go Server session data -#multiserver = 0 -multiserver = 1 # Set multiserver to 0 (zero) to disable and 1 (one) to enable # defaults to 0 +#multiserver = 0 +multiserver = 1 -#dbhost = localhost -dbhost = pgserver.mycompany.com # Set dbhost to the name of the database host # defaults to localhost +#dbhost = localhost +dbhost = pgserver.mycompany.com -#dbuser = postgres -dbuser = someuser # Set dbuser to the user ID for logging into the database # defaults to postgres +#dbuser = postgres +dbuser = someuser -#dbname = x2go_sessions # Set dbname to the database name # defaults to x2go_sessions +#dbname = x2go_sessions -#dbschema = -dbschema = postgres # Set dbschema to the master schema in a multi-schema X2Go database # This is the schema used to coordinate information from the individual # X2Go Server schemas in a secure environment (where one server cannot # view another server's session data # defaults to an empty string +#dbschema = +dbschema = postgres -#dbtable = sessions # Set dbtables to the database table used to hold the session data # defaults to sessions +#dbtable = sessions #========================== diff --git a/cups-x2go.conf b/cups-x2go.conf index 7232018..e21628c 100644 --- a/cups-x2go.conf +++ b/cups-x2go.conf @@ -15,30 +15,31 @@ #========================== # Used when this print server must service multiple X2Go Servers # This requires a single database for all X2Go Server session data -#multiserver = 0 + # Set multiserver to 0 (zero) to disable and 1 (one) to enable # defaults to 0 +#multiserver = 0 -#dbhost = localhost # Set dbhost to the name of the database host # defaults to localhost +#dbhost = localhost -#dbuser = postgres # Set dbuser to the user ID for logging into the database # defaults to postgres +#dbuser = postgres -#dbname = x2go_sessions # Set dbname to the database name # defaults to x2go_sessions +#dbname = x2go_sessions -#dbschema = # Set dbschema to the master schema in a multi-schema X2Go database # This is the schema used to coordinate information from the individual # X2Go Server schemas in a secure environment (where one server cannot # view another server's session data # defaults to an empty string +#dbschema = -#dbtable = sessions # Set dbtables to the database table used to hold the session data # defaults to sessions +#dbtable = sessions #========================== -- 1.7.4.1

Date: Fri, 15 Apr 2011 10:13:16 +0200 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> --- Normally Git outputs a warning when applying such patches. This can also be checked using `git diff --check` before a commit or using `git log -p` and the trailing white space is marked by red color. --- README.Multi-CUPS-Servers | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README.Multi-CUPS-Servers b/README.Multi-CUPS-Servers index 885d8bf..69b4907 100644 --- a/README.Multi-CUPS-Servers +++ b/README.Multi-CUPS-Servers @@ -17,7 +17,7 @@ The cups-x2go virtual printer can be used on a CUPS server running on the X2Go Server or can be used on a separate CUPS server. However, the current implementation associates a CUPS server with only a single X2Go server. It is not possible to have many X2Go Servers share a single, central CUPS print server. -This can be especially problematic in highly virtualized environments where there +This can be especially problematic in highly virtualized environments where there may be hundreds of X2Go Server instances on a single host. It would seem enormously wasteful to have a CUPS instance running on each rather than a single, shared CUPS server. We need to patch the current cups-x2go files to make this possible. @@ -38,18 +38,18 @@ it dynamically? Thankfully, the username is passed as one of the arguments to the cups-x2go backend and the username is also stored in the x2go_sessions database. The username is the connection which makes it all possible. However, there is normally only a single database for a single -X2Go Server. Thus, the shared CUPS server solution is predicated upon using a shared database +X2Go Server. Thus, the shared CUPS server solution is predicated upon using a shared database and the shared database patches we previously created. In fact, this specific patch also requires the database patches we provided for using X2Go in a VServer environment. It is probably possible to adapt the proposed shared CUPS server patches to work with a shared X2Go database server without our shared database patches but we have grave security concerns with that configuration because all X2Go servers connect to the same database using the postgres super user account. That would give any user access to all other user's -session information and, on a poorly configured database, access to any other database +session information and, on a poorly configured database, access to any other database running on the database server. -Discussing those patches is outside the scope of this document but let me give at least a -basic understanding so that the cups-x2go patches make sense. The shared database patch allows +Discussing those patches is outside the scope of this document but let me give at least a +basic understanding so that the cups-x2go patches make sense. The shared database patch allows all X2Go Servers to store their data in a central PostgreSQL database without using the postres super user. Each X2Go Server stores its information in a separate schema. Among the various patches for running X2Go in a VServer environment is another change to the database where a -- 1.7.4.1

Date: Fri, 15 Apr 2011 10:16:54 +0200 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> --- There is also a trailing white space after #dbschema = ^ but I do not know if that should be removed or net. --- cups-x2go.conf | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cups-x2go.conf b/cups-x2go.conf index e21628c..9369115 100644 --- a/cups-x2go.conf +++ b/cups-x2go.conf @@ -34,7 +34,7 @@ # Set dbschema to the master schema in a multi-schema X2Go database # This is the schema used to coordinate information from the individual -# X2Go Server schemas in a secure environment (where one server cannot +# X2Go Server schemas in a secure environment (where one server cannot # view another server's session data # defaults to an empty string #dbschema = -- 1.7.4.1