curl SSL connect error – NSS error -5961

I got this error when I wanted to clone a git repo over HTTPS:

# git clone https://git.my.org/projects/test.git
Initialized empty Git repository in /tmp/test/.git/
error:  while accessing https://git.my.org/projects/test.git/info/refs

If I access the server with curl there’s error too:

# curl -v --insecure https://git.my.org
* About to connect() to git.my.org port 443 (#0)
*   Trying 192.168.4.97... connected
* Connected to git.my.org (192.168.4.97) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* NSS error -5961
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

That was a CentOS 6 box and it had not been updated for quite some time. The curl version:

# curl --version
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

I fixed it by updating nss lib and curl:

# yum update -y nss curl libcurl

Note that both nss and curl need to be updated. After the update:

# curl --version
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

Postfix – Replace Sender Address and Add Reply-to Header

We have a network in which a bunch of servers send out lots of notification emails and all these emails are relayed to the outside world through a single Postifx server (by setting relayhost variable in main.cf on the servers). Sometimes developers don’t pay enough attention and address the emails as from some domain that is not of our network, and such emails tend to be classified as spam by the receivers’ email provider.

Continue reading “Postfix – Replace Sender Address and Add Reply-to Header”

Getting Started with Cobbler

I’m not a full-time system administrator and my knowledge is really limited in this domain, especially when it comes close to hardware. But I need to re-install several servers in a data center without physically accessing them. They’re using CentOS 6 now, and I want clean installs of CentOS 7.

I started looking into Cobbler. To avoid making the physical servers inaccessible through network, I played a while with Cobbler in some VirtualBox VMs in my MacBook and here are some notes.

Continue reading “Getting Started with Cobbler”

svnsync alternative

svnsync, like its doc says, is the Subversion remote repository mirroring tool. We may need to have a mirror for backup, or for faster checkout/update in a remote datacenter.

There are lots of documentations and articles about how to set up a mirror using svnsync. But in a situation that connection between mirror and master is really bad, svnsync fails frequently and leaves the mirror locked. Then we have to manually unlock the mirror repository to get it recovered.

Is there an alternative? Short answer – YES:

Continue reading “svnsync alternative”

Compiling Subversion 1.8

Getting compiled binaries is easier but sometimes it just isn’t a choice. It was 2007 when I last compiled subversion, it was still 1.4. I remember that I had a tough time figuring out the apr/apr-utils compatibility issues, and installing neon.

Now it’s 1.8. The new version deceptively gave me an impression that things has become much easier – on a CentOS 6.3 box it compiled, installed and worked with Apache 2.2 (installed by yum) perfectly! I didn’t realize it until I started checking out a repo from it. The checkout was successful but with a tiny warning – post commit FS processing had error: Couldn’t open rep-cache database.

This message was also deceptive. It made me think of permission problems. But it turns out to be a sqlite3 issue! It has the same cause with another problem – when I tried to checkout the repo on the svn server itself through file protocol, it failed with this message: SQLite compiled for 3.8.2, but running with 3.6.20.

Install with sqlite3

Since the sqlite3 version shipped with CentOS was lower than required by subversion, I downloaded the sqlite3 amalgamation, compiled it, and copied the binary and header files to correct locations. Then the configure script stopped complaining about it. I thought that fixed it but obviously it didn’t.

The correct way of installing subversion with the correct version of sqlite3 is like this:

./configure –with-sqlite=/path/to/sqlite-amalgamation/sqlite3.c

HTTP support for client

Later I noticed that the svn client didn’t even support HTTP.

Now subversion uses serf as client HTTP library.

To compile it, you need a build tool called scons. Then just follow serf’s README file.

Enjoy.