tightvnc black screen server Fedora 13 , client windows XP - client

I get a black screen with the above setup. I have tried RealVNC and TigerVNC clients too on windows with the same result.
Any ideas?
Thanks

It's possible your VNC server is running, but there is nothing running in it; no window manager, no desktop environment (GNOME), etc.
That probably means you ran the VNC server directly without using some of the friendly wrapper scripts such as vncserver. For example, if you run Xtightvnc directly, that's what you'll get.
For example, on Ubuntu I usually start a VNC session (or port 5901) like this which starts the VNC/X-server and the normal desktop environment:
vncserver -geometry 1024x768 :1
On Ubuntu vncserver is a link to tightvncserver. If you don't have vncserver on Fedora 13 then try tightvncserver.

Related

Can I develop with VS Code in containers on a remote host running Windows/WSL2?

Original Post
I have a Windows workstation with WSL2 and Docker installed that I am able to use for container based development in VS Code. I would like to be able to develop inside the containers on this system remotely. I am able to SSH directly into the WSL2 environment on the workstation and am able to start the docker daemon without logging directly into Windows by creating a Task to start the daemon automatically as described here: https://stackoverflow.com/a/59467740/10692741
However when I try to access Docker on the remote machine by following this guide: https://code.visualstudio.com/docs/remote/containers-advanced#_developing-inside-a-container-on-a-remote-docker-host, I get the following error:
error during connect: Get http://docker/v1.24/version: net/http: HTTP/1.x transport connection broken: malformed HTTP status code "\x00c\x00o\x00m\x00m\x00a\x00n\x00d\x00"
I have also tried connecting via a SSH tunnel as outlined here: https://code.visualstudio.com/docs/remote/troubleshooting#_using-an-ssh-tunnel-to-connect-to-a-remote-docker-host and am unable to connect to Docker as well.
Has anyone had success with a setup like this? Or is this not supported due to limitations with Docker on Windows, WSL2, and/or Windows OpenSSH implementation?
Update: 2021-01-21
When I SSH into the Windows machine remotely, I am able to see the docker containers in the VS Code extension. I am able to start them, stop them, and enter into them with the shell. However, when I try to attach VS Code I get same error shown above.
Things that may have possibly affected this over the past couple days:
Adding SSH keys on my local machine to the ssh-agent via ssh-add /my/key
Exposing Docker daemon on tcp://localhost:2375 without TLS on the remote Windows machine
Also I want to note that the I've tried using Windows, Mac, and Linux as the local machine. With Mac and Linux I am able to open a remote session into the Windows machine, but from the Windows local machine I am able to SSH into the remote Windows machine but cannot open a remote connection in VS Code for some reason.
Ok, I was able to get this working using the port/socket forwarding technique. For sake of clarity, I'll use:
local development workstation, local workstation, or just workstation to indicate the computer from which we wish to use VSCode to access Docker containers on ...
the remote Docker host, remote, or just Docker host
Sanity check -- Do you have Docker Desktop installed on both systems? On the local development workstation, you can skip the WSL2 integration, but you'll at least need the client tools, since the VSCode extension uses them.
Steps I took:
I already had Docker with WSL2 integration set up on my main system (which for the purposes of this exercise, became my remote Docker host), along with VSCode, so I knew everything was working there. It sounds like that was your starting point as well.
On another system on the same network (accessed with RDP to make it simple), I already had VSCode installed as well, with the Remote Development Extension Pack. I also have WSL on that system, but only a v1 instance there. Not that WSL on the workstation should be a factor at all for the purposes of this exercise.
I installed Docker Desktop for Windows on that local development workstation.
I also installed the Docker extension for VSCode, since I didn't yet have it on the local development workstation.
On the workstation, I was not yet set up to SSH from PowerShell into my WSL Ubuntu distro on the remote. From PowerShell on the workstation, I generated an ECDSA key (per this and other documents) and added the public key to my authorized_keys on the the remote.
On the workstation, I started the OpenSSH Authentication Service and added the newly created key to the agent (in PowerShell) with ssh-agent add ~\.ssh\id_ecdsa.
I logged out of the workstation and back in so that the path changes were picked up for the Docker desktop install.
I was then able to ssh from Powershell on the local to Ubuntu/WSL on the remote with the port forwarding. Since I'm using the Windows 10 OpenSSH server as a jumphost to my WSL SSH servers, my command looked slightly different (with a -o "ProxyCommand ... mainly), but overall the structure is the same as the one listed in the "SSH Tunnel" doc you linked in your question.
On the remote (manually, not through any integration from the local), I did a basic docker run -it --rm Ubuntu and left it open.
On the local, from PowerShell, I set the DOCKER_HOST environment variable via [System.Environment]::SetEnvironmentVariable("DOCKER_HOST","tcp://localhost:23750").
I was then able to see the remote container using docker ps on the local. I could also docker exec -it containername bash into it remotely.
Of course, the above two steps aren't needed in the long term for VSCode, they were just part of my process to make sure everything was up and running (since, as you might expect, I did have several points at which I failed during this process).
So with that working, it was a simple matter in VSCode to change the Docker extension's DOCKER_HOST setting to tcp://localhost:23750. And voila, I could see all images on the remote as well as attach to them from VSCode.
Other thing(s) to check
I'll add to this list if we find additional reasons why it might not be working, but for now:
You mention that you are starting the Docker Desktop daemon automatically at startup via Task Manager, but you don't mention anything about the WSL2 instance. However, since you are able to ssh into it, I assume you have a way to bring it up as well? My experience has been that, unless the owning user is logged in, WSL terminates any instances after a few seconds, even if a service is running. There's a workaround, I believe, that I can dust off if this is a problem.

Docker - Replacement for `dockerd` on Mac

I wanted to start the docker daemon with an open TCP address like this: docker daemon -H tcp://0.0.0.0:2375, but the terminal suggested that I use dockerd instead, which is apparently not a program that comes with the Docker Client for mac. Is there a way I can either
A - get some form of dockerd on my mac machine.
B - get around the use of dockerd by some other method.
?
Install socat command: brew install socat
Choose a port: (in the example 8099)
Run: socat -d -d TCP-L:8099,fork UNIX:/var/run/docker.sock
and then use tcp://localhost:8099 as API URL
works for me, hope this helps
Finally I found the config of mac docker like dockerd.
Click the docker icon in the menu bar, preferences, advanced
get around the use of dockerd by some other method. (2016)
Note that in 2022, you can go without dockerd/Docker Desktop entirely.
See Batuhan Apaydin's article "A modern toolkit to start working with container images on macOS that meets your needs without requiring a Docker Daemon or even Docker Desktop".
It uses lima+nerdctl
The nerdctl tool is designed as a drop-in replacement for the Docker client
And Lima is a hypervisor that launches Linux virtual machines with automatic file sharing, port forwarding, and containerd.
The name of lima comes from an abbreviation of the first two capital letters of LInux MAchines.
The design of Lima is similar to WSL2, but Lima focuses on macOS as the primary target host.
Lima uses QEMU, which is a generic and open source machine emulator and virtualizer, as a hypervisor under the hood to achieve the virtualization thing.
Lima can also work with other container engines such as Podman and even for non-container applications.
By default, when lima launches a VM, it runs buildkitd and containerd in a rootless way and also downloads necessary client tooling around them such as buildctl, nerdctl.
Everything will be set up for us. So, all that’s left is building, pulling, and running containers
For buildkit, Batuhan proposes developer-guy/buildkit-machine
buildkit-machine allows you to make buildkitd daemon accessible in your macOS environment.
To do so, it uses lima, which is a Linux subsystem for macOS, under the hood.
lima spins up a VM that runs buildkitd daemon in a rootless way which means that sock file of the buildkitd daemon is now be able to accessible from /run/user/<USERID>/buildkit/buildkitd.
So: no more Docker Desktop / dockerd, and use container in a rootless mode!
For more, see Bret Fisher's video "Free Docker Desktop Alternatives: DevOps and Docker Live Show (Ep 156)" (Jan. 2022)
I have found a workaround for this in the official forum
https://forums.docker.com/t/using-pycharm-docker-plugin-with-docker-beta/8617/9
$socat TCP-LISTEN:2376,reuseaddr,fork UNIX-CLIENT:/var/run/docker.sock
That workaround opens port 2376 to the world... as TLS isn't enabled, this is a bad idea as anyone on the same network can hijack your docker daemon
It is not supported to run dockerd on Mac. From this issue:
I think on Darwin it should never suggest to run dockerd. The daemon runs in a Linux virtual machine, so you do not need to (and cannot) run it manually.
If you want to do any specific configuration on mac, you might have already installed Docker Desktop. Docker desktop supports configuration using UserInterface shown below in the screenshot.

