Skip to main content

Don't let your kids play with NoSQL!

Not that I do much anything with NoSQL, but I really enjoyed this article about Oracle's NoSQL Database, especially the point where they removed the white paper, titled "Debunking the NoSQL Hype" (from May 2011!).

The last sentence sounds like one of those old public service announcements:

  Go for the tried and true path. Don't be risking your data on NoSQL databases.
Another favourite:
  As a result, NoSQL databases may only have partial or no sql support.
No shit, Sherlock! :-)

Fedora 16 Beta

Somehow I can't help myself, over and over again. And curiosity wins again, as I try to install Fedora 16 Beta, this time on a 20" iMac (MB323LL/A). To my surprise, it sucked a somewhat less than previous version, let's recap:

  • Sound still does not work, #580703 seems to cover it.
  • abrt seems to work now: at least I was prompted to send a bug report about some SELinux messages and it concluded that it'd be a duplicate. Yay, abrt.
  • pidgin-otr was able to install this time.
  • What about all these gvfs bugs in past relases? Not sure about that, I'm using LXDE now, which still uses gvfsd but I did not notice any ill-effects so far.
  • /bin/mount still lists an awful lot of crap, too much IMHO. But I forgot to open a UI-bug for this, maybe this helps (and explains what I mean):
      alias mounted="mount | egrep -v '^(cgroup|debugfs|hugetlbfs|mqueue|securityfs|systemd)'"
    
  • Although the says completed in 2009" I could only confirm this with F16 (and the LXDE spin), startup time is amazing now.
  • Yum still sucks, big time. It's slow (surprise!) and when I dared to interrupt a running yum I had to perform all kinds of black magic to get the package database in a clean state again. Unbelievable.


  • Moving on...

rtorrent: GET /announce?info_hash=

Running rtorrent and a webserver on the same machine reveals the following strange entries in the webserver's log:

127.0.0.1 - - [21/Oct/2011:18:59:02 -0700] "GET /announce?info_hash=.... \
                   HTTP/1.1" 404 142 "-" "rtorrent/0.8.6/0.12.6"
This happens every few minutes or so. It's not causing any trouble, but why does rtorrent connect to localhost? Someone at #rtorrent pointed out that it may be a tracker, resolving to localhost. And indeed, going through the trackerlist a popular tracker decided to resolve some of their servers to localhost. And they even explain why:
   Because retarded ISPs and registrars like to hijack NXDOMAIN responses to display 
   ads and crap. Also, if you are using a service like OpenDNS, you'll get their generic
   error response instead.
Understandably :-)

Well, redirecting localhost seems weird, so for now I'm just adding the tracker in question to /etc/hosts and point it to an unused private IP address to get rid of these bogus log entries.

pkgutil: Bad signature detected in catalog!

For some reason, this happened:

# pkgutil -u CSWpkgutil
Checking integrity of ../catalog.mirrors.usc.edu_pub_csw_unstable_sparc_5.10 with gpg.
gpg: Signature made Wed Oct 05 12:32:42 2011 PDT using DSA key ID 9306CC77
gpg: Can't check signature: public key not found
Bad signature detected in catalog!
But the key had been imported already:
# gpg --list-keys 9306CC77
pub   1024D/9306CC77 2011-08-31
uid                  OpenCSW catalog signing 
sub   2048g/971EDE93 2011-08-31
So why would pkgutil not recognize it? truss(1) to the rescue!
# truss -elfda pkgutil -u CSWpkgutil
[...]
20753/1:         3.2282 execve("/opt/csw/bin/gpg", 0x0020A208, 0x00028B60)  argc = 5
20753/1:         argv: /opt/csw/bin/gpg --homedir /var/opt/csw/pki --verify
[....]
20753/1:         3.3719 open("/var/opt/csw/pki/pubring.gpg", O_RDONLY)  = 3
Aha! So we need to import the key to CSWpkgutil's keystore:
# gpg --homedir /var/opt/csw/pki --keyserver keys.gnupg.net --recv-key 9306CC77
gpg: requesting key 9306CC77 from hkp server keys.gnupg.net
gpg: key 9306CC77: public key "OpenCSW catalog signing " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
After doing that (and setting the key's trust) pkgutil worked again :-)

The procedure entry point could not be located in the dynamic link library MSVCP90.dll

The original error message was a bit more cryptic:

  The procedure entry point Xbad@ds2@std@@XBYP3error_type@regex_constants@32@@Y
  could not be located in the dynamic link library MSVCP90.dll
The web is full of errors like this and various solutions are proposed but it seems to be important which application generates this error. In this case it was avgnt.exe. And indeed, installing the Microsoft Visual C++ 2008 SP1 Redistributable Package made the error go away :-)

Error 1603: A fatal error occurred during installation

While trying to install vCenter Server, the installation of the included Microsoft SQL Server 2005 Express Edition failed. In the install logs, one can find something like this:

Error: Action "ReportChainingResults" threw an exception during execution.
One or more packages failed to install. Refer to logs for error details. : 1603
        Error Code: 0x80070643 (1603)
Windows Error Text: Fatal error during installation.
  Source File Name: sqlchaining\sqlchainingactions.cpp
Compiler Timestamp: Sat Oct 25 08:47:07 2008
     Function Name: sqls::ReportChainingResults::perform
