Hi all,
those of you you have been following the commits on X2Go server
(x2goserver.git) these days, will have noticed that the commit diffs
are quite massive.
I am currently restructuring the whole x2goserver project and I am
migrating the whole Perl code into a proper Perl API (X2Go::Server).
Main reason: I need quite a few of the X2Go server-side commands for a
proper implementation of a Perl based X2Go session broker. And instead
of having to install the server packages on hosts that do not
necessarily have to be an X2Go server, I rather prefer to have the
Perl API installable via separate packages.
So, the Debian/Ubuntu users of X2Go will notice that the x2goserver
package will not upgrade on ,,apt-get upgrade'' (if the nightly repos
is in your APT sources). This is because it depends on new packages
yet to be installed on your X2Go server system (libx2go-*-perl).
Currently, I want to encourage you staying away from the x2goserver*
packages in the nightly builds, they may be a little buggy, although I
always intend to have a working Git master branch at the end of the day.
I'll give notice when the X2Go::Server Perl package transition is
fully complete (probably by the end of the week).
Greets,
Mike
--
DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31
mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xâĻ
Hi All:
Thanks John, Mike. Thanks for the responses.
1) Apologize, but don't know how to respond to threads other than to write a new email - assume this is the wrong way to do this. May be way we set up our profile? We don't get email responses to questions, and go to archive to retrieve them. Fix this?
2) Mike's Response
"Have you read this tutorial? I guess, it still is up-to-date...
http://www.x2go.org/doku.php/wiki:advanced:multi-node:x2goserver-printing"
Hi Mike - great suggestion - have seen this tutorial, but didn't occur to us to try it. We're going to spend a bit more time trying to get single node to work, as figure that may come in handy...but think your suggestion is going to be the way for us to go.
3) John's Response
"Does the CUPS server have rights to write to the client's spool
directory? Good luck - John"
Hi John - how are you? Good question...spent some time trying to check by comparing server where we connect directly to the x2go server vs. x2go running on a Vserver guest including on both:
/tmp/.x2go-user1/spool/C-user1-50-1347811312_stDGNOME_dp24 (see below)
/var/spool/cups
Even if we (assuming no mistakes) make the permissions comparable on both the x2go to x2go server and the x2go to x2go server on Vserver guest on these folders, no joy.
This may be the right track, though....a couple of observations/questions:
a) On the box where we connect directly the x2go server (no vserver involved), in the .x2go folder for the user there is a healthy "spool" link - on the vserver example, this link exists but is broken (they both point at /tmp); Bertl at Vserver says this is OK.
b) When we try to print, on the working x2goclient to x2goserver (again, no vserver), the /tmp/.x2go-user1/spool/C-user1-50-1347811312_stDGNOME_dp24 folder gets created along with the pdf for the print job. NOTE: this does not happen on the x2go client to x2go server on Vserver guest. I.e., no comparable folder is created. So this folder which we think gets generated on the fly, only gets generated on the x2go to x2go server (not the instance where we connect to the x2go server on the vserver guest).
Q: would this be because of permissions?
c) we get entries in the error_log on the x2go client to x2go server on Vserver guest of:
E [16/Sep/2012:16:56:12 +0000] Unable to open listen socket for address ::1:631 - Address family not supported by protocol.
E [16/Sep/2012:16:56:13 +0000] Unable to bind broadcast socket - Address already in use.
Our understanding is that this has to do with IPv6 not working or being set up. However, when we think we disabled IPv6 using "echo 'blacklist ipv6' >> /etc/modprobe.d/blacklist" the errors disappear but we still can't print. Does this matter?
We also tried adding some entries to /etc/cups/cupsd.conf like:
Allow from 127.0.0.1
Allow from 192.168.1.0/24 #your ip area.
...but nothing changed.
As always, any suggestions appreciated.
Best,
Ted
Package: x2goclient
Severity: important
Version: 3.99.3.0-prerelease
Hi Alex,
The current implementation of the http session broker code in X2Go
Client has a task called setpass.
From reading the code of the example session broker you sent me some
weeks ago and from looking at the X2Go Client code in
httpbrokerclient.cpp you do not request the user to enter his old
password before changing it to a new password.
From my perspective this is a no-go feature and it should be changed
to something that also PAM and other passwd tools would do. Request
the old passwd, set the new password (twice on the GUI).
Even if there is an authentication happening prior to changing the
password, the old password should be queried again, before a password
change is possible.
With x2gobroker in Git, I I would like to work in this direction and
we will need an adaptation in X2Go Client sooner or later, I guess.
Greets,
Mike
--
DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31
mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xâĻ
Hi All:
We are trying to get x2go printing to work on a Debian Squeeze Vserver guest.
1) First, tested without Vserver - set up an x2go virtual printer on a box running x2go server; connected via an x2go client and could print (used steps from http://www.x2go.org/doku.php/wiki:components:printing)
2) On another box running Vserver, set up Vserver Guest and replicated our steps to set up x2go printing including a virtual x2go printer - used http://linux-vserver.org/Problematic_Programs#Cups_print_server which entails as we understand it disabling cups listening to loopback 127.0.0.1 on the host so it doesn't conflict with the Vserver,
We also adding entries to ccapabilities (SECURE_MOUNT, SECURE_REMOUNT,BINARY_MOUNT) based on some other posts.
When we connect via X2go from "client" netbook to Vserver guest, and try to print, we can see the x2go virtual printer and printing appears to happen, but fails (both trying settings to print directly to a printer and the pdf pop approach using evince).
We're not sure how to troubleshoot this...we get an error in the Vserver cups error log "/var/log/cups/error_log" of "Unable to open listen socket for address ::1:631 - Address family not supported by protocol.) that we think is generated by the printing attempt..
This would seem to suggest some problem with sockets(?)...
Suggestions appreciated!
Any suggestions appreciated.
PS: on the same Vserver guest, from x2go on the netbook client we can print to a network printer on the local Vserver guest/host network. But not the virtual x2go virtual printer.
Hi Stephen:
Thanks for the x2go response....turns out (duh) we'd missed some steps including adding the virtual server as described on http://www.x2go.org/doku.php/wiki:components:printing (it had been a while since we'd set this up)
Now stuck on new problem...trying to get x2go printing to work inside of a Vserver...
Ted