Build a full Ubuntu desktop docker image

I want to build a full version of Ubuntu 14 desktop as the base image for gui applications, I know how to build on the Ubuntu desktop version by the debootstrap, as described in https://docs.docker.com/articles/baseimages/, but that is a minimal Linux version and some GUI application cannot run perfectly, because there are some basic components missing, such as a font family, so I want the full control of a basic image, thanks!
fcwu/docker-ubuntu-vnc-desktop
https://github.com/fcwu/docker-ubuntu-vnc-desktop provides a convenient setup:
docker run --name ubvnc -p 6080:80 -p 5900:5900 dorowu/ubuntu-desktop-lxde-vnc:bionic
Then either:
visit: http://127.0.0.1:6080/#/ which runs a noVNC more limited JavaScript VNC client
run:
sudo apt-get install tigervnc-viewer
xtigervncviewer :5900
Then inside vinagre, you might want to go into full screen mode to be able to see the full desktop
I also tried vinagre, but it was much laggier when scrolling Firefox on YouTube.
To quit just kill docker on the terminal. And to restart the machine
docker start ubvnc
and then reconnect with VNC. Then to quit the machine:
docker stop ubvnc
You have to wait a few seconds for the VNC server on the guest to start before you can connect.
Chromium won't start from the menu. If you try to launch it from the command line it explains why:
Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
Firefox does not care however.
TODO: no audio. --device /dev/snd did not help:
How to play sound in a docker container
https://forums.docker.com/t/how-to-get-sound/36527
https://github.com/fcwu/docker-ubuntu-vnc-desktop/issues/49
See also:
Can you run GUI applications in a Docker container?
How to open Ubuntu GUI inside a Docker image
Tested on Ubuntu 19.04 host, fcwu/docker-ubuntu-vnc-desktop, dorowu/ubuntu-desktop-lxde-vnc image id: 70516b87e92d.
I don't see the benefits of it, but impossible n'est pas français (impossible isn't French).
Docker Desktop is a way that will give you an X11 server to connect on using SSH.
This Dockerfile creates a docker image and once it's executed it creates a container that runs X11 and SSH services. The ssh is used to forward X11 and provide you encrypted data communication between the docker container and your local machine.

Start Windows GUI program in the PuTTY shell

I created an SSH session into my localhost through PuTTY. I am running OpenBSD server on the localhost which is a Windows 7 machine. The login was successful. Now I want to start programs in the PuTTY shell for example notepad.exe. I changed the directory to c:\windows\system32. The command start notepad runs without error but I don't see any window.
Is the notepad running in the background without a windows. If yes, how to make the window visible??
Yes, it's quite likely the Notepad is run in an invisible Windows session on the server. Note that it does not make a difference in this case that the server is the local machine.
If you hoped for the window to appear on the "local" machine magically, you are out of luck.
Generally, it's possible to run a GUI application on remote machine and see the GUI locally. On Unix it's quite common. Typically X Window is used for that.
But Windows GUI applications cannot be "tunneled" via SSH session to a local machine.

X11vnc server exits when I close tightVNC viewer

I followed this blog to set up a VNC connection from my Windows 8 laptop to my BeagleBone Black.
Digital Diner: Quick hint for Beaglebone Black user
It works well except for one problem: the X11VNC server on the Beagle Bone Black exits when I close the TightVNC Viewer on my laptop. I have to connect a remote terminal to the BBB using PuTTY and run the command given in the blog in order to reconnect.
Any suggestions on how to keep the server from exiting when I close the TightVNC viewer connection on my laptop? Is there a way to always have the X11vnc server running on the Beagle Bone Black so I can connect anytime?
I found the answer here: BeagleBone Black Google Group.
The key is to add -forever to the end of the command to start the X11vnc server.
x11vnc -bg -o %HOME/.x11vnc.log.%VNCDISPLAY -auth /var/run/gdm/auth-for-gdm*/database -display :0 - forever - nopw
I also added this command to the start up applications. System --> Preferences --> Startup Applications

Resources