By default, trimming is disabled in Debian Buster. If you have an SSD, you can enable periodic trimming:
$ sudo systemctl enable fstrim.timer
The alternative is continuous trimming, which is enabled by passing discard option to the filesystem in /etc/fstab/.
Installing Firefox via Snap is an easy way to get the latest Firefox version on your favorite distro, regardless of the version the distro ships with. However, due to Snap’s security model, Yubikeys, or any other FIDO tokens do not work out of the box. To enable U2F devices, like Yubikeys, you need to give the Firefox package the necessary permissions manually:
$ snap connect firefox:u2f-devices
A quick and secure way to generate numerical PINs. The only dependency is coreutils so it should work on almost any system out-of-the-box.
$ shuf --random-source=/dev/urandom -i 0-9 -r -n 6 | paste -sd ''
659010
The following snippet should work on every system that has coreutils.
$ shuf /usr/share/dict/words --repeat --random-source /dev/random -n 5
You can swap /usr/share/dict/words with any good wordlist, like EFF’s or Arnold Reinhold’s Diceware list.
You can also add it for ease of use to your ~/.bash_aliases
alias passphrase="shuf ~/dotfiles/misc/diceware8k.txt --repeat --random-source /dev/random -n"
And then you could easily use it in bash:
$ passphrase 5
notch
kane
to
drag
cater
By default, when you touch a Yubikey it types an OTP code. These codes looks like:
cccjgjgkhcbbirdrfdnlnghhfgrtnnlgedjlftrbdeut
Theoretically they are used for Yubico’s proprietry authentication, but in reality they are mostly annoying. This is especially true for Yubikey Nano, which is impossible to remove without touching it and triggering the OTP.
Disabling the OTP is possible using the Yubikey Manager, and does not affect any other functionality of the Yubikey.
$ sudo apt install yubikey-manager
$ ykman config usb --disable otp
Disable OTP.
Configure USB interface? [y/N]: y
Note for Yubikey 4: the above command will not work and fail withe the following error:
Error: Configuring applications is not supported on this YubiKey. Use the `mode` command to configure USB interfaces.
Instead use the following command:
$ ykman mode FIDO+CCID
Set mode of YubiKey to FIDO+CCID? [y/N]: y
Mode set! You must remove and re-insert your YubiKey for this change to take effect.
Virtual Machine Manager (virt-manager) doesn’t automatically start your virtual networks. This leads to the following error when starting a vitual machine
Error starting domain: Requested operation is not valid: network 'default' is not active
To solve this error, on Virtual Machine Manger go to Edit->Connection Details->Virtual Networks, select the required network (‘default’ in our case) and press the Start Network button (has a play-button icon). You can avoid having to go through this process by ticking the Autostart checkbox, which will make the network start automatically at boot.
After a recent upgrade to Debian Stretch, my OpenVPN server stopped working. Checking the relevant log file, /var/log/openvpn.log, I found the following not very helpful error message.
Fri Nov 23 16:46:37 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017 Fri Nov 23 16:46:37 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08 Fri Nov 23 16:46:37 2018 daemon() failed or unsupported: Resource temporarily unavailable (errno=11) Fri Nov 23 16:46:37 2018 Exiting due to fatal error
Fortunately, someone already reported this error to debian and found out that the error is caused by the
LimitNPROC=10
in the /lib/systemd/system/openvpn@.service. The LimintNPROC directive in systemd is used to limit the number of forks a service is allowed to make. Removing this limit, might not be the best idea. So, I would suggest that instead of commenting it out, to find out the minimal value that allows OpenVPN to start and work. After some testing, I found that the minimal value that worked for me is
LimitNPROC=27
After editing the /lib/systemd/system/openvpn@.service, you need to reload the systemd service files and restart the OpenVPN server process.
$ sudo systemctl daemon-reload $ sudo systemctl restart openvpn@server
Sharing data between guest and host system is necessary in many scenarios. If the guest is a Linux system, you can simply add a shared folder that will be automatically mounted. However, this does not work if the guest is Windows. Sometimes, you can simply workaround it by using Samba shares, but in some scenarios network configuration makes it difficult. For example, when using usermode networking, the host machine can’t communicate easily via the network with the guest.
However, there is another way to share folders in virt-manager that actually works for Windows guest – SPICE . The first step is to configure the sharing in virt-manager. In the VM details view, click on “Add Hardware” and select a “Channel” device. Set the new device name to org.spice-space.webdav.0 and leave the other fields as-is.
Now start the guest machine and install spice-webdav on the guest machine. After installing spice-webdav make sure the “Spice webdav proxy” service is actually running (via services.msc).
Now running C:\Program File\SPICE webdavd\map-drive.bat will map the shared folder, which is by default ~/Public. If you encounter the following error
System error 67 has occurred.
the network name cannot be foundIt means that the Spice webdav proxy service is not running.
If you want to change the shared folder, you will have to use virt-viewer instead of virt-manager, and configure it under File->Preferences.
You can use the xdg-mime utility to query the default mime-type associations and change them.
xdg-mime query default video/mp4
Will return the .desktop file associated with the default app to open mp4 files. To change the default association:
xdg-mime default vlc.desktop video/mp4
you need to specify the desktop file to open files of the specified mime type. To check the mime-type of a given file, use
file -ib filename
Duply is a convenient wrapper around duplicity, a tool for encrypted incremental backups I’ve used for the last couple of years. Recently, after a recent upgrade, my Amazon S3 backups failed, reporting the following error:
'Check your credentials' % (len(names), str(names)))
NoAuthHandlerFound: No handler was ready to authenticate. 1 handlers were checked. ['HmacAuthV1Handler'] Check your credentials
Boto, the backend duplicity relies on for the Amazon S3 backend, requires to pass authentication parameters through the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables. As different backends require different variables, duply used to make that transparent, one would just set TARGET_USER and TARGET_PASS and duply would take care of the rest. However, duply 1.10 broke compatibility and requires you to set the variables yourself. Hence, the fix is to replace the TARGET_* variables with exported AWS_* variables:
# TARGET_USER='XXXXXXXXXXXX' # TARGET_PASS='XXXXXXXXXXXX' export AWS_ACCESS_KEY_ID='XXXXXXXXXXXX' export AWS_SECRET_ACCESS_KEY='XXXXXXXXXXXX'