As of this writing Puppet 5 isn’t supported by Foreman’s latest version (1.15.2) yet. I saw some discussions or tickets in the community about Puppet 5 but I can’t wait for a new release. I want to integrate Foreman with a separately installed Puppet 5 for several reasons:
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.
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.
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:
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:
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.
After upgrading Evernote to version 5 on Mac, I found that they completely revamped the interface with a new sidebar and a new shiny editor. It looks more beautiful but I felt confusing because it’s too different from last version.
The first thing I did was to close the guide and switch to the old style snippet view. This way it looks a bit familiar to me. But the new sidebar is nearly useless. I used to switch to different notebooks from the old sidebar because there’s a list of all notebooks. Now the new sidebar only lets you choose recent notes, and switch among notes, notebooks, tags and other views. If you want to switch to another notebook, you have to click the notebook title above the notes list – one more click!