Clementine music player - boolean search operators

Clementine was forked from Amarok 1.4 a while back, and ever since has been my favorite music library/player.

I'm using Clementine version 1.4 rc1 but I'm sure this feature in the stable version 1.3.1 as well: boolean search operators.

So far all I can get to work is OR, AND, -, and () inside the sub-playlist search field. The global search and Library search don't support any of this stuff. For example: 

(rating:3.5 OR rating:4 OR rating:4.5 OR rating:5) AND genre:rock AND artist:-audio

will filter your playlist down to just high rated songs of any genre containing the word "rock" like "Classic Rock", "Christian Rock", and plain old regular "Rock". Without the parenthesis that AND would only apply to the term "rating: 5" so it'll show all songs with rating between 3.5 and 4.5 of any genre, and only 5-star songs of a genre like "rock" or "Punk Rock" and so on. You'll get no 5-star Ska in that search, only lesser rated Ska. Moreover, the `artist:-` part means you'll be without any artist matching the substring "audio" so that means no Audioslave nor Audio Adrenaline

Like I said: this only works in the search field above each playlist (below the tab bar). It doesn't work in the library search or the global search.

This was first published 2020-10-25 but then I discovered the minus sign after failing with `!` and `NOT` and so on so I updated this post on 2023-03-28.

PCI Passthrough without IOMMU, AKA Gaming on Qubes 4.0.3

Step Zero: Know that Qubes is designed for security, not for fun times, not for ease of use, not for a pretty UI. Qubes is a fantastic and unique OS that everyone should give an honest try to, but it's also kind of ugly and a pain to use. Before reading my words any further, you should read up on the "correct" way to use and think about Qubes. If this doesn't scare you off, then read how the author of Qubes uses it as a daily driver. The flow charts help a lot. It'll be much easier to use Qubes if you're in the right mindset. For example: when you boot up Qubes and log in, you're sitting at a desktop without any network access and you should never install any programs on it. This sounds crazy until you read more about how everything is virtualized. Your email? Three different VMs: a different VM for each email account (optionally). It starts to feel a lot smoother and more natural after you get into that mindset. Your tasks aren't divided into programs, they're divided into... social circles, shall we say? You communicate differently with your boss, your parents, your friends, and your spouse. You'd share different information with each of those groups of people, and even different friends you'd treat differently. Some of my closest friends are terrible with money, and I'd sooner extend a loan to my boss than some friends. It's the same with your software. I trust Steam more than Origin, and neither of them enough to have full, unfettered access to my documents and music. I don't even trust my music player to have write access to my music, ever since iTunes destroyed all of my ID3 tags decades ago. Normally we do everything on our computer in one context. As I type this I have 135 tabs open in one browser. Some of them are personal, some are professional, some are ephemeral, some sites are solid and statically generated, and some sites are slightly suspect because they're written in PHP or Cold Fusion--basically a neon sign reading 'easy to hack'. As usual, XKCD puts it best in #1200 pointing out how our whole lives are in one box. You could carry around a work phone, a personal phone, a work computer, a personal computer, an even more personal computer that's never connected to the Internet because it contains all of your passwords and pictures of your drivers license and Social Security card because even knowing those numbers makes your life so much easier if you were to ever lose the cards themselves. You could segregate your life onto multiple computers, or you could have one computer containing a lot of tiny fake computers. That's Qubes.

Step One: Mandatory: you must have at least two monitors, each one plugged into a different GPU. Or the same monitor with two inputs, each plugged into a different GPU, but that'll make the initial setup more difficult. There comes a point later on when your Windows qube will appear to hang or crash, but actually it's sending everything to your other monitor while leaving its last frame on its qube window/frame buffer thing. If you only have one GPU then plug the other into your motherboard and let your CPU run that one. One of these GPUs and all of its monitors will be passed through to a guest OS. A PS/2 Mouse and Keyboard and a separate USB mouse and keyboard is heavily recommended, but not mandatory. Your life will be better with a set of PS/2 and USB inputs (two keyboards and two mice) but you can live without them.

Step Two: Install Qubes 4.0.3 or later on a large disk. SSD/NVMe is recommended, but more important is size. There's probably a way to use multiple hard drives with Qubes, but I haven't gone looking and the GUI doesn't offer any help here. A fast drive will make everything better, but you'll want to prioritize size here; 200GB will be small for a daily driver (maybe too small) and 100GB will be a painful squeeze for even a brief test machine.

Step Three: After installation you reboot, and you're greeted with some configuration checkboxes. Even on an SSD this part takes forever. No choices here will mean life or death, it's 100% preference. I leave the defaults and also check the box for a separate USB qube, but I don't combine Net and USB into the same qube. I like the idea of every USB device being plugged in being immediately isolated from the main system by default. It's trivial to turn this USB isolation off after the fact.

Step Four: You're finally at a desktop. It's ugly. First up is to hit the "Applications Menu" at the top right (or right-click the desktop) go to "System Tools" and launch "Qubes Updater" which takes forever to run the first time. Check all the boxes and run those updates. If you've opted to have a Whonix qube, then you should now go back into the Applications Menu (or right-click the desktop) and hover over any qube containing the name "whonix" and run a program in there. Any program might work, but I use WhonixCheck. The point is to be asked how you want to connect, and make sure it's working. When the Whonix VM is getting updated in that Qubes updater program you're currently running, it'll need to know how to connect to the Internet, and that's what you're doing now. Once your own tests have succeeded, you can close that knowing the Qubes updater will succeed when it eventually makes its slow way down to the two Whonix VMs.

Step Five: Make XFCE less ugly. Beyond the ascetic advantages, there's also a security benefit to this. Applications > System Tools > Appearance will keep your eyes from bleeding, but Applications > System Tools > Window Manager will help you use your system more safely and more easily. Change the window decorations to something that lets you see a lot of blue. Don't browse around too long, just find something that shows off the blue in the window decoration. Now open something from the qube named "personal" or "disposable DVM". Notice how the lock icons in the Applications menu are colored Yellow and Red respectively. Notice how your Window Manager settings window is blue. If you've followed my advice and seen Joanna's flow charts, these colors will already make sense to you. Now, with a "personal" and "Disposable DVM" program each open, continue deciding which window decoration is prettiest while also immediately communicating which context you're in. Oh, also make sure the GPU and monitor you're wanting to pass through isn't currently being used to display your desktop. Applications > System Tools > Displays will let you easily disable that screen. I haven't tried blacklisting the GPU from the kernel, so know that isn't necessary... I think.

Step Six: When the Qubes Update program has completed successfully, reboot. Now the real work of PCI passthrough and gaming begins. Log back into Qubes and open up Applications > System Tools > Qube Manager. You'll be using this program a lot.

Step Seven: Click the top-left plus icon: Create New Qube

Step Eight: Gaming on Linux works great, it's easy to set up, easy to use, and as such is boring and doesn't need this step-by-step guide. I recommend basing your Gaming-on-Linux qubes on Debian because Fedora comes and goes so fast, the template that came with Qubes is probably already past its End Of Life support. This is Qubes' fault, not Fedora's, but it's still your problem to deal with. If you want to install Steam in Debian on Qubes, then you should also run these two lines in your gaming qube to install some needed 32-bit libraries.

sudo dpkg --add-architecture i386

sudo apt install libgl1-mesa-glx:i386

Fun fact about using templates in Qubes: userdata is persistent, but any system-level stuff (anything that required sudo, like installing Steam) is gone as soon as the VM is shut down. If you want system stuff to persist, you'll have to do it to the template. Applications > Template: debian-10 > Terminal will give you access to that template. Any changes you make in there will stick around forever and be available to all qubes based on that template. For this reason, when making your Linux Gaming qube, you should select Type: "Standalone qube copied from a template". I know what you're thinking: why not install Manjaro or whatever myself and forget the template? The reason is the tight and fluid integration already set up and working with these Debian and Fedora templates. Notice how you choose a random program from a qube that isn't running, it then starts that qube, shows you just that program, and you could be convinced it's all happening locally on your main OS? That kind of automagical X11 forwarding is already set up and working, and anyway there's nothing wrong with Debain 10--that thing will be supported until mid 2024.

Step Nine: Gaming on Windows on Linux, on the other hand, will consume the rest of this tutorial. If you couldn't tell by the Fedora version, Qubes is a bit stuck in the past. Qubes prefers to work with Windows 7, but in theory all of this will work with any future version--Windows 10 certainly installs and runs fine, and I got most of the PCI passthrough working without a hitch. If you want Windows 7 but don't want to be on the unpatched side of the big bad Internet, then this is where Qubes shines: you can set very specific firewall rules for ingress (locked down by default) and egress (wide open by default) network traffic, and have those rules be unique for each qube even if they're all sharing the same NIC. You just want to play games on Windows 7, right? Install, configure, and update everything as far as you can, then lock down all traffic coming in or out of the box except for steampowered.com or install all the games you want and then cut off all networking. Whatever your plans here, they start with clicking that Create New Qube button in the Qube Manager program, and selecting Type: "Empty standalone qube" and checking the box "launch settings after creation"

