So, was pretty sure that “ForwardAgent yes” was added all over my SSH config. And that was working fine, on Linux. When I moved all my stuff to my newly bought Mac, well, discovered that it’s not working anymore. So, actually, 2 lines need to be added to each host configuration:

Then, the tricky part. Somehow, from the rules and makefiles in there, I found out that if you’re not changing latest version of Lustre in debian/changelog, it will build version 2.6 with a name, something like: 1.8.1.50. Also, somewhere along the way, it also expects a “-” after the version. Not good. For this to change, we’ll add this to the beginning of debian/changelog (only the first line counts):

After that, instead of building packages with version 1.8.1.50-1 it will build packages with the same version as the sources are. I think it’s safe to maybe only change first line’s version and that’s it. Then:

make debs

This will create all necessary deb files and will put them in lustre-release/lustre-2.6.0/debs/ (I’ve also included the kernel debs and e2fsprogs, I needed an archive that can be installed on production servers):

I had to re-configure clustered LVM to non-clustered LVM for some Lustre setup I’m working on. Thing is, clustered LVM can only be accessible if clvmd service is running. But I couldn’t start it, because I needed all cluster services down. After searching, I found that:

Paths were valid, ownership of folders was root.root, still, I had sample.log which wouldn’t get renamed to sample.log.1 and new file wasn’t created either. Have been sitting on this for days now. Decided to redo the config (was actually a bigger one, removed every comment, removed everything it wasn’t needed for my test and ran logrotate with the new config, forced. And eventually after carefully reading the logs (used logrotate -vf /path/to/conf) I found out that:

Ok, the file existed. So what? It had the necessary permissions to delete/replace it. But, of course, it didn’t. Moreover, after getting this error, creating other sample.log.1 files didn’t work either so rotation failed. So I deleted that empty file (yes, it was empty) and retried the logrotate on my test config. Of course, it worked. Surely I couldn’t find any documentation on this, so next time it happens, try to run verbosely and check for “file exists” errors. That will explain strange logrotate behavior.

So, I’ve had a problem with trying to run things as ansible and sudo. Of course, password was not required for any of my sudo commands, but I often get “command not found”. Clearly, after running “env” with ansible using sudo on a server, I noticed I was missing /usr/sbin and /sbin from my path, as opposed to root’s PATH with had both folders.

In my case, was a Debian init stript which relied on start-stop-daemon, which is in sbin, and I got the command not found error. Here is how you set it up in a playbook:

Today I also discovered loops. I had to run a bunch of commands on a lot of servers, searched a bit and found loops. So, if you need to run 5 commands on your servers on a single task from a playbook, do the following: