Category Archives: linux

by

Installing the nVidia drivers on Fedora 18 – version.h does not exist [Fixed]

For a gaming system, I always want the latest driver. So, I often go nVidia’s site, download the latest (sometimes beta) drivers for my Fedora 18 system. After upgrading to a new kernel (there’s been a few released lately), I was unable to install the nVidia blob drivers from the site, and it took me a while to figure out why.

When running NVIDIA-Linux-x86_64-313.18.run, as downloaded from the site, I kept getting the following error:

If you are using a Linux 2.4 kernel, please make sure
you either have configured kernel sources matching your
kernel or the correct set of kernel headers installed
on your system.

If you are using a Linux 2.6 kernel, please make sure
you have configured kernel sources matching your kernel
installed on your system. If you specified a separate
output directory using either the \”KBUILD_OUTPUT\” or
the \”O\” KBUILD parameter, make sure to specify this
directory with the SYSOUT environment variable or with
the equivalent nvidia-installer command line option.

Depending on where and how the kernel sources (or the
kernel headers) were installed, you may need to specify
their location with the SYSSRC environment variable or
the equivalent nvidia-installer command line option.

So I started digging into the driver, and ran it with a “-x” option to extract it only, like so:

sh ~/NVIDIA-Linux-x86_64-313.18.run -x

That created a directory structure that I could look into, and looking through the files, I figured “kernel” was a good directory to start in, and “conftest.sh” sounded like something that would be used to … drum roll … check configuration and do some sanity testing before allowing me to continue.

For some reason, /usr/src/kernels/3.7.8-202.fc18.x86_64/include/linux no longer includes a version.h (which the nVidia driver uses), so it was failing to detect which kernel version I had installed. After some searching through the filesystem, I found that it was instead in /usr/include/linux/version.h.

Now there are probably much more elegant ways to do this, like with some environment variables or magic switches to the NVIDIA.run file, but my crude solution worked:

ln -s /usr/include/linux/version.h /usr/src/kernels/3.7.8-202.fc18.x86_64/include/linux/version.h

After that, the driver installed just fine and I’m back to 3D accelerated goodness (none of that fallback mode crap for Gnome Shell).

And actually, I’ve popped in to KDE 4.9 to have a look around, as I haven’t tried this desktop environment in a few years. Seems okay so far. Gnome Shell has been giving me some trouble lately at work (very sluggish performance over time requiring a restart of the DE), so maybe this will be better…

I’ll have to see how it performs with my games…

by

Google (GMail team specifically) randomly decides to enforce strict SSL for external POP3/IMAP accounts

After Google announced it was doing away with personal (or was it trial?) Google Apps accounts, I’m getting the impression they want to get rid of freeloaders (like me). I have a free GMail account, which I’ve setup to retrieve messages using POP3S from my e-mail server at home. This allows me to get better spam and phishing filtering, and also get e-mail addressed to my personal account (@moldvan.com). This was a great setup until…

On December 12th (or around there; the official announcement was vague), the GMail team decided to flip the switch to do strict SSL certificate checking. What this means is if there is any problem with an SSL cert, the connection will be rejected and boom you’ve got no e-mail anymore.

The above was done without any warning, and I just thought things were quiet until I logged into my GMail account Sunday evening and saw “Error synchronizing account (account name)”. Digging through the error, I found that the certificate had expired (I was using the default Dovecot SSL config).

Aaaanyway, special thanks to Sergiy Dzysyak at http://site4fast.blogspot.com/2011/10/dovecot-ssl-how-to.html, who put together a good document on getting the SSL part of DoveCot working okay.

The first mistake I made was adding the ssl_cert_file and ssl_key_file to /etc/dovecot/dovecot.conf, instead of /etc/dovecot/10-ssl.conf. The config in 10-ssl.conf overrode the other one, and I didn’t know I had e-mail sitting lonely on my GX260 at home for a few nights.

I got a free SSL cert a while back from StartSSL.com, but they don’t support subdomains, so mail.moldvan.com wasn’t going to work anymore. I quickly changed my MX records to point to www.moldvan.com (the CN of the SSL cert I got for free), and changed up the config mentioned above, and all was well again. :D

by

DNSMasq breaks DNSBL! Fixed…

Steven Bowen liked this post

So this was driving me nuts, and was effectively stopping me from turning off GMail and using my own e-mail server with RoundCube/ZPush. Basically, I get a ton of spam. One of the reasons I’d been using GMail is because the spam detection is great.

To block spammers, there are RDNSBLs (Reverse DNS Black Lists) that when performing a reverse DNS lookup return something in the 127.0.0.0/8 range if someone is on the “bad list”, and your MTA can be configured to block senders based on these responses.

At home, I have Tomato installed on my wireless router. I’m all set to use that as a DNS server to speed up and cache DNS lookups, but there is one problem: when a response comes back as 127.0.0.x from a DNS lookup, DNSMasq doesn’t like this and simply drops it. This is very bad for a RDNSBL, as it relies on exactly those type of responses.

I’ve been tinkering with getting this working forever, and tcpdump again helped me debug an application that wasn’t giving me much info. On my web/e-mail server, I watched the output of tcpdump for port 53, and waited a while until a spam message came through. I saw that Sendmail was doing the lookup, however each time it was simply letting the “bigger boobs” or whatever spam message through. I couldn’t for the life of me figure out why even my manual lookups were failing:

[root@webl001t mail]# nslookup 45.83.75.187.zen.spamhaus.org.
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
*** Can't find 45.83.75.187.zen.spamhaus.org.: No answer

<<< Note >>>: Repeat the above ad nauseam for about a month, on and off of course

Finally, I decided it was Sendmail that was the pain in the ass, and had to be my router. Just as a hunch, I unchecked “Use internal DNS”, and after a “service network restart” on the server, now the same DNS lookups were working!

[root@webl001t mail]# nslookup 45.83.75.187.zen.spamhaus.org.
Server:
Address:

Non-authoritative answer:
Name: 45.83.75.187.zen.spamhaus.org
Address: 127.0.0.4
Name: 45.83.75.187.zen.spamhaus.org
Address: 127.0.0.11

This, however, wasn’t the best solution as I’d rather not use my ISPs DNS servers if possible. But, I was finally on to something. Googling “DNSMasq DNSBL” came up with a lot of hits, and this discussion finally got me the answer.

After I added the below to my Tomato configuration under Advanced -> DNS/DHCP, I was finally good to go, still using my own DNS and also able to lookup domains with 127.0.0.0/8s in the response.

rebind-domain-ok=/rfc-ignorant.org/
rebind-domain-ok=/sorbs.net/
rebind-domain-ok=/uribl.com/
rebind-domain-ok=/surbl.org/
rebind-domain-ok=/dnswl.org/
rebind-domain-ok=/njabl.org/

[root@webl001t log]# nslookup 45.83.75.187.zen.spamhaus.org.
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: 45.83.75.187.zen.spamhaus.org
Address: 127.0.0.4
Name: 45.83.75.187.zen.spamhaus.org
Address: 127.0.0.11

by

Fix for “Could not apply stored configuration for monitor” in Gnome 3

Prior to removing, you can verify that ~/.config/monitors.xml exists and has the configuration causing Gnome to show the error.

Open a terminal, and run the following:

-f ~/.config/monitors.xml && rm ~/.config/monitors.xml

That could also be a simple deletion of ~/.config/monitors.xml, but it’s more fun that way. :D

by

Copy a file with progress in Linux

You’ll need the “pv” program, which will monitor status through a pipe. On my Fedora box at work this was easy, ‘yum install -y pv’ (apt-get should work, also, for Debian based systems, but I haven’t confirmed that).