Step Ten: First you'll want enough disk space for the "System storage max size". This number can be increased any time the qube is off, but can never be decreased ever. Be careful with your typing because it saves automatically, you only get one try at this.

Step Eleven: That Rubicon crossed, click over to the "Advanced" tab and give yourself some Initial memory to work with. Don't "Include in memory balancing". Your gaming machine won't "Provide network" either, so make sure both of those boxes are unchecked. Virtualization Mode needs to be "HVM" for PCI passthrough, so set that.

Step Twelve: Firewall rules can be ignored for now, so click over to the "Devices" tab. Here's where you find out which of your GPUs are which. Call me superstitious, but I don't think you should cut your GPU in half: give both the "VGA controller" and the "Audio device" halves of your GPU to the qube.

Step Thirteen: Applications and servers can be written off as "not an option" for Windows qubes, which isn't actually correct but close enough. Click "Apply" and then click back to the Advanced tab and select "Boot qube from CDROM". Leave that tiny window open while you think about where your ISOs are stored. Mine are on a NAS. If yours are too then now's a time admire some of the polish put into Qubes. In one of your Fedora or Debian based qubes, install cifs-utils or whatever package for your given protocol, and connect any one of your qubes to your ISOs share. Once you've done that, go back to the tiny "Boot qube from device" window, and select the bottom option "from file in qube" and browse for your iso. If that file picker window is iris-scaldingly bright, then open a terminal in that file picker's qube and run

[ -f ~/.config/gtk-3.0/settings.ini ] && printf "gtk-application-prefer-dark-theme=true" >> ~/.config/gtk-3.0/settings.ini || mkdir -p ~/.config/gtk-3.0/ && printf "[Settings]\ngtk-application-prefer-dark-theme=true" > ~/.config/gtk-3.0/settings.ini

That long command will check to see if you've already been configuring those settings; if so it'll add a request for dark themes to the end of the config file, if not it'll create the config folder and file with a request for dark themes. Remember that user settings are preserved in and unique to each qube. System level changes (like stuff requiring sudo) are only preserved when made in the template qube, and are then available to all dependent qubes.

Step Fourteen: After the normal OS installation, go about configuring and updating everything. You'll need to watch the Qube Manager, because every reboot only gets half way and ends up shut down, so you'll have to right-click your Windows qube each time and select "Start/Resume qube". Several hours and reboots later you should have everything updated and drivers for hard drives and PCI devices installed and functional. By now you'll have noticed your passed through GPU and its attached monitor are working for your guest qube, even without IOMMU support. That was pretty easy. You can even mouse around the guest qube's monitor from the tiny window displayed on your host OS; neat.

Step Fifteen: The final piece of the puzzle is giving your guest OS a dedicated USB mouse and keyboard, and only having a PS/2 mouse and keyboard for your host OS. You can use two USB-to-PS/2 adapters if you don't have any dusty old ball mice around. If you don't go for this 'two mice and two keyboard' recommendation of mine, you'll keep accidentally sliding your mouse out of the little window on your host OS and lose all of your input into the guest Qube and therefore lose your game you loser. To dedicate a mouse and keyboard that will be locked inside your guest qube, first make sure you don't currently have a "sys-usb" qube running, hoovering up all of your USB devices. If you do then shut that qube down (immediately losing all of your USB devices) and right click it in the Qube Manager, select "Qube Settings" and click the "Devices" tab and remove all of its USB controllers. In theory you could give some controllers to this sys-usb qube and some to your Windows qube, but in practice I've found that difficult but I also didn't try too hard. Click "OK" and go back to your Windows qube. Give it some or all of your USB controllers and start it up. Does it fail and mention "libxl"? Here's the secret sauce: "Configure strict reset for PCI devices". In the "Devices" tab of your Windows qube's settings is a button with that label. Click that long button and hold down the Control key to select all of your USB controllers. Now it should boot up with no issue, and have those USB devices working fine.

Step Sixteen: Maybe you want to limit your new qube to only talk to Steam? Until I figure out how to get it communicating with its host, the Windows qube can't accept any changes while it's running, they require the qube be shut down and then started back up before they're applied. Because of this, you should install Steam in a Linux qube for rapid testing of these firewall rules, because I still haven't cracked this nut. Hope you have better luck than me with this info:

https://support.steampowered.com/kb_article.php?ref=8571-GLVN-8711
http://whois.arin.net/rest/org/VC-2/nets

162.254.192.0/21
192.69.96.0/22
205.196.6.0/24
208.64.200.0/22
208.78.164.0/22

Forcing urBackup through HTTPS

UrBackup is an open source top-notch server software for making live, bare-metal backups and storing those backups as VHDs. These VHDs can then be instantly virtualized by Hyper-V, KVM, and maybe VirtualBox too. These VHDs could also be slowly imported into XenServer or vSphere and virtualized there

The point is: not only do you get scheduled, self-cleaning, differential backups of running machines, but you can instantly restore them to a VM even if their original hardware recently exploded (also you can just restore one file out of a whole backup, because you accidentally deleted something). Actually getting backups of Windows machines to boot may require a lot of work, but Linux is robust enough to get right back up in a VM without any additional work. urBackup is an excellent, self-hosted service that everyone should be running all the time.

However: it's not super secure by default.

Create an Admin Password

1. navigate to http://mahbox:55414/ or whatever your address is
2. click on "Settings" at the top middle of the page
3. click "Users" down a bit and to the left
4. "Create user"
5. make an admin with a unique password. This is going to be sent in the clear, until you finish this poorly written tutorial.
6. Hit save and test your new password.

Block Random Data Dumps

Any machine on your local network at any time can claim to (or actually) be a urBackup client and start sending any data to your server at any time without so much as a forged invitation--anyone for any reason can send you any files (like a virus) at any time by default. Let's clamp down on that.

This I'm not so sure about, and I'm probably not doing it right or still leaving stuff exposed. In most repos you'll find an Uncomplicated Fire Wall program that's secretly just a front-end to iptables. Let's use that, because it's uncomplicated and probably already installed on your server.

sudo ufw allow ssh
sudo ufw allow https
sudo ufw deny 55414
sudo ufw deny 55413
sudo ufw enable
sudo ufw status

SSH and HTTPS we'll use now and later respectively, so we want to allow those through the firewall. 55414 is the unsecured web UI port which we're going to reverse proxy through HTTPS later, and 55413 is the port I think urBackup uses to scan for any client that wants to send it data. We want to discourage that behavior, and so are blocking that port. On the main urBackup page there's a little plus button at the bottom right where you can manually add names or IPs of machines you want to manually invite to back up to you.

Forcing urBackup through HTTPS

NGINX is designed exactly for this purpose, but we're going to use Apache2 instead because I at least have a passing understanding of Apach2 and how to manipulate it. Also it's the most popular web server on the planet so you'll be able to find a lot of guides on how to use it, you know: like this one right here. Install Apache2 from your distro repos, and then run this code on your freshly installed urBackup box:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod ssl
sudo a2dissite 000-default.conf
sudo a2ensite default-ssl.conf
sudoedit /etc/apache2/sites-available/default-ssl.conf

We're not going to pointing to a folder full of HTML files like a traditional web server, so comment out the DocumentRoot declaration. While you're at it, fill out the ServerAdmin email address to where ever you want human visitors to be able to contact you at.
The rest of the config is fine as default, but let's add a few lines near the bottom, but still inside the VirtualHost definition.

ProxyPreserveHost On
ProxyPass / http://127.0.0.1:55414/
ProxyPassReverse / http://127.0.0.1:55414/

Save and close the text file, and finally restart the service to see the new changes:

sudo systemctl restart apache2

Like I said: we're not serving HTML files out a folder like usual, we're instead going to reverse-proxy to an existing HTTP service--specifically the one on the same box at port 55414. Now check out the fruits of your labor. navigate to https://yourbox or whatever your address is and you should be presented with a sell-signed cert protecting the familiar urBackup web UI. Feel free to type in your password, knowing that it's being encrypted over the wire.

More and better information about this reverse-proxy stuff we just did is available here.

Sony Vaio svs13ab1gl - Boot from flash drive

Hold down the "Assist" and "VAIO" buttons at the same time.

FreeNAS SMB share mount error(95): Operation not supported

TL;DR: either mount with higher security using
mount -t cifs //freenas/share /mnt/share -o vers=3\.0,username=me
or lower FreeNAS's SMB share security to NT1



