Ubuntu-18.04-gnome-spice boot file ubuntu.sh problem

[fadams]

Ubuntu-18.04-gnome-spice boot file ubuntu.sh problem

[yanbx]

Cannot get file status (stat) for "/root/.xauthority \r" : No file or directory is available

[yanbx]

[yanbx]

file /root/.Xauthority does not exist

[fadams]

I can't say for sure, but it sounds to me like you are trying to run the `ubuntu.sh" via sudo or similar.

If you have successfully built the ubuntu-gnome:18.04 from the https://github.com/fadams/docker-gui/tree/master/9-virtual-desktops/ubuntu-18.04-gnome directory (and TB I'd try to get that working before trying the VGL or SPICE versions) then if you are in that directory you should just do

./ubuntu.sh

You shouldn't run any of the launch scripts in the book as sudo. If you need sudo for Docker because you aren't in the docker group still run the script without sudo - the point of the docker-command.sh and $DOCKER_COMMAND is to work out whether to do docker run or sudo docker run

If you try to run the actual script as sudo you will mess up other permissions.

The docker-xauth.sh stuff creates a .docker.Xauthority based on your user's Xauthority but creates a wildcard hostname so it can authenticate to your host's X Server from the container. If you look in that docker-xauth.sh script you should see what it is doing.

This question is making me all the more convinced that you really need to go back to basics as you are trying to run before you can walk.

What I'd advise you to do is to start way back with the examples in https://github.com/fadams/docker-gui/tree/master/4-local-applications/simple-X11-applications once you have got them working (and understand why they are doing what they are doing) then you will be in a better position to understand some of the more complex examples.

As I keep saying the book explains a lot of the reasoning behind a lot of the approaches taken in quite a bit of detail and many of the examples build upon what was learned in previous examples.

In simple terms the containers bind-mount the host's X11 unix domain socket and create a .docker.Xauthority based upon the .Xauthority that ges placed in the user's home directory

[yanbx]

Hello, excuse me
I am currently using the directory \ simple-x11-applications \x11-apps, but every sh in the execution cannot be executed without that file or directory. What is the error?

[yanbx]

[fadams]

So to be clear:
You have cloned the repository and in a shell you have done a cd to something like

<path to where you cloned the repo>/docker-gui/4-local-applications/simple-X11-applications/x11-apps/

in that directory build one of the Docker images - there are two Dockerfiles, one for stretch another for bullseye. When the image is built run

./xlogoV4.sh

in that same directory

If you are seeing something like

 /root/.Xauthority does not exist

it suggests to me that you are trying to run things via sudo or as root - do not do that

Also check that you have a .Xauthority file in your home directory - you should have one there created by your Display manager when your desktop gets launched. Please tell me that you are running these examples on an X11 desktop and not a headless server.....

You are running an X11 desktop? If you are running on Wayland you might have more issues. The examples should run in XWayland but it has been a while since I've tried that.

[yanbx]

Yes, I am preparing to run an X11 on Docker. The system environment of the desktop program's underlying host is Centos7.0. At present, the error /root/

1. Install the Xauth module in the underlying host environment. 2. Log in with Xauth, but this file still does not exist
   My current environment is like this. Due to the network security problems of the company, he has created an account for me to log into the host, such as yanbx/123456. He does not have the root permission.
   At present, this user also performs relevant Docker operations through sudo in Docker environment
   How can I deal with this situation?

[yanbx]

I think I know my mistake, I want to ask you when you execute your program directory level is the level of your project?
In particular, where do I put the script directory under bin?
I query the find / | grep ". Xauthority "you found by this command. / root/this is the right address He carried out in my sh directory
How to deal with this, please?

[yanbx]

[yanbx]

[fadams]

From the above you are doing everything as root *that is a really really bad idea"
You really need to log into your system as a regular unprivileged user and clone the repo as an unprivileged user you are asking for trouble if you install everything as root and run everything as root - not just from the perspective of this repo it's just a really bad idea in general.

I don't have any more time ATM I think you really need to go back to basics a bit.

You say "At present, this user also performs relevant Docker operations through sudo in Docker environment" yes but that doesn't mean run the script as sudo.

You need to log in as a non privileged user (i.e. as your normal user account not root) you need to clone the repo somewhare off your home directory as you so it will have something like yanbx:yanbx owner/group probably with a uid/gid something like 1000:1000

These questions really aren't issues with this repo they are really more issues with how you have set up your environment.

[yanbx]

Okay, I'll adjust it accordingly

[yanbx]

When was xserver-xspice-passwd created?

[fadams]

OK, so I keep telling you to go back to basics.

You shouldn't be asking this question until you've managed to get the basic X11 applications working and you've spent some time understanding how containers are connecting to your desktop environment's X Server.

To answer that question it was created when you ran one of the xserver-xspice launch scripts - if you don't already have one saved then running those scripts will ask you to enter a password that you'd like the SPICE server to use to authenticate the SPICE connection. If you read the scripts there's a block with a comment that says "Create password if required"

Also to be clear and as I said in a previous reply the way the SPICE password is created here is insecure and really only intended as a starting point and SPICE's authentication methods in general aren't especially strong, but that's beyond the scope of this repo.

[yanbx]

Hello, I have to bother you for now. According to you, I'm currently executing the 9-1 Xephyr Chapter 9 use cases under this example
After executing xephyr.sh, there was no error, but according to what you said in the article, I do not understand how to appear the desktop?Can you explain that?

[yanbx]

Running xephyr.sh will launch a nested, resizeable, X Server that
defaults to listening for inbound X11 connections on display :1. To
change the display number of the nested X Server use the
NESTED_DISPLAY environment variable, e.g.:
NESTED_DISPLAY=: 10 . /xephyr. sh
which will launch Xephyr listening on display :10.

[yanbx]

I didn't quite understand this sentence in the book

[fadams]

Running the Xephyr example will only run Xephyr. Xephyr is simply a nested X Server.

It sounds like you are expecting a desktop to appear?

What you quoted:

Running xephyr.sh will launch a nested, resizeable, X Server that
defaults to listening for inbound X11 connections on display :1. To
change the display number of the nested X Server use the
NESTED_DISPLAY environment variable, e.g.:
NESTED_DISPLAY=: 10 . /xephyr. sh
which will launch Xephyr listening on display :10.

