Archive for the ‘Linux’ Category
Ubuntu, systemd-resolver and DVE-2018-0001
I noticed that systemd is spamming syslog with:
Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
DVE-2018-0001 is a workaround for some captive portals that respond to DNSSEC queries with NXDOMAIN. systemd-resolver in Ubuntu retries every one of these NXDOMAIN responses without EDNS0.
In practice this means one syslog entry every time a domain isn’t resolvable. This is surprising, so I dug further.
Ubuntu pulled in a PR to systemd implementing DVE-2018-0001 in systemd-resolved. It’s not configurable, except that it’s not attempted in DNSSEC strict mode.
As an aside, I feel like Ubuntu integrating unmerged upstream patches isn’t fair to systemd. I incorrectly assumed that it was systemd that was introducing these spammy log messages. Maybe they will eventually, but they haven’t yet.
I’m pretty sure it’s a terrible idea, but I enabled DNSSEC strict mode by setting DNSSEC=yes in /etc/systemd/resolved.conf. I’ll have to try to remember I did this in a few days when I can’t browse the web.
There’s a really good write-up at askubuntu.com of the underlying problem.
x509 hash changes in Ubuntu Oneiric
Did your commands with custom -CApath stop working after upgrading to Oneiric? Mine did. It turns out Oneiric introduced a change (via OpenSSL 1.0.0, maybe?) that changed the subject hash algorithm used to index certificates in a -CApath directory. Look for a handy code snippet after the jump.
Read the rest of this entry »
scp and POSIX ACLs
scp doesn’t play well with POSIX filesystem ACLs, and as far as I can tell there’s nothing to be done about it.
The problem is that the server side explicitly calls open(2) with the mode of the file on the client side in all cases. Since the file’s group permissions are linked to the mask ACL, this means that — for a mode 644 file — the file gets set mask::r-- instead of inheriting the default mask from the directory.
In my opinion, the correct way to do it would be to create the file without an explicit mode unless the -p command line option was used. In fact, I would have thought that was the point of the -p flag.
This issue isn’t exclusive to ACLs, really. It seems like it would cause problems with standard unix permissions as well. Anyway, the only way around it seems to be changing the mode on the client side prior to the scp. bummer.
Note: I determined this by examining the version of OpenSSH distributed with Ubuntu Lucid, which is 5.3p1. Please let me know if you’ve had a different experience.
Dell OMSA quick links
In my recent web scour, here are the most useful links for a minimal install of Open Manage Server Administrator to keep an eye on storage status.
- Dell YUM Repository – Use this handy yum repo to install and stay up-to-date on the latest OMSA. Pay particular attention to the section on how to install the individual OMSA components.
- OMSA 6.4 Documentation and in particular the CLI Guide
- Dell Linux Engineering for GPG Key 23B66A9D
Random Notes for OMSA & Dell Update Packages on CentOS 5:
- Use the more recent OpenIPMI package from Dell’s yum repo
- Dell Update Packages rely on libstdc++-33.i386 (which is documented) but also libxml2.i386 & procmail (which is not)
Dell embraces and extends command line utilities
From Dell’s OMSA Manual:
Use the omreport -? command to get a list of the available commands for omreport.
Really, Dell? You’ve decided to go another way on the whole CLI thing? That’s cool, I’m sure there wasn’t any good reason every other Unix utility uses -h for help. Oh wait…
# ./omreport -?
zsh: no matches found: -?
zsh: exit 1 ./omreport -?
Thanks Dell. What I needed was another special case in my life.
Fix your drifting pointer in GNOME
Plagued with a drifting pointer? I sure am.
For me this happens when I accidentally zoom using an accessibility “feature” in GNOME. Actually, it’s in Compiz and ambushes me when I accidentally hit Super (windows key) instead of Alt when resizing a window using the Alt+middle click+drag combination.
Compiz seems to be a little particular about getting the screen fully zoomed out again, but here’s a method that’s (so far) always reset the zoom without leaving me with a randomly drifting cursor.
To zoom out again, hold the super key and scroll down using your scroll wheel. I’m sure there’s a better way, but I don’t know it. Disabling zoom hotkeys in gconf-editor didn’t seem to work for me. If you’ve figured this out, please leave a comment!
ecryptfs mount options
I was having trouble tracking down the ecryptfs mount options that can be used to stop the mount.ecryptfs helper utility from prompting quite so much. I tested this on Ubuntu 10.10. ecryptfs_verbosity claims to be the option that I really want to change, but I couldn’t get this one working.
You can add these options to your /etc/fstab. Their values are partially documented here: http://ecryptfs.sourceforge.net/README
Here’s what I added to my /etc/fstab to stop mount.ecryptfs from prompting for anything besides the password on Ubuntu 10.10:
/root/.crypto /root/crypto ecryptfs noauto,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_passthrough=n,ecryptfs_enable_filename_crypto=n 0 0
Beware the spacewalk
I think spacewalk is great. It’s a great product provided for free and sponsored by Red Hat. In fact, I think it’s so great that it’s going to keep RHEL-based distros relevant for non-enterprise users for the next 2-3 years. Of course, then someone will add support for debian/unbuntu, but that’s beside the point.
I think spacewalk is great. I’ve been using it to good success for a little while now. It hasn’t reached 1.0 yet, but that hasn’t given me a single problem. Until now.
I expected the roadmap to 1.0 was more of a process of removing the Red Hat proprietary bits, removing Oracle dependence, finishing the migration to java, adding the open source flourishes, etc. The releases up to this point have been reliable and robust.
Then Spacewalk 0.7 released a version of rhnsd that was broken. Not just a little bit broken, either. A lot broken. Broken in a way that means it doesn’t work under any circumstances. Broken in a way that means the code was never tested prior to commit or release. Also it leaks file descriptors. Also it leaks memory.
rhnsd isn’t a minor part of the client. It’s the daemon that runs in the background and calls rhn_check on a configurable interval. If rhnsd isn’t working, that means clients don’t check in. If clients don’t check in then there’s really no point in having Spacewalk.
I expect there to be bugs in pre-1.0 software, of course, but I don’t think it’s too much to ask that code at least be trivially tested prior to release. I still like Spacewalk, but it’s clear that I should be a lot more active in my support of the project.
The thing I don’t understand, though, is that Spacewalk has been released for a month. How has no one else noticed a problem? The community seems pretty active. Am I using Spacewalk in a novel way? Does no one else upgrade their clients? It just doesn’t add up. Maybe I’m doing it wrong.
HD audio buzzzzzzz
So… I’m using a dangerously long audio cable to connect my computer. It’s always caused a buzzing sound when connected to the amp but not my computer. No surprise there.
After a recent hardware refresh, though, it started buzzing while the computer is powered up and connected. It will start buzzing about 10 seconds after a sound is played and continue buzzing until another sound is played. This behavior immediately made me think of a Karmic release note about putting sound cards to sleep.
After figuring out where the kernel documentation is for Ubuntu (it’s the linux-doc package), powersave.txt confirmed my suspicions. The easiest solution for me was to disable this sleep behavior. I’m using a desktop and while it might be nice to put my sound card to sleep, it’s really not necessary.
It turns out that this option is explicitly set to the default in Ubuntu 9.10 in /etc/modprobe.d/alsa-base.conf. To disable this behavior, all you have to do is set power_save=0 in the snd-hda-intel options line. You can change the setting in the running kernel via /sys/module/snd_hda_intel/parameters/power_save.
After a quick “echo 0 >> /sys/module/snd_hda_intel/parameters/power_save”, everything was back to normal, and I could get on with my day.
rsyslog and logwatch don’t play well together
Notice a hell of a lot fewer log messages being reported since you’ve upgraded to a modern syslog supporting RFC 3339-style high-precision timestamps? Yeah, me too.
It seems as though logwatch doesn’t support these timestamps, so it silently filters out all messages recorded by my rsyslog daemons. What’s worse is that I can’t easily figure out a way to disable that behavior. It’s implemented using an executable filter, and — while there’s plenty of documentation about how to override configuration in /etc/logwatch — there’s no documentation about how to *remove* a filter.
Oh well. I never much liked logwatch, anyway. I mostly don’t like any log monitoring scheme that requires me to read through hundreds of daily e-mails that almost always report everything is normal. That’s not sustainable…
tech stuff. 
You must be logged in to post a comment.