On 11/08/2013 05:18 PM, John Andersen wrote:

On 11/8/2013 2:49 PM, Ted Byers wrote:

...

Is it posible to have some kind of GUI, either KDE or Gnome, that runs over ssh to let me work on those machines, at least until I can get out to get a replacement monitor? This works (as others have mentioned) on a fast local network, but you will be disappointed with the results if you have to traverse the internet.

You can launch either the full remote Graphical desktop, or simply a graphical program.

Serviceable but not all that great.

It is true that the performance of an X program over an SSH tunnel will be very disappointing, but the performance of VNC to view an entire remote graphical desktop is quite acceptable, particularly using the "tight" encoding available with the TightVNC package (which I have on Ubuntu, but should also be available with OpenSuse). My remote location has only a 1Mbit uplink speed, but I find the performance to be more than simply serviceable. Just to be clear about VNC, you're not actually launching either a graphical program or a full desktop. With VNC, you're simply looking at a copy of the remote desktop and manipulating it as though you were on the remote keyboard and monitor. In fact, the monitor at the remote location (if someone were watching) would show exactly what you see and do remotely. Jim -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/8/2013 6:51 PM, Ted Byers wrote:

I thank everyone that replied to this.

Clearly I have a number of options, and some studying to do. One thing that impinges on performance is that these machines are all sitting on my desk, connected by a 1 Gbps LAN, so I doubt performance will be all that bad. ;-)

--- If it is over a private LAN, do you need your session to be encrypted? Even using RC4 in ssh (which is the fastest option AFAIK) still introduces lag time. If you have the option of a private lan, having your display not use 'ssh' for forwarding will help quite a bit. I.e. - set your DISPLAY on the target machine to your local machine name:0.0. My big issue has been getting Mesa to work ... I've seen some accelerated graphics in leechcraft's display of it's modules as large icons -- the animation was so smooth, it had to be local (to the display), but I haven't been able to configure Mesa to work with it's swrast driver.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, Nov 9, 2013 at 1:56 PM, jdd wrote:

On 11/8/2013 6:51 PM, Ted Byers wrote:

...

I thank everyone that replied to this.

did you try NX?

http://dodin.info/wiki/index.php?n=Doc.Remote-access-NX

I will look at that link when I get back, but at this stage, until I saw your post, I didn't know there was such a thing called NX. Thanks. I will investigate this too. Cheers Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-11-09 20:02, Ted Byers wrote:

My needs seem, on the face of it, rather simple: something like Dolphin, so I can easily find files; a programmer's editor, like Emacs, &c., oh, and of late, KOrganizer. If all the machines were Windows, I'd be using RDP, but I don't know if RDP even exists in th eUnix world.

IMO, ssh on a local network is fast enough. Of course, the more graphic enhancements the apps use, the slower they are. And if you have a gigabit network, it is faster. For example, you could use a local editor to edit remote files, sharing the remote folder via nfs. On the other hand, text tools such as gcc work equally fast over ssh. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

On 11/9/2013 11:02 AM, Ted Byers wrote:

On Sat, Nov 9, 2013 at 1:49 PM, Linda Walsh wrote:

...

If it is over a private LAN, do you need your session to be encrypted?

No, I don't need encryption, but ssh is the only tool I have used on any Linux to connect to one linux box to another.

You still use ssh for the connection, BUT, Say you are logging in from "Desktop" to "Server". You'll need the REMOTEHOST from PAM to be set in "/etc/security/pam_env.conf" .. I have: ---- # The original idea for this came from Andrew G. Morgan ... #<quote> # a pam_env module ... would be an "auth" module that returns PAM_IGNORE # for the auth part and sets the environment returning PAM_SUCCESS in # the setcred function... #</quote> ... # First, some special variables # # Set the REMOTEHOST variable for any hosts that are remote, default # to "localhost" rather than not being set at all #REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST} REMOTEHOST DEFAULT="" OVERRIDE=@{PAM_RHOST} # # Set the DISPLAY variable if it seems reasonable DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY} # --- (the comments are from the file -- i.e. it suggests this usage as pam_env is only supposed to be called once/session when you 1st log into the machine). Overrides are applied if override var is set, else it goes w/defaults. --- Then in your .bashrc, export DISPLAY="$REMOTEHOST:0" #cuz ssh will set it to "localhost: ---- Then you need to make sure pam_env.so is in your: /etc/pam.d/common-auth file as top "non-comment": auth optional pam_env.so AND (important), make sure it is NOT listed in /etc/pam.d/common-session (NOTE: the reason for this, is that the value "PAM_RHOST" is only available when you FIRST login and go through pam's authorization stage) The suse maintainer made a buggy change that overwrites DISPLAY and REMOTEHOST with blank or null values (not very useful) every time you do something like "su" or "sudo" (and other things that start a new session). So you need to work around the Suse bug introduced in 12.3. --- Then your DISPLAY will be set to point directly at your 'Desktop', and goes in "clear text" over port 6000 (for DISPLAY :0). If I wasn't clear on anything, let me know... Also, as an "FYI", you want to make sure you are not using ssh's compression over a 100Mb or faster connection, as the fastest compression will slow you down ~50%, on a 1Gb connection the percentage slow down is worse (~90% or more). Finally, you mention:

If all the machines were Windows, I'd be using RDP, but I don't know if RDP even exists in th eUnix world.

There is "xrdp" if you can figure out how to configure it.. mine bails because my desktop settings are confused. But my win xrdp client does attach to the choice manager on my linux box.. just no desktop... C'est la vie -- so that's another option. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd wrote:

...

I have a couple servers, using a KVM to have them share a monitor, keyboard and mouse. Alas, it looks like the monitor has died.

notice that a monitor is very cheap nowaday :-)

Monitors take space. XDMCP used to work well, but it's been pretty much useless in KDE on openSUSE 12.x. Hopefully, it will be fixed in 13.x. It's beyond belief that something that's long been a feature on Unix/Linux can be broken for so long, despite bug reports. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh wrote:

...

Monitors take space. XDMCP used to work well, but it's been pretty much useless in KDE on openSUSE 12.x. Hopefully, it will be fixed in 13.x. It's beyond belief that something that's long been a feature on Unix/Linux can be broken for so long, despite bug reports.

---- Use of REMOTEHOST and DISPLAY as set in an "auth" module goes back 20 years, but Suse broke that to use with their non-standard session support. When pointed out in a bug report, that they had broken the original usage of it -- they said such usage was no longer supported.

Even running multiple desktops is broken. You can no longer start another desktop session and reliably use it. One unbelievably stupid problem that occurred a while ago was you couldn't even click on an availble XDMCP connection, because as soon as you moved the mouse, the menu would close. XDMCP worked well in 11.4, but it's been unusable since then. Perhaps the developers should take a look at what works, before they break things with new "features". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/11/13 08:48 AM, psavoie1783 wrote:

On 08/11/13 05:49 PM, Ted Byers wrote:

...

I have a couple servers, using a KVM to have them share a monitor, keyboard and mouse. Alas, it looks like the monitor has died.

I also have a workstation in which I have OpenSuse running within a virtual machine. I can ssh from that virtual machine to these servers, but I am not yet comfortable with using only a terminal to work on a computer (I did so decades ago in the days of DOS, but that was a lifetime ago, and I don't recall anything useful from that time).

Is it posible to have some kind of GUI, either KDE or Gnome, that runs over ssh to let me work on those machines, at least until I can get out to get a replacement monitor? Ideally, whatever is suggested would be viable for both the Ubuntu server and the Opensuse server.

Thanks

Ted

Hi Ted

Not using Opensuse, but Centos here. I use tigervnc to bring over desktops through ssh. Very simple to set up. Once you install the package, uncomment the last two lines in the /etc.sysconfig/vncservers

Small error -- Sorry should read /etc/sysconfig/vncservers

file and change "myusername" to whomever -- as root.

Very important next thing to do is, as user, run the vncpasswd command to give the user a password.

Start and enable the service on the server then as long as you see a mention of the users XAuthority file created, it should be set up fine.

On the client side, as user, run:

vncviewer -via user@host localhost:2

Where the number 2 is the same in the vncservers file and is also the display number that is used. Works well on my gigabit home network and is securely run in an ssh tunnel.

Hope this helps.

Phil

Phil -- To err, is human To never grow up, is divine -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/10/2013 09:20 AM, Anton Aylward pecked at the keyboard and wrote:

I have set up vnc on some of my servers but I'm faced with a few conundrums.

First, if I run

# systemctl isolate multi-user.target

it goes away. But if I use "ssh -X" to the server I can run the X/GTK GUI tools.

Secondly all the ways I've found to set up a vcnserver start it ip as a singleton. I cant see how to treat it like I do other network services and have it started from XinetD and have it (a) run on demand and (b) run more than once. Call it "multi-seat" if you will. Since it uses, or can use, a software framebuffer (eating memory) then why not? It sounds better than the way Citrix/Cisco do Windows VDIs.

You DO NOT need X running on the remote servers to start their GUI programs, you only need to install the needed programs/libraries. ssh -X should be enough. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

My point is that that this doesn't seem to be the same with vnc. Or at least I haven't found a way to, for example, have the XinetD spawn copies of the vncserver on demand, allowing many people to make a vnc connection to the server, each getting their own instance.

XDMCP does that, at least up to openSUSE 11.4. It's been busted since. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org