Is exactly what should happen. Are you seeing a window appear that is simply a black window that appears to do nothing much else?

If so that's exactly what should happen as that example is, as I say just the Xephyr nested X Server. You can launch X11 applications to it by setting their DISPLAY to :1 but it's really just an illustration. If you aren't seeing a black window then you haven't sorted the issues out from the other day with respect to your desktop environment. Did you get the simple X11 apps like Xlogo running?

The virtual desktop examples use Xephyr, but they launch their own Xephyr as part of their init process. How they work is that they are running systemd and systemd starts the Display Manager launching an X Server, which in their case is Xephyr.

I do keep repeating that I really think that you should start from the beginning and move on one you understand what is actually happening at each stage. You seem to be jumping right ahead into things without necessarily understanding what they are trying to achieve. In all honesty I do believe that starting closer to the beginning, getting that working, understanding what is actually going on then moving on will be a far better strategy for understanding this.

[yanbx]

I've run the XLogo example and I've done it through display and before when the example was set up when I executed the sh script it would display itself or it would display itself through display=
However, after executing the Xephyr sh in your chapter, no error was reported, and the interface was not automatically displayed. SH was executed in display mode, and still no error was reported and no response was made.

[yanbx]

So ask how to start the example of your chapter?For example, in the next two chapters, I ran the sh file and just mirrored it up but nothing happened.I want to see the final desktop effect how to start?Can you take a look at it?

[yanbx]

I have a problem with the chapter 6 Xlog instance, but I am running into a problem in Firefox
"Your profiles can not be loading it may be missing or inacessable"
Do you need to set up the Firefox configuration?

[yanbx]

Hello, today I have run a simple graphics program into a complex desktop program to understand the details. Now I want to learn the desktop. The problem I have encountered is the one I mentioned above, the successful execution of mirror bulid script sh does not report an error, but I do not know where to look at this desktop.Can you explain it for me?I ran Xephyr debian-bullseye-lxde ubuntu-18.04-gnome,

[yanbx]

”NESTED_DISPLAY=: 10 . /xephyr. sh “

I want to make sure that this is not the case. I want to re-understand the article by dispaly or SSH remote xhost based on the previous example of X11 boot.

[yanbx]

The next few use cases in Chapter 9 are started in the same way, right?

[yanbx]

The xserver - xspice, xserver xspice - HTML 5 this two instances running result shows that a firefox not just a matter of visit http://ip:port connection, mirror started successfully,
The other problem with this project is that I am using normal users to execute sh script and Firefox browser to launch a problem report
Your firfox profile can not be loaded

[fadams]

I'm afraid that you are overwhelming me with posts there are too many questions about too many different aspects to understand very much at all.

So say "I've run the XLogo example and I've done it through display and before when the example was set up when I executed the sh script it would display itself or it would display itself through display=
However, after executing the Xephyr sh in your chapter, no error was reported, and the interface was not automatically displayed. SH was executed in display mode, and still no error was reported and no response was made."

I'm struggling to understand by this - I don't really understand what you mean by "I've done it through display"

So let's assume that you have cloned the repo *as user yanbx" into /home/yanbx so you have a directory path that begins /home/yanbx/docker-gui

Having done that now cd to /home/yanbx/docker-gui/4-local-applications/simple-X11-applications/x11-apps

In there you should see a Dockerfile a Dockerfile-bullseye and several scripts. If you build either of the Dockerfiles e.g.

docker build -t x11-apps .

you should end up with an image called x11-apps

If you then do:

./xlogoV4.sh

You should see the X Logo appear. I have literally done just that (obviously using my own path to the docker-gui repo) and have a nice X Logo appearing on my local desktop.

You say "However, after executing the Xephyr sh in your chapter, no error was reported, and the interface was not automatically displayed. SH was executed in display mode, and still no error was reported and no response was made." again I have no clue what you mean by "display mode"

So do cd to /home/yanbx/docker-gui/9-virtual-desktops/Xephyr again you will see a few Dockerfiles. If I cd to my own path and do

docker build -t xephyr .

That will build the xephyr image from an ubuntu:18.04 base image. If I then do:

./xephyr.sh

In that directory I get a black window appear saying "Xephyr on :1.0 (ctrl+shift grabs mouse and keyboard)"

The Xephyr window doesn't do anything especially interesting in of itself. The point of having that section in the book is actually to illustrate the importance of having a Window Manager.

If you are seeing a boring black window, what it is is a nested X server listening on DISPLAY :1

To be clear that Xephyr doesn't launch a desktop in of itself it is simply an example of a nested X Server.

If you are not seeing a black window appear then TBH I have no clue what your issue is.

You are logging on to a local workstation with its own display and graphics card right?

Re "I have a problem with the chapter 6 Xlog instance, but I am running into a problem in Firefox" I don't know what you mean at all here. Xlog?

I have no idea about ""Your profiles can not be loading it may be missing or inacessable" Do you need to set up the Firefox configuration?"

To be *absolutely clear" pretty much all of the examples in that section use the containerised firefox from https://github.com/fadams/docker-gui/tree/master/5-more-complex-applications/browsers/firefox if you haven't built that image nothing will work as expected and to be honest I'd strongly recommend making sure that you can build that image and run it locally.

In all honesty I still think you seem to be jumping ahead

Re "The xserver - xspice, xserver xspice - HTML 5 this two instances running result shows that a firefox not just a matter of visit http://ip:port connection, mirror started successfully," I'm sorry I'm not at all sure what that is saying. I don't really know what you mean by "two instances running"

If that has run correctly - do you mean xserver-xspice or one of the xserver-xspice-eyeos ones? When that launches it first runs an X Server that is also a SPICE server and it then launches the containerised Firefox. If you launch that on your local machine all you should need to do is to launch another browser and navigate to localhost:5800 if you are successful then you should see Firefox running in whatever browser you used to navigate to localhost:5800

I definitely suspect something odd with your desktop,or that you are not in fact sitting in front of a local workstation with its own graphics card.