From there, running a “pv file1 > file2″ gave me the following:

[user@system Downloads]$ pv Windows8-ConsumerPreview-64bit-English.iso > /media/6330-3630/download/Windows8-ConsumerPreview-64bit-English.iso
1.24GB 0:02:49 [5.03MB/s] [=============> ] 37% ETA 0:04:46

Yes, I have downloaded the Windows 8 Consumer Preview for use on my Dell Mini Duo. If there are any gotchas there I’ll write more about that in a separate blog post. Or maybe I’ll write about how flawlessly it worked. LOL ;)

Another good use of pv is the following, which will restore to mysql from an SQL dump file (tip from here):

# pv database_backup.sql | mysql my_database
96.8MB 0:00:17 [5.51MB/s] [==> ] 11% ETA 0:02:10

by

Coming to you live from moldvan.com … also, WTFPL

Well, sort of live anyway. I purchased moldvan.com to make my e-mail addresses shorter and set up the forwards in Sendmail, so that works okay now. Since the changes to my A records haven’t propagated yet, moldvan.com on the web side still forwards to matthewmoldvan.com. Oh well.

Another funny thing I found while digging through the imapsync source for work is the following:

imapsync is free, open source but not always gratis software cover by
the Do What The Fuck You Want To Public License (WTFPL).
See COPYING file included in the distribution or the web site
http://sam.zoy.org/wtfpl/COPYING

Opening that URL gives the following:

            DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
                    Version 2, December 2004

 Copyright (C) 2004 Sam Hocevar 

 Everyone is permitted to copy and distribute verbatim or modified
 copies of this license document, and changing it is allowed as long
 as the name is changed.

            DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

  0. You just DO WHAT THE FUCK YOU WANT TO.

Well said, sir.

by

Mounting an NFS share on the Seagate BlackArmor NAS 110

I had a hell of a time using the NFS options on the Seagate BlackArmor NAS, mostly because of the lack of documentation from Seagate regarding the options necessary to actually use the damn thing as an NFS share. In my mount options, I kept getting the error:
"Connecting to NAS volume:
Unable to connect to NAS volume : NFS Error: Unable to Mount filesystem: The mount request was denied by the NFS server. Check that the export exists and that the client is permitted to mount it".

This is of course because I was specifying the wrong path to the NFS share (because of the lack of documentation on the correct path). Well, after a couple few guesses, I finally figured out what was wrong and was able to mount the device as a data store in ESX 3.5. Basically the share name was :/nas/.

Of course they don’t tell you this anywhere in the documentation, nor did I find any forum posts or other results on the web about it.

So, hopefully this helps someone out there.

by

Fancy colors break grep

When I first saw the new fancy colors for the grep command in Linux in Fedora 15 I was happy to see they added colorizing for grep results. It seems to work fine on my Fedora system, but I saw some weird behavior on a CentOS 5.7 system.

I finally narrowed it down to /etc/skel/.bash_profile, which includes the line:

Line 16:
export GREP_OPTIONS=\'--color=auto\'

This file gets copied into all new user’s home directories, and unfortunately causes nothing but issues.

Check out this weird behavior:


[test@servername ~]$ env | grep bash
grep: bash: No such file or directory
[test@servername ~]$ unset GREP_OPTIONS
[test@servername ~]$ env | grep bash
SHELL=/bin/bash

I found this because one of the scripts I wrote used grep and started to fail. Absolutely NOTHING was working with grep, which is a HUGE problem. I wonder if anyone is aware of the problem … someone should probably file a bug report with CentOS or the grep developer or someone who cares. :P

by

WHY IS OUR WEBAPP SO SLOW? SSL Client certs and JBoss 4.2.3

