On a local development machine, I use Windows and PuTTY, with a linux server VM that I use to replicate the development environment for things like running tests and so forth. The VM (VirtualBox) uses a vboxfs share that contains my local projects.
I have set up msysgit on my machine to use PuTTY, my preferred SSH client, and that all works fine. Unfortunately, when I set a git remote URL, it has to use PuTTY's format to specify a session (ssh://<session name>/<repo>) in order for msysgit to work, which means none of the git urls work in the VM environment. This isn't a huge deal, but I was curious: Is there a way to reconcile the two configurations so I can use git commands in either environment without manually setting a remote url each time?
One work-around is to install PuTTY on your Linux machine. There are several precompiled versions out there or you can just download the official source and compile them.
Related
I have a very strange problem with Cygwin sshd and changing the PATH environment variable through the Windows control panel. This is with Windows 10 64 running in a Parallels VM
After a reboot ssh sessions into the Windows machine will still use the old path. Local Cygwin sessions have no such problem: they will use the new path.
Note the bold text: I am aware that without the reboot this is expected to happen (because sshd got started with the old environment). But the After the reboot has got me baffled. If I ssh into the machine I see the old PATH. If I then reboot the VM again and ssh in again I finally see the new path.
Incidentally (fodder for future people googling this) I had the problem while using gitlab-runner to run CI/CD jobs on Windows using Parallels VMs on my Mac. So I would prepare the VM to have all the right tools installed and everything set correctly, then shut it down. gitlab-runner will then clone the VM and run the CI/CD jobs on it. Works now, as long as I reboot the original VM twice with an ssh session in between before having it cloned by gitlab-runner:-)
I never posted the answer I found: the problem was that hibernate was enabled on Windows. Actually the first "restart" was usually a shutdown followed by a startup.
But, by default Win10 has hibernate enabled, and if that is the case a shutdown and startup don't actually reboot the OS.
Disabling hibernate fixed it.
Double-check your Cygwin sshd installation, as described in "Installing Cygwin and Starting the SSH Daemon"
it makes sure the %PATH% does not reference other SSH, like W10 OpenSSH.
it stops any other SSH service.
it defines a Cygwin SSH Windows service, using a local account, which then should pick up the same account new path after a single reboot (or even with restarting the service, without reboot)
I am not sure why you need two reboots in your case, but see if that Cygwin sshd setup works better.
For instance, I have a virtualised Linux-box running in my windows environment, and I have a shared-folder mapped to /vagrant and in that shared folder I have readme.txt. Is there a command I can run from within the virtualised OS to pop up readme.txt in my favourite text-editor in the windows host environment?
In a nutshell I'm just wondering if there is a standard way to invoke a host command from the guest.
I'm thinking an analogue of the cygstart command that cygwin provides, perhaps a part of the guest additions package.
This seems like it should be a well trodden path, since its highly likely a guest might want to communicate with its host in certain configurations.
Looks like somebody wrote a tool for this https://github.com/marcosdiez/openfile
Unfortunately it looks like there isn't a VirtualBox API for this so he has to run a server in the host:
it is necessary to run a C# server on Windows which accepts and runs
remote commands from the Unix box.
Should do the job though!
I've set up a git server (and gitolite) on an Ubuntu machine at Amazon. I want to interact with this server on Windows. I've installed Git for Windows (the one that comes with Visual Studio Tools for Git), but trying to access the server ends in the bash prompt telling me "Permission Denied (publickey)." I have the ssh keys from the git user on my local machine and Pageant has them loaded, but I don't see any way of telling the git client to use them. How do I tell the git command line to use my ssh keys?
Or better yet, does anyone have experience setting up Visual Studio Tools for Git to access their own personal git server rather than one at GitHub?
Ok, so turns out there is a seemingly undocumented step required to set the private keys for Git for Windows.
When Git for Windows is installed, it creates a new folder, C:\Users\[user]\.ssh. In order to set the keys to use for ssh you must copy for private ssh key for the git user to this directory and it *MUST be named "id_rsa"*. Once you have that key in that folder, you're golden.
We are having a linux build server and the build scripts are written in ruby. All the jars are deployed on linux servers only and are generally copied to the application servers using ssh.
There is a new service which needs to be deployed on a windows server. Is there a way to copy and configure the jar deployment from the linux machine to the windows server.
Using ruby / shell scripting?
If you are already using SSH in your build script I would think the easiest thing to do would be to install an SSH server on the Windows box. You can use sshd via Cygwin or opt for a commercial product like WinSSHD (I'm sure there are numerous other free or paid products out there).
Once you have that running you can more than likely reuse most of the existing script relating to moving files around and use a gem like Win32Utils to do any windows specific tasks.
My linux box has unfortunately died. I can access the raw SVN repositories from a backup and I need to revive them on my Windows box (at least for the timebeing). Is there a way of migrating/importing these repositories, given that I can't run "svnadmin dump" on the linux box?
I'd suggest booting from a Linux live CD of the same distribution as your Linux server, or create a virtual machine with VMWare Player or VirtualBox and mount the filesystem, then you can do an svnadmin dump from there.
As it's no longer in use (no commits or checkouts), try copying the whole repo to your Windows box.