[SOLVED] Accessing another Kubuntu 9.10 just as you'd be sitting there

[Passiday]

Hello,

I am looking for a reliable way how to connect from Kubuntu 9.10 another Kubuntu 9.10 PC.

That other PC might be used at that time by another person, but I'd like to access the installed software and files on it, without disturbing the user physically using that PC. I understand that things like clicking on audio file and expecting the sound coming out of speakers at my end would require some advanced tinkering, so I don't ask for that. All I want is to see my normal plasma workspace, as if I had logged on that PC, sitting there.
I kind of don't like the idea of using VNC for this purpose (if that's even possible to use it transparently, while there is active X session of another user in progress), because the content it receives is basically stream of graphics. I'd prefer to connect to the other PC via remote X session, but I have no idea how to do it properly.

Thanks,

Passiday

[doctordruidphd]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

To see you whole plasma desktop, I think you will have to use krdc. That's going to slow the remote PC down quite a bit, though.

If you can live with one application at a time, then ssh -X username@machine should do it.
(note the capital 'X'). It will bring up a terminal from which you can launch an X application. I don't know what would happen if you tried to launch plasma-desktop. Give it a try, I guess.

[THHHB]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

There is also x11vnc (http://www.karlrunge.com/x11vnc/), but this gives you control over things like the mousepointer and will disturb the person using it. For your requirements I'd suggest the fish-protocol(for access from everywhere) or nfs(from LAN) for graphic file transfer using dolphin/konqueror and ssh -X for starting programs.

[GreyGeek]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

Unless your PC is connected to your ISP's modem directly, without going through a wireless or other router, your dchp deamon gives you an address which cannot be seen outside your local network ... i.e., all of those solutions are for PCs on the same local network (192.*.*.*), or for PCs which have IP addresses not in the 10.*.*.* or 192.*.*.*.

So, if you want to control a PC that is on your 192.*.*.* local network these work fine If your PC is behind a wireless router and your target remote PC is behind ANOTHER wireless router they won't be able to connect. Even going to grc.com's shieldsup to determine your IP address on the Internet side of your cable modem, and that or your remote target, and using those IP addresses won't work because those addresses are for the modem, not your PC.

The solution? Unplug from the wireless router the cable that goes from the modem to the wireless router, and plug it into the eth port on your PC. (Yes, that prevents other laptops using your wireless from getting an Internet connection). Then, the IP address of your modem is your IP address.

[Passiday]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

To see you whole plasma desktop, I think you will have to use krdc.

This option is not ok, because it totally hijacks the active session of the user sitting at that PC. At least, as I tried to use it - on the target PC site I launched Krfb (Desktop Sharing), initiated the invite, got the connection parameters, went to the client PC, used KRDC to connect to the target, then the target PC popped up warning that someone is attempting to connect, clicked "Accept" there, and then I was able to use that PC remotely (the mouse cursor was invisible though), but all the actions were visible on the target PC's screen, not even mentioning that the user sitting by that PC could not continue with his business. So, that is not what I call transparent connection.

If you can live with one application at a time, then ssh -X username@machine should do it.
(note the capital 'X'). It will bring up a terminal from which you can launch an X application. I don't know what would happen if you tried to launch plasma-desktop. Give it a try, I guess.

This is exactly what I was looking for. Most of the time using one app is just fine. However, enjoying my special layout and settings of plasma desktop on the target PC would be very nice. So I went on and launched the plasma-desktop, and funny things happened. The remotely launched plasma desktop loaded in fine, so I saw all my desktop widgets, the KMenu showed items of the remote PC, I could run software from there, etc. However the Alt-F2 launch shortcut was still operating on local PC. The taskbar showed only the apps that were loaded on the local PC. So it was kind of confusing. I even had no decent means how to get rid of that remote plasma desktop session: hitting Ctrl+C in the console where I launched it had no effect, typing exit in attempt to end the ssh session had no effect. KMenu-logout had no any effect whatsoever. Event Ctrl+Esc and killing the plasma-desktop process did not give me back my local plasma-desktop. Finally I did Alt+F2 abd launched plasma-desktop, that kind of gave me back my local environment, but still left the unfunctional remote desktop kind of "below" my local desktop. Weird stuff.
I hope it is possible to launch that remote plasma desktop on some kind of parallel session (or whatever how its called), and switch between those sessions with whatever means (ie, keyboard shortcut, select some menu with mouse, console command). But anyway those local and remote desktops should not be mixed up.

[doctordruidphd]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

Hmm, interesting.
Were you logged into the local PC with the same account you ssh'd in with? If so, it probably confused kde, since it is trying to store in session information in the same places. Try logging into the local PC as a different user than what you are using for ssh, and see if it keeps things straight that way.

I honestly didn't think it would work at all. Pleasant surprise.

[Passiday]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

Well, the user name is exactly the same, however I am not sure if the OS then really confuses them as the same. After all, these are different accounts set up on different computers, is the Linuxs' user system really so weak so that it would confuse those user accounts just because they happen to have similar login names?

Today I thought I might switch to another console session (if that's the right name for that feature that you can switch between several environments via Ctrl+Alt+F1-F7), do the ssh -X to my target PC there (which of course worked fine), and then launch plasma-desktop there. But typing and entering just "plasma-desktop" had no any effect whatsoever. I guess I have to start X windows and launch the plasma-desktop when X is running, but I have no idea how to make this happen from the bare console, and also how to properly shut that session down when I'm finished.

Passiday

[dibl]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

is the Linuxs' user system really so weak so that it would confuse those user accounts just because they happen to have similar login names?

Come on -- have you ever in your life found a local area network that permits multiple users to use the same login name? Now that would be weak!

Shhheeeeeeeeeeeesh!

[doctordruidphd]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

Well, the user name is exactly the same

It's not an issue of weakness on the OS. Think about what you are doing here: You have a plasma workspace open on a system, that stores configuration files, state information about what it is doing, etc, under that username. If you open another plasma workspace as the same user, then there's going to be some collision between the information being stored about each session. I doubt that plasma has been designed to avoid that -- no doubt it could be designed that way, but my guess is it isn't. It has nothing to do with limitations of the OS. When you ssh into a machine, as far as that machine is concerned, you are logged in as a user on that system, not any other. If I am logged in as 'mickeymouse' on this computer, and I ssh into it from another compuet as 'mickeymouse', then I am logged in as the same user, albeit with a different process tree. The confusion arises when kde stores and reads information about its session characteristics in a disk file in the user's home directory.
It really doesn't matter who you are logged in as on the system you are ssh-ing with, as that is never seen by the host. You could be running an entirely different OS, and still use ssh to get into the system. Years ago, when I ran a bunch of linux workstations, I had a windows 3.1 PC with x server software on it, so I could get into all the unix systems from one box. Worked like a charm (but then Win 3.1 was one h... of a better OS than windows is now, my opinion only).
What I am saying rather long-windedly is that I don't think kde is set up to support multiple plasma sessions by the same user at the same time.
You might try, as an experiment, to log into your host system with one account, and ssh into it with another, and see how well it works. That would put all of the speculation to rest.

Edit: another thing to try might be to ssh and run kdm, as opposed to plasma-desktop, and see what happens.

[Passiday]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

I am sorry I have triggered some sheeeeshing from experts here. I think there's miscommunication here, and perhaps I should not use rhetoric attack, commenting the weakness of Linux' users system, which should have never been taken at face value.

Ok, so here's the setup:
1st PC, called A. There is one user account "Alice", and theres an active KDE session with that account.
2nd PC, called B. There are two user accounts: one with login name "Alice", another with login name "Bob".

Now, my comment about different accounts with similar login names was (I still think sane) assumption that Alice@A is something completely different than Alice@B.

What I am trying to do, is this:
I log in A with Alice@A, and then, using whatever method I am trying to find in this thread, connect to B, where Bob has an active session. Bob is browsing the Web, working with Open Office, and he must not be disturbed. I want to start remote session with B, logged on as Alice@B. So, sitting at A, I'd be able switch between two fully functional KDE sessions: Alice@A and Alice@B, while Bob@B is not disturbed at all (well, he might notice some slowdown, when Alice@B takes some share of processor/memory/disc resources, but that's not the point).

Of course, I understand that there might be wonders, if I, while sitting at A, would try to connect and have remote KDE session with Bob@B. That indeed could cause some unpredictable influence on the experience on both Bob@B sessions.

As I was saying, it seems that I am very close at getting what I am looking for. I just need to learn how to launch two parallel X sessions on the same PC - one with local user account, but other - sshed remote login. I would be very grateful if someone helps getting there.

Thanks,

Passiday

[Snowhog]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

Running multiple X sessions is of course, completely doable, using Ctrl+Alt+F1 through F6 ttys to start another X session. This might be the approach you want to pursue?

[doctordruidphd]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

Now, my comment about different accounts with similar login names was (I still think sane) assumption that Alice@A is something completely different than Alice@B.

Correct. A knows nothing about accounts on B, and vv.

I log in A with Alice@A, and then, using whatever method I am trying to find in this thread, connect to B, where Bob has an active session. Bob is browsing the Web, working with Open Office, and he must not be disturbed. I want to start remote session with B, logged on as Alice@B. So, sitting at A, I'd be able switch between two fully functional KDE sessions: Alice@A and Alice@B, while Bob@B is not disturbed at all (well, he might notice some slowdown, when Alice@B takes some share of processor/memory/disc resources, but that's not the point).

That should work. Alice@B and Bob@B are two different accounts, with two different uids and two different home directories. Are you saying that is the arrangement that did not work? If so, I'm not sure why. B should be able to keep two different users apart from each other, no matter where or how they are logged in.

Of course, I understand that there might be wonders, if I, while sitting at A, would try to connect and have remote KDE session with Bob@B. That indeed could cause some unpredictable influence on the experience on both Bob@B sessions.

Right. If you tried to connect from A with ssh -X Bob@B while Bob is running an X session on B, I would expect all sorts of problems trying to run the desktop in both sessions.

[Passiday]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

That should work. Alice@B and Bob@B are two different accounts, with two different uids and two different home directories. Are you saying that is the arrangement that did not work? If so, I'm not sure why.

I am saying I don't know how to make it work. When I activate tty1 (Ctrl+Alt+F1), and console with login prompt opens in the text mode. I log in there as Alice@A, to get to the command prompt. Then I type ssh -X Alice@B, and the prompt turns into Alice@B:~$. However, I am still left with that same text-mode console. I guess I must then type some command in order to run the graphic shell, and/or some command to run the plasma desktop in the graphic shell. I don't know if that graphic X session would then be loaded in tty1 or somewhere above tty7 (where I suppose the slots for graphic shells are reserved, I don't know if the graphic shell can be even loaded in tty1-tty6). And, when I am finished, I need to know how such remote session is properly terminated. Maybe that would be just standard KMenu-Logout.

So basically what I am lacking perhaps is some set of console commands that would load/unload the graphics shell, and run the application of choice (ie, plasma-desktop) when the graphics shell is loaded.

Passiday

[doctordruidphd]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

OK. By default, k/ubuntu is set up to run its X sessions in CTRL-ALT-F7. If there is a way to get x to run in consoles 1-6, I don't know it (but would like to). So one possibility is after starting your login with tty1, type plasma-desktop, then do a CTRL -ALT-F7 to get the x session. The other option would be to log in normally with your graphics session, open Konsole, and start your ssh session from there.

[Passiday]

Re: Accessing another Kubuntu 9.10 just as you'd be sitting there

If I open console in existing session, ssh to the remote, and type startx -- :2, this is what I get:

startx -- :2


X.Org X Server 1.6.4
Release Date: 2009-9-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-23-server i686 Ubuntu
Current Operating System: Linux Garludo 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 i686
Kernel command line: root=UUID=2727e0c8-4e85-4dc5-a1df-d8a57facd88d ro quiet splash
Build Date: 04 March 2010 09:56:47AM
xorg-server 2:1.6.4-2ubuntu4.2 (buildd@)
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.2.log", Time: Sat Apr 3 23:33:46 2010
(==) Using config file: "/etc/X11/xorg.conf"
Setting master
[config/dbus] couldn't take over org.x.config: org.freedesktop.DBus.Error.AccessDenied (Connection ":1.213" is not allowed to own the service "org.x.config.display2" due to security policies in the configuration file)
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server

And then it stops. No X session is loaded in tty9 (nor in tty8 or anywhere else). Might it be connected with that error - "[config/dbus] couldn't take over org.x.config: org.freedesktop.DBus.Error.AccessDenied"?

Update:
Well, it turned out that this has successfully started the 2nd X session _on_ the remote PC - when I went to check how it looks (it's in another room), the screen was loaded with Alice@B session, tty9 activated. So, the Bob@B would have been not only disturbed, but also could be presented with Alice@B session, with possibility to tamper with it. So obviously I did it the wrong way - started the new X session not on A, but on B (well, I am confused about the terminology here - the graphic interface to the remote session should be accessible in tty9 on A, but I don't know if that means that "the session is run on B", or A, or both. I don't know if someone with proper rights sitting at B could see or interfere with the Alice@B session.).