The long version:
FreeNAS is probably the best NAS software available for any price. Unfortunately, I was having trouble mounting its SMB shares on my Linux desktop or my XenServer hypervisor. After a bit of Googling and a bit of trial-and-error, I've come to the conclusion that mount.cifs version 6.4 defaults to a SMB protocol version weaker than SMB 2. Windows 7 seems to require SMB 2, and Windows 8 and 10 seem to prefer SMB 3. FreeNAS will support all of these versions and more, but by default only allows connections using SMB 2 through SMB 3.

The best solution would obviously be to use a newer protocol and to change your fstab to include vers=3.0 among your comma-separated list of options and when you want to manually mount something use vers=3\.0 among your comma-separated list of options.

If you can't or won't use a newer protocol, you can instead lower the standards of your FreeNAS server by logging into its web interface, clicking "Services" then "SMB" and changing the "Server minimum protocol" to NT1.

Either of these options work for me using FreeNAS 9.10.2-U2, Ubuntu 16.04.2, and XenServer 7.1

Exim4 repeatedly sending out the same email

TL;DR: run
rm /var/spool/exim4/db/*




The long version:

A script of mine has been working diligently for months, sending me email when things break, or more often when I purposefully reboot a monitored computer.

This morning it was sending out the same email every few minutes, well after the issue was resolved. While I'm still not sure, I suspect an email was caught in my 'outbox', being sent over and over. In a fit of holiday cheer, I remembered XKCD 838 and looked in /var/spool/ to find a folder called exim4 that was empty except for four files in its db folder. I moved these binary files and the emails stopped. I then sent a test email, and the files immediately reappeared, with the same file sizes the had before. The test email was successfully received, and it's been quiet for hours now.

I don't know what those files do, but I do know that moving/deleting them fixed my problem when a reboot didn't. I didn't find any useful information on Google or in /etc/exim4/conf.d/ so I figured I'd post my findings here.

My problem was with an Ubuntu 16.04.1 server running Exim version 4.86_2 and GNU Mailutils 2.99.99 sending mail via Gmail's SMTP server.
As always: Your Mileage May Vary.

Hyper-V: The operation failed because the file was not found.

TL;DR: Give permission for the local user named SERVICE to access the files in question.



The long version:

Hyper-V is a powerful hypervisor. It's a shame it has to run on such a stupid OS with so loosely defined user accounts. The Hyper-V service (as it exists by default on Windows Server Core 2012r2, and probably everywhere else) runs as the user "Local System". As is the case on all OSs, a user must be given permission to access and manipulate a file (in this case, VHD files). You'd think that giving access to "Everyone" or "LOCAL SERVICE" would do the trick, but you'd be wrong. Apparently, the real name of "Local System" is "SERVICE", and I don't know why services.msc doesn't just say that.

Since I first set up Hyper-V, I've been getting an error message that looks like this:

Window Title: Virtual Machine Connection
Main Instruction: The application encountered an error while attempting to change the state of 'VM name'.
Content: 'VM Name' failed to change state.
The operation failed because the file was not found. 

Searching the great and powerful Google lead me nowhere. Thankfully, I was able to solve it pretty easily. In my case, I'm using a Core install so I don't waste any more resources on the big stupid Windows than I have to. This means I have to do everything remotely. Obviously you'll need a machine with the permission and ability to manipulate the permissions of these files. I did it from an SMB/CIFS share of the VHD repo, but you can remote in and do it locally, or temporarily enable Admin Shares, or better yet: SSH in and run chmod or chown--just kidding, that would be too easy.

1. From any machine with a full Windows installation (I haven't tried doing this from any other OS) navigate to the folder holding the "file not found" files. I used Windows 7 to fix my 2012r2 Core, but you can use whatever is handy.
2. Right-click on their parent folder (or several grand-parents down, whatever) and go to Properties. 
3. Click the "Security" tab.
4. Click "Edit..."
5. Click "Add..."
6. Click "Advanced"
7. Click "Locations..."
8. Select the actual host of this folder, not your local computer, not a Domain Controller. It should be the top-most item on the Location tree.
9. Click "OK"
10. Click "Find Now"
11. This should show every single user, group, and security principal local to that machine. Press the S key to be brought to the 'S' section of this alphabetically sorted list.
12. Look for a group called "SERVICE".
13. Double-Click the "SERVICE" group to choose it.
14. Click "OK"
15. Now back at the "Permissions for [folder]" window, give the "SERVICE" group full control.
16. Click "OK" a bunch, and you're done.

Start up your VM and cross your fingers.

This worked for me, and I didn't see it posted anywhere else, so I figured I'd share it. As with anything, Your Mileage May Vary.