Source Line Number: 3521
It turned out not to be a DCOM issue and Microsoft had KB 968749 in place: the solution would be to obtain the latest servicepack for MSSQL 2005 Server. But as the package was included with the VMware bundle, applying a service pack to a not-yet-installed version of MSSQL 2005 Server did not seem like a sound option. However, their workaround worked like a charm, I even tried the Fix it for me thingy: a small executable had to be downloaded and some Microsoft magic is applied to the system. After doing this, vCenter Server could be installed just fine.

Well, almost: the %systemdrive% was a bit low on space and the installation stopped when there was no more space. Windirstat revealed that %windir%\$hf_mig$ was pretty big, but should not be deleted. However, moving this directory to another drive should be OK. After doing that, a junction was created to satisfy the old pathname. With that in place, the installation continued and the system seems fine so far.

Peer certificate cannot be authenticated with known CA certificates

So, this bittorrent site switched to HTTP Secure. And in the name of HTTPS Everywhere I praise them for that. Yet my beloved rTorrent client seems to have a problem with that:

(15:17:33) Peer certificate cannot be authenticated with known CA certificates: 
    "https://torrents.thepiratebay.org/4224797/debian-slink-i386-binary.4224797.TPB.torrent"
Which is strange, my browsers don't have a problem with that. But cURL disagrees:
$ curl -I https://torrents.thepiratebay.org/
  curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
  error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Hm, what up with that? The browser shows "Equifax Secure Certificate Authority" and there are indeed Equifax certificates in /etc/ssl/certs. But apparently not the correct ones:
$ strace curl -I https://torrents.thepiratebay.org/ 2>&1 | grep etc/ssl
stat64("/etc/ssl/certs/2f2c2f7c.0", 0xbf8e2148) = -1 ENOENT (No such file or directory)
So, cURL is looking for a certificate with the hash of 2f2c2f7c. Of course, we cannot construct the correct certificate just with that hash. But we can search for it :-)

Looking around, we find something like this. OK, the hash matches. But where's the certificate from? Searching a bit more brings us to "GeoTrust Intermediate CA Certificates for Rapid SSL". Extracting the GeoTrust Rapid SSL Primary Intermediate CA Certificate we can see:
$ openssl x509 -hash -fingerprint -noout -in geotrust_ca_rapid_ssl.crt 
2f2c2f7c
SHA1 Fingerprint=C0:39:A3:26:9E:E4:B8:E8:2D:00:C5:3F:A7:97:B5:A1:9E:83:6F:47
The hash matches ;-) We'll now move it to our default certificate store and run c_rehash to generate the correct symlink:
$ sudo mv geotrust_ca_rapid_ssl.crt /etc/ssl/certs/
$ sudo c_rehash /etc/ssl/certs
[...]
geotrust_ca_rapid_ssl.crt => 2f2c2f7c.0
Now cURL works fine:
$ curl -I https://torrents.thepiratebay.org/
HTTP/1.1 200 OK
Content-Type: text/html
ETag: "1070355883"
Last-Modified: Tue, 10 Nov 2009 11:25:43 GMT
Expires: Thu, 08 Sep 2011 11:22:36 GMT
Cache-Control: max-age=172800
Server: lighttpd
Content-Length: 5
Date: Tue, 06 Sep 2011 23:12:32 GMT
X-Varnish: 1297278148 1293045530
Age: 42648
Via: 1.1 varnish
Connection: keep-alive
...and so does rTorrent :-)

However, the question remains how trustworthy this GeoTrust Rapid SSL Primary Intermediate CA Certificate really is. You may feel more comfortable to just add the site's certificate to the certificate store (and not the whole CA):
$ echo | openssl s_client -connect www.thepiratebay.org:443 2>/dev/null | \
   sed -n '/BEGIN/,/END/p'  > tpb.crt
$ sudo mv tpb.crt /etc/ssl/certs
$ sudo c_rehash /etc/ssl/certs

Extended Attributes and ACLs on MacOS X

The last article on this topic covered Linux systems, let's see how things are on MacOS X:

EA - Extended attributes


Extended attributes (arbitrary name/value pairs) are marked with an @ sign on the command line:
$ ls -l .DS_Store 
-rw-------@  1 bob  staff     24580 Aug  7 01:04 .DS_Store

$ xattr -l .DS_Store 
com.apple.FinderInfo:
00000000  20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00  |        ........|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020

$ xattr -p com.apple.FinderInfo .DS_Store 
20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

$ xattr -d com.apple.FinderInfo .DS_Store 
With the last command, we removed the extended attribute from the file. But there's more:

ACLs - Access Control Lists


With the EA removed, a plus-sign (+) appears, marking Access Control Lists. They can be shown with ls(1) and changed with chmod(1):
$ ls -l .DS_Store 
-rw-------+ 1 bob  staff  24580 Aug  7 01:04 .DS_Store

$ ls -le .DS_Store 
-rw-------+ 1 bob  staff  24580 Aug  7 01:04 .DS_Store
 0: group:everyone deny delete
Somehow this ACL was set for many (all?) files in my home directory and it was impossible to delete files w/o entering the admin password first. Removing the ACL helped:
$ rm -f .DS_Store
rm: .DS_Store: Permission denied

$ chmod -a "group:everyone deny delete" .DS_Store

$ ls -le .DS_Store
-rw-r--r--- 1 bob  staff  24580 Aug  7 01:04 .DS_Store
Deleting this ACL from all objects in $HOME with chmod -R helped indeed and deleting files is now possible again, w/o being asked for a password.