Windows Defender Firewall Inbound Rule for ICMPv6
Hi!
I'm getting more into IPv6 these days and found that ICMP is very important for IPv6 connectivity.
Windows Defender Firewall with Advanced Security (on Windows 10 at least) comes with some inbound ICMPv6 allow rules, but unfortunately they don't allow for quite enough.
I went ahead to create a rule by hand, but found out that you cannot set a group for the rule through the GUI, so instead I opted for creating a little PowerShell command.
You have to run it from a UAC-elevated PowerShell instance.
This rule is based on the existing default ICMPv6 rules.
Create the rule:
New-NetFirewallRule -DisplayName "Core Networking - CUSTOM - Allow Incoming ICMPv6" -Group "Core Networking" -Direction Inbound -Action Allow -Protocol ICMPv6 -Program System
Remove the rule again:
Remove-NetFirewallRule -DisplayName "Core Networking - CUSTOM - Allow Incoming ICMPv6"
Some people may want to exclude echo request for privacy or "security (through obscurity)" reasons, but I don't think it's that big of a deal.
Of course feel free to customize the command in general. The official documentation page (docs.microsoft.com) is very informative.
If you have any other firewalls between you and the sender, you may have to check their rules as well.
I tested the rules with a website like ipv6-test.com.
Thanks for reading!
(Re)Setting Hyper-V Virtual Machine Client Zoom Level
Hi!
A couple of days ago I was playing around with Hyper-V virtual machines. At some point I set the "View" => "Zoom Level" to 25%.
Unfortunately, at 25% the window becomes so small that you cannot see the View menu in the menu bar any more because it gets cut off. And for some reason you cannot use the arrow keys on the keyboard to navigate the menus either.
This zoom level not only applies for a single virtual machine, but all of them, as it as a general Hyper-V client setting.
Trying to access the menu when the VM is shut down does not work because the "Zoom Level" submenu is disabled, and once the VM is booted up, the window resizes instantly.
The only reliable way to (re)set it appears to be editing the Hyper-V client configuration on the host file system:
- Close the Hyper-V client window (the one that opens when you connect to / double-click a VM)
- Open the file at
%UserProfile%\AppData\Roaming\Microsoft\Windows\Hyper-V\Client\1.0\vmconnect.configand set the setting withZoomLevelback to100(or something similarly usable):<?xml version="1.0" encoding="utf-8"?>
<configuration>
<Microsoft.Virtualization.Client.InteractiveSession.InteractiveSessionConfigurationOptions>
<setting name="ZoomLevel" type="System.UInt32">
<value>100</value>
</setting>
[...]
</Microsoft.Virtualization.Client.InteractiveSession.InteractiveSessionConfigurationOptions>
</configuration> - Save and close the file
- Connect to / double-click a VM again
I hope this was helpful to you.
Thanks for reading!
Source: How to restore auto zoom level in Hyper-V VM window (answers.microsoft.com) - Answer by Trond.R. on November 27, 2020 (Sorry, apparently you can't link to answers directly)
Uploading a Snapshot to a Fresh Home Assistant OS Instance
Hi!
After finding that my previously running Home Assistant OS instance was no longer working let alone starting properly, I decided to wipe it and simply install from a fresh image today. In order to pick up where I left off, I wanted to restore from a snapshot that I made a short while ago.
Out of the box, Home Assistant OS does not seem to come with any way to upload snapshots (or any other kind of files) onto the instance. Usually, this would not be a problem, because I had previously used the Samba share add-on from the official add-on repository, but since updating it to the new repository website, the Samba share add-on seems to have disappeared.
My first alternate approach using the SSH access did not work either, as I could not use SFTP because it is not effectively using proper SSH/SFTP but an intermediate wrapper for the Home Assistant console.
The quickest way I found that had minimal impact on the system in terms of creating a mess was to use Docker and download my latest snapshot from a web server hosted somewhere else via cURL. In this case I was using a self-hosted Nextcloud instance with a shared file link, but your mileage may of course vary.
Prerequisites / Assumptions
- You are using the Home Assistant OS official image on a device in headless mode, so you have a minimal system without neat tools like curl or wget pre-installed.
- You have uploaded the snapshot file to a web server that is accessible from the Home Assistant OS system (in terms of network connectivity).
Steps
- Enable SSH access by following the official documentation on how to enable SSH access to the host.
- Update from 2020-05-21: They seem to have restructured the documentation and the original instructions are no longer on that page. It used to say:
Use a USB drive formatted with FAT, ext4, or NTFS and name it CONFIG (case sensitive). Create an "authorized_keys" file (no extension) containing your public key, and place it in the root of the USB drive. File needs to be ANSI encoded (not UTF-8) and must have Unix line ends (LF), not Windows (CR LF). [...] From the UI, navigate to the Supervisor system page and choose "Import from USB". You can now access your device as root over SSH on port 22222. Alternatively, the file will be imported from the USB when the Home Assistant OS device is rebooted.
- Update from 2020-05-21: They seem to have restructured the documentation and the original instructions are no longer on that page. It used to say:
- Log into the Home Assistance OS instance via SSH.
- Type the command "login" to enter the actual shell.
- Use the following command to download the snapshot file:
docker run --rm curlimages/curl https://my.server.local/a1b2c3d4.tar > /mnt/data/supervisor/backup/a1b2c3d4.tar
(Change URL and file names of course. The destination directory should be fine.) - You might want to check file integrity for the file via md5sum or sha512sum etc.
- If you want to be extra tidy, you can remove the cURL Docker image again by executing
docker image rm curlimages/curl - Close the SSH session and open a new one.
- Do not enter the actual shell but instead execute this command to get Home Assistant to notice the newly uploaded snapshot:
snapshots reload - Now log into the Home Assistant web interface or just keep using the console and restore what you need.
- Done!
I hope this saved you a bunch of research because I myself could not find anything quick and practical on this topic.
Thanks for reading!
Fix GNOME GUI Login After Upgrade to Debian 10 Buster (VirtualBox VM)
Hello!
Yesterday I upgraded my old Debian VirtualBox VM from Debian 9 stretch to Debian 10 buster.
After going through all the usual upgrade steps from the official documentation and rebooting, I found myself waiting for the GNOME user selection in order to log in. Except that it was stuck with the gray background and nothing except the mouse cursor was showing up or working.
I switched to a text-only terminal (Ctrl+Alt+F5) and logged in via command line. Looking at /var/log/syslog I found the following messages repeating over and over:
gnome-shell[1281]: Failed to set CRTC mode 1448x953: Invalid argument kernel: [ 192.917346] [drm:drm_crtc_helper_set_config [drm_kms_helper]] ERROR failed to set mode on [CRTC:29:crtc-0]
1448x953 is the resolution I am using for the VM.
This current VM was created back when Debian 7 wheezy was still current, and I knew that a more recently created VM (originally with Debian 9 stretch) was working fine after upgrading to 10, so I figured that the info about the resolution from gnome-shell might have something to do with the VM's settings.
Sure enough, I found out that there were about a handful of settings that were different, most likely because over time VirtualBox defaulted to slightly different settings depending on my hardware, the template for the OS I selected (different Debian major releases) and the VirtualBox release itself. A couple of VM starts and configuration changes later I narrowed the problem down to the following VM setting:
Display => Screen => Video Memory
I raised the original 12 MB to 16 MB and thankfully the next boot showed the GNOME login mask as per usual!
Surely this is a very edge case kind of scenario, but I am hoping that this might help you in case you come across the same problem. All the other search results I found regarding roughly the same error message in the logs were about different things.
Thanks for reading!
Disable Autoplay For Videos in Firefox 63
Hi!
Just after updating to Mozilla Firefox 63 (on Windows), I found that my setting to disable autoplaying media / videos was no longer effective - at least for HTML5 videos.
Apparently one of the changes for this release was to include an autoplay video blocker, but I could not find anything definitive about this in the settings.
I decided to disable autoplay for all videos (which is my preferred setting anyway) once again by doing the following:
- Open the config editor by entering about:config in the navigation bar.
- Enter the "autoplay" as a filter.
- Find the entry "media.autoplay.default", double-click it and set it to "1" to disable media autoplay browser-wide.
I just left the old setting "media.autoplay.enabled" as "false", even though it does not seem to be relevant any more.
After reloading the website with the video (in this case YouTube), once more it showed the play icon on top of the video instead automatically starting playback.
I hope this was helpful.
Thanks for reading!
Using Git Bash With Custom Installation Of GPG / GnuPG
Hi!
You have probably noticed that Git for Windows comes with MinGW64, which enables you to use programs (or to be more precise: Windows versions of these programs) that are usually only available to Linux users. One of the programs that MinGW64 / Git for Windows ships with is GPG / GnuPG. The current version of Git for Windows (2.17.1) for example comes with GPG version 1.4.22.
If you prefer using a custom installation of GPG / GnuPG by default, which is probably much more current than the one you installed manually (2.x), you can achieve this by doing the following:
- Install GPG as you normally would
- Make sure it is executable in the command line / PowerShell (as in: make sure the bin/ subdirectory of the GPG program directory is included in the PATH environment variable)
- Go to the Git for Windows program directory (e.g. C:\Program Files\Git\)
- Navigate to the usr/bin/ subdirectory and rename gpg.exe to something else (like gpg_disabled.exe)
- Close any open Git Bash instances and start a fresh one
- Check the GPG version via
gpg --version
The way that Git Bash works is that is has its own set of directories which have a higher priority when looking for executable files than the ones in Windows' PATH environment variable. So in order to have your own GPG executable working as the "gpg" command, you have to get the included gpg.exe out of the way so it keeps looking in Windows' PATH environment variable.
You can still access the old GPG executable by using the new name (e.g. "gpg_disabled").
Unfortunately you have to do these steps every time you install or update Git for Windows, but at least now you know where to look!
The upside is that now Git (executed from the Git Bash) also uses your own version of GPG for its GPG-related operations.
I hope this was helpful.
Thanks for reading!
Rewrite MySQL / MariaDB Database Dump Create View Statements For Current User
Hi!
If you would like to import a database dump file created by MySQL's or MariaDB's mysqldump executable, but it contains statements to create views, the import process may abort with an error when it comes to creating views.
When creating a view, MySQL wants to know who created it, and for that it needs a username and the host. If the user who is executing the import does not have sufficient privileges or the original user referenced in the dump does not exist (for example when importing the dump into a fresh database for a migration), this leads to an error.
Usually when I import a dump, I don't care so much about the "SQL Security Definer", so I just want to set it to the importing user.
You can generate a new, modified SQL dump file very easily with the following shell command:
$ sed -r 's#^(/\*!50013 DEFINER=).+?( SQL SECURITY DEFINER \*/)$#\1CURRENT_USER\2#' input_file.sql > output_file.sql
This command simply scans through the entire dump, looking for the statement created by mysqldump which triggers the database to create the view if it doesn't exist already. It then sets the user information to CURRENT_USER which refers to the user that is currently executing the import.
Please note that because the search pattern is so specific, it will probably require some modification in the future, depending on the version of mysqldump you're using and if / how they change this particular statement. On the upside the chance that it will accidentally modify something it shouldn't is pretty low.
I hope this is helpful to you!
Thanks for reading!