2

I'm trying to set up continuous deployment of a hugo site using Jenkins on an Ubuntu 16.04 server. I've installed hugo using snap as was recommended on their site. I've been able to get the site working on my main user account, but when I try to have Jenkins do it, it hits this error:

cannot create user data directory: /var/lib/jenkins/snap/hugo/1766: Permission denied

Which seems a little odd because the Jenkins has write permissions to that folder, if I'm reading the permissions correctly:

jenkins@computer: ~$ ls -al /var/lib/jenkins/snap/hugo/1766
total 8
drwxr-xr-x 2 jenkins jenkins 4096 May 11 01:33 .
drwxr-xr-x 4 jenkins jenkins 4096 May 11 01:33 ..

Am I missing something here? Are there other things I need to do?

theodinspire
  • 61
  • 1
  • 8

2 Answers2

1

when I try to have Jenkins do it

Make sure the Jenkins job is actually running as jenkins: add a step in your job to print id -a.
Chances are: it is not running as Jenkins, but as your main account, which does not have the right to write in that folder.

"cannot create user data directory": it is possible 1766 is the id of the user account, created as the user.
Check if creating (as your main account) that 1766 folder, with a chmod 777 (for testing) helps.

Note hugo issue 3143 does mention:

Snaps are read-only for security. We want to prevent a hostile party from sneakily changing the software on your machine, so you cannot modify a snap that is installed on your system. This also means you can always check the signature on the snap, even long after you installed it, to make sure it is still exactly the software you intended. If you want to modify a snap, you can usually build your own version of it, especially if it is open source.

So where can a snap write data? Each snap gets its own set of writable directories which have specific properties. There are two directories which the snap can write to independent of the user. One of these is versioned - each time the snap is upgraded the data is saved and the new snap revision can upgrade its copy. The other ‘common’ data directory is not versioned and is used for big blobs of data that you don’t want to duplicate across revisions of the snap:

/var/snap/<name>/current/  ← $SNAP_DATA is the versioned snap data directory
/var/snap/<name>/common/   ← $SNAP_COMMON will not be versioned on upgrades

Typically, configuration is stored in one of these, along with system-wide data for the snap.

There are also an equivalent two writable directories for each snap in the user home, which can be used to store snap data that is specific to one user or another, separately:

~/snap/<name>/current/      ← $SNAP_USER_DATA that can be rolled back
~/snap/<name>/common/       ← $SNAP_USER_COMMON unversioned user-specific data

You can use the snap edition of Hugo to write (i.e. run hugo new site etc.) anywhere inside your $HOME directory, say ~/tmp/htest, but not in the system-wide /tmp directory.

That matches the "Hugo Install from snap" section:

Hugo-as-a-snap can write only inside the user’s $HOME directory—and gvfs-mounted directories owned by the user—because of Snaps’ confinement and security model.

Use sudo snap install hugo --classic to disable the default security model if you want hugo to be able to have write access in other paths besides the user’s $HOME directory.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • The script is very much running from the Jenkins account. I did do the `id -a` thing, but when I was first troubleshooting, I was running it from the console as the Jenkins user – theodinspire May 11 '18 at 07:32
  • @theodinspire so you confirm that, within your Jenkins job, an id -a done just before the hugo command (which hugo command are you using by the way?) does return jenkins? – VonC May 11 '18 at 08:30
  • Unfortunately, this did not work for me. Though this did give me an idea which eventually did find it. I wish I could give half credit. – theodinspire May 12 '18 at 23:28
  • @theodinspire Great! Post your answer (and you can accept it too) – VonC May 12 '18 at 23:29
1

I solved this ultimately by:

  • uninstalling Jenkins with sudo apt-get remove --purge jenkins
  • creating a standard user account named jenkins
  • reinstalling Jenkins and
  • setting the Jenkins Workspace Root Directory to /home/jenkins/workspace/${ITEM_FULL_NAME}

Could also probably be cured by making a directory /home/jenkins that is owned by the Jenkins profile

theodinspire
  • 61
  • 1
  • 8
  • The big thing was making a user folder for Jenkins so that it’d have somewhere to write to. I guess I could’ve faked it too: make a home directory for it and assign ownership to the Jenkins account. – theodinspire May 13 '18 at 00:10
  • That was what I assumed at the start of my own answer: that the process was running using a stand Jenkins account, with its own folder. – VonC May 13 '18 at 00:11