Packages fail to build; invalid option '--asroot'

[StijnRuts]

If I run the folowing with sudo:

- name: install pkgname
  packer: name=pkgname

I get this error message:

failed: [user@host] => (item=pkgname) => {"failed": true, "item": "pkgname"}
msg: failed to install package pkgname, because: makepkg: invalid option '--asroot'

This is because with version 4.2.0 of makepkg the "--asroot" parameter has been removed.
(https://projects.archlinux.org/pacman.git/tree/NEWS#n57)

If I run it without sudo it hangs forever, waiting for a password.

[austinhyde]

Oh man, I completely missed the notification until now! Sorry about that!

Correct me if I'm wrong, but, isn't the issue here that packer is using makepkg --asroot, and not anything in this project? See keenerd/packer#131

If you think there's a way for me to work around this issue in this module, I'd love to hear it. Otherwise, I'm afraid there's not much I can do.

[StijnRuts]

I have been looking into this a bit more, and I have found some sort of workaround:

Add

nobody ALL = (root) NOPASSWD: /usr/bin/pacman

to /etc/sudoers (or to a new file in /etc/sudoers.d).
Then, instead of

packer --noconfirm --noedit -S somepackage

use

sudo -u nobody packer --noconfirm --noedit -S somepackage

for installing packages.

I've got this to work with yaourt, for packer I still get an error (sudo: sorry, you are not allowed to preserve the environment)

For reference, this blog post seems related: http://allanmcrae.com/2015/01/replacing-makepkg-asroot

Hope someone finds this usefull...

[ichilton]

Hi!

This is great - I like that you've mirrored the pacman module syntax.

I don't get why you closed this issue though - am I missing something, or does it mean that unless you have sudo configured to allow the user ansible is using to execute pacman without prompting for the password, it's useless? :(

I added /etc/sudoers.d/pacman with:

ichilton ALL=(root)NOPASSWD: /usr/bin/pacman

I can now successfully use packer from the command line using ichilton.

If I try to use ansible though, just sits there forever. Looking at ps, it's stuck on:

su -c pacman --noconfirm -U package.pkg.tar.xz

That's because of this code in /usr/bin/packer:

# Called whenever anything needs to be run as root ($@ is the command)
runasroot() {
  if [[ $UID -eq 0 ]]; then
    "$@"
  elif sudo -v &>/dev/null && sudo -l "$@" &>/dev/null; then
    sudo -E "$@"
  else
    echo -n "root "
    su -c "$(printf '%q ' "$@")"
  fi
}

sudo -v prompts for the password - so that doesn't work, so it falls back to using su -c, which obviously asks for the password.

I'm pondering creating my own repo and building the AUR's I need and uploading them to there, so ansible only has to add the repo and do a normal pacman install - but then they need to be kept up-to-date periodically.

Anyone got any better suggestions for using AUR from Ansible now packages can't be built as root, but it needs root to install dependancies?

Thanks,

Ian

[austinhyde]

The original reason I closed this was mostly because from the point of view of what this module does and should do, there really isn't anything I can do. The crux of the issue here is that packer needs to run half normal to build, half escalated to install. Ansible pretty much locks modules into running all normal or all escalated, and as far as I know, there's not really a way to hook into its escalation system mid-process. And obviously, tweaking permissions config files definitely isn't something this module should do.

That said, yeah, this is obviously a problem. Just one I don't see a way out of for the time being. I've been debating just making a vanilla AUR module that ONLY builds the package, then using the pacman module to install the built package. This way, the build/makepkg can happen unprivileged and the install can happen privileged, and it all fits nicely into Ansible's "become" (sudo) system.

[austinhyde]

Hmm... I just had an idea about this, actually. I'll look into it when I get a little bit of free time.

[ichilton]

Yes, that's a great idea! - having a single step is obviously neater, but having a build package step with sudo: no and an install step with sudo: yes would be a better option than messing with sudo and giving users privileges I don't really want them to have!

What's your idea?

[austinhyde]

Alright, opened #3 to address this!

@StijnRuts, @ichilton: if you want to check that out, and see if it works for you, that'd be great!

My idea was basically, "what if we can trick sudo -v into passing without prompting for the password?" which lead to using sudo from the ansible sudo session back down to the original user. This takes advantage of the fact that apparently sudo keeps the session going even through nested sessions.

This basically boils down to (cringe!):

sudo sudo -u austin sudo -v

• first sudo is ansible's sudo upon ssh
• second sudo is invoked by this module to drop back down to me
• third sudo is invoked by packer itself when deciding whether to use sudo -E or su -c.

[ichilton]

That's brilliant! - a much better idea, and thank you for getting it done so fast!

That seems to work a treat with a quick test - I didn't even have to fix the shebang on the script :)

I'll try it on another machine later - one which doesn't have any AUR"s on yet.

[ichilton]

Seems to be working ok - though it's highlighted another, unrelated issue!

packer by default uses /tmp for build, which is tmpfs, which fills up :(

Looks like packer looks at $TMPDIR - is it possible you'd have packer-ansible call it with an alternative location?

Thanks,

Ian

[austinhyde]

Try this in your playbook:

- packer: name=some-package state=present
  environment:
    TMPDIR: /some/other/tmpdir

As far as I'm aware, that environment variable will get passed all the way through to the packer invocation.

[ichilton]

cool, i'll try that.

Is there a way to set that globally for a number of packer install tasks?

[austinhyde]

Unfortunately, not as far as I can tell. Ansible has pretty limited docs on the subject.

The best you'll get is by doing something like

vars:
  packer_env:
    TMPDIR: /some/other/dir

tasks:
  - packer: name=some-package state=present
    environment: packer_env

Which isn't really much worse than adding another parameter to the module itself.

[ichilton]

ok, thanks!

[ichilton]

So you wouldn't be willing to add it to your call to packer? - this will be a problem to anyone without lots of memory.

[austinhyde]

Eh... I'm open to it, but IMO, and presuming this actually works, Ansible's built-in environment handling is the best approach here. It means less complexity in this module, and gives the opportunity for setting other environment variables as well later down the road.

Adding an environment: packer_env isn't any more noisy or harder to read/write than e.g. packer: name=some-package state=present tmpdir={{packer_tmpdir}}

[austinhyde]

That said, if the environment key doesn't work properly, I'm more than willing to accommodate ;)

[ichilton]

ok, i'll give it a try! :)

[ichilton]

That doesn't seem to work :(

I just tried:

- name: Install Dropbox
  packer: name=dropbox state=present
  environment:
    TMPDIR: /var/tmp

but it still uses /tmp

It seems packer isn't good at cleaning up after itself, as when one completes ok it leaves the build files around which fills up /tmp

[austinhyde]

Alright. I'll open a separate issue and look into it.