You mention "I ran Xephyr debian-bullseye-lxde ubuntu-18.04-gnome" why? Nowhere in the book does it say anything about doing that. It's pretty clear that the Xephyr example is simply illustrating why it's important to have a Display Manager.

I really strongly advise you to read *from the beginning" and work your way through the examples somewhat in order. Honestly, you really will learn an awful lot more and understand more about what you are doing. I don't think jumping about all over the place is helping anyone.

However let's do this:
cd to /home/yanbx/docker-gui/9-virtual-desktops/debian-bullseye-lxde
or wherever the actual path you have takes you
In there is a Dockerfile and a script called debian.sh

If you do

docker build -t debian-lxde:bullseye .

After a while hopefully you should successfully end up with an image called debian-lxde:bullseye

Once that image is built all you should need to do is (from that directory)

./debian.sh

It will ask you to enter a password and a confirmation, then after a short period it will launch a Display Manager window where you enter the password you have just created. After that it will launch the Desktop.

As I said in a previous response those images are quite sophisticated. When they launch they run systemd in the container and systemd will launch the Display Manager which causes the X Server to be launched - in this case that X Server is Xephyr but the Xephyr in this case is part of the debian-lxde:bullseye image.

I've literally done just what I said above on my machine and have had a containerised Debian desktop appear with no problems whatsoever, so there is definitely something strange about your environment if you don't see a desktop appear.

I say again if you are not sitting at a local workstation with a local graphics card looking at a local display you are going to be having a bad day. To be clear the point of many of the examples is to be able to remote things, but it's a lot easier to understand the process if you start of locally.

If you are sitting at a local workstation with a local graphics card looking at a local display then I'm struggling to understand your environment. You definitely need to be logged in as a normal (non root) user to a normal graphical desktop for these examples to make much sense. Do you have a /home/yanbx/.Xauthority file (or whatever your home directory is)? You are definitely running X11 rather than Wayland right?

[fadams]

Again you are bombarding me with too much information to try and make sense of.

The fundamental point is this "At present, I am using Xshell remote tool to remote a Linux environment computer on my own computer, and all instances are carried out in the remote Linux environment."

So stop right there. That is the first time you mentioned anything about running in that type of remote environment. That is exactly why I have said several times on this thread that you really, really need to go right back to basics and work through the examples getting the earlier examples working before moving on.

"Do you mean that I have to operate locally" not necessarily, but the work in this repo generally makes an assumption that you are sitting in front of a local machine. That not being the case will certainly have quite a profound impact and makes it a lot harder to figure out what is going on.

BTW I can't see any of the images you've tried to upload

You say "Secondly, on the issue of the firefox, my current situation is firefox mirror, on the case and run sh scripts I think no problem, is to use ordinary users after running the script Pop-up firefox, firefox popup tooltip, prompt error is I the problem yesterday, appear this problem, I will try after the xserver - xspice up"

I don't really understand what you are trying to say here but "I will try after the xserver - xspice up" but have you not been listening. I have said several times that many of the remote examples from chapter 6 and 8 depend on the Firefox image from chapter 5. If you haven't built that image then they aren't going to work.

The other day you said "but I am running into a problem in Firefox"Your profiles can not be loading it may be missing or inacessable"". I can't say for sure, but I'm fairly sure that is down to a permission error. You showed in an earlier post that you had previously been running everything as root. That is a really bad idea. Hopefully now you have stopped doing that, but when you originally cloned the repo did you do it as root? If you did and did not subsequently delete that and clone it again as user yanbx then the directories in the repo will still likely be owned by root. Now most of the examples will actually create a "home" directory, so if you cd to docker-gui/5-more-complex-applications/browsers/firefox build the image and run the example that will try to create a directory based on your username in the docker-gui/5-more-complex-applications/browsers/firefox directory - that's what the lines

mkdir -p $(id -un)/.config/pulse
mkdir -p $(id -un)/.config/dconf

at the start of the script do. If the repo was cloned as root and you are now running as yanbx then you won't have write permissions in that directory. So if you still have lots of things owned by root hanging around you need to sort that out before you do much else.

I'm not at all familiar with Xshell.

Is your local machine a Windows machine? You said the other day you were running CentOS. So are you accessing the remote CentOS machine purely via ssh and a terminal or is Xshell running up a complete Gnome Desktop for your CentOS and forwarding that (I'm specifically talking about your own environment) 'cause I'm not clear about how your X Server is set up.

also what do you get if you run

echo $DISPLAY

[yanbx]

So let me just summarize what I've done now, so that you can see that I'm in a difficult situation right now.
At present, I started to run the examples from Chapter 4 to the last chapter. By now, I have basically mastered the content of your mirror and started the mirror according to your introduction. Next, I will send you the screenshots of the problems encountered and explain them to you.
At present, there are two problems:
First of all, the first xserver - xspice - eyeos, xserver xspice - HTML 5 xserver - xspice tells the story of the three case spice protocol I run up The result is the pop-up firefox but no content Fire fox according to the home page is a container words didn't see what results related, the trouble to explain
The second problem is that this is critical
The last chapter in Ubuntu-18.04 - Gnome-Spice is now up and running and I have seen the desktop results accordingly
But using a browser to access http://172.18.90.172:5800 run results as shown in figure:

[yanbx]

[yanbx]

Then I used Spice to set the password in the admin desk, but the browser did not respond. The article said that I could use the client or the browser can access me. There may be some problems with the client's link

[yanbx]

Sorry, I just got your reply, could you please answer me according to my new question?Trouble because the morning's problem has been partially solved

[yanbx]

[yanbx]

[yanbx]

Please take a closer look at my screenshot

[fadams]

I specifically asked you to stop bombarding me with responses you've just posted six separate messages. If you keep doing that I'm going to stop replying. I also said that I can't see any of the images you've tried to upload so asking me "Please take a closer look at my screenshot" is pointless as all I see is "Uploading image.png"

I am not actually clear what you have actually tried and what you have skipped as you seem desperate to jump into xserver - xspice - eyeos.

Wen you ran the x11-apps example did you run

./xlogoV4.sh

or did you need to do anything else to get it working?

Have you tried to run things like the gnome-calculator example? Have you successfully got that working?

Have you tried to get any of the examples in chapter 5 working? Have you actually got the Firefox example running?

You say "First of all, the first xserver - xspice - eyeos, xserver xspice - HTML 5 xserver - xspice tells the story of the three case spice protocol I run up The result is the pop-up firefox but no content Fire fox according to the home page is a container words didn't see what results related, the trouble to explain" I'm afraid that I don't understand what you are saying here.

I really don't understand what you mean by "he story of the three case spice protocol I run up". You say "The result is the pop-up firefox but no content" so let me try to understand that. Are you saying that when you run that it basically starts up OK and then when you point your browser to <address of SPICE server>:5800 you see the containerised Firefox but that containerised Firefox can't see a network. Or are you saying you can't actually connect from the browser to the SPICE server. It's really important to understand the distinction.

In both of those cases it's likely to be a network issue. Are you trying all of this from within your CentOS desktop or are you trying to connect to the SPICE/webserver from a browser on your local Windows machine. If the latter then I'd suggest first try to connect from a browser hosted on your CentOS desktop.

When xserver-xspice-eyeos runs it will be running on your CentOS server bound to its local IP and exposing port 5800 and 5900. Now depending on what the local network looks like for that CentOS machine you should be able to to see the server from within the 192.168.. network but it should not be visible on any externally routable IP, believe me you really do not want that - as I said previously it is simply using Websockify as a simple HTTP web server and the SPICE password mechanism is fairly insecure too. If you want to expose it to a browser on your local windows machine two options are 1. set up an SSH tunnel 2. Run a "proper" and properly secured Web server on the remote (your CentOS) host and use that to proxy to the less secure SPICE HTTP server. But to be clear if you can access the X Spice server from a browser that is running on the private network of the host running the X Spice server then that is where the scope of the book stops and I'm not about to spend time explaining how to set up an SSH tunnel and definitely not how to secure a Web server. The content from Chapter 6 on X11 forwarding should help get you started setting up an SSH tunnel, though that is tunnelling X11 not HTTP, but the principal is essentially the same.

[yanbx]

I am sorry. Maybe I am anxious to solve the problem and want you to understand my problem, so I sent many records. I will not do this in the future.
Directly to the last question, my goal is to want to use your last ubuntu 18.04 - gnome - spice example, using the spice links to the client You like to do a good job of the spice that mirror the desktop through agreement, at present this example of mirror has been build success, and can start up in local desktop, desktop to see what you said as a result, but I use spice client to use Through the spice: / / 172.16.18.90:5900 remote link This link,Access with a browser is your book said http://172.16.18.90:5800 this way is not good only to see the user name and password input interface after the password is still displayed below the black screen.
Do you understand the above questions?I look forward to your patient reply and help to solve this problem. OK, now I can't analyze why the link is not available. It is estimated that there is something wrong with our installation agreement.，Could you please help us to analyze the reasons that we have to solve by ourselves? Thank you very much

[fadams]

On "my goal is to want to use your last ubuntu 18.04 - gnome - spice example" so can I check what you have so far then, you say "at present this example of mirror has been build success" so by that am I correct in my understanding that you have successfully built the image ubuntu-gnome-spice:18.04 and as it uses ubuntu-gnome-vgl:18.04 as a base image you have also successfully built that and because that uses ubuntu-gnome:18.04 you have also successfully built that.

That is my interpretation of what you are saying there, but it would be good to confirm.

You say and can start up in local desktop, desktop to see what you said as a result so that is sounding positive, but to be explicit about it are you saying that if you are in the directory docker-gui/11-remote-virtual-desktops/spice/ubuntu-18.04-gnome-spice and have run

./ubuntu.sh

What you see appearing is a Display Manager and if you enter your password into the Display Manager's "password" box then you get a Gnome Desktop appearing. Is all of that correct?

If that is correct I think that the issue then might be that the Display Manager doesn't play especially well with multiple logins.

As I say if you have been successful enough to get the Display Manager appear then do not log on just yet. Instead try connecting via the SPICE client or browser (and as I say before I mean a browser or SPICE client from your CentOS Desktop to rule out network issues).

If you connect from a browser on port 5800 you should first see a simple window that says flexVDI on the top left. If you see that you have successfully connected to the SPICE HTML5 client, if not then I'm still not sure what's going on. But if you do see the flexVDI window if you then enter the SPICE password you should then see a Display Manager appear in a browser. If you see that then you are winning and you should be able to use that to log on to the Gnome Desktop.

[yanbx]

Hello, reply to you under you confirm the problem, after I performed locally at present, I have seen the Gnome desktop By user name and password has already entered into the desktop, the browser flexDI also saw you said that kind of simple interface, I try to enter a password click on the browser enter, below is still a black screen, did not show the Gnome desktop login, and on other machines I use spice client to connect, has been in the links, in the long run will be prompted to link is not on the graphic display.Could you please analyze where you see the problem, is it the display manager you said?

[fadams]

So you are saying when you launch

./ubuntu.sh

You are seeing the Display Manager (in other words the graphical login window for the Desktop) and when you enter you password the Gnome Desktop appears. Correct?

So the issue is purely with the SPICE login

So if you already have the containerised Gnome Desktop running having started it from your CentOS desktop then you are not going to be able to log into that via SPICE (or HTML5) that's what I meant by "the Display Manager doesn't play especially well with multiple logins" so if you are already seeing that Gnome Desktop power it down as in use the normal Gnome method to quite out of the (containerised) desktop. When you do that make sure the container has stopped.

Now run

./ubuntu.sh

again but do not then enter your password and login to the Desktop

By " the browser flexDI also saw you said that kind of simple interface" so I think you are saying here that you are seeing the flexVDI window? If you are - and have not already logged in to the Desktop via the Display Manager that initially popped up - then when you enter the SPICE password into the flexVDI password box then you should see the Display Manager (login window) appear in your browser - if you do then you should be able to then log in to the desktop.

If you already have the desktop running because you logged into it from the initial Display Manager then you won't be able to log in via SPICE.

[yanbx]

I don't quite understand what you mean. I don't know if I understand it correctly. Do you mean that the desktop pops up locally at present
, first directly through the client or browser login, right?
When I opened the browser and saw the Flexdi password input, it still showed a black screen on the browser. When I used the client, it showed the connection directly. After a long time, it indicated that the link could not be connected to the graphical interface
Can say clearly, I clearly the problem is to start again after the sh local have seen a GONE desktop xeythr way, then I will open a browser to try the spice links, is the phenomenon interface can see, I said the password after, according to the browser to see through the client also not make the above said problem

[fadams]

You say that you have got that example working without the SPICE part correct?
So then you do

./ubuntu.sh

You should get a window pop up after a few seconds that is basically a login window. Are you seeing that?

If you are seeing that then normally you'd enter the password you created for the containerised desktop into that login window and once you do you should see the containerised Gnome Desktop.

What I am trying to say is that after the Ubuntu orange "login window" appears do not then log on. Instead try the SPICE connection.

[yanbx]

You mean, after execution, I input the Spice username and password Settings, and the desktop pops up to display the login screen, I don't want to login at this time, right?
At this time, I should use the browser or the client to link the desktop remotely, to see the effect, right?Is that what you mean?

[fadams]

I mean:
Step 1. run

./ubuntu.sh

Step 2. wait until the login window appears - please confirm that you are seeing the orange Ubuntu login window
Step 3. Connect via SPICE client or browser. If you want to use SPICE then do not at this point log in using the login window that first appeared
Step 4. From your SPICE client or the Browser flexVDI enter the SPICE password
Step 5. You should then see a new login window, say in your browser
Step 6. Use that one to log in to the Desktop

If you are not seeing the orange Ubuntu login window I mention at step 2 then I'm not clear how you were previously able to log in directly to the desktop.

[yanbx]

OK, I understand your steps, but I want to make sure that I am using the Spice client of the remote-viewer. It is directly input the remote link address, but there is no place to input the user name and password.This is a little bit questionable.And the browser interface, there is only a place to enter a password, there is no user name, can you explain this?I checked the use of remote-viewer. The first step was to enter the remote link and click the link. At this time, he was still in the connection and could not get the user name and password.Do I understand you correctly?

[fadams]

By remote viewer you mean the Remote Viewer SPICE client application on your CentOS desktop right?

So firstly you haven't confirmed that you are indeed seeing the orange Ubuntu login screen please confirm that you are!!!!

If you are seeing this then when you start up Remote Viewer the Connection Address should look something like:

spice://172.16.18.90:5900

though you should be able to use

spice://localhost:5900

If you are running it on the same host where your container is running (and I'd recommend starting out by doing that to rule out any network related issues)

When you run that Remote Viewer should pop up a window that says "Authentication is required for the SPICE connection to..." and there should be a password entry box.

[fadams]

You say "And the browser interface, there is only a place to enter a password, there is no user name, can you explain this?" Are you talking about the flexVDI browser interface? or the display manager (the orange login) interface. For the case of the flexVDI the password there is the SPICE password. For the Display Manager you should actually see the username above the password entry box. You don't need to enter a username to log on to the desktop because the Display Manager is configured in a way that if there is only a single user it doesn't ask for the user name. You can actually configure LightDM to always ask for a username too but you'd need to modify the Dockerfile to change that.

[yanbx]

You may understand wrong, because you remind me in the morning, don't use xshell remote tools to perform sh script, so I go directly to deploy application it server directly to the server on the execution of sh scripts see pop-up orange desktop, just I didn't press you said don't log in, I saw the desktop after I log in.
Then, going back to my own machine and using remote-view to connect to the deployment server remotely via Spice, can you see if the problem is caused by the orange screen that pops up when I log in directly on the server native?Your program does not allow the same user to log in in different places, right?

I just want to confirm with you about the user name and password problem, because when I used remote-view to connect to the deployed server, I kept reminding you that the user name and password had not been entered in the connection.I just want to confirm whether my problem is related to my logging on the orange desktop.Please confirm the cause of my problem, and I will follow your steps to verify it again tomorrow

I have seen your reply that the browser will prompt me to input the user name and password, but I did not have this prompt. It is directly the interface IP host password you mentioned, and the three filling boxes are shown in black below the page

[fadams]

To be honest I'm having a hard time following your logic. And you are not answering anything I'm asking for. I have asked you several times to confirm whether you are seeing the orange Ubuntu login window after running

./ubuntu.sh

And you have not replied.

Are you or are you not seeing the login screen. I think you are but you need to be more explicit and answer these things.

You say " you said don't log in, I saw the desktop after I log in" if you have reached a point where you are actually seeing the full Gnome Desktop then I have to assume that you have seen the login screen and entered the desktop's password. But as I keep on saying if you have logged in to the Gnome Desktop then at that point you will not be able to connect via SPICE.

You have to let the orange login window appear but as I keep saying do not log in to it Once that window appears then try Remote Viewer or the HTML client. But are they being run on the same host as the Ubuntu container. You have to try connecting from there first to try and rule out any network questions.

I'm afraid I have other things to do now so I won't be responding for a while.

[yanbx]

Maybe the translation is not good, sorry, I replied in the above,
I run the script, and I see the orange desktop on my running application server.

Hello, I'm sorry. Maybe there is something wrong with my translation software. I would like to add that I have seen the complete GONE desktop, and I basically understand what you mean

It's okay. You go first.
I have a question. I'll leave you a message here

thank you

[fadams]

OK I really have to go in a minute but if you" see the orange desktop on my running application server" then on the same server where you launched then try running a browser and navigating to localhost:5800 or whatever the Docker IP is.

By "`see the orange desktop on my running application server" do you mean the ubuntu login window or the full ubuntu desktop. If you mean the full desktop it means you've already logged in. I keep saying you need to do a SPICE connection once the lofin window has appeared bu before you try to log in to it.

You should see the flexVDI, initially with a black screen below. The flexVDI has boxes that say Host:, Port: and Password.

In the Password box you need to enter the SPICE password (you should have set that up when you first ran the ./ubuntu.sh once you enter that, if everything goes well then you should see an Ubuntu login window appear in your browser.

If you see that then log in with the Desktop password.

Those are precisely the steps that I do from my workstation.

I really do have to go now.

[yanbx]

If you are busy, you busy first, your own business is important
I tried it by myself according to your steps, but today I did see that the interface was still black after entering the password and clicking Enter.
Remote tool connections are also poor.That's why I'm so anxious to confirm with you today.Currently I only see X11 running on that server on my own machine with an orange desktop.
Thank you for your reply in your busy schedule. Tomorrow I will try again according to your steps. If there is any problem tomorrow, I will leave a message to you.

After looking at your steps,
Step 5. You should then see a new login window, say in your browser
I don't have a login window here, but I will directly display the Flexdi website. Could you please help me analyze this after you finish your work?

If you are deploying this desktop environment, do you have a log file for the SPICE protocol that we can use to find errors ourselves

[fadams]

I'm honestly at a loss to understand what is happening in your environment. On the positive side if you definitely have built the ubuntu-gnome-spice:18.04 and have actually previously managed to log in to the Gnome Desktop via the the main login window then I think you are most of the way there, but I'm really not sure what is missing. It is strange too because it sounds like you are also seeing the flexVDI window and you'd only see that if the container was serving the HTML5.

One thing you could maybe try.....

So there are actually two different passwords that get created.

in your ubuntu-18.04-gnome-spice directory you should see a "home" directory - that should be a directory with the same name as your username. You should also see a file etc.tar.gz. Those are created when you first run

./ubuntu.sh

If you delete those then run

./ubuntu.sh

again, then be very careful when following the next instructions.

It will first ask

Enter new UNIX password: 
Retype new UNIX password: 

That is the password for the containerised Ubuntu desktop

once you have entered that and confirmed it asks

Enter the new value, or press ENTER for the default
	Full Name []: 
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] y

There you can largely just hit enter except for answering y to the last question.

After all that it will then say

Creating SPICE password
Enter password: 

That is asking you to enter the SPICE password that you want to use later to log in

I mention trying that step again in case you ended up not correctly setting the SPICE password. What I have noticed is that if I enter an incorrect SPICE password the flexVDI doesn't give any error message it just stays blank.

What actually happens if you use the Remote Viewer client? In my case if I use

spice://localhost:5900

as Connection Address and click Connect I get an "Authentication required" popup asking for a password and if I enter my SPICE password I see the orange Ubuntu login window and if I type an incorrect SPICE password I see a popup "Unable to authenticate" - which I'd expect to see.

If you do not see an "Authentication required" popup from Remote Viewer what exactly do you see? If I enter the wrong address I just see "Connecting to server" then the window disappears and is replaced by "Unable to connect to the graphic server spice://...." but to be clear that only happens if I enter the incorrect address and if I enter the correct address/port of my SPICE sever it asks for my SPICE password and when I enter it I then get the orange ubuntu login window.

So in short start from scratch to make sure that you have definitely entered the desktop and SPICE passwords that you want to use and from the Remote Viewer Spice client if you are not seeing the password pop up then carefully check the address - and make sure that you use port 5900 from Remote Viewer and 5800 from the browser client.

I'm afraid that I have no more ideas at present.

[yanbx]

Hello, I have seen your reply. I probably did the same with the steps. Today I will try it again.
I sorted out my problems yesterday according to the steps you said yesterday. There are some problems that I didn't show up in your steps
The steps of my success, I will mark success at the end, please see the results of the steps as follows:
Step 1. Run./ubuntu.sh-- Successfully

Step 2.
"Wait until the login window appears - please confirm that you are seeing the orange Ubuntu login window".
---- Success, I see the automatic pop-up desktop window

Step 3. Connect via SPICE client or browser. If you want to use SPICE then do not at this point log in using the login window that first appeared
This step explains that the orange window appears, but I logged in.

Step 4. From your SPICE client or the Browser flexVDI enter the SPICE password
-- Successfully operated, enter the password in the browser

Step 5. You should then see a new login window, say in your browse

------ There is a problem with this step. After entering the password, there is no login window under the browser. Using the remote client, you just enter the connection, but it always prompts you to know the error in the connection.I also often look at the browser debugging interface (F12), found that there is a script error, I do not know you have it?

step 6
Use that one to log in to the Desktop
Because of the above steps, the sixth step is not reached

I wonder if the problem with Step3 is causing it?

[yanbx]

Thank you very much indeed. I have succeeded in following your steps and have seen the results I want.
My SPICE protocol was invalidated after I logged in to the orange desktop.
So why do we fail to connect remotely because I log in to the orange interface?Does your approach support a password-less approach?Is it possible to remove the VDI input box on the browser?

[fadams]

So to be clear. From your reply above you appear to be saying that when you followed the steps precisely you were indeed able to successfully connect via one of the SPICE clients - please confirm that is correct and thus you have achieved the main goal.

Re "So why do we fail to connect remotely because I log in to the orange interface?". It is quite complicated to explain, especially if you are not really quite familiar with how Linux inits into a Graphical Desktop.

I have previously tried to summarise what is going on but to repeat that: If you look at the ubuntu.sh script you should see that it runs /sbin/init this is quite profound because these containers are basically doing exactly what a non-containerised Desktop would do once the kernel has booted. Running /sbin/init causes systemd to run in the container, which starts all of the regular Linux services and eventually inits to the graphical Desktop. The systemd service that does this starts a Display Manager - in this case LightDM and that in turn will launch an X Server and a greeter process, in this case slick-greeter.

In a regular environment this would launch the workstation's "real" X Server, but I have to configure the Display Manager to use a different X Server (in this case Xephyr) instead of Xorg. If you look at the ubuntu-gnome:18.04 you can see some of that.

There are many subtleties. It's possible to launch X Servers in many ways, but one of the reasons I went with the approach of following the normal graphical startup as closely as possible is because in desktop environments there is generally a reliance on a number of services like systemd, D-bus, logind, polkit without those whilst you might see a desktop appear it might be broken in a number of ways like no PulseAudio daemon or with no polkit there would be no privilege elevation mechanism so things like being able to "power down" the desktop from the graphical environment wouldn't work. As I said previously there is a lot going on in those containers. I've tried to explain in the book but it gets quite complicated.

With systemd there is the concept of "seats" and again initing in the way I have "tricks" systemd into thinking there is a valid seat0 which in turn allows logind and polkitd to start.

It gets even more complicated when adding SPICE into the mix. The approach I took was to take advantage of LightDM's built-in mechanism to launch VNC servers. If you look at the bottom of ubuntu-gnome-spice:18.04 there is a comment that says "Script to launch Xspice "pretending" to be Xvnc" which is explained in more detail in the book.

So that's the background of some of the reasons I wanted to launch the Display Manager (login window). The things is though, and why you observed the issue you saw, is that Display Managers only allow a single login - if you think about it remember it's the thing you normally see when you log in at your workstation.

For the sort of use case that you actually want to employ. You are actually probably better off building the Dockerfile-no-xephyr image in the ubuntu-18.04-gnome-spice. I was reluctant to mention this previously but the way that works is that rather than the Display Manager launching Xephyr instead of Xorg then using some "magic" to pretend the SPICE server is a VNC server instead when we init to the graphical startup the Display Manager actually launches Xspice directly.

The reason I didn't mention this before is that at that point nothing is visible, but you can then log in via the SPICE/HTML5. I wanted to be clear that you were actually able to log in via SPICE before I mentioned it because it would have been impossible for me to work out what was going on in your environment without having got to the point of seeing the login screen.

On "Does your approach support a password-less approach?" well yes it is possible to configure SPICE to use different authentication approaches including no authentication. To do that though you would need read that section in the book in more detail, understand how ubuntu-gnome-spice:18.04 Dockerfile works and create your own version.

I'm not going to do that for you, as I said previously the point of this repo is to be educational and give people enough knowledge to move forward on their own it is not about providing fully production-ready solutions. That said if you look at the bottom of the Dockerfile you should see the Xspice startup which looks like

Xspice $1 -ac -noreset -nolisten tcp --port 5902 --password $(cat /tmp/lightdm/.xserver-xspice-passwd) --vdagent --video-codecs ${SPICE_VIDEO_CODECS:-gstreamer:h264;gstreamer:vp8;gstreamer:mjpeg;spice:mjpeg} --deferred-fps 60

You'd need to read the Xspice documentation but it might be simply a case of removing the --password $(cat /tmp/lightdm/.xserver-xspice-passwd) but to be clear it has been a while since I looked at those documents.

Re "Is it possible to remove the VDI input box on the browser?" again I'm not going to do that for you. It is possible though, yes. Once you have worked out how to get SPICE to connect without a password I think it'd be possible to "hide" that part of the flexVDI UI. You'd really need to spend a bit of time working out how it works though. In ubuntu-gnome-spice:18.04 I already do some modifications. TBH it has been a while since I created that Dockerfile and I had to modify the HTML client to add host/port/password entry UI. You could always try deleting from line 60 to line 69 in the Dockerfile which would remove my "patches" to the spice-web-client that may do what you want but if it doesn't you are on your own.

[fadams]

I've just looked at http://manpages.org/xspice and the --disable-ticketing is what you need to tell Xspice to not require a client password. So replace --password $(cat /tmp/lightdm/.xserver-xspice-passwd) with --disable-ticketing.

However I've just done a quick experiment after rebuilding the image.

If you connect with Remote Viewer it will launch straight to the Ubuntu Display Manager without asking for a SPICE password, however the HTML5 flexVDI actually still requires something in the entry box.

[fadams]

OK I'm feeling generous today. I've just done a bit of "hacking around" with the ubuntu-gnome-spice:18.04 Dockerfile.

The following has modified the Xspice to use --disable-ticketing and I've made some modifications to some of the original Web client patches to make it hide the flexVDI login and go straight to the Display Manager.

A strong caveat to this is that it is just a quick hack and there are more elegant ways to achieve what you want, but you'd need to look at the Web App in more detail. The main Javascript for this part is in /usr/local/bin/spice-web-client/run.js. One of the things I do is add document.getElementById("login").style.display = "none";in the init() function, but making the html default to that style is probably nicer than changing it on document.ready.

Compare what I have below with the original and it should hopefully be fairly obvious what I've done.

I've already spent far too long on this thread.

FROM ubuntu-gnome-vgl:18.04

RUN apt-get update && DEBIAN_FRONTEND=noninteractive \
    apt-get install -y --no-install-recommends \
    python-numpy python-setuptools \
    xserver-xspice-hwe-18.04 spice-vdagent && \
    # LightDM complains if Xvnc isn't present, even if
    # [VNCServer] config. specifies a command= option.
    ln -snf /usr/bin/Xspice /usr/bin/Xvnc && \
    mkdir /tmp/audio-fifo && \
    chmod 1777 /tmp/audio-fifo && \
    # Modify PulseAudio daemon config to support SPICE.
    echo "load-module module-pipe-sink file=/tmp/audio-fifo/playback.fifo format=s16 rate=48000 channels=2" >> /etc/pulse/default.pa && \
    # The Xspice --auto option is convenient, but if
    # we have large display resolutions Xspice will
    # crash with OOM. We need to modify the config in
    # /etc/X11/spiceqxl.xorg.conf, which in turn means
    # we can't use --auto and that exposes a bug in
    # /usr/bin/Xspice where temp_dir isn't initialised.
    sed -i 's/if args.auto:/temp_dir = ""\nif args.auto:/' /usr/bin/Xspice && \
    # Set buffers to handle larger resolutions.
    sed -i 's/#Option "NumHeads" "4"/Option "NumHeads" "1"/' /etc/X11/spiceqxl.xorg.conf && \
    sed -i 's/#Option "SurfaceBufferSize" "128"/Option "SurfaceBufferSize" "512"/' /etc/X11/spiceqxl.xorg.conf && \
    sed -i 's/#Option "CommandBufferSize" "128"/Option "CommandBufferSize" "512"/' /etc/X11/spiceqxl.xorg.conf && \
    sed -i 's/#Option "FrameBufferSize" "16"/Option "FrameBufferSize" "32"/' /etc/X11/spiceqxl.xorg.conf && \
    # If not using --auto the --audio-fifo-dir flag
    # seems to be ignored, so we need to use the config.
    sed -i 's/#Option "SpicePlaybackFIFODir" "\/tmp\/"/Option "SpicePlaybackFIFODir" "\/tmp\/audio-fifo"/' /etc/X11/spiceqxl.xorg.conf && \
    # Download websockify and flexVDI fork of
    # eyeos spice-web-client.
    WS_VERSION=0.9.0 && \
    SPICE=3.1.0 && \
    curl -sSL https://github.com/novnc/websockify/archive/v${WS_VERSION}.tar.gz | tar -xzv -C /usr/local/bin && \
    curl -sSL https://github.com/flexVDI/spice-web-client/archive/${SPICE}.tar.gz | tar -xzv -C /usr/local/bin && \
    cd /usr/local/bin/websockify-${WS_VERSION} && \
    python setup.py install && \
    mv /usr/local/bin/spice-web-client-${SPICE} \
       /usr/local/bin/spice-web-client && \
    # Tweak spice-web-client to add a basic
    # host/port/password entry UI.
    sed -i 's/document.location.port/port/g' \
        /usr/local/bin/spice-web-client/lib/utils.js && \
    sed -i 's/<div class="float-right">/<div class="float-right">\n\n                <label for="host">Host: <\/label><input type="text" id="host" value=""\/><label for="port"> Port: <\/label><input type="text" id="port" value=""\/><label for="password"> Password: <\/label><input type="password" id="password" value="" onkeyup="checkIfEnterPressed(event)"\/>\n/g' /usr/local/bin/spice-web-client/index.html && \
    sed -i 's/$(document).ready(start);/$(document).ready(init);/g' /usr/local/bin/spice-web-client/run.js && \
    sed -i 's/translate();//g' \
        /usr/local/bin/spice-web-client/run.js && \
    sed -i 's/function start ()/\nfunction init () {\n	translate();\n    document.getElementById("login").style.display = "none";\n    document.getElementById("showclientid").style.display = "none";\n    document.getElementById("uploadfile").style.display = "none";\n    document.getElementById("host").value = document.location.hostname;\n    document.getElementById("port").value = document.location.port;start();\n}\n\nfunction checkIfEnterPressed (event) {\n    if (event.keyCode === 13) {\n        start();\n    }\n}\nfunction start ()/g' /usr/local/bin/spice-web-client/run.js && \
    #sed -i "s/data\['spice_address'\] || ''/document.getElementById('host').value/g" /usr/local/bin/spice-web-client/run.js && \
    sed -i "s/data\['spice_address'\] || ''/document.location.hostname/g" /usr/local/bin/spice-web-client/run.js && \
    #sed -i "s/data\['spice_port'\] || 0/document.getElementById('port').value/g" /usr/local/bin/spice-web-client/run.js && \
    sed -i "s/data\['spice_port'\] || 0/document.location.port/g" /usr/local/bin/spice-web-client/run.js && \
    #sed -i "s/data\['spice_password'\] || ''/document.getElementById('password').value/g" /usr/local/bin/spice-web-client/run.js && \
    sed -i "s/data\['spice_password'\] || ''/'fakepassword'/g" /usr/local/bin/spice-web-client/run.js && \
    # Create systemd service to launch html5 SPICE
    echo '[Unit]\nDescription=HTML5 SPICE WebSocket proxy\nAfter=syslog.target network.target\n\n[Service]\nUser=lightdm\nType=simple\nExecStart=/usr/local/bin/websockify 5800 localhost:5900 --web /usr/local/bin/spice-web-client\nTimeoutStopSec=20\nKillMode=process\nRestart=always\nRestartSec=2\n\n[Install]\nWantedBy=multi-user.target\nAlias=websocket.service\n' > /lib/systemd/system/websocket.service && \
    ln -snf /lib/systemd/system/websocket.service \
       /etc/systemd/system/multi-user.target.wants/websocket.service && \
    # Script to launch Xspice "pretending" to be Xvnc
    echo '#!/bin/bash\nif [ "$1" == ":2" ]; then\n  Xspice $1 -ac -noreset -nolisten tcp --port 5902 --disable-ticketing --vdagent --video-codecs ${SPICE_VIDEO_CODECS:-gstreamer:h264;gstreamer:vp8;gstreamer:mjpeg;spice:mjpeg} --deferred-fps 60 > /dev/null &\n  XSPICE_PID=$!\n  cleanup() {\n    kill -TERM $XSPICE_PID\n  }\n  trap cleanup SIGINT SIGTERM EXIT\n  sleep 0.25\n  kill -USR1 $PPID\nfi\nsocat - TCP:localhost:5902' > /usr/bin/Xspice-lightdm-wrapper && \
    chmod +x /usr/bin/Xspice-lightdm-wrapper && \
    echo '[LightDM]\nminimum-display-number=1\n[Seat:*]\nuser-session=ubuntu-xorg\nxserver-command=/usr/bin/Xephyr-lightdm-wrapper\n[VNCServer]\nenabled=true\ncommand=Xspice-lightdm-wrapper' > /etc/lightdm/lightdm.conf.d/70-ubuntu.conf

VOLUME /tmp/audio-fifo

[yanbx]

Thank you very much for your reply, and thank you for replying to my question today. I am also a novice in the field of virtualization and just transferred to this technical field.
Before have been engaged in Java and micro service architecture related work, I was a newcomer, the field have to learn something, thank you for your reply, so some days patient may still after a lot of trouble to you, but is virtualization technology stack, and then to do some research on my own, may have begun to introduction, ask the question may be, to achieve a certain goal in China, information about the spice the domain architecture is very little, so check to your this article, I was very excited, may be tempted to put this thing up and running, continue to study the implementation of the inside and the main technical points, company here just want to do this,Time is also very tight, just want to build your things quickly, and then in-depth study of some technical points, so the question may be very presumptuous, I think I should say so, so please forgive me.
I like making friends very much. It is really a kind of fate to meet you on GitHub. Can we keep in touch and become friends in the future?Some technical things, it is convenient to discuss with you.

[fadams]

This is a link to the main SPICE documentation https://www.spice-space.org/documentation.html
The flexVDI spice-web-client page is here https://github.com/flexVDI/spice-web-client, which is a fork of
The eyeos spice-web-client here https://github.com/eyeos/spice-web-client