writing of /usr/lib/R
5
0
Entering edit mode
@michael-green-1489
Last seen 10.2 years ago
New to the list, first post! I'm doing sysadmin work for our Bioinformatics department where I manage a couple of IBM BladeCenter based clusters. Systems are running SLES9 SP1 i586 (dual Xeon 32bit). Before I'm going to ask my question I must admit that I'm complete novice to R, and since I won't use it myself I didn't read much of the documentation supplied with the package. My question is more related to system administration + R, rather then to R itself. So here it is: Some time ago I received a request from our users to install R on one of the clusters. I went ahead and installed R-base-2.1.0-1 supplied by the vendor (SuSE/Novell). After that following the request of the users, I installed the Bioconductor packages using the standard procedure described at <http: www.bioconductor.org="" download="">: source("http://www.bioconductor.org/biocLite.R") biocLite() Soon thereafter it became apparent that during their work with R, our users need to install/uninstall or otherwise change the hierarchy under /usr/lib/R which is of course not writable by any user other than root. As you surely know that's the case for almost every directory under /usr. From talking to one of my users I've learned that R routinely downloads/installs/updates itself and the changes go into /usr/lib/R exclusively (or almost exclusively?). Now I'm faced with dilemma of how to allow users to write to /usr/lib/R, which is not a big deal on itself as there are at least a couple of ways doing that: 1. Play with standard unix permissions: create a new group for R users; chgrp <that_group> /usr/lib/R. etc... 2. Create ACL for /usr/lib/R But my question is not about how to make /usrlib/R writable, but this: since /usr and everything under it is not traditionally writable by regular users what's the official stance of R developers on this? Is it assumed that all R users should have root access to the system where R installed to be able to change contents of /usr/lib/R and actually do any useful work? About our R installation: bioinfo4:/usr/lib/R # R R : Copyright 2005, The R Foundation for Statistical Computing Version 2.1.0 (2005-04-18), ISBN 3-900051-07-0 > sessionInfo() R version 2.1.0, 2005-04-18, i686-pc-linux-gnu attached base packages: [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" [7] "base" -- Warm regards, Michael Green
• 1.8k views
ADD COMMENT
0
Entering edit mode
Liaw, Andy ▴ 360
@liaw-andy-125
Last seen 10.2 years ago
/usr/lib/R/library is the default place where packages are installed, but by no means the only place where they can be installed. Where R searches for packages when asked is defined by the environment variable R_LIBS, which can be defined in several possible places. See the `Details' section of ?Startup (type that at the R prompt). BTW, R-help is probably the more appropriate place for a non-BioC specific question like this. You're likely to get more useful help there. Cheers, Andy > From: Michael Green > > New to the list, first post! > > I'm doing sysadmin work for our Bioinformatics department where I > manage a couple of IBM BladeCenter based clusters. Systems are running > SLES9 SP1 i586 (dual Xeon 32bit). > Before I'm going to ask my question I must admit that I'm complete > novice to R, and since I won't use it myself I didn't read much of the > documentation supplied with the package. My question is more related > to system administration + R, rather then to R itself. > > So here it is: > Some time ago I received a request from our users to install R on one > of the clusters. > I went ahead and installed R-base-2.1.0-1 supplied by the > vendor (SuSE/Novell). > After that following the request of the users, I installed the > Bioconductor packages using the standard procedure described at > <http: www.bioconductor.org="" download="">: > source("http://www.bioconductor.org/biocLite.R") > biocLite() > > Soon thereafter it became apparent that during their work with R, our > users need to install/uninstall or otherwise change the hierarchy > under /usr/lib/R which is of course not writable by any user other > than root. As you surely know that's the case for almost every > directory under /usr. From talking to one of my users I've learned > that R routinely downloads/installs/updates itself and the changes go > into /usr/lib/R exclusively (or almost exclusively?). > Now I'm faced with dilemma of how to allow users to write to > /usr/lib/R, which is not a big deal on itself as there are at least a > couple of ways doing that: > 1. Play with standard unix permissions: create a new group for R > users; chgrp <that_group> /usr/lib/R. etc... > 2. Create ACL for /usr/lib/R > > But my question is not about how to make /usrlib/R writable, but this: > since /usr and everything under it is not traditionally writable by > regular users what's the official stance of R developers on this? Is > it assumed that all R users should have root access to the system > where R installed to be able to change contents of /usr/lib/R and > actually do any useful work? > > About our R installation: > bioinfo4:/usr/lib/R # R > > R : Copyright 2005, The R Foundation for Statistical Computing > Version 2.1.0 (2005-04-18), ISBN 3-900051-07-0 > > > sessionInfo() > R version 2.1.0, 2005-04-18, i686-pc-linux-gnu > > attached base packages: > [1] "methods" "stats" "graphics" "grDevices" "utils" > "datasets" > [7] "base" > > -- > Warm regards, > Michael Green > > _______________________________________________ > Bioconductor mailing list > Bioconductor at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor > >
ADD COMMENT
0
Entering edit mode
Liaw, Andy wrote: >/usr/lib/R/library is the default place where packages are installed, but by >no means the only place where they can be installed. Where R searches for >packages when asked is defined by the environment variable R_LIBS, which can >be defined in several possible places. See the `Details' section of >?Startup (type that at the R prompt). > > Using R_LIBS, the user simply uses install.packages() in R to install a package and R and R_LIBS takes care of the rest. We added the following to each users shell-startup script to manage many users on a heterogeneous system: if test "${R_LIBS}" = ""; then # Get the OS type in lower case ostype=`uname -s | tr '[A-Z]' '[a-z]'` export R_LIBS=${HOME}/R/R_LIBS/${ostype}/library/ if ! test -d "${R_LIBS}"; then mkdir -p ${R_LIBS} fi fi This was needed because some packages build native code and therefore had to be installed in seperate locations depending on platform. Plain R packages would take up unecessary space this way, but we could live with that. Note that R_LIBS may hold more than one directory, so you could include a R_LIBS=${HOME}/R/R_LIBS/cross-platform/library/ directory, but then the user has to specify this directory explicitly when calling install.packages(). /Henrik >BTW, R-help is probably the more appropriate place for a non-BioC specific >question like this. You're likely to get more useful help there. > >Cheers, >Andy > > > > > >>From: Michael Green >> >>New to the list, first post! >> >>I'm doing sysadmin work for our Bioinformatics department where I >>manage a couple of IBM BladeCenter based clusters. Systems are running >>SLES9 SP1 i586 (dual Xeon 32bit). >>Before I'm going to ask my question I must admit that I'm complete >>novice to R, and since I won't use it myself I didn't read much of the >>documentation supplied with the package. My question is more related >>to system administration + R, rather then to R itself. >> >>So here it is: >>Some time ago I received a request from our users to install R on one >>of the clusters. >>I went ahead and installed R-base-2.1.0-1 supplied by the >>vendor (SuSE/Novell). >>After that following the request of the users, I installed the >>Bioconductor packages using the standard procedure described at >><http: www.bioconductor.org="" download="">: >>source("http://www.bioconductor.org/biocLite.R") >>biocLite() >> >>Soon thereafter it became apparent that during their work with R, our >>users need to install/uninstall or otherwise change the hierarchy >>under /usr/lib/R which is of course not writable by any user other >>than root. As you surely know that's the case for almost every >>directory under /usr. From talking to one of my users I've learned >>that R routinely downloads/installs/updates itself and the changes go >>into /usr/lib/R exclusively (or almost exclusively?). >>Now I'm faced with dilemma of how to allow users to write to >>/usr/lib/R, which is not a big deal on itself as there are at least a >>couple of ways doing that: >>1. Play with standard unix permissions: create a new group for R >>users; chgrp <that_group> /usr/lib/R. etc... >>2. Create ACL for /usr/lib/R >> >>But my question is not about how to make /usrlib/R writable, but this: >>since /usr and everything under it is not traditionally writable by >>regular users what's the official stance of R developers on this? Is >>it assumed that all R users should have root access to the system >>where R installed to be able to change contents of /usr/lib/R and >>actually do any useful work? >> >>About our R installation: >>bioinfo4:/usr/lib/R # R >> >>R : Copyright 2005, The R Foundation for Statistical Computing >>Version 2.1.0 (2005-04-18), ISBN 3-900051-07-0 >> >> >> >>>sessionInfo() >>> >>> >>R version 2.1.0, 2005-04-18, i686-pc-linux-gnu >> >>attached base packages: >>[1] "methods" "stats" "graphics" "grDevices" "utils" >> "datasets" >>[7] "base" >> >>-- >>Warm regards, >>Michael Green >> >>_______________________________________________ >>Bioconductor mailing list >>Bioconductor at stat.math.ethz.ch >>https://stat.ethz.ch/mailman/listinfo/bioconductor >> >> >> >> > >_______________________________________________ >Bioconductor mailing list >Bioconductor at stat.math.ethz.ch >https://stat.ethz.ch/mailman/listinfo/bioconductor > > > >
ADD REPLY
0
Entering edit mode
@benilton-carvalho-1375
Last seen 4.7 years ago
Brazil/Campinas/UNICAMP
Hi Michael, If your users had a file called .Reviron in your home dir containing the following line: R_LIBS=/your_home_dir/Rlib they would be able to install/uninstall R packages without your (admin) intervention and without offering any risk to system. Hope that helps, b.
ADD COMMENT
0
Entering edit mode
@james-w-macdonald-5106
Last seen 7 hours ago
United States
Hi Michael, Note that this question is more applicable to R-help <r-help at="" stat.math.ethz.ch=""> rather than BioC, since it concerns R-administration rather than a particular BioC package. Anyway, there are (at least) two ways around this problem that don't involve making /usr/local writable by normal users. First, if there are not that many users, they can always install R in their /home/username directory (e.g., ./configure and make, but no make install). This is preferable in many ways due to the fact that R and BioC are released semi-annually, which can make your job a pain if the end users are constantly wanting the latest version. Of course this will require that each user have enough disk space allotted to them. I think this is probably the most common way to do things. Second, you could simply install R in the same fashion to a directory where everybody has write privileges. This has the advantage of using less disk space, but you then run the risk of people changing the installation in ways that adversely affect other users. HTH, Jim Michael Green wrote: > New to the list, first post! > > I'm doing sysadmin work for our Bioinformatics department where I > manage a couple of IBM BladeCenter based clusters. Systems are running > SLES9 SP1 i586 (dual Xeon 32bit). > Before I'm going to ask my question I must admit that I'm complete > novice to R, and since I won't use it myself I didn't read much of the > documentation supplied with the package. My question is more related > to system administration + R, rather then to R itself. > > So here it is: > Some time ago I received a request from our users to install R on one > of the clusters. > I went ahead and installed R-base-2.1.0-1 supplied by the vendor (SuSE/Novell). > After that following the request of the users, I installed the > Bioconductor packages using the standard procedure described at > <http: www.bioconductor.org="" download="">: > source("http://www.bioconductor.org/biocLite.R") > biocLite() > > Soon thereafter it became apparent that during their work with R, our > users need to install/uninstall or otherwise change the hierarchy > under /usr/lib/R which is of course not writable by any user other > than root. As you surely know that's the case for almost every > directory under /usr. From talking to one of my users I've learned > that R routinely downloads/installs/updates itself and the changes go > into /usr/lib/R exclusively (or almost exclusively?). > Now I'm faced with dilemma of how to allow users to write to > /usr/lib/R, which is not a big deal on itself as there are at least a > couple of ways doing that: > 1. Play with standard unix permissions: create a new group for R > users; chgrp <that_group> /usr/lib/R. etc... > 2. Create ACL for /usr/lib/R > > But my question is not about how to make /usrlib/R writable, but this: > since /usr and everything under it is not traditionally writable by > regular users what's the official stance of R developers on this? Is > it assumed that all R users should have root access to the system > where R installed to be able to change contents of /usr/lib/R and > actually do any useful work? > > About our R installation: > bioinfo4:/usr/lib/R # R > > R : Copyright 2005, The R Foundation for Statistical Computing > Version 2.1.0 (2005-04-18), ISBN 3-900051-07-0 > > >>sessionInfo() > > R version 2.1.0, 2005-04-18, i686-pc-linux-gnu > > attached base packages: > [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" > [7] "base" > > -- > Warm regards, > Michael Green > > _______________________________________________ > Bioconductor mailing list > Bioconductor at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor -- James W. MacDonald Affymetrix and cDNA Microarray Core University of Michigan Cancer Center 1500 E. Medical Center Drive 7410 CCGC Ann Arbor MI 48109 734-647-5623
ADD COMMENT
0
Entering edit mode
Why no make install ? If you supplied the prefix command during configure everything goes fine. My usual bi-annual jig is : wget http://www.cran.r-project.org/src/base/R-2/R-2.2.0.tar.gz # varies tar xvfz R-2.2.0.tar.gz # varies cd R-2.2.0 # varies ./configure --prefix=/home/adai/R make make check make install Then I install most of R and BioConductor packages which takes a couple of hours to download and install. This currently requires about 1.3 GB in hard disk but most users would only require a handful of packages in which case this size will be substantially smaller. I find this is often the best solution as system administrators are usually very busy people and get annoyed when I ask them to update R/BioConductor on frequent basis. But as James pointed out, this depends on the number of people using R, how cutting edge they like to be and if they know how to install R as well as space and internet speed. Regards, Adai On Tue, 2005-11-08 at 08:58 -0500, James W. MacDonald wrote: > Hi Michael, > > Note that this question is more applicable to R-help > <r-help at="" stat.math.ethz.ch=""> rather than BioC, since it concerns > R-administration rather than a particular BioC package. > > Anyway, there are (at least) two ways around this problem that don't > involve making /usr/local writable by normal users. > > First, if there are not that many users, they can always install R in > their /home/username directory (e.g., ./configure and make, but no make > install). This is preferable in many ways due to the fact that R and > BioC are released semi-annually, which can make your job a pain if the > end users are constantly wanting the latest version. Of course this will > require that each user have enough disk space allotted to them. I think > this is probably the most common way to do things. > > Second, you could simply install R in the same fashion to a directory > where everybody has write privileges. This has the advantage of using > less disk space, but you then run the risk of people changing the > installation in ways that adversely affect other users. > > HTH, > > Jim > > > > Michael Green wrote: > > New to the list, first post! > > > > I'm doing sysadmin work for our Bioinformatics department where I > > manage a couple of IBM BladeCenter based clusters. Systems are running > > SLES9 SP1 i586 (dual Xeon 32bit). > > Before I'm going to ask my question I must admit that I'm complete > > novice to R, and since I won't use it myself I didn't read much of the > > documentation supplied with the package. My question is more related > > to system administration + R, rather then to R itself. > > > > So here it is: > > Some time ago I received a request from our users to install R on one > > of the clusters. > > I went ahead and installed R-base-2.1.0-1 supplied by the vendor (SuSE/Novell). > > After that following the request of the users, I installed the > > Bioconductor packages using the standard procedure described at > > <http: www.bioconductor.org="" download="">: > > source("http://www.bioconductor.org/biocLite.R") > > biocLite() > > > > Soon thereafter it became apparent that during their work with R, our > > users need to install/uninstall or otherwise change the hierarchy > > under /usr/lib/R which is of course not writable by any user other > > than root. As you surely know that's the case for almost every > > directory under /usr. From talking to one of my users I've learned > > that R routinely downloads/installs/updates itself and the changes go > > into /usr/lib/R exclusively (or almost exclusively?). > > Now I'm faced with dilemma of how to allow users to write to > > /usr/lib/R, which is not a big deal on itself as there are at least a > > couple of ways doing that: > > 1. Play with standard unix permissions: create a new group for R > > users; chgrp <that_group> /usr/lib/R. etc... > > 2. Create ACL for /usr/lib/R > > > > But my question is not about how to make /usrlib/R writable, but this: > > since /usr and everything under it is not traditionally writable by > > regular users what's the official stance of R developers on this? Is > > it assumed that all R users should have root access to the system > > where R installed to be able to change contents of /usr/lib/R and > > actually do any useful work? > > > > About our R installation: > > bioinfo4:/usr/lib/R # R > > > > R : Copyright 2005, The R Foundation for Statistical Computing > > Version 2.1.0 (2005-04-18), ISBN 3-900051-07-0 > > > > > >>sessionInfo() > > > > R version 2.1.0, 2005-04-18, i686-pc-linux-gnu > > > > attached base packages: > > [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" > > [7] "base" > > > > -- > > Warm regards, > > Michael Green > > > > _______________________________________________ > > Bioconductor mailing list > > Bioconductor at stat.math.ethz.ch > > https://stat.ethz.ch/mailman/listinfo/bioconductor > >
ADD REPLY
0
Entering edit mode
Hi folks, Thank you all for your cool ideas! And I'll make sure I send questions like this to the proper list next time. Actually I've discovered the R_LIBS env var in the FAQ, 5 minutes after I hit the Send button ;-) Also, it's worth to note that we have luxury here of running distributed SAN-attached file system accessible by all the nodes of the cluster. It's General Parallel File System (GPFS) from IBM. So I was thinking why not utilize that? I can copy /usr/lib/R to GPFS and then symlink from all the nodes to it. That will also serve the purpose of having all the nodes work against exactly the same /usr/lib/R. On the other hand I'm cautious about making /usr/lib/R shared because of the race condition it can cause. Because what will happen if, for example, these two users are running different R scripts on two different nodes of the cluster and their R processes both try to install/upgrade packages in the shared directory? Won't they clash? I have presently only 2 users (power users I must admit) using R and their number is not expected to grow between two and maybe several more. -- Warm regards, Michael Green
ADD REPLY
0
Entering edit mode
> Hi folks, > > Thank you all for your cool ideas! And I'll make sure I send questions > like this to the proper list next time. > > Actually I've discovered the R_LIBS env var in the FAQ, 5 minutes > after I hit the Send button ;-) > > Also, it's worth to note that we have luxury here of running > distributed SAN-attached file system accessible by all the nodes of > the cluster. It's General Parallel File System (GPFS) from IBM. So I > was thinking why not utilize that? I can copy /usr/lib/R to GPFS and > then symlink from all the nodes to it. That will also serve the > purpose of having all the nodes work against exactly the same > /usr/lib/R. > > On the other hand I'm cautious about making /usr/lib/R shared because > of the race condition it can cause. Because what will happen if, for > example, these two users are running different R scripts on two > different nodes of the cluster and their R processes both try to > install/upgrade packages in the shared directory? Won't they clash? There is a lock file during package install/removal, if I remember correctly. Otherwise the last one to install/remove wins, I believe... > I have presently only 2 users (power users I must admit) using R and > their number is not expected to grow between two and maybe several > more. > > -- > Warm regards, > Michael Green > > _______________________________________________ > Bioconductor mailing list > Bioconductor at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor >
ADD REPLY
0
Entering edit mode
Liaw, Andy ▴ 360
@liaw-andy-125
Last seen 10.2 years ago
> From: lgautier at altern.org > > > Hi folks, > > > > Thank you all for your cool ideas! And I'll make sure I > send questions > > like this to the proper list next time. > > > > Actually I've discovered the R_LIBS env var in the FAQ, 5 minutes > > after I hit the Send button ;-) > > > > Also, it's worth to note that we have luxury here of running > > distributed SAN-attached file system accessible by all the nodes of > > the cluster. It's General Parallel File System (GPFS) from IBM. So I > > was thinking why not utilize that? I can copy /usr/lib/R to GPFS and > > then symlink from all the nodes to it. That will also serve the > > purpose of having all the nodes work against exactly the same > > /usr/lib/R. > > > > On the other hand I'm cautious about making /usr/lib/R > shared because > > of the race condition it can cause. Because what will > happen if, for > > example, these two users are running different R scripts on two > > different nodes of the cluster and their R processes both try to > > install/upgrade packages in the shared directory? Won't they clash? > > There is a lock file during package install/removal, if I remember > correctly. Otherwise the last one to install/remove wins, I believe... It's when the package is in use, I believe, so that a package cannot be overwritten when someone is using it. Andy > > I have presently only 2 users (power users I must admit) using R and > > their number is not expected to grow between two and maybe several > > more. > > > > -- > > Warm regards, > > Michael Green > > > > _______________________________________________ > > Bioconductor mailing list > > Bioconductor at stat.math.ethz.ch > > https://stat.ethz.ch/mailman/listinfo/bioconductor > > > > _______________________________________________ > Bioconductor mailing list > Bioconductor at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/bioconductor > >
ADD COMMENT
0
Entering edit mode
Shi, Tao ▴ 720
@shi-tao-199
Last seen 9.4 years ago
You can find a step-by-step instruction on 'how to install R packages in non-system directories' from this website: http://support.stat.ucla.edu/view.php?supportid=31 best, ...Tao
ADD COMMENT

Login before adding your answer.

Traffic: 734 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6