Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update/package singularity #11094

Open
wants to merge 4 commits into
base: develop
from

Conversation

Projects
None yet
5 participants
@vsoch
Copy link
Contributor

vsoch commented Apr 2, 2019

This pull request will close #9698, specifically we are allowing for installation of Singularity (versions 3.0 and up). Specifically:

  • Singularity version 3.0 and up is a different install flow from (now legacy) Singularity - it uses golang as opposed to Autotools. There might be a better way to do this, but since both allow for installation from branches / source .tar.gz, I thought it would be cleaner to have singularity (3.0.0 and up) and 'singularity-legacy'.

Here are some things that I learned that could help others in the future (and we can discuss).

  • Go itself is installed under gcc at opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/go-1.11.5-73pcics3bti7rafvlgjzmcgtaeogebxg. It has a src folder but this is not GOPATH.
  • GOPATH is not defined by the module providing go. There is no "spack location" for go modules (I was thinking that maybe there should be, but I think it's cleaner to be able to compile Golang stuffs, and then get rid of the excessive repos that are usually found on a (kept) GOPATH.

GOPATH Troubles

As I mentioned, GOPATH is not defined, but Singularity is expected to be found under $GOPATH/src/github.com/sylabs/singularity. This led to most of the issues with install - the default location that the repo is dumped into doesn't match that. This means that we are able to compile, but when the time comes to build, the entire cloned repo is expected to be found under GOPATH. If we add the building directory to GOPATH, this actually means it's expected to find <build_dir>/src/github.com/sylabs/singularity which doesn't exist. If we try to change the build to some place other than there, we then lose having vendors/ in the present working directory and it breaks.

The solution I came up with was to create a temporary GOPATH in /tmp, and in fact we move everything there. This mimics the correct path setup and allows for configure / make / make install without any issues.

vsoch added some commits Apr 2, 2019

adding singularity back in as singularity-legacy
Signed-off-by: Vanessa Sochat <vsochat@stanford.edu>
updating old singularityware paths
Signed-off-by: Vanessa Sochat <vsochat@stanford.edu>

@vsoch vsoch referenced this pull request Apr 2, 2019

Closed

Help with GOPATH #11085

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 3, 2019

And heads up (some future release) of Singularity will use go modules, which hypothetically should make the install easier! sylabs/singularity#3184

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 8, 2019

ping - do you need anything else from me?

@baberlevi
Copy link
Member

baberlevi left a comment

Looks good to me, I have not tried to install it yet (will do that soon)

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 9, 2019

Awesome!

There's a new rocket emoji response! I'll save that one for after you test :)

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 9, 2019

[edit: add note about warning when setting GOPATH]
[edit^2: see updated version below]

Here's an alternate implementation of this.

It overrides the staging functionality and just moves the unpacked source tree into location that go expects to find it.

A couple of other changes which your version will also need:

  • I don't understand why you have all your dependencies constrained to the develop version, you'll need them when you build the released versions too.
  • You can't use the github "archive" URL, which points to the automagically tar'ed up file; it's missing the VERSION file and the git bits that mconfig needs to figure out the package_version. Using the "download" URL (which points to the pre-autotool'ed tarball y'all uploaded) works. You could probably also re-run autotools and make it work.

The package.py below works for me but might stand some tuning. Haven't tried @develop. Are the depends all needed all the time and are they all build,link or are some run (e.g. squashfs)? I switched to MakefilePackage then overrode most of the interesting bits, I think. Perhaps the base Package is more reasonable (@adamjstewart?)? The develop version needs git, it's used in mconfig but you might not need it in the released versions.

This warns about Suspicious requests to set or unset 'GOPATH' found, because I'm heavy-handedly overwriting the GOPATH that was set by our dependency on go. I think only having this single thing on the GOPATH is cleaner/safer/neater. Seems like there's a force option (see set_or_unset_not_first in lib/spack/spack/util/environment.py, but using it is left as an exercise for the reader (not immediately obvious to me...)). Alternatively, prepending to to GOPATH with spack_env.prepend_path('GOPATH', self.stage.path) also appears to work.

 # Copyright 2013-2019 Lawrence Livermore National Security, LLC and other
 # Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)

 from spack import *
 import os
 import shutil
 import tempfile

 import llnl.util.tty as tty

 class SingularityAlt(MakefilePackage):
     '''Singularity is a container technology focused on building portable
        encapsulated environments to support "Mobility of Compute" For older
        versions of Singularity (pre 3.0) you should use singularity-legacy,
        which has a different install base (Autotools).
     '''

     homepage = "https://www.sylabs.io/singularity/"
     url      = "https://github.com/sylabs/singularity/releases/download/v3.1.0/singularity-3.1.0.tar.gz"
     git      = "https://github.com/singularityware/singularity.git"

     # ##########################################################################
     # 3.1.1 Release Branch (GoLang)

     version('develop', branch='master')
     version('3.1.1', '158f58a79db5337e1d655ee0159b641e42ea7435')

     depends_on('go')
     depends_on('libuuid')
     depends_on('libgpg-error')
     depends_on('squashfs')
     depends_on('git')

     phases = ['configure', 'build', 'install']

     # Where go traditionally thinls the source should be.
     def singularity_dir(self):
         return join_path(self.stage.path, 'src/github.com/sylabs/singularity')

     # Unpack the tarball as usual, then move it to the traditional location
     def do_stage(self, mirror_only=False):
         super(SingularityAlt, self).do_stage(mirror_only)
         shutil.move(self.stage.source_path, self.singularity_dir())

     def configure(self, spec, prefix):
         with working_dir(self.singularity_dir()):
             configure = Executable('./mconfig --prefix=%s' % prefix)
             configure()

     def build(self, spec, prefix):
         with working_dir(self.singularity_dir()):
             make('-C', 'builddir', parallel=False)

     def install(self, spec, prefix):
         with working_dir(self.singularity_dir()):
             make('install', '-C', 'builddir', parallel=False)

     def setup_environment(self, spack_env, run_env):
         # Point GOPATH at the top of the staging dir
         spack_env.set('GOPATH', self.stage.path)
@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 9, 2019

What are you thinking about doing about the setuid bits?

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 9, 2019

pps. I'm pretty sure that in my alt implementation above there's a way to tell the package, just once, that configure and build and etc... should all be with working_dir(self.singuarity_dir()):, but I haven't dug it up yet.

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 10, 2019

I played golf with this a bit, took advantage of MakefilePackage's use of build_directory and generally cleaned/tightened it up. Both 3.1.1 and @develop build for me on CentOS 7. Haven't tried running them [yet].

 # Copyright 2013-2019 Lawrence Livermore National Security, LLC and other
 # Spack Project Developers. See the top-level COPYRIGHT file for details.
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)

 from spack import *
 import shutil


 class SingularityAlt(MakefilePackage):
     '''Singularity is a container technology focused on building portable
        encapsulated environments to support "Mobility of Compute" For older
        versions of Singularity (pre 3.0) you should use singularity-legacy,
        which has a different install base (Autotools).
     '''

     homepage = "https://www.sylabs.io/singularity/"
     url      = "https://github.com/sylabs/singularity/releases/download/v3.1.1/singularity-3.1.1.tar.gz"
     git      = "https://github.com/singularityware/singularity.git"

     version('develop', branch='master')
     version('3.1.1', '158f58a79db5337e1d655ee0159b641e42ea7435')

     depends_on('go')
     depends_on('libuuid')
     depends_on('libgpg-error')
     depends_on('squashfs', type='run')
     depends_on('git', when='@develop')  # mconfig uses it for version info

     # Where go traditionally thinks the source should be.
     # MakefilePackage uses this as working_dir in build/install steps
     @property
     def build_directory(self):
         return join_path(self.stage.path, 'src/github.com/sylabs/singularity')

     # Unpack the tarball as usual, then move it to the traditional location.
     def do_stage(self, mirror_only=False):
         super(SingularityAlt, self).do_stage(mirror_only)
         shutil.move(self.stage.source_path, self.build_directory)

     # Hijack the edit stage to run mconfig.
     def edit(self, spec, prefix):
         with working_dir(self.build_directory):
             configure = Executable('./mconfig --prefix=%s' % prefix)
             configure()

     # Set these for use by MakefilePackage's default build/install methods.
     build_targets = ['-C', 'builddir', 'parallel=False']
     install_targets = ['install', '-C', 'builddir', 'parallel=False']

     def setup_environment(self, spack_env, run_env):
         # Point GOPATH at the top of the staging dir.
         spack_env.prepend_path('GOPATH', self.stage.path)
@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 10, 2019

