I'm trying to connect SSH but it returns the error that there is no Linux installed on the machine on PhpStorm (IDE by JetBrains).
I use the Fedora 36 distribution. When I start the project via SSH through the remote field, it connects normally:
Now, if I try to create a new project only to connect and start working within the IDE itself according to the folders, it gives me the error that Linux is not installed on the machine:
Return error:
How can I manipulate the folders and codes of a project equally VSCode SSH extension? In SSH through the IDE itself as if it were a project from 0 ? Is it possible in PhpStorm?
Related
I've currently moved from old WSL which was called Bash to Ubuntu from windows store. I'm using it along with ConEmu terminal emulator. To configure this two together, I need to specify ubuntu.exe path in conemu, but I can't find it, do you know where's it installed ? For instance, before it was C:\Windows\system32\bash.exe
Execute where ubuntu command in cmd to find correct path.
for example:
C:\Users\USERNAME\AppData\Local\Microsoft\WindowsApps\ubuntu.exe
Every time i run a docker command remotely (e.g docker-machine ssh default) I always get an error saying that default is not running although I started the docker machine manually on the Windows machine. When I run "docker-machine ls" the state is set to "Timeout" but I run it on the actually windows machine and it is "Running". Im using Docker Toolbox w/ VirtalBox on Windows 10 machine with UAC disabled. I also have a Server 2012 box that shows the same results with docker toolbox. Im running the command remotely through power shell. I installed Docker Toolbox using my local account with and without elevated permissions.
I want to be able to spin up and remove docker containers from TeamCity through the command line (Teamcity on Windows).
Thanks
I develop locally using PhpStorm, Git and VirtualBox on my local machine. I use Git to handle the process of moving work to staging or production environments. Currently I'm using MobaXterm (an excellent free tabbed ssh client for windows) to have terminal access to do things on staging and production servers. PhpStorm has a local terminal built in, but how would I use it to have multiple ssh terminal access? (This way I can have local, remote staging, and remote production terminal access all from within my IDE)
Figured it out!
On a fresh copy, PhpStorm will have Tools > Terminal to bring up the local terminal. To have additional ssh terminal access, this is what I did...
Setup servers
1.1) File > Settings > (Type: "Deployment" into the search box)
1.2) Hit the + button and fill in the necessary fields into the connection tab.
1.3) Click on the "Mappings" tab and clear the field "Local path"
since we will only be using the terminal.
1.4) Repeat Steps 1.2 and 1.3 for each server you want a terminal tab for.
1.5) Don't set any of these as default, so that you will be prompted to choose
a server in Step #2 below...
Start a remote terminal tab (this will also open up local terminal)
2.1) Tools > Start SSH session (this option doesn't appear until Step #1 is
completed)
2.2) You will be prompted to select a server from Step #1.
The terminal window appears and a new tab appears next to "local" in the
terminal window.
EDIT: (Thanks to Dan Dascalescu) you may want to also ensure the SSH Remote Run plugin is enabled. It's enabled by default in PhpStorm 8 (not sure about earlier versions).
PhpStorm has a plugin called "SSH Remote Run".
See also the built-in terminal.
I have been looking out for ways to setup an automation environment and I found this application named Vagrant. I read the docs on the site, however I wanted to know from the experts out there if Vagrant with Oracle VirtualBox would suffice my needs.
I need to have a script that will call Vagrant to initialize a VM [The VM-Image is always the same - Windows Server 2008 R2]
I need to copy some of my project related files from a shared location onto the VM
Call a Batch file that will take care of test runs for me inside the VM
Once my test run is complete, This VM needs to be self destroyed/destructed.
Also, I would like to know if the Image be a custom .ISO file?
Sounds like Vagrant and VirtualBox will work for that scenario. Also, you might find that running commands in the VM using WinRM or SSH may be the easiest way to launch tests.
If you haven't already seen it, the blog post about Windows support in Vagrant 1.6 is informative: https://www.vagrantup.com/blog/feature-preview-vagrant-1-6-windows.html
Creating a VirtualBox/Vagrant base VM from an .iso should work, and you can then do all of your work using the VM from that point onward.
To get started, you might try these steps:
Create a VirtualBox VM from your Windows .iso, using the VirtualBox GUI or cmdline tools.
Once you have the VM in the state you want it, shut it down and package it as a vagrant box - for example, on a Mac that step looks like (where Win7x64 is the dir containing the VirtualBox VM):
cd ~/VirtualBox\ VMs
vagrant package --base Win7x64 --output win7x64_base.box
Once that finishes, tell vagrant about the new base box:
vagrant box add win7x64_base /path/to/win7_base.box
Then you can vagrant init/vagrant up the VM:
mkdir win7 && cd win7
vagrant init win7x64
vagrant up
To enable SSH access, I installed Cygwin in the VM and configured sshd. So, after launching you can SSH in by running vagrant ssh
Note that if there's no Windows user in the VM named 'vagrant', you can specify the SSH username to use with vagrant ssh by placing this in your Vagrantfile:
config.ssh.username = 'user1'
As mentioned above, WinRM is also an option for remotely running commands.
And Vagrant apparently has some convenience features to make it easy to RDP into the VM, but I haven't looked at that.
If we have a headless test server running sikuli (both ubuntu and windows configurations needed), how to get it work without a physical monitor and preferably for as many screen resolutions as possible.
I successfully got sikuli running in headless mode (no physical monitor connected)
Ubuntu: check Xvfb.
Windows: install display driver on the machine (to be headless) from virtualbox guest additions display drivers and use TightVNC to remotely set resolution from another machine.
Detailed steps for windows 7
Assume that:
Machine A: to be headless machine, windows 7, with vnc server ready (e.g. TightVNC server installed and waiting for connections).
Machine B: will be used to remotely setup the virtual display driver on machine A.
steps:
Download virtualbox guest additions iso file on Machine A from here (for latest version check latest version here and download VBoxGuestAdditions_x.y.z.iso)
Extract iso file (possibly with winrar) into a directory (let us call it folder D)
using command prompt cd to D folder
Driver extraction
-To extract the 32-bit drivers to "C:\Drivers", do the following:
VBoxWindowsAdditions-x86 /extract /D=C:\Drivers
-For the 64-bit drivers:
VBoxWindowsAdditions-amd64 /extract /D=C:\Drivers
Goto device manager
add hardware
Restart and connect with VNC viewer, now you should be able to change screen resolution
other valuable info on launchpad.
I got SikuliX working in a true headless mode in GCE with a Windows 2016 client system. It takes some duct tape and other Rube Goldberg contraptions to work, but it can be done.
The issue is that, for GCE (and probably AWS and other cloud environment Windows clients), you don't have a virtual video adapter and display, so, unless there's an open RDP connection to the client, it doesn't have a screen, and SikuliX/OpenCV will get a 1024x768 black desktop, and fail.
So, the question is, how to create an RDP connection without having an actual screen anywhere. I did this using Xvfb (X Windows virtual frame buffer). This does require a second VM, though. Xvfb runs on Linux. The other piece of the puzzle is xfreerdp 2.0. The 2.x version is required for compatibility with recent versions of Windows. 1.x is included with some Linux distros; 2.x may need to be built from sources, depending on what flavor Linux you're using. I'm using CentOS, which did require me to build my own.
The commands to establish the headless RDP session, once the pieces are in place, look something like this:
/usr/bin/Xvfb :0 -screen 0 1920x1080x24 &
export DISPLAY=:0.0
/usr/local/bin/xfreerdp /size:1920x1080 /u:[WindowsUser] /p:"[WindowsPassword]" /v:[WindowsTarget]
In our environment we automated this as part of the build job kicked off by Jenkins. For this to work under the Jenkins slave, it was also necessary to run the Jenkins slave as a user process, rather than a service... this can be accomplished by enabling auto admin login and setting the slave launch script as a run (on logon) command.
For those looking to automate on ec2 windows machines, this worked for me: http://www.allianceglobalservices.com/blog/executing-automation-suite-on-disconnectedlocked-machines
In summary, I used RDC to connect, put the following code in a batch file on remote desktop, double clicked it, and sikulix started working remotely (kicking me out of RDC at the same time). Note that ec2 windows machines default to 1024x768 when tscon takes over which may be too small so TightVnc can be used to increase the resolution to 1280x1024 before running.
tscon.exe 0 /dest:console
tscon.exe 1 /dest:console
tscon.exe 2 /dest:console
tscon.exe 3 /dest:console
START /DC:\Sikulix /WAIT /B C:\Sikulix\runsikulix.cmd -d 3 -r C:\test.sikuli -f C:\Sikulix\log.txt -d C:\Sikulix\userlog.txt
I just figure out a way to resolve similar issue.
My env:
local: windows pc
remote (for running sikulix + app I would like to test): windows ec2 instance
My way:
1.create a .bat file, its contents:
ping 127.0.0.1 -n 15 > nul
for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do (
%windir%\System32\tscon.exe %%s /dest:console
)
cd "\path\to\sikulix"
java -jar sikulixide-2.0.5.jar -r /path/to/sikulix -c > logfile.log
prepare your app
run the bat (right click > run as administrator)
ping will give your 10s, so that you can bring your app back to front
you will be disconnnected from rdp connection
Explanation:
ping is like "sleep"
for loop: kick out current user & keep session alive