On 25/08/14 18:00, Trey Dockendorf wrote:
Kenneth,
Thanks for response, see inline.
EasyBuild supports all of these (although maybe not these recent
versions, cfr. ACML), except for Octave which is in the works (and
has
been for a while), see
https://github.com/hpcugent/easybuild-easyconfigs/pull/196 and
https://github.com/hpcugent/easybuild-easyconfigs/pull/418.
I got ACML 6 working using a modified easyblock based on EB_ACML. I'm not sure
they can be merged since ACML6 lacks an install script. It's a pure untar into
prefix.
Probably a version check + an alternative path for ACML v6.x in the
existing EB_ACML easyblock would suffice.
Octave I've built by hand and can only imagine how unpleasant it is to
automate in a re-usable way :).
I've seen some of that, it's pretty tricky indeed.
I recognize a lot of these as being supported by EasyBuild already,
while some others are new (e.g. towhee, tesseract, ior).
towhee - http://sourceforge.net/projects/towhee/ - not sure what it's used for
but requested by local Petroleum engineering users.
tesseract - OCR application used by our local Digital Humanities group
ior - I use this for benchmarking our parallel filesystem (FhGFS/BeeGFS)
They are somewhat uncommon I would guess so once I get to them I'll try my hand
at making easyblocks for them.
Sounds excellent!
Hmm, if you notice unexpected behavior here, open an issue for it. I
don't think many people are actively using these settings, so maybe
we
got something wrong there.
I'll likely move to using a dedicated user for builds based on Fotis' and
others comments.
If you use --group, you're specifying that the software should *only*
be
available to people in that group, so it'll remove permissions from
'other', yes.
The functionality required to make everything read/write for
user/group
is there, but there's no command line option yet to control that.
Right now, EasyBuild generally removes write permissions for
group/other, to avoid that nasty mistakes result in disasters (e.g.,
when you install software for a group of users, you don't want to
give
them write permissions on the install dirs), see
https://github.com/hpcugent/easybuild-framework/blob/master/easybuild/framework/easyblock.py#L1458
.
I think you'd want something like --add-permissions=770, or something
along those lines?
Sort of, basically a "chmod -R g=u /path/to/installed/app". That's if I continue relying on group
membership and individual user's building apps, though I may move to dedicated user to build apps and use the
group membership to dictate who can "become" the easybuild user via sudo (I want to avoid giving
the user a password and even a shell if possible). I've had to do something similar for departments I
support outside HPC where a shared account is needed, and I end up just creating an alias in /etc/profile.d
that would be something like "easybuild-login" which executes a specific sudo command to login as
that service account.
We've been using a dedicated user since forever, and I would recommend
against it, since it has a couple of specific disadvantages.
One being that the home directory (and others) quickly becomes a huge
mess of files created by the different people having access to that
account, with people stepping on each others toes unless very strict
policies are adhered to (which generally doesn't work in practice).
Another is that it's harder to track who did what: who performed a
particular software installation, and why?
Our intention is to shift to an 'easybuild' POSIX group, with user
support team members involved with installing software being members.
That does require us to get the permissions right so we can install new
versions even if someone else handled a previous version, etc.
If we feel some support to get this right is missing, we will add it
(unless someone else has already).
regards,
Kenneth