[edit: added a note about moving the run_before after the edit def'n]

Thinking it might appear less magical, I tried replacing the do_stage method with something uses the @run_before('edit'), but it never gets called. I'm not sure why... Leaves me with two questions: do others think it's less magical and why doesn't it work?

E.g., commented out the do_stage and added this:

     @run_before('edit')
     def move_src_tree(self):
         shutil.move(self.stage.source_path, self.build_directory)

I also tried moving this @run_before bit after I define the edit method, and it still does not seem to be called. 😕

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 10, 2019

@hartzell thanks for looking at the PR! Is there a compelling reason to not use what I developed, with small tweaks to ensure dependencies are installed for tags other than develop? I tested (both older and new Singularity) and it works.

I didn't look at setuid because (I don't recall) it was supported for the (now deprecated) previous version of Singularity. As a general rule, I don't add features until users ask for them.

I saw in an email (but can't find the comment here) a question about why I didn't have the dependencies used for (non develop) install. The only reason is that I'm completely new at Spack, and didn't know to do this.

Anyway, if you get something fully working I can offer to test. Otherwise, I think it would be logical to move forward with the code I wrote.

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 10, 2019

I started playing with it because it felt icky to have to build outside of the normal place that Spack builds things (it goes to lengths to manage its directories, having a special case seemed like a problem waiting to happen). This, I think, is a genuine shortcoming of your approach.

Perhaps someone (@tgamblin, @adamjstewart, @alalazo, @davydden ???) could chime in about whether doing the build in /tmp (actually tempfile.gettempdir()) is ok.

I think that my version is more idiomatic (though I'm likely not unbiased), leveraging the built-ins from MakefilePackage means that there's less code to write and if/when something global needs to be changed, SinguarityPackage will get it for free. On the other hand, it's a bit less explicit (more magical) if one doesn't know MakefilePackage and Spack well. On the gripping hand, I'm fudging a bit with my [ab]use of the edit phase, so....

You should try your builds in a minimal environment. There's no way to build [new versions of] singularity without go, so the only way your 3.3.x version could have built is if you were picking up go from elsewhere. Ditto the other dependencies. Here are the dependency docs. I suspect that you need all the things for all versions (unless e.g. develop has added new features that require new dependencies). I think that most of them are used to build singularity (type=('build','link')) but that squashfs is used at runtime when manipulating images (type='run'). libgpg-error doesn't seem to be needed at build-time, not sure what's up with it. You should double check my reasoning.

Your version didn't work for me, out of the box. I don't have GOPATH defined in my environment.

==> Installing singularity-van
==> Searching for binary cache of singularity-van
==> Finding buildcaches in /bifx/apps/spack/mirror/build_cache
==> No binary for singularity-van found: installing from source
==> Using cached archive: /home/ghartzell/spack/var/spack/cache/singularity-van/singularity-van-3.1.0.tar.gz
==> Staging archive: /home/ghartzell/spack/var/spack/stage/singularity-van-3.1.0-64wpjn4hnmhjb5euepoqi2ofgcbz5sdi/v3.1.0.tar.gz
==> Created stage in /home/ghartzell/spack/var/spack/stage/singularity-van-3.1.0-64wpjn4hnmhjb5euepoqi2ofgcbz5sdi
==> No patches needed for singularity-van
==> Building singularity-van [Package]
==> Executing phase: 'configure'
==> Error: KeyError: 'GOPATH'

/home/ghartzell/spack/var/spack/repos/builtin/packages/singularity-van/package.py:39, in configure:
         36    def configure(self, spec, prefix):
         37
         38        # $GOPATH/src/github.com/sylabs/singularity
  >>     39        tmpgo = prepare_gopath()
         40
         41        # Remove old install
         42        if os.path.exists(tmpgo):

See build log for details:
  /home/ghartzell/spack/var/spack/stage/singularity-van-3.1.0-64wpjn4hnmhjb5euepoqi2ofgcbz5sdi/spack-build.out

That said, environment changes should be made in a setup_environment method (docs here). Using its prepend_path (or set) avoids you having to check whether it's already set.

Patching over that, building fails because mconfig needs git to determine the version info.

Adding that dependency still fails for 3.1.0 because you're using the archive tarball (just a tar of the repo at that commit) and it doesn't include the VERSION file or the .git subdir. That can be fixed by switching to the download URL that points to the tar.gz file y'all uploaded.

Here's a diff that gets your approach to build both versions on CentOS 7 (ignore the bit where I rename the class so that it can reside alongside mine and the original in my screw-around-tree).

[ghartzell@bifx1n03 spack]$ diff -u var/spack/repos/builtin/packages/singularity-van/package.py var/spack/repos/builtin/packages/singularity-van/package.py.orig
--- var/spack/repos/builtin/packages/singularity-van/package.py	2019-04-10 09:04:52.466773041 -0700
+++ var/spack/repos/builtin/packages/singularity-van/package.py.orig	2019-04-10 09:07:20.444913558 -0700
@@ -9,7 +9,7 @@
 import tempfile


-class SingularityVan(Package):
+class Singularity(Package):
     '''Singularity is a container technology focused on building portable
        encapsulated environments to support "Mobility of Compute" For older
        versions of Singularity (pre 3.0) you should use singularity-legacy,
@@ -17,20 +17,19 @@
     '''

     homepage = "https://www.sylabs.io/singularity/"
-    url      = "https://github.com/sylabs/singularity/releases/download/v3.1.0/singularity-3.1.0.tar.gz"
+    url      = "https://github.com/sylabs/singularity/archive/v3.1.0.tar.gz"
     git      = "https://github.com/singularityware/singularity.git"

     # ##########################################################################
     # 3.1.0 Release Branch (GoLang)

     version('develop', branch='master')
-    version('3.1.0', 'd3a963ae85c527521434723b1cf8dda9594bf6c6')
+    version('3.1.0', 'f3f1388f7e904dbcc1f7934740b847a771965019')

-    depends_on('go')
-    depends_on('libuuid')
-    # depends_on('libgpg-error', when='@develop')
-    depends_on('squashfs', type='run')
-    depends_on('git')
+    depends_on('go', when='@develop')
+    depends_on('libuuid', when='@develop')
+    depends_on('libgpg-error', when='@develop')
+    depends_on('squashfs', when='@develop')

     phases = ['configure', 'build', 'install']

@@ -75,7 +74,7 @@
     '''
     gopath = os.path.join(tempfile.gettempdir(), 'go')
     tmpgo = os.path.join(gopath, 'src', 'github.com', 'sylabs', 'singularity')
-    os.environ['GOPATH'] = gopath
+    os.environ['GOPATH'] = gopath + ':' + os.environ['GOPATH']

     # Create gopath
     if not os.path.exists(gopath):

You could also replace the calls to os.path.join with path_join, which is always available.

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 10, 2019

Anyway, if you get something fully working I can offer to test. Otherwise, I think it would be logical to move forward with the code I wrote.

FWIW, the version in my initial comment is fully working, as far as i know. Its use of do_stage has established precedent (tho' I'm the establisher, in the bcl2fastq package) so it should be acceptable; I was just playing with @run_before to see if there was a prettier alternative.

updating singularity install
Signed-off-by: Vanessa Sochat <vsochat@stanford.edu>
@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 10, 2019

Haha, you called it "singularity-van..."

Here comes the Singularity Van! All aboard!

It looks like the formatting of your changes is doing the reverse - your changes are in red (and my original green). I just want to clarify / state that in case anyone else gets confused (I did).

I just made some tweaks to address the GOPATH, .tar.gz referenced at url, and the dependencies. I tested for @develop and without, and didn't get any issues.

I think there are two choices here. We can either have a "spack maintained" GOPATH that keeps the enormous numbers of dependencies for compile (this will get big very fast, and also be confusing about what was found in the user GOPATH vs. spack), and given cloning from master branches it will be hard to manage when several builds need the same repo) or just create this temporary install location, and then build from there, and cleanly remove. I chose the latter because I thought managing an internal GOPATH would be messy and annoying. Definitely would be okay to do otherwise, but be prepared that soon there will be go modules that don't need this.

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 10, 2019

[edit: add question mark to first sentence :)]

What are you worried about being on GOPATH? It appears that everything that singularity needs to build is within it's vendor directory, so all you need to do is point GOPATH at a directory (either Spack's stage dir or your tempdir) that contains a path named src/github.com/sylabs/singularity that is a directory that contains your unpacked tarball. There's nothing else needed, I think/assume.

Am I incorrect about what's in its vendor dir?

If you were using go get to pull down Go dependencies, then you'd be being non-Spacky and should declare resources for them (not sure how that's being handled at the moment for Go dependencies). But I think that you've vendored everything that you need.

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 10, 2019

"vendor" is expected to be in the present working directory of the build, and Singularity now (current version) has quite a bit of content in there. With modules this will change (and further complicate things) but for now it must be the case that the cloned repo is in GOPATH, and the PWD of the build has vendor in it to be found.

You can try it other ways if you want, I spent quite a bit of time and this was what I got working.

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 10, 2019

Do the current 3.x.y versions (ignoring future use of Go modules, for now) need anything that's not included in the vendor dir?

If so, then there's still work to be done because Spack frowns on downloading things during the build/install step; it's a control-freak that likes to do it itself during its stage step, with digest values for repeatability and etc....

If not, then we're nearly in violent agreement, the major difference is this bit:

  • you've relocated the unpacked tarball into a subdir of tempfile.gettempdir() and pointed GOPATH at it; and
  • I've relocated the unpacked tarball into a subdir of Spack's managed staging dir and pointed GOPATH at it.

The big difference here is whether the build should happen within Spack's managed spaces (like all of its other builds do) or elsewhere.

The other bits (inheriting from MakefilePackage, using setup_environment, etc...) are just idiomatic Spack suggestions.

Go modules will eventually introduce another layer of complication. I, personally, hope that applications like Singularity will continue to vendor all of their dependencies (which modules will support) rather than downloading them on the fly. But....

You can try it other ways if you want, I spent quite a bit of time and this was what I got working.

I appreciate the amount of time it takes to get going with Spack. That's why I thought it was worth sharing a working idiomatic alternative rather than just commenting line by line.

But, the most important question is, does the Singularity-Van play tunes like the Ice Cream truck?

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 10, 2019

Singularity-Van serves ice cream and avocados, primarily :)

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 10, 2019

FWIW,

  1. I just used the --keep-stage argument to spack install (leveraging the existing mechanisms) so that it doesn't remove the stage/build directory used by my alternative implementation above.

    It does not appear that make/Go is dragging in any unforseen dependencies. In other words, it seems like Singularity has everything it needs stashed within its vendor dir.

    Side effect of the above is that I'm convinced that relocating the src dir using do_stage is a better approach than trying to use @run_before('edit'), because after spack stage ... runs it's in location that a Go user would expect it to be.

  2. I used ldd to look at the resulting binaries and they don't seem to depend on any unexpected shared libraries; I don't seem to be linking to anything from the system.

    But, the dependency list for 3.1 has a couple of things that make me nervous:

    • wget; which is presumably used to fetch images. If so, it should have a depends_on of type run.
    • openssl; I'm not sure how this gets used. My build doesn't seem to link to anything from it, so....
  3. W.R.T. setuid capabilities, I can't find any mention in the current 3.1 docs about anything being installed setuid. There is a discussion of it here in the deprecated docs, but the components it mentions are no longer installed.

    There is a libexec/singularity/bin/starter-suid installed; though it's not actually setuid. This bit of the generated builddir/Makefile:

    # starter suid
    starter_suid_INSTALL := $(DESTDIR)$(LIBEXECDIR)/singularity/bin/starter-suid
    $(starter_suid_INSTALL): $(starter)
        @echo " INSTALL SUID" $@
        $(V)install -d $(@D)
        $(V)install -m 4755 $(starter) $(starter_suid_INSTALL)

    looks like it would be setting that bit if it could.

    I don't think that many people run their Spack builds as root (I know I don't), so I don't think that there's anything the build can do to set that bit.

    It might be helpful by printing out a message as part of the build, suggesting that the user might want to sudo chmod 4755 $(spack location -i singularity)/libexec/singularity/bin/starter-suid (but build up the string w/in the package.py using prefix and etc...). That is, of course, assuming that that is the/a file that should be setuid.

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 10, 2019

Wait, there is no install with root? Singularity is extremely limited without that. That's not super logical to me - is there an active user of the (current) Singularity via Spack that can comment on this?

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 10, 2019

Let's step back a second. The installation procedure is driven by the use cases of the users installing it, and this is different than I anticipated (I expected an install with root, Singularity doesn't function the same without it). Do you know of a set of users that can comment on how they have used the Spack installation of Singularity (with or without root?) We need to take these into consideration.

@scheibelp

This comment has been minimized.

Copy link
Member

scheibelp commented Apr 10, 2019

Wait, there is no install with root?

I'm not familiar with singularity so apologies if this is a silly question, but are we talking about root permissions, or the root package in Spack?

If we're talking about root permissions, then no, Spack currently doesn't support installing as root for any package, although I have an in-progress PR to support that at #9521

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 10, 2019

strange, let me swing back to the (one) issue that I know of where a user asked about Singularity - we should clarify this before moving forward. I'll reference the PR here.

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 11, 2019

@scheibelp -- Singularity runs containers, like (this is going to give a bunch of people a big headache) Docker but in a way that's much more sensible in an HPC environment. More info here. I'm a big fan!

In order to get its full benefits, there's a bit that needs to be setuid. Admins can decide whether to install it that way (which enables full functionality) or without the making that helper prog setuid (which limits the functionality). There's a good discussion here at the old site.

If you install it by hand using their instructions, your last step would be something like sudo make install and there's a bit that does the requisite chmod.

It looks like #9521 would indeed fix things, at least for interactive builds (I wonder what happens with my Jenkins job?).

@vsoch -- I've used the old package in the past, and my solution was to just

sudo chmod 4755 $(spack location -i singularity)/path/to/files/that/needed/to/be/setuid

I think that having the package in Spack is quite useful, even if people have to do this bit by hand.

The alternatives seem to be to build it "by hand" or install it from RPMS that I dig up from somewhere. I try really hard to limit the set of repo's from which I pull RPMS and building it by hand requires either having the prereqs in the base system (I try to run a minimal base system) or link into some Spack tree (at which point...).

@sknigh

This comment has been minimized.

Copy link
Contributor

sknigh commented Apr 11, 2019

@vsoch In my use case, I install in two passes, the first I install singularity's dependencies / everything else as a normally privileged user (which some packages like tar seem to require), then I install singularity as root. It's a pain, but I would consider it a shortcoming in spack's workflow, not the singularity package.

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 11, 2019

@sknigh -- Just to be clear, you're doing something like:

# as a normal user
spack install --only dependencies singularity
# install the last bit as root
sudo spack install --only package singularity
@sknigh

This comment has been minimized.

Copy link
Contributor

sknigh commented Apr 11, 2019

@hartzell That's correct, I also like to do a fetch first and a clean or recursive chown after to prevent root-owned artifacts outside of singularity's installation path.

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 12, 2019

[edit, need to chown the suid binary also...]

@sknigh et al. -- So with Singularity 3.x.y, it looks like all you'd need to do for the second step would be:

sudo chown root $(spack location -i singularity)/libexec/singularity/bin/starter-suid
sudo chmod 4755 $(spack location -i singularity)/libexec/singularity/bin/starter-suid

Perhaps the package could print/log/... a helpful message to that effect?

It might even be a feature request for Singularity to provide a singularity-doctor script that that's installed as part of the package (and therefor doesn't require the source tree) that checks a deployment and suggests such fixes (à la Homebrew's brew doctor).

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 13, 2019

hmm, so for some reason I wrote this a few days ago and it never posted! Let's try this again... :)


Thanks @sknigh, your use of sudo is what I had initially expected for Singularity - at least I can't imagine being happy with functionality without it. When we get more feedback about others use, the question I want to answer is how realistic is it to want Singularity installed (without sudo). If it's not an ideal or common use case, then with #9521 we should update the PR here so that you don't need that "extra step."

Do we know any others using Singularity via spack? I would suspect they do similar.

@sknigh

This comment has been minimized.

Copy link
Contributor

sknigh commented Apr 17, 2019

@vsoch sudo is a requirement. I prefer hartzell's suggestion: when the user is not root, the install step dumps a command with the correct path and so the user make the change if he has the permissions. I suggest using tty.warn() so it's more visible.

@vsoch

This comment has been minimized.

Copy link
Contributor Author

vsoch commented Apr 17, 2019

That works for me! @hartzell @baberlevi I'm pretty inexperienced with spack so if you want to go ahead and do the "best practices" addition (and any other changes to my PR) please go ahead! I think edits from maintainers is on so it should work. I'll learn a lot by seeing how you do it.

I'm also developing my (first from scratch!) golang library this week so someday soon I'll be a lot better at it. :) Gotta start somewhere!

@hartzell

This comment has been minimized.

Copy link
Collaborator

hartzell commented Apr 17, 2019

@vsoch -- will do, have fun go-ing nuts!

@sknigh

This comment has been minimized.

Copy link
Contributor

sknigh commented Apr 18, 2019

@hartzell some configuration files must be owned by root too.

sudo chown root $(spack location -i singularity)/libexec/singularity/bin/starter-suid
sudo chmod 4755 $(spack location -i singularity)/libexec/singularity/bin/starter-suid
sudo chown root $(spack location -i singularity)/etc/singularity/{singularity.conf,capability.json,ecl.toml}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.