Unable to download scripts in VUgen after connecting to HP PC - performance-testing

I am receiving an error while downloading the scripts from PC to VuGen. I have logged into the respective project in PC and able to see the scripts but I'm unable to download.
This is the error I'm receiving while I try to download the scripts:
Downloading is not permitted
Could not load script. No script was found in folder
Also the download option in PC is disabled.

Related

My remote server can't start nodejs service

My remote server is installed with centos system, but after downloading and installing the nodejs program released from the official website, my project cannot be executed, and the webpage provided by the .js file service of the project cannot be opened remotely.

Debugging VSCode Extension within a remote container

I'm currently using vscode-tomcat extension within a RHEL7 container and developing over SSH using the vscode-remote extension. However, I am unable to launch the tomcat debugger due to this unresolved issue.
"TypeError: Cannot set property 'readableListening' of undefined"
The issue only occurs when trying to launch the Tomcat debugger while doing remote SSH development. I am making an attempt to debug the issue, but I'm not sure how to debug a VSCode extension within a remote container.
Any tips would be greatly appreciated. Let me know if I can provide any additional details.
There is now documentation for all of this. Read
https://code.visualstudio.com/api/advanced-topics/remote-extensions#debugging-using-ssh
and then keep reading because further down you will find this
https://code.visualstudio.com/api/advanced-topics/remote-extensions#debugging-using-ssh
in fact read all of it, there's a lot of stuff there that initially made me think "So?" but which is vital knowledge in specialised problems.
Here's the portion relating to the immediate problem.
Debugging using SSH
Follow steps:
After installing and configuring the Remote - SSH extension, select Remote-SSH: Connect to Host... from the Command Palette (F1) in VS Code to connect to a host.
Once connected, either use File > Open... / Open Folder... to select the remote folder with your extension source code in it or select Git: Clone from the Command Palette (F1) to clone it and open it on the remote host.
Install any required dependencies that might be missing (for example using yarn install or apt-get) in a new VS Code terminal window (Ctrl+Shift+` ).
Finally, press F5 or use the Run view to launch the extension inside on the remote host and attach the debugger.
Note: You will not be able to open the extension source code folder in the window that appears, but you can open a sub-folder or somewhere else on the SSH host.
The extension development host window that appears will include your extension running on the SSH host with the debugger attached to it.
Installing a development version of your extension
Anytime VS Code automatically installs an extension on an SSH host, inside a container or WSL, or through GitHub Codespaces, the Marketplace version is used (and not the version already installed on your local machine).
While this makes sense in most situations, you may want to use (or share) an unpublished version of your extension for testing without having to set up a debugging environment. To install an unpublished version of your extension, you can package the extension as a VSIX and manually install it into a VS Code window that is already connected to a running remote environment.
Follow these steps:
If this is a published extension, you may want to add "extensions.autoUpdate": false to settings.json to prevent it from auto-updating to the latest Marketplace version.
Next, use vsce package to package your extension as a VSIX.
Connect to a codespace, development container, SSH host, or WSL environment.
Use the Install from VSIX... command available in the Extensions view More Actions (...) menu to install the extension in this specific window (not a local one).
5.Reload when prompted.
Tip: Once installed, you can use the Developer: Show Running Extensions command to see whether VS Code is running the extension locally or remotely.

scp from Linux to Windows: 'C:\Program' is not recognized error

In my linux machine, I'm trying to send a file over to a Windows machine via:
scp fileNameA user#windowServer:fileNameA
I get the following message:
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
What's prompting this message?
I've installed OpenSSH on the windows machine, and I can successfully SSH into it. I don't want to use WinSCP, FileZilla, etc, because I have to automate this in a script. This has to be done from the Linux machine, so I'm not interested in doing pscp from the Windows machine.
I have met the same problem today.
I think it is an issue in the new version of OpenSSH, which was published few days ago. I reverted previous version (v7.6.1.0p1-Beta), which was working correctly on my VM from https://github.com/PowerShell/Win32-OpenSSH/releases and problem was fixed without any changes in configuration.
I just fixed the same problem by moving my installation of OpenSSH from C:\Program Files\OpenSSH to C:\OpenSSH.
I had to first uninstall it properly using the provided script in Win32-OpenSSH and then follow back the information provided there https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH but only changing the path to C:\OpenSSH.
I met a similar issue today, trying to copy files to a Windows server running OpenSSH-Win64. I solved the problem by adding C:\Program Files\OpenSSH, which is the recommended installation location, to the Windows path:
Open the Control Panel, go to the System and Security section and open up System.
Click on Advanced System Settings and, in the System Properties dialog box, click Environmental Variables.
In the System Variables section of the dialog box, select Path and click Edit....
Click New, add the OpenSSH folder path and click OK to apply the change.
Then, do not forget to restart the OpenSSH service, either in the service management console or by running net stop sshd, followed by net start sshd in an elevated console.

NodeJS Installer wont open on Vista

From the NodeJs website I have downloaded node-v0.12.3-x86.msi to a Windows Vista PC.
It just doesnt install. No error appears. I tried restarting. I even Googled it a million times.
Anyone know how to install NodeJS?
Peace and love to you all.
The file might be blocked because it was downloaded from the Internet. On Windows Vista if you attempt to install a blocked MSI file, the file is not installed and no error is reported. Unblock the file by:
Right click on the file and click Properties.
In the properties dialog click Unblock.
Close the dialog.
Install the file.
If that doesn't work try installing with diagnostic logging from the command line using msiexec:
msiexec /l*v Desktop\Install.log /I Desktop\node-v0.12.3-x86.msi
Note: This assumes you are running the command from your user directory: C:\Users\<your name>.

vmware player unable to start services in kubuntu

my environment:
kubuntu : 3.2.0-generic-pae
vmware player: VMware-Player-4.0.4-744019.i386.bundle
And i have been installed it.
$sh VMware-Player-4.0.4-744019.i386.bundle
I have a problem, when i launch "menu->system->VMware Player"
it launch a window and start compiling:
[ok] Virtual Machine Monitor
[failed] Virtual Network Device
[ok] VMware Blocking Filesystem
[ok] Virtual Machine Communication Interface
[ok] VMCI Sockets
[result fail]Starting Vmare Services
See log file /tmp/vmware-root/modconfig-2722.log for detail
from log file:
[msg.dictionary.load.openFailed] Cannot open file "/usr/lib/vmware/settings":
No such file or directory.
[msg.dictionary.load.openFailed] Cannot open file "/root/.vmware/config":
No such file or directory.
[msg.dictionary.load.openFailed] Cannot open file "/root/.vmware/preferences"
No such file or directory.
Failed to find /lib/modules/preferred/build/include/linux/version.h
Failed to compile module vmnet!
Could some people tell me what's wrong ?
I suppose that there are no linux headers installed on your machine, that is why it is impossible to build the vmnet module. You must install headers and then try once again.
Ok, I've had the same problem this evening when upgrading from 4.0.3 to 4.0.4. What I've found to work is to first download the patch from this VMWare community thread - http://communities.vmware.com/thread/344213
Unzip it and then open the patch-modules_3.2.0.sh in gedit. There will be three lines at the top that read:
fpatch=vmware3.2.0.patch
vmreqver=8.0.2
plreqver=4.0.2
You have to change the plreqver=4.0.2 to plreqver=4.0.4
Then, open your terminal and run
sudo ./patch-modules_3.2.0.sh
As a side note, keep that file handy, because I found that I had to do the same thing when upgrading from 4.0.2 to 4.0.3 in Ubuntu 12.04. However, when you try the same again in the next upgrade (e.g. change the plreqver to 4.0.5 and run the script), it will say that the file is already patched and it won't work.
To get around this, you need to go to the "/usr/lib/vmware/modules/source/" folder, find the hidden file called ".patched", and delete it (easiest option is to "sudo nautilus" in terminal and hunt through the folder structure). Then it thinks that it hasn't been patched and does the process again.
Hope this gets your VMWare back up and running.

Resources