Today we had a problem after enabling client certificate authentication in JBoss 4.2.3. At first, I googled the problem and found that a potential JBoss speedup was to specify a different SSLRandomSeed option to point to /dev/urandom instead of the default “builtin”. Basically since the SSL parts were using /dev/random, which depended on entropy to generate “uniquely random” output. By pointing to /dev/urandom, which weren’t blocked by a lack of entropy (such as mouse movement, keyboard input, etc), the thought was that the initial SSL client handshake would be quicker.

From WikiPedia:

When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.[3] The intent is to serve as a cryptographically secure pseudorandom number generator, delivering output with entropy as large as possible. This is suggested for use in generating cryptographic keys for high-value or long-term protection.

Slightly problematic was the fact that /dev/random should be used for more “secure” applications, as opposed to /dev/urandom.

Anyway, long story short, the /dev/random thing didn’t fix our issue. The actual problem was that DNS lookups from the server to the outside world were blocked (the server was probably trying to do name lookups for the FQDNs of the certs/etc), and this was causing the initial connection to go VERY slowly (8 seconds or so until the DNS lookup timed out).

The simple(r) fix was to open up the firewall from that server to the world, and all was right. In the end, I did end up learning a bit more about entropy and JBoss, so I consider it a win. :D

by

Fedora 16 upgrade – ouch

I’m always pretty excited about a new Fedora release. Yesterday, Fedora 16 was released, and of course I decided to go grab it. This morning, I popped the DVD in and started the install process.

First problem

The installer tries to activate all of your screens. I have dual monitors setup with my laptop open, and all three screens cannot be activated all at once. So when anaconda (the installer) tried to activate all three, the “next” buttons on the bottom left were on the third screen, which was inactive. This lead to a frustrating “tab over to the button and pray that it’s the one that makes it go to the next screen” problem. No big deal, figured it out. But if I wanted to any advanced partitioning or other operations where guessing was simply not good enough, this would have been a deal breaker. Odd scenario, but it seems with a Dell XPS and 3 screens, I’ll get the worst of all worlds when it comes to odd scenarios.

Second problem

If you have /var on any other partition other than root (which you probably should), the upgrade option will not be presented at all. This is a known bug (see here), for which the workaround is to mount /, as well as your other /var partition, and copy over /var/lib/rpm to /. Simple enough for someone with moderate Linux-fu, but maybe difficult for others. Then again, for the relatively uninitiated with Linux, /var is probably under the root partition anyway. So not too much to gripe about, except that it’s a pretty big oversight on someone’s part.

Third problem

Once I got past the first two, all seemed to be going smoothly. Until the upgrade finished and I was greeted with a screen that told me updating the boot loader failed. Great.

Fedora 16 uses Grub2 now, so I had the pleasure of learning the new grub2-* commands to fix my installation.

After trying a few times to do the below and being hit with errors, I had to add –force to the grub2-install command.
grub2-install /dev/sda
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
However, blocklists are UNRELIABLE and their use is discouraged.
/sbin/grub-setup: error: will not proceed with blocklists


grub2-install --force /dev/sda
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
However, blocklists are UNRELIABLE and their use is discouraged.
Installation finished. No error reported.

FINALLY I got a bootable system.

Fourth problem

THAT. Thanks to the ATI drivers not being available yet, X segfaulted and I had to reboot into run level 3. Thankfully GRUB2 allows for legacy GRUB style run level specification (add a 1 to the end of the “kernel” line, as before) and I was able to fix this disaster with a:

yum remove -y '*catalyst*'

Of course I gave up the eye candy that came with using the fglrx driver, and can’t seem to enable my second monitor anymore.

Conclusion

Upgrading is a giant pain in the ass. But I’ll probably do it again on my HTPC at home. Because I’m technologically masochistic. :P

Update

: Nov 14: I found an errant file in /etc/modprobe.d that was blacklisting the radeon driver, causing all of my 3D effects to be broken. After commenting out the line “blacklist radeon” in /etc/modprobe.d/blacklist-fglrx.conf, everything worked much better. I have full 3D effects again and no fallback mode.