Closed tedm closed 9 years ago
I've been experimenting with a vnc target that can be used instead of X11 and Xephyr, allowing you to access the chroot's desktop through an offline VNC client. It sort of works, but I need to figure out how to launch a new Chromium tab from the shell. If you can figure that out, I can put the final pieces together and put it up for testing.
When I run the VNC client you linked to, it says it doesn't support ARM yet. Also, what VNC server are you running in the chroot? I installed vino, but I think it needs gnome.
To run a command from the shell, write the extension app called "tab_chroot" then
write a gcc program like this that can execute from the command line:
int main(void) { int ret = system("~/Downloads/tab_chroot");
return(0); }
I don't know how to write tab extensions yet, but I think drinkcat does ;)
Did you see the message in the unmount chroot issues thread that the two fingers on touchpad on ARM ummounts, and exits the sigkill loop?
Right, that's probably gated on PNaCl. I'm not aware of any other offline VNC apps though.
The vncserver is vnc4server, which creates a VNC server with its own X11 server included, independent from any desktop. You have to use a vnc viewer to see this desktop.
I'm afraid that C code is completely irrelevant.
If you have a comment on the unmount chroot issue, please post your comment in that issue.
I was thinking extension / icon, but for launching a new tab in a an open chrome window, this works for me:
$google-chrome http://localhost/test/php (or http://127.0.0.1/test.php)
The google-chrome
wrapper script only exists on standalone Chrome. Running /opt/google/chrome/chrome in Chromium OS starts a new Aura window, which is bad news bears. I wish it were that simple...
Does everything else in the vnc target work? Could be worth sharing as a beta and tell people to use a VNC extension to open 0.0.0.0 manually until that last bit is figured out.
I can format it into a target and add a branch; it's currently just a proof-of-concept hack. A couple things that need to be done before it's releasable:
just started playing with this looking at how i can get a few full screen games added to my daughter's chromebook. going direct from shell and running full screen without needing to start up a separate xserver works a treat--it's just a bit manual at the moment. having the hooks to allow people to create their own private extensions which effectively scripts all the steps from enter-chroot to launching the desired application would be a really powerful enhancement to a vanilla chromebook.
Sorry for the (massive) delay. I've added a vnc branch, and you can grab the latest version of that branch here. It's extremely rough right now, but it's something to play with if you want it. Specify -t vnc
before anything else (i.e, -t vnc,xfce
). Then use startxfce4 or whatever as normal; it currently just prints out the display number and a link you can copy-paste into the address field if you use this vnc viewer. I do not know of any other VNC viewer that runs offline. Unfortunately it requires NaCl, so you'll have to use a different extension (one without offline support and with the privacy/performance implications of using a hosted VNC client) on Samsung's ARM Chromebook.
tried installing crouton-vnc but got this error:
Installing target vnc...
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package vnc4server is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'vnc4server' has no installation candidate Unmounting /usr/local/chroots/precise... chronos@localhost / $
was going to try the html5 novnc, as the linked one above doesn't support ARM.
Argh. Looks like xtightvncserver is available on both platforms though. Try editing the /prepare.sh to install xtightvncserver instead.
I used apt-get in my existing xfce precise shell to install xtightvncviewer (with fonts, etc.), and the apt-get instlall xtightserver and have the install options below:
I restarted and ran /usr/bin/vncserver
which said my desktop was localhost:2
and set a password.
I hot-keyed to chromeos, and ran novnc, entering above info, but got timeouts. Does the other vncserver use port 8080 ?
Suggested packages:
tightvnc-java
The following NEW packages will be installed:
tightvncserver
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 692 kB of archives.
After this operation, 1,140 kB of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports/ precise/universe tightvncserver armhf 1.3.9-6.2ubuntu2 [692 kB]
Fetched 692 kB in 2s (248 kB/s)
Selecting previously unselected package tightvncserver.
(Reading database ... 104041 files and directories currently installed.)
Unpacking tightvncserver (from .../tightvncserver_1.3.9-6.2ubuntu2_armhf.deb) ...
Processing triggers for man-db ...
Setting up tightvncserver (1.3.9-6.2ubuntu2) ...
update-alternatives: using /usr/bin/tightvncserver to provide /usr/bin/vncserver (vncserver) in auto mode.
update-alternatives: using /usr/bin/Xtightvnc to provide /usr/bin/Xvnc (Xvnc) in auto mode.
update-alternatives: using /usr/bin/tightvncpasswd to provide /usr/bin/vncpasswd (vncpasswd) in auto mode.
root@localhost:/home/ted# ^C
upon running /usr/bin/vncserver &
I get the output below.
netstat -a shows that :5902 and :x11-2 might be related ports to xtightvnc server, a quick search shows #125 got pretty close with a windowed only vnc connection?
root@localhost:/home/ted# ps ax | grep vnc 14403 pts/5 S+ 0:00 grep --color=auto vnc root@localhost:/home/ted# /usr/bin/vncserver & [1] 14550 root@localhost:/home/ted# Warning: localhost:1 is taken because of /tmp/.X1-lock Remove this file if there is no X server localhost:1
New 'X' desktop is localhost:2
Starting applications specified in /root/.vnc/xstartup Log file is /root/.vnc/localhost:2.log
using netc
looks like port is 5902:
root@localhost:/# ps ax | grep vnc 14558 pts/5 S 0:00 Xtightvnc :2 -desktop X -auth /root/.Xauthority -geometry 1024x768 -depth 24 -rfbwait 120000 -rfbauth /root/.vnc/passwd -rfbport 5902 -fp /usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/75dpi/,/usr/share/fonts/X11/100dpi/ -co /etc/X11/rgb 14567 pts/5 S 0:00 /bin/sh /root/.vnc/xstartup 29632 pts/5 S+ 0:00 grep --color=auto vnc root@localhost:/#
log file shows it got a connection from client 127.0.0.1 but not a valid RFB client ?
tightvnc server is running fine in the chroot, as I'm now on another computer running xtightvncviewer, and have the chroot up in a window after entering ip:5902 and password. My default wallpaper is gone, and default xfce is here, so I'm wondering if it picked up my raring chroot?
below is shell output from non chromebook, successfully connecting to chroot vncserver (client is a dell with mint quantal xfce):
ted14 ted # /usr/bin/vncviewer Connected to RFB server, using protocol version 3.8 Enabling TightVNC protocol extensions Performing standard VNC authentication Authentication successful Desktop name "root's X desktop (localhost:2)" VNC server default format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Warning: Cannot convert string "--helvetica-bold-r---16-------" to type FontStruct Using default colormap which is TrueColor. Pixel format: 32 bits per pixel. Least significant byte first in each pixel. True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0 Using shared memory PutImage ^CCleanupSignalHandler called ShmCleanup called ted14 ted # ^C
Why not just change the generated /prepare.sh script to use the other package like I suggested? You're reinventing the wheel...
I will do that now, and test it.
But doing this will only provide a working vnc server in the chroot on the ARM, as even on my networked PC with chroot in vnc window, I can't copy from chroot and paste into my host OS, so the copy/paste to chromeOS side still needs a chromeos localhost vnc client (at least on the ARM).
But the vnc server working in the chroot is exciting!
I need help here. I have 2 prepare.sh files, one in:
/usr/local/chroots/precise/prepare.sh
and one in:
/mnt/stateful partition/dev_image/chroots/precise/prepare.sh
backing them up, and chmod 700 (they were 500), to edit the vnc4server to xtightserver, then saving, then running:
sudo sh -e ~/Downloads/crouton-vnc -t vnc,xfce -u
both generated the "Package vnc4server is not available...E: Package 'vnc4server' has no installation candidate' messages.
So I need to edit file(s) besides prepare.sh, right?
I opened up crouton-vnc in vi, but cannot find vnc4server referenced there either.
What am I missing here?
Those are the same file; the partition has two mount points.
Running crouton-vnc again overwrites prepare.sh. Edit the prepare.sh and then just enter-chroot; crouton will ask if you want to run the prepare.sh (say yes).
OK, this works. I have removed my vncserver, edited prepare.sh using tightvncserver, and entered the chroot, answering yes to continue completing the install. The tightvncserver was retrieved and installed properly. (note that the package name is tightvncserver, which is unpackages to /usr/bin/vncserver and alternate ways of starting the vncserver.
The preferred way is probably ~/.vnc/xstartup although files like vncserver are placed in /usr/bin
~/.vnc is also the directory for log files, where you can see which port is used (default appears to be port 5902), and which window your vnc is (default localhost:2)
Optionally, if you want to test your vnc server immediately, you can from apt-get install xtightvncviewer and immediately view a vnc session of your current chroot. You will be asked for your ip (enter ip:port), and optionally a password if you set one.
You can also set a view only password.
You should be able to startup the vnc server in /etc/rc.local, just as you would sshd, and other servers.
Note that your vnc session may not look exactly like your local session as it may drop your wallpaper, and revert to the defaults, at least with my xfce, but it is the same underlying chroot. Below is an image of the VNC window, on top of the customized chroot:
Let me know where to upload the proper prepare.sh with chmod 500 settings. It is the one generated by crouton-vnc but replaces the vnc4server with tightvncserver package.
If this is the best way we can implement a vnc server in the chroot, I will write it up in the wiki. I did not encounter bug #125 where a full-screen VNC window doesn't function, because the default VNC window size from this package is 1024 or so, which is smaller than my 1376 and 1440 screens, so it was not capable of going to full-screen on those systems.
None of that, actually. Once you have the VNC target installed, just use startxfce4 as normal. It should launch Xvnc instead of X11.
You are right. I just quit my chroot, and entered again, and went straight to /usr/bin/vncviewer and the server is running.
I then checked the process below. How is it auto-starting? It put nothing in /etc/rc.local? And is this a safe thing to auto-start a vnc server that opens a tcp port?
root@localhost:/usr/bin# ps ax | grep vnc 13328 pts/1 S+ 0:00 grep --color=auto vnc 24548 ? S 0:00 Xtightvnc :2 -desktop X -auth /root/.Xauthority -geometry 1024x768 -depth 24 -rfbwait 120000 -rfbauth /root/.vnc/passwd -rfbport 5902 -fp /usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/75dpi/,/usr/share/fonts/X11/100dpi/ -co /etc/X11/rgb 24556 ? S 0:00 /bin/sh /root/.vnc/xstartup root@localhost:/usr/bin#
I don't think that one was launched by my script...you should probably reboot to get to a sane state, then just try doing startxfce4.
I powered off and on, and yes, it is not coming up automatically:
But I don't understand what power cycling did that completely exiting and unmounting, then restarting the chroot did. Actually, I have an idea, that I will test tomorrow - after running the new prepare.sh the first time, then answering yes to the prompt, and having the chroot updated with the vnc package, I exited the chroot, and went to /usr/local/chroots/precise to send the prepare.sh and noticed it was gone after it was used, so I made a new one, cp'd it to ~/Downloads to upload or attach. But by making a new one (from a .bak file), I think it ran again, so perhaps it runs once after installing.
Should you consider leaving the prepare.sh file there, perhaps renaming it prepare.used or prepare.last so advanced users can see if the parameters and font types/directories are what they want, or can debug?
I realize you can't leave it there as executable or it will run every chroot entry, but renaming, or chmod to non exec?
I will look into this tomorrow. Thanks.
root@localhost:/usr/bin# xvncviewer xvncviewer: ConnectToTcpAddr: connect: Connection refused Unable to connect to VNC server root@localhost:/usr/bin# ps ax | grep vnc 8454 pts/3 S+ 0:00 grep --color=auto vnc root@localhost:/usr/bin# ^C
David,
When you get a chance, I'd love an explanation of what's different between using VNC and VT3. Would it be easy to set up one instance of crouton to use one or the other?
Based on this commit it looks like I could apt-get install vnc4server
and create a script that starts Xvnc
instead of X
, maybe something like:
~/bin/lcdinit:
export MAIN_DISPLAY="lcd"
xinit
~/bin/vncinit:
export MAIN_DISPLAY="vnc"
xinit
/etc/X11/xinit/xserverrc:
SET_DPI="-dpi 239"
if [ "$MAIN_DISPLAY" = "vnc" ]; then
exec /usr/bin/Xvnc -DeferUpdate 10 -NeverShared -SecurityTypes none -IdleTimeout 0 -localhost -once "$@" $SET_DPI
else
exec /usr/bin/X -nolisten tcp "$@" $SET_DPI
fi
Yep, that should work (I've tweaked the lines to fix the syntax), and yes, the two techniques will interop just fine.
Benefits of running in VT3 are that you get GPU/3D acceleration, it runs at full resolution with minimum lag, and it's the most efficient battery-wise. Downsides are that currently Chromium seems to drop connections when not the active VT (see #118), you can't share the clipboard without something like #144, the keyboard shortcut to switch chroots sucks (#48), and you can't see your Chromium OS tabs and your chroot at the same time.
Benefits of running in VNC are that it runs in a tab or a window (so you can arrange it with your other tabs however you desire), switching to the chroot is the same as switching to any webpage, and if your VNC client implements clipboard synchronization you automatically get that. Downsides are that you don't have any GPU acceleration, there's a bit of lag and overhead due to encoding/decoding/rendering the VNC protocol, all possible resolutions have to be supplied to the Xvnc command line (pass multiple -geometry parameters), and you have to have an extension installed and launch (or auto-launch) it.
The third option is running using Xephyr, which nests an X11 server inside the Chromium OS one and uses ratpoison to swap between them. Benefits/downsides are pretty much a hybrid of VT3 and VNC: switching between the chroot and Chromium OS is easier and faster because of the nicer shortcut keys and that you're not changing VTs, there's no lag and the graphics system is pretty efficient, and Chromium doesn't drop connections while in the chroot; however, you still need #144 for clipboard synchronization, you can't see your chroot and Chromium OS at the same time, you don't get GPU/3D acceleration, and you can't change resolution at all.
@tedm, yes, it sounds like you reset your changes.
yes. Let me know if you have a crouton-vnc that makes a prepare.sh with tightvncserver instead of vnc4server and I will test again. I don't know vnc well enough to know what additional optimal default parameters should be passed other than replacing the vnc4server package with tightvncserver.
Also, is it a bug that the vncclient that goes along with tightvncserver (xtightvncviewer package) doesn't pick up my xfce customizations?
The last time I used vnc was many years ago with the LTSP project, and there was only one X server that we knew about. Wallpapers were not yet invented... ;) As an instructor, we teach from books that mention vnc is outdated... and potentially insecure and inefficient ... of course that's not all entirely true.
@tedm - It looks like David switched to using the tightvncserver about a week ago.
@David - Just installed crouton-vnc using targets vnc,xfce and it works great. One question though - after looking at some of the branch files, it looks like maybe I should have specified targets vnc,xephyr instead since it looks to be setup that way ???
Thanx again for all your work!
Thanks @DennisLfromGA - I will update and test it tonight or tomorrow. Is a pretty cool thing, and I think the only way to graphically remotely use your chroot that I'm aware of . On the ARM though, we don't have a chromeos client, so split-screen isn't doable yet.
@dnschneid - If crouton-vnc is working well for getting the server components in a chroot, will it be just worked into crouton with vnc being an additional target, or will crouton-vnc stay separate? Thanks!
Is there anything a non-programmer can do to help get a chromeos compatible extension supported on the ARM?
A minor thing but I installed crouton-vnc with just targets vnc,xfce and when I ran 'croutonversion -d -c' it balked 'cause wget wasn't installed. Maybe the cli-extra target should be installed too or automagically included - or just install wget. Lots of options, possibly too many... ;- )
updating my precise / xfce worked fine, using crouton-vnc version:
0-20130615192011-vnc:557000ed
using sh -e ~/Downloads/crouton-vnc -t vnc,xfce -u
prepare.sh showed tightvncserver and the whole chroot was updated as normal.
I can vnc into the chroot from another pc, but I lose my default wallpaper and desktop customizations.
Also I can't seem to copy from the chroot, which is running in a vnc viewer in another chrome tab on this windows 7 pc. I can copy, but it's copying to the chroot's clipboard, and the VNC Viewer extension is not copying it to Chrome's clipboard, allowing me to paste here. (I had to manually flip back and forth and type that version). There are a couple of other VNC extension apps. I'll try them later, or it could just be some settings within VNC Viewer that I need to adjust.
Update - In my kde desktop when I open any windows like 'Settings', etc., I can't left-click in the window to select anything - right-click doesn't work either. I can, however, still close the window by right-clicking the taskbar app and selecting close and I can use the taskbar menu, etc. - kind'a strange.
I'll check my xfce desktop next and make sure everything's working there and report back.
@DennisLfromGA - I don't have a kde chroot right now to test, but I wonder if your vnc client is getting confused by the fancy kde transparency settings? I'd be curious to know how your xfce session works, and if by some chance your chroot's desktop custom settings are retained through your vnc session.
@tedm - It could be kde is too fancy, I prefer it over xfce but I guess in this case I'll just stick with xfce since it is stilling doing a stellar job.
Thanx for the input.
OK, I found a working vnc client that works on the ARM - it is vnc viewer by 0x65 labs in the chrome store. It sort of works, in that it's not really an extension, but a sub-window that when active takes control of the keyboard (so basic chrome things like screenshots can be tricky).
I think the reason I'm getting a default desktop is that when I launch /usr/bin/vncserver in the chroot, it assigns the vnc terminal to :2 and I still want :1 to exist when I hot key back to it.
Here's a screenshot of the chroot running in a vnc window on chromeos:
and here is my normal chroot (:1):
@DennisLfromGA vnc,xfce is correct. vnc,xephyr would install both VNC and Xephyr, and Xephyr would become the active X11 method (since you installed it last). You would also not have a desktop environment installed. Good catch on wget; I might have to include that in core afterall.
@tedm once it's ready, it will be included in the main crouton as a vnc target. The reason you're getting a different desktop is because you're manually running vncserver as root, which is a really bad idea in general. The whole point of the VNC target is that once you've installed it, anything that starts an X server (startxfce4, etc) will use VNC as the X server. If you just want to run VNC manually, the vnc target isn't necessary, but you still shouldn't be running vncserver as root. If you just want to add VNC access to your existing, running desktop, you can use x11vnc to share the chroot display over VNC.
@David - Thanx for the info. I was having problems with kde, etc.- I have a bad habit of loading up a ton of targets and, in this case, it broke the vnc server so, in my haste, I deleted the crouton-vnc chroot. I then installed a new one with the targets vnc,xephyr,xfce,cli-extra thinking it was the preferred way to go and it also broke the vnc server but, lo and behold, I figured it out - small wonders never cease... I discovered that the xserverrc file was linked to xephyr instead of vnc (as you graciously pointed out above) so I took the long way around and found out how to set up alternatives (via update-alternatives) and installed xserverrc-vnc as the auto option with xserverrc-xephyr as the alternative and all is well again. ;)
The 'wget catch' was just happenstance. 'croutonversion -d -u' reports the current version as the vnc branch (0-20130615192011~vnc:557000ed) and the latest version as the master (0-20130621110823~master:22bc1c1f) which I guess is expected until it's merged.
[ Learn somethin' everyday - this is one of the many reasons I love linux and crouton in specific. ]
Having Ubuntu in a tab is a very cool thing!
@David thanks, it does make sense to use vnc as a user. I couldn't connect when starting vncserver as user (precise/xfce), so since I made a new chroot with crouton-vnc with -t vnc,xfce -r quantal and vncserver is running with what look like all the right parameters, but the client doesn't bring up the user desktop on chromeos, just a blank x screen. iptables wasn't loaded by default, so I used apt-get to retrieve it, and have /sbin/iptables -P INPUT ACCEPT in /etc/rc.local.
Again, because you're running vncserver manually.
um. after installing vnc,xfce it did not start automatically. What is the proper way to start it non-manually, check it's port, etc. ?
Run startxfce4 and check the terminal output.
@tedm - I'll take a stab at it -
These 2 things have hung me up a time or two - or three ;)
Most VNC clients let you specify the display number, and automatically add 5900 to it.
Thanks @DennisLfromGA - I did not have that link (it was linked to /etc/crouton/xserverrc), so I made it link to /etc/crouton/xserverrc-vnc), exited, restarted, and got a lot of RANDR missing errors.
@dnschneid David - vnc server does not autostart. Tried ports 5900 - 5905.
xserverrc-vnc wraps Xvnc (is this compatible with arm?) - tried replacing Xvnc with vncserver but got these errors:
chronos@localhost / $ chronos@localhost / $ sudo startxfce4 -n quantal
bash: chronos@localhost: command not found
chronos@localhost / $ /usr/bin/startxfce4: Starting X server
bash: /usr/bin/startxfce4:: No such file or directory
chronos@localhost / $
chronos@localhost / $
chronos@localhost / $ New 'X' desktop is localhost:1
bash: New: command not found
chronos@localhost / $
chronos@localhost / $ Starting applications specified in /home/ted/.vnc/xstartup
bash: Starting: command not found
chronos@localhost / $ Log file is /home/ted/.vnc/localhost:1.log
bash: Log: command not found
chronos@localhost / $
chronos@localhost / $
chronos@localhost / $ waiting for X server to shut down XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
bash: syntax error near unexpected token (' chronos@localhost / $ after 6 requests (6 known processed) with 0 events remaining. bash: syntax error near unexpected token
('
chronos@localhost / $ ..........
bash: ..........: command not found
chronos@localhost / $ /usr/bin/xinit: X server slow to shut down, sending KILL signalbash: /usr/bin/xinit:: No such file or directory
chronos@localhost / $ Unmounting /usr/local/chroots/quantal...
bash: Unmounting: command not found
chronos@localhost / $ Sending SIGTERM to processes under /usr/local/chroots/quantal...
bash: Sending: command not found
chronos@localhost / $ chronos@localhost / $
For those of you, like me, that were sorely missing 'tab completion' in your xfce4 vnc session, I found an article explaining how to get it back via 'Settings --> Window Manager --> Keyboard'. Here's an excerpt from the article -
..."Turns out Xfce was assigning something called
Here 'tis -
Xfce Tab and auto-complete terminal via VNC - http://goo.gl/5XohY
@DennisLfromGA that...is bizarre. Thanks for finding that.
@tedm it looks like you just copied and pasted a chunk of terminal output into the terminal as input. I have no clue what you're doing. Do exactly the following:
sudo sh -e ~/Downloads/crouton-vnc -t vnc,xfce -n vnctest
to completion.sudo startxfce4 -n vnctest
@dnschneid - yes, sorry about that output, it is mangled with a paste as I was copying it, and it didn't really show anything useful. I am currently running the steps above. Should complete in an hour or so.
still installing, but do these x11/xephyr messages mean anything - the x11 target does not work on ARM after the installing xserverrc-vnc lines?
I: Extracting zlib1g... Moving bootstrap files into the chroot... Preparing chroot environment... Installing brightness into the chroot... Installing croutonversion into the chroot... Installing host-dbus into the chroot... Installing host-x11 into the chroot... Installing croutonpowerd into the chroot... Installing croutonxinitrc-wrapper into the chroot... Installing xinit into the chroot... Installing xserverrc-vnc into the chroot... x11 target does not work on ARM. Substituting in xephyr. Installing croutoncycle into the chroot... Installing croutonpowerd into the chroot... Installing croutonwheel into the chroot... Installing croutonwm into the chroot... Installing croutonxinitrc-wrapper into the chroot... Installing xinit into the chroot... Installing keylaunchrc-xephyr into the chroot... Installing xserverrc-xephyr into the chroot... x11 target does not work on ARM. Substituting in xephyr. Installing startxfce4 into the host... ...
Can we get crouton so instead of hot-keying, it is just in a tab in chrome? Then we get our linux and chroot a bit more seamless, without hot-keying back and forth.
Seems like one would just need to modify the chrubuntu so it fits in a chrome window instead of the whole physical display.