Whey the applications running in VNC shows up in host instead of in client? - vnc

When I connect to the vnc server with vncviewer, I get a stranger thing: I can see the desktop of gnome or xfce4 and their menus, every GUI application I launch doesn't show up. At first I thought the applications failed to run. Then I found the applications appeared in the vnc server's screen! My settings are:
vncserver: tigervncserver on Debian 10
the content of ~/.vnc/xstartup:
unset SESSION_MANAGER
exec /usr/bin/xfce4-session &
vnc client: xtightvncviewer on Debian 8
I use the client to connect a vncserver on Ubuntu 18, it works well. Do you have any suggestion to debug this issue? Thanks.

On my Ubuntu/XFCE enviroment, on the host device, my DISPLAY env variable is set to :1.0 and not :0 , so when I started a vnc on :1, the applications would pop up on the host display. Just start the vncserver on :2 or above, and the problem will not occur.

Related

Run a gui based application on a remote Linux machine using telnet

I need to run a gui-based application on a remote PC to which I am connected over telnet. The remote PC runs Linux Ubuntu 18.04
To figure out the screen, I run the following command on the remote machine:
echo $DISPLAY
which gave me :1 as result.
Then I run the program on the remote machine from my client (over telnet) using:
DISPLAY=:1 application_name
The program started correctly (since, in addition to the GUI, it prints some things on the command line) but the GUI didn't show up. But, if I run my app directly on the remote machine, everything is fine.
As a test, I tried to run firefox browser on an another machine (always through telnet) with the following command:
DISPLAY=:0 firefox
and it worked. Note: on the other machine the output of echo $DISPLAY was :0. Furthermore, I could not test my app on the second machine.
It seems that there are different settings between the two machines since what I'm trying to do works on a machine, but not on the other.
Do you have any idea of what type of setting should I check?
Did you try to run your application on the first remote machine but with DISPLAY=:0 instead of :1?
What is the error message you get from application when you started application in the first case ("DISPLAY=:1 app_name").

Virtualbox- Cant access to VM when running in Headless mode

I installed an ubuntu server with openssh server on a virtualbox and it works fine. when I start it from GUI I can access it via ssh and Putty, there is no problem. When I start it In headless mode from virtualbox gui there is no problem either.
the problem is, when I run it using VBoxManage startvm "Ubuntu" --type headless it returns a message saying that the Ubuntu is running in headless mode but when I want to connect via ssh to it, its not accessable. my host os is windows 10 and the ubuntu server name is "Ubuntu" and os version is ubuntu-16.04.2-server-x64 and I installed openssh-server and dkms as it described here: https://www.htpcbeginner.com/install-virtualbox-guest-additions-on-ubuntu-debian/
when I work in GUI evrything is fine but I want to run it from windows command line to save some time.
It looks like that the command line vm "Ubuntu" is diffrent from GUI vm "Ubuntu". But I have only one vm on virtualbox. in gui there is one and in cmd vboxmanage list vms returns one vm. so what is the problem?
I also added virtualbox guest addition from Device menu in virtualbox GUI
Edit:
I saw another command : VBoxHeadless --startvm "Ubuntu" its not working either. but unlike the last command it does not show message that Ubuntu is Running. actually it will stuck in execution and the cursor turns to a blinking dash for ever. so I should close the cmd to get ride of it.
I checked something. If I use NAT on network adapter and port forwarding, it works even from cmd. but when using bridge to avoid using port forwarding its not working. in the bridge mode there is connection and ping is working but cant ssh to the Ubuntu.
I found the solution. the solution is I should keep the NAT interface as primary as is by default and make a secondary interface in virtualbox gui settings. the secondary interface should be Host-only. then by using this question and its answer I added an interface to guest Ubuntu to a static address. now I can ssh to the static Ip address even if I run the vm from command line, and there is no need to port forwarding.

Connecting to Localhost on Mac from Another Mac: Websocket Issues?

I have a node.js web app running on http://localhost:3000/ on my iMac. I am able to log on to that web app from Chrome on my MacBook using the Wi-Fi IP address of my iMac (found in System Preferences->Network) and the port my web app is running on:
http://10.0.0.37:3000
When using this technique, is there any reason why a websocket would fail in calling a service on a distant server?
Thanks in advance to any thoughts!
It turns out nothing was wrong with websockets. The camera on my MacBook was deactivated for some reason, and that was causing errors from the service I was accessing. I was able to reactivate the camera using instructions from this page:
Quit all apps that you are trying to use with the Camera > Open
Terminal (find in /Applications/Utilities) > copy and paste the
following command then hit the Enter key > Type administrator password
hit Enter.
sudo killall VDCAssistant
if still at the terminal, issue the following command:
sudo killall AppleCameraAssistant

Ubuntu : Turn on and login into a remote computer

I want to run some application on a remote computer. I am able to turn it on using wakeonlan but how can I log into it and start the application using terminal?
ssh yourusername#computernameorip
ProgramNameToExecute

vim on virtualbox startup is slow when connected via putty

I am running freebsd on virtualbox (with virtualbox-ose-additions installed in freebsd).
the vim startup is very quick (instantaneous) in the vbox console window.
but when connected via putty from the host machine, the vim takes about 6-7 seconds to startup.
the connection from putty is via ssh authentication.
and the host to vbox connection is NAT+portforwarding.
This has happened to me when I had X11 Forwarding turned on in Putty but didn't have an X Server running (always the case when using Putty from (I assume) Windows unless you're running specific software like Cygwin or Xming to have a local X Server).
Alternately, your shell startup scripts may set the DISPLAY environment variable improperly when you're ssh'd in instead of using a console.

Resources