Hi All:
Another quick update - we think enabling fuse in the vserver guest is part of the problem, though the vserver folks suggest this may be a security/stability problem.
In any event, that fixed the broken spool link, and we think we're on to "cups admin how to" issues that may be solved outside of this forum.
More to follow...
Best,
Ted
Hi Ted,
On So 30 Sep 2012 16:35:37 CEST wrote:
Another quick update - we think enabling fuse in the vserver guest
is part of the problem, though the vserver folks suggest this may be
a security/stability problem.In any event, that fixed the broken spool link, and we think we're
on to "cups admin how to" issues that may be solved outside of this
forum.
On your contral CUPS server (Vserver host) you have to set up a print
queue with the cups-x2go backend. You have to share this printer (and
restrict access by network/netmask in cupsd.conf).
On the X2Go server you either have to use a printers.conf file that
points to the central CUPS server or you have to run a CUPS daemon
(listening on localhost only) that does a BrowsePoll request to the
central CUPS server.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Sun, 2012-09-30 at 10:35 -0400, senrabdet@aol.com wrote:
Hi All:
Another quick update - we think enabling fuse in the vserver guest is part of the problem, though the vserver folks suggest this may be a security/stability problem.
In any event, that fixed the broken spool link, and we think we're on to "cups admin how to" issues that may be solved outside of this forum.
More to follow...
<snip> Newer kernels may break out the capability required to make FUSE work from the admin capability but I've not investigated that yet. If you allowed the admin capability in your vserver guest, you shot your security to bits. If I recall correctly, the capability limitation was not in mounting FUSE drives but only in unmounting them, strangely. That's why we moved the x2gocleansessions script to the VServer host - not to mention that it means we can run one process for many hundreds of servers rather than one each firing every five seconds.
We do have this working without opening the admin capabilities but I do not remember the details off the top of my head and we are using an old and heavily adapted version. Good luck with it - John
Hi John,
On Mo 01 Okt 2012 04:12:25 CEST "John A. Sullivan III" wrote:
On Sun, 2012-09-30 at 10:35 -0400, senrabdet@aol.com wrote:
Another quick update - we think enabling fuse in the vserver guest is part of the problem, though the vserver folks suggest this may be a security/stability problem.
<snip> Newer kernels may break out the capability required to make FUSE work from the admin capability but I've not investigated that yet. If you allowed the admin capability in your vserver guest, you shot your security to bits. If I recall correctly, the capability limitation was not in mounting FUSE drives but only in unmounting them, strangely. That's why we moved the x2gocleansessions script to the VServer host - not to mention that it means we can run one process for many hundreds of servers rather than one each firing every five seconds.
We do have this working without opening the admin capabilities but I do not remember the details off the top of my head and we are using an old and heavily adapted version. Good luck with it - John
For X2Go Server 3.2.0.0 I am currently fully restructuring the
x2goserver src:package. Would it make sense for you to package the
x2gocleansessions script in a separate package? What other components
do you have running on the Vserver host that do not run on the X2Go
servers (Vserver guests)?
Mike
--
DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi John,
On Mo 01 Okt 2012 04:12:25 CEST "John A. Sullivan III" wrote:
On Sun, 2012-09-30 at 10:35 -0400, senrabdet@aol.com wrote:
Another quick update - we think enabling fuse in the vserver guest is part of the problem, though the vserver folks suggest this may be a security/stability problem.
<snip> Newer kernels may break out the capability required to make FUSE work from the admin capability but I've not investigated that yet. If you allowed the admin capability in your vserver guest, you shot your security to bits. If I recall correctly, the capability limitation was not in mounting FUSE drives but only in unmounting them, strangely. That's why we moved the x2gocleansessions script to the VServer host - not to mention that it means we can run one process for many hundreds of servers rather than one each firing every five seconds.
We do have this working without opening the admin capabilities but I do not remember the details off the top of my head and we are using an old and heavily adapted version. Good luck with it - John
For X2Go Server 3.2.0.0 I am currently fully restructuring the
x2goserver src:package. Would it make sense for you to package the
x2gocleansessions script in a separate package? What other components
do you have running on the Vserver host that do not run on the X2Go
servers (Vserver guests)? <snip> Hi, Mike. I believe x2gocleansessions is it and we do not have it quite right. We made major changes to the way the database is handled to close some of the security holes but I think you have already addressed
On Mon, 2012-10-01 at 07:53 +0200, Mike Gabriel wrote: those issues. Hmm . . . actually some of those changes may still be necessary as they were for both security and centralized x2gocleansessions. There is one x2go_sessions database for all x2go servers. Each server has a separate schema with a trigger to update the sessions table in a sessions table in the public schema to which only the postgres user has access. All of the details are included in those extensive posts and patches we posted a couple of years ago to the X2Go mailing list. Thanks - John
-
John A. Sullivan III -
Mike Gabriel -
senrabdet＠aol.com