I have an issue with VS Code and WSL remote extension. On my machine, Windows Defender Firewall blocked node. I do not have sufficient rights to unblock it, but admins created excluded folder, where based on what they said "I can copy everything that I will need and it is excluded from Windows Defender Firewall check". So I copied VS Code there but I need to also copy the package with Debian Linux there and link it to the new path.
But I was not able to find where this path to Debian is stored, and how it can be changed. For me, the folder is now in
C:\Users\{username}\AppData\Local\Packages\TheDebianProject.DebianGNULinux_... and need to be moved to C:\ExcludedFolder
Is this possible? Thank you very much for your response.
First up, you might be able to solve your firewall problem a slightly different way. I can't say for certain (and things are always changing), but it's been my experience that Firewall/Defender only detect and block for WSL1 applications. This is at least true for the malware/antivirus detection, but I believe it would extend to the firewall functionality as well. On the other hand, if it doesn't, then moving the instance to a different directory may not help with your issue.
You can double-check the version of your Debian instance using wsl -l -v. If it's version 1, then let's try converting it to 2 (if you have that permission on your system).
The first steps here are going to be the same regardless of whether you just convert the instance or move it:
First, exit your WSL/Debian instance and then issue wsl --shutdown. You can do this from PowerShell, CMD, or the Start Menu; but I'm going to assume for the rest of the instructions that you are in PowerShell.
Run the following in PowerShell:
cd <your exclusion directory>
mkdir wsl\images
cd wsl\images
wsl --export Debian 2021-11-02_Debian_backup.tar
Assuming that your instance is WSL1 and you want to try to convert to WSL2, you at least now have a backup. Run wsl --set-version Debian 2 to convert it to WSL2. Then start it up and see if there are any differences in how node behaves. You can always convert it back with wsl --set-version Debian 1, of course.
If you still need to try moving it:
cd <your exclusion directory>\wsl
mkdir instances\debian_exclude
wsl --import debian_exclude instances\debian_exclude images\2021-11-02_Debian_backup.tar --version 2
wsl -d debian_exclude
Note that you can, of course, call the filenames and directories whatever you want. Also note that you can change the version number when you import it. Select whichever WSL version you need there.
You should now be in a new instance of Debian, but you'll be running as root by default. You need to set the default user of the imported instance by creating /etc/wsl.conf with the following:
[user]
default=<your_wsl_username>
Exit the instance, run another wsl --shutdown, and restart. You should now be running as your normal user. Try node again there to see if new location allows it to be excluded from the firewall rules.
If everything is working as intended, you can wsl --unregister Debian to remove the old instance. Please note that this will remove all files in the instance, so please make sure that your backup and new instance have everything you need first.
Unregistering the old instance should set the new one as your default, but if not, you can use wsl --set-default debian_exclude.
Related
I have a local vscode installed for windows.
Afterwards I setup wsl-2 and use it as my shell.
When I tried to open a file with code using the code filename command, it installed vscode anew instead of using the local windows install.
Installing VS Code Server for x64 (054a9295330880ed74ceaedda236253b4f39a335)
Is there a way to point wsl to use the windows install when triggering it via the code command?
I don't specifically mind using either or, but settings/extensions etc. for one are not used by the other.
By checking with Git Bash where the location of code is when triggering it (type -a code) and comparing it to the ubuntu wsl shell, I came to the conclusion, that it is actually the same install that is being triggered, . I will have to check why some extensions do not seem to "carry over" though.
The code that is being triggered is a script, that behaves differently when being triggered from within WSL.
How about an alias?
# Set alias
alias code2='/mnt/c/Users/Username/AppData/Local/Programs/Microsoft\ VS\ Code/bin/code'
# Open a file now
code2 file.txt
I have a docker container I wrote that sets up AWS profiles for me. In Linux it works great, on WSL it partially works.
When I run the container I am mounting the ~/.aws directory, checking if the profiles exist and if they don't exist I create them. If they do exist I don't do anything.
In Linux I can run this container and then continue to use aws-cli with no problems.
In Windows subsystem for Linux - when I run the container the first time around, it will create the profiles for me. If I choose to run the container again it sees that the profiles already exist so it does nothing. This tells me the file exists somewhere but I cant use aws-cli because the file doesn't exist at ~/.aws.
So my question is where is ~/.aws in WSL when mounted to a docker container? I've attempted to do a find on the entire filesystem in WSL and that returns nothing. I've also tried changing the mount path to /root/.aws and I run into the same conditions.
EDIT:
I still don't know the answer to my question above. But if anyone comes across this question I did find a work around.
I've updated Docker Desktop to allow mounting the entire c:/ drive. Then I just changed my docker run command to mount c:/.aws instead of ~/.aws, so my command looks like -v c:/.aws:/root/.aws. After that I added this environment variable in WSL export AWS_SHARED_CREDENTIALS_FILE="/mnt/c/.aws/credentials" and now aws cli picks up on my profile changes.
The shell always expands ~ to the value of the HOME environment variable. If that environment variable is not set, then it expands to nothing. If you want to find where ~/.aws is located, then you can write something like echo ~/.aws and the shell will expand it for you.
The only exception is that ~user expands to the home directory of the user user; the HOME environment variable is not consulted there.
You have to remember that in your setup the docker engine (docker for windows) is installed on windows, it is inside the windows environment that the docker command is 'launched'. So when you say use ~/.aws it looks in the windows file system for this location.
In windows ~ is a valid directory name (try mkdir ~ from a cmd prompt) so when you say map ~/.aws I'm unsure what actually gets created. maybe try searching your c drive for a folder called ~. There is no ~ shortcut in windows for the home folder, and if there was which home would it be? the home of the logged in windows user? or the home inside WSL?
To make this work in WSL you need to pass ~/.aws to wslpath like this:
➜ echo $(wslpath ~/.aws)
/mnt/c/home/damo/.aws
But this location is the path according to WSL not windows you need to do it twice with the -w flag the second time
➜ echo $(wslpath -w $(wslpath ~/.aws))
C:\home\damo\.aws
which would make your final docker command look like this:
docker run -it -v $(wslpath -w $(wslpath ~/.aws)):/root/.aws awsprofileprocessor:latest
With this you will now be telling docker for windows the windows path to put the mount
Please let me know if this works for you, I'm interested in how it turns out.
I am running PhpStorm on Linux Mint installed in /opt. PhpStorm is notifying me that there is an update available (8.0.3), but then it tells me it doesn't have write permission to apply the update, and that I should run it as a privileged user to update it.
If I run phpstorm.sh as root/sudo it asks for license info and looks as though it's running the installer rather than the program. PhpStorm is licensed when I run it from the desktop.
So how can I run updates?
I had the same issue and was able to change ownership of the PhpStorm folder to get it to work. Assuming your username is newownername and PhpStorm installation is located in /opt/phpstorm, the command should look like this:
chown -R newownername /opt/phpstorm
Note that you should change username and path to appropriate values.
No need (and not recommended) to change the ownership or the permissions of the opt/phpstorm directory. In fact, the error message returned says exactly what you should do: run it as a privileged user to update it.
After exiting PHPStorm, you can run it as a privileged user using the following instructions
sudo updatedb && sudo locate phpstorm.sh
sudo /path/to/phpstorm.sh
The first instruction updates the locate database and returns the location of the phpstorm executable in your computer.
Use the returned location as the path in the second instruction.
When starting PHPStorm as root, it will start with the default settings. It might even ask you if you want to apply your license... No need to change any of this: the default settings and running PHPStorm in evaluation mode will work just fine. After it starts, check for updates in the menu Help and apply them normally. PHPStorm might restart once again as root. Just close it once more and restart normally. When restarting as your user, you'll be given the ability to select your normal settings (usually stored in your user's directory: the path will be suggested). Accept and continue. PHPStorm will start with all your preferences and settings restored and properly upgraded.
If plugin updates are required, you can update them normally. No need to do it using root.
This solution is recommended by JetBrains. Changing the ownership or the permissions of the opt/phpstorm directory is not recommended and in fact pointed as incorrect by Jet Brains, as you can verify on their answer regarding the process of upgrading a similar product: Fixed: PyCharm automatic update fails on Linux due to permissions.
sudo chown -R $USER:$USER /opt/PhpStorm* , worked for me.
JetBrains are publishing their entire IDE portfolio as snaps, including PHPStorm. Snaps work on all supported versions of Ubuntu, including 14.04 and on Linux Mint 17.x and 18.x.
Some of the advantages of the JetBrains snaps are that they are always up to date, will automatically stay updated and are very easy to install.
To install PHPStorm in Ubuntu or Linux Mint:
sudo apt install snapd
sudo snap install phpstorm --classic
I know the purpose of "biosdevname" feature in Linux, but I'm not sure how
exactly it works.
I tested it with Ubuntu 14.04 and Ubuntu 14.10 (both 64-bit server editions)
and it looks like they enable it by default - right after system startup my
network interface has a name such as p4p1 instead of eth0, no customization
is needed. As I understood it, in order for biosdevname to be enabled, BOTH
of these two conditions must be met:
a boot option biosdevname=1 must be passed to a kernel
biosdevname package must be installed
As I already mentioned, both Ubuntu 14.04 and 14.10 seem to offer biosdevname
as a default feature: they come with biosdevname package already installed, I
didn't need to modify grub.cfg either - GRUB_CMDLINE_LINUX_DEFAULT has no
parameters and my network interface still has a BIOS name (p*p*) instead of a
kernel name (eth*.)
Later I wanted to restore the old style device naming and that's where the
interesting part begins. I decided to experiment a bit while trying to disable
the biosdevname feature. Since it requires biosdevname package to work (or
so I read here and there), I assumed removing it would be enough to disable the
feature, so I typed:
sudo apt-get purge biosdevname
To my surprise, after reboot my network interface was still p4p1, so
biosdevname clearly still worked even though biosdevname package had been
wiped out.
As a next step, I applied appropriate changes to /etc/network/interfaces in
order to restore the old name of my network interface (removed entry for p4p1
and added entry for eth0). As a result, after another reboot, ifconfig
reported neither eth0 nor p4p1 which was another proof that OS still
understood BIOS names instead of kernel names.
It turned out that I also had to explicitly change GRUB entry to
GRUB_CMDLINE_LINUX_DEFAULT=biosdevname=0 and update GRUB to get the expected
result (biosdevname disabled and old name of network interface restored).
My question is: how could biosdevname work without biosdevname package? Is
it not required after all? If so, what exactly provides the biosdevname
functionality and how does it work?
The reason biosdevname keeps annoying you even after you uninstall the package, is that it installed itself in the initrd 'initial ramdisk' file as well.
When uninstalling, the /usr/share/initramfs-tools/hooks/biosdevname is removed, but there is no postrm script in the package so update-initramfs is not executed and biosdevname is still present in the /boot/initrd... file used in the first stage of system startup.
You can fully get rid of it like this:
$ sudo update-initramfs -u
I'm developing a little program that creates virtual joysticks on linux, with a python front end. It is a fork of Linux-Virtual-Joystick.
I need to write to dev/uinput in order to create the user-defined joystick.
The file is opened with O_RDWR (I temporarily added read/write access others for the file whilst debugging). When I do
write(uifd, &uidev, sizeof(uinput_user_dev));
it returns -1 and sets errno to 22(EINVAL). The arguments are correct, and the file was successfully opened.
Did anyone else encounter this problem? I shelved the project for about a month, but I remember that it worked in the last version of Ubuntu.
Update: uinput works on ubuntu 12.10
I think the problem you have is with access rights to uinput. The error message you receive is typical of that and I have seen the identical behaviour before with other devices.
In order to test that assumption, change the /dev/uinput permissions to allow access to all:
chmod +0666 /dev/uinput
Then try again your code. If now it works fine, you will need to make that change permanent, since otherwise it will revert back to the original permissions after reboot.
To do that in a safe fashion, add a rule file to be located at: /etc/dev/rules.d
with the following line:
KERNEL=="uinput", GROUP="udev_group"
To see how a rule file should look like, check the udev rules file located at:
/lib/udev/rules.d/50-udev-default.rules
When ready, add a a group named udev_group and add your user name to it (or any user that is supposed to have write access to uinput).
You may need to reboot to get the new rule working.
The outcome would be that any user who's member of that group will have full access to uinput, which is exactly what you wanted.
to add the group you can install "Users and Groups":
sudo apt-get install gnome-system-tools
and launch it at:
Application -> System Tools -> Administration -> Users and Groups**
or in terminal:
gnome-system-tools
Since uinput module is missing, you should consider building it before going further.
I've never rebuilt a Linux kernel module this way, so you can follow the explanation here
First, you need to get the corresponding Linux source code and headers. Also install module-init-tools
Then, change dir to /usr/src/linux and do as root
cp /boot/config-* ./.config
make drivers/input/misc/uinput.ko
It'll take a minutes to build uinput.ko
Check if it works before move uinput.ko to /lib/modules/<"yourkernelversion">/kernel/drivers/input/misc
insmod ./drivers/input/misc/uinput.ko
Edit 1:
It seems that since Linux 2.6.35-17.23, uinput is a built-in module. That's why it's not shown by lsmod.
I have just taken a look at your code, and I think the problem is in this line
if (write(uifd, &uidev, sizeof(uinput_user_dev) != sizeof(uinput_user_dev)))
It should be
if (write(uifd, &uidev, sizeof(uinput_user_dev)) != sizeof(uinput_user_dev))
Hope that helps
I had this error in Ubuntu 14.04 too, from your repo (https://github.com/ferry-/Linux-Virtual-Joystick-cpp) . I fixed it by zeroing out the device::uidev member in the device constructor in device.h.
memset(&uidev, 0, sizeof(uidev));