Raspberry Pi: Remote desktop with tightvnc and mac - macos

I am trying to setup tightvnc on my Raspberry Pi 2 (rp2), so I can remote in from my mac. I have done this before and it went smooth as butter. But this second setup has been a real challenge and i am not sure why. I used these steps: https://www.raspberrypi.org/documentation/remote-access/vnc/. The only thing I did wrong on this - I setup automatic start up before ever connecting to the vnc server or setting up the password, which makes me think might be the root of the problem.
When I try to connect to my rp2 via finder's connect to server feature, I get a message saying that I cannot connect and need to check the settings on the host. I can ssh into rp2, and i can see that indeed tightvnc is not running, but! .X0-lock and X0 in /tmp/ folder do exist. If I delete both of these and restart tightvnc and then connect to the rp2 from my mac I can see grey pixelated screen & mouse cursor. ???
I tried removing tightvnc, tried disabling autostart, but it always persists which is beyond me (i have used linux before for school and work, so I am not a complete noob, but not an expert either). I tried redoing the steps to correct the install, no luck.
Any ideas? Any thing I can take a look at? I might just wipe the whole raspberry instal.
Thanks!

Related

bash tab auto-complete is too slow but it isn't with teraterm or putty

I'm using Ubuntu 18.04 and it got stuck in 1~2 seconds when I push the tab button for auto-completion.
I've been trying to resolve this problem but I couldn't make it. I even changed my computer to the new one but it has same problem.
One weird thing is that when I connect my ubuntu with ssh in other pc(using teraterm or putty or other pc's ubuntu), the problem is gone and works well.
I don't know why.. Could it be a network problem? My ubuntu pc is behind the firewall and proxy but my companies' ubuntu next to me works well.
Is there anything suspicious to you?
sudo updatedb
The database is rebuilt for auto completion.
Maybe check your hard disk health as this could be a hardware issue, and the disk is struggling to read, and the command is searching the database and taking longer to complete.
I've finally found the answer!!
To resolve this problem, turn off the "Terminal bell" option of terminal.
In terminal,
Edit > Preferences > Sound > Terminal bell

VMWare: File not Found, on Mac OS 10.10 Yosemite

I'm having trouble opening VMWare on my Mac pro OS 10.10. I didn't do anything, moving its files or anything. I just turned my Mac off before I went to bed last night, and then this morning, when I tried to open VMWare again on my Mac, it keeps giving me this waring:
File not found.
I'm very confused, I've important files storing on my Windows workspace and need to have it restored.
What I've tried:
I've uninstalled VMWare on my machine, and re-downloaded and reinstalled it back, but, no luck, still the same warning. VMWare doesn't open at all.
I've also restarted my machine, hoping that something magic can happen, but unexpectedly, no luck.
OK, question resolved after I went to the Tech Stop at my University.
We just found that Windows 7 was somehow gone in my VMWare, then we opened Virtual Machine Library of VMWare, then re-installed Win7 into this VMWare, as this picture shows: http://postimg.org/image/blnk4x59z/
Now things are working fine.
Some other people might run into the same issue in the future, I don't know why this happened and nobody really knows what's going on.
I called VMWare tech support, but they don't provide any help since I downloaded it for free from our CS department website. But our department tech assistance has never met this issue. So nobody to turn to.
But anyway, pretty simple to fix:
Just re-install win7 in your VMWare, if you run into the same case as I did, by opening your Virtual Machine Library.
I experienced the same symptom after rebooting my Mac. SSun's answer helped me to solve it, but I think I can offer a bit of further insight.
VMWare Fusion was actually launching successfully, but when attempting to open a machine that was open at last quit, it fails to find the machine's files. I mis-interpreted the message as meaning that VMWare couldn't find an internal file and thought it had failed to launch. I got the same error when attempting to reinstall.
SSun refers to re-installing a guest OS. To be specific, one just needs to delete the reference to the virtual machine in VMWare (after dismissing the popup and you can access to the Window menu and open your virtual machine library); not reinstalling the actual guest OS. One can then recreate the reference by opening the machine via File > Open. Alternatively, resolve the root cause of the machine not being found.
In my case the root cause was that the virtual machine resided on a different hard drive to Mac OS and was referenced via a symlink. This hard drive had failed to mount automatically at boot up.
The same confusing error occurs when reinstalling because at the end of the install, VMWare launches automatically, triggering the symptom again.
I followed the steps from kb.mit.edu below to resolve this issue:
Click OK to close the error message.
Close the Virtual Machine. Click the red dot in upper left hand
corner or execute the keyboard shortcut Command+W
Follow the menu path Window >> Virtual Machine Library to open the
Virtual Machine Library.
Right-click on the thumbnail image for the VM or hold down the Ctr
key while clicking on the thumbnail image for the VM. Result: A
drop-down menu appears.
Select Delete Result: Remove Virtual Machine dialog box appears, with
options to Cancel, Move to Track or Keep File.
Choose Keep File.
However after doing the above, I found out that you need to resart your machine for eveything to work properly, else the problem will still persist.
If you get this error – including after deleting a VM (i.e., you cannot do anything inside the VMWare Fusion app to resolve this) – I found that the following will work, without reinstalling the app, deleting its preferences, or rebooting the host Mac, but at the tiny cost of having to re-add your VMs to the list of the available ones (a simple drag-and-drop operation):
Shut down any running VMs that are functioning, then shut down VMWare Fusion.
Trash the "~/Library/Application Support/VMware Fusion/vmInventory" file
Open the Activity Monitor app, search for "vm", and shut down everything with "vmware", "vmnet", and "vmrest" in its name. (Or do effectively the same thing in the Terminal, with ps aux | grep vm and then kill -9 on each of the appropriate process numbers, if you're command-line-oriented.)
Go find your VMs in Finder.
Restart the VMWare Fusion application.
Drag each of your VM packages to VMWare and drop it on the now-empty left pane of the Virtual Machine Library window to re-add the the VM to the list.
Test-start each of them to make sure you didn't break anything. [This is the paranoia option, here.]
Restart VMWare to make darned sure it writes out new config files. [My trust level in this app is quite low of late.]

WDS ImageUnattend does not run

We've successfully set-up WDS (Windows Deployment Services) and had it all working (it's serving an unattended Windows 7 x64 installation, the user only has to F12 then wait for the install to finish) but it no longer works the way it did before.
We're trying to F12 the exact same machine where it used to work. The WDS part of the installation is still automatic (unattended) but ImageUnattend.xml does not seem to run on the client at all now, it gets stuck at the language selection (everything after that is manual as well which is supposed to be automatic).
Inspecting C:\windows\panther on the client machine shows that WDS pops up with an error: WDS CallBack_WdsClient_CopyPrivatesDone: Failed to process client unattend variables.
Changing "%MACHINENAME%" to "*" in the ImageUnattend.xml file makes it all automatic again, however it then renames the computer incorrectly.
The variable %MACHINENAME% worked before, so why does it not work now? Has anyone else met this issue before?
Using a different user (domain administrator) in the ImageUnattend.xml file does not seem to change anything.
After countless of attempts with at least 15 new ImageUnattend.xml files, I decided to restart the server and use the original files I knew worked before.
This fixed it.

Portable Windows Mosh?

I was wondering if there's a way to use Mosh on windows without Cygwin?
I need to be able to put it on my USB drive and copy it over to a windows computer and be able to Mosh into one of my servers. Otherwise, is there a way to use Cygwin and have it portable? I did get mosh working under windows via Cygwin, but that meant I had to add an environment path to the windows computer, which, on the windows computer that I'm working on doesn't allow you to change that, since I don't have admin privileges.
MobaXTerm is portable and supports Mosh.
It works quite well. I spent all day using it on a very dodgy connection and it worked like a charm.
Just get the most recent version and from the Session menu select Mosh. It did does not support IPv6 (at least in Version 9.2 (2016-09-18)):
Bugfix: Mosh sessions are forced to IPv4 only (IPv6 is not yet supported by Mosh client/server)
But it might work now, since Version 10.4 (untested):
We also improved MobaXterm behavior and fixed issues with multi-monitors, IPv6 connections, mouse scrolling and keyboard shortcuts.
Interestingly enough, I wanted MOSH for Windows too, and I find Cygwin to be very messy. Instead, I just downloaded a minimal Text-only Debian distribution, booted it up in VirtualBox, and installed MOSH. Surprisingly, it's much less time consuming and requires less tweaking than going the Cygwin route, and makes less modifications to the host machine.
In fact, there is a portable VirtualBox, so you can put your MOSH VM and Portable VirtualBox on a memory stick.
I haven't even tried to optimize things, but it runs just fine on the 256MB of ram I gave it. It would probably run just fine on 64MB or less.
I do hope MOSH will be built into PuTTY/KiTTY in the future.
I have noticed that a new version of MobaXterm has been released (version 7.1) and includes an intergrated Mosh session.
So, you dot not need anymore need plugin for that.
They said that it is "experimental", but I have tested it, and it is working quite well.
As of now, Mosh has added support for Google Chrome (or any of Chromium Browsers) as an official extension. So you can keep a portable google chrome & use mosh from there.
For Windows, there isn't a single solution install to support MOSH. Rather, you have to sort of "stitch together" a few options to make it work.
MOSH itself does not need ssh or any other initial program necessarily. It is possible to start a session on your server, then using the published connection information, go to your client (in this case your windows box) and use that information to connect the session. This is sort of messy and is the main reason people use SSH to basically establish a connection to the server, remotely start a MOSH server, get the session information back to your client machine, then launch the MOSH experience.
The two pieces you need on the client side (if you make the connection manually) are the server port number and symmetric encryption key. A typical example of one given by a MOSH server would be:
MOSH CONNECT 60001 U0MWPbwn3BdcdMyNLnSFCA
Where 60001 is my port number and "U0...CA" is my encryption key. Don't ever give this out BTW as ANYONE can connect to your running MOSH server with this information (that is, they would look just like an IP change just like you do when you get disconnected and reconnected)
So, back to installation. MobaXterm (currently at v10.5) is a free for personal use app that you can find at https://mobaxterm.mobatek.net/. Installation is relatively straight forward. One word of caution however, their SSH implementation is rudimentary. Basically they support password authentication for ssh. If you use public keys, you cannot have one with a password on it and expect it to work (the code to ask you for your password appears to be missing). This might not be a show stopper for everyone but this is where my company stopped following this thread.
Within MobiXTerm, you want to hit the "Sessions" button at the top left to bring up a new session window. Press the Mosh button on the top right to get the start of your session (NOTE: This is IPv4 only. Zippo luck on getting IPv6 with this to work). Enter your remote host and the username of the ssh account you will be using. If you have an unsigned ssh key, then you can use the Advanced Mosh setting to link that private key with this session (at this point, as a security guy, I'm sort of passing out). At this point, as long as mosh is correctly running on your server (with the 60000-61000 UDP ports open in the server firewall), things should "just work".
Ok, so its not too painful to get working this way. But other than terminal functionality, its not very much fun either. Although MobiXterm is an X-server, I haven't yet gotten X to function over the mobi connection (at least not automatically).

Mac OSX snow leopard file sharing with windows box

Having a weird issue. I'm new to Macs and have a windows VM that I'm running on a new macbook pro via VM Fusion. I setup a file share on the windows side (Win 7) and accessed it from the Mac side using the "Connect to Server" dialog. I did it successfully several times, even adding in a symlink on the mac side and starting a git repository. About halfway through my first pull from my git server the pull froze (i.e. didn't continue pulling). I waited for quite a while like that before killing the terminal window, and after that I was no longer able to connect to the share in any fashion. I've tried removing the share on both sides, rebooting both sides, but ever since then trying to connect back to that VM gives me an error that "There was an error connecting tot he server {ip address}. Check the server name or IP Address, and then try again"
IP is right, I've tried it with the name as well (which is how I did it originally) which was also right; I can ping from the mac side to the windows side both the IP and name. I have tried editing /etc/hosts to point a name at the IP address that way, same result. I've tried turning off the windows firewall and antivirus, no difference.
I guess I'd assume it was me not doing something right on the shares, except that it went from working to not working w/o me changing any settings. It's a new box, so it's possible that there was an OS patch (on either side) that caused the change, but I didn't notice any going in during the time in question.
UPDATE: I pulled another new mac patch down (I guess I didn't have them all) and it worked again. Right up until I froze it again with the git issue (I had tried to resolve the pack size issue that appeared to be the root cause of the git problem, I was wrong).
Is there any process I should look at killing and restarting? This behavior seems like there's a hung process somewhere, though shutting the mac down and booting it up again isn't helping, so I don't know.
Figured it out. Turns out that turning off sharing on the windows sid,e then turning it back on solved it.

Resources