dl

David Lundgren

Web Developer & Systems Administrator

Ansible “Authentication or permission failure.”

I recently upgraded some servers, and on reboot I ran into the peculiar condition where I received the following warning:

fatal: [user] => Authentication or permission failure. In some cases, you
 may have been able to authenticate and did not have permissions on the remote
 directory. Consider changing the remote temp path in ansible.cfg to a path
 rooted in "/tmp". Failed command was: mkdir -p
 $HOME/.ansible/tmp/ansible-tmp-1401973086.25-185293296215162 && echo
 $HOME/.ansible/tmp/ansible-tmp-1401973086.25-185293296215162, exited with
 result 1

I followed the instructions I found on Changing Ansible Temporary Directory, as it has worked for many others. I had to turn on verbose logging but I still couldn’t see the issue. After running the command manually I got the following error

mkdir: cannot create directory '.ansible': Disk quota exceeded`

Basically, when I restarted my servers the grpquota and usrquota commands in /etc/fstab took effect. I’m not sure why they were on as we have restarted these servers on other occasions and they were not there. While I have these servers scheduled for a restart, to remove the quotas, and add noatime, I’ve simply turned off the quotas using quotaoff /

Leaving the LPi Development Team

It’s never easy leaving a great team. The last three years have been full of growth for me, both mentally and professionally. In those years I have been given the chance to integrate Phing as our deployment automation tool, learn more about coffee (thanks Eric!) and begin the path of mentoring without being completely condescending. I’ve worked on projects that handled geo-spatial searching in MySQL [FYI: you want to use this UDF for distance calculations as it is order of magnitudes faster], to those that help manage church websites. Those who know me, would have asked why I chose to work at LPi given it’s religious affiliations, it’s about the code, and the chance to work on stuff that a large group of people will actually use!

I will miss the team, but by embracing the changes in our life we learn to move forward. IT is full of change anyway, staying static means certain death. Some LPi competitors are learning this the hard way, and I still look forward to seeing them either being acquired or leaving LPi’s market.

FreeBSD and sudo defaults

Several weeks ago I started transitioning some Ubuntu VM’s to FreeBSD VM’s . On previous VM’s I was able to use the following command line without any problems

sudo phing code-update

After switching to FreeBSD I found that sudo, or its “sudo -E” variant, was having problems when running in sub shells. Phing svn tasks were asking for passwords that were previously setup to use svn+ssh. Using “sudo svn list svn+ssh://svn.example.com/svn/project” worked but not when phing ran. It turns out there are two environment variables that Ubuntu’s sudo package was preserving: HOME & MAIL. NOTE: Ubuntu 14.04LTS’ sudo package appears to only preserve HOME.

I created /usr/local/etc/sudoers.d/svnusers

Defaults env_reset
Defaults env_keep+="HOME"

This made FreeBSD’s sudo work as it had on Ubuntu. A day’s worth of investigation to solve the riddle but it works as I would expect it to.