 |
 |
Hi Sam, so, if your preference is for the cern all-in-one bundle, then all the instructions are in the cern url which I sent to you. Changing the ports is trivial and does not require low level tweaking, since the values are in the meta-configuration file system.cnf. Just put reasonable values following the criteria which are there. My advice is to setup/run tests in a machine which is not in production, even a linux laptop is 100% ok. Just for convenience and ease of operation. Just a question: what is your test setup supposed to be for? Fabrizio Sam Skipsey wrote: > Hi Fabrizio, > > So, I tried setting oss.localroot (and r/w) , but the data server > still insists that it doesn't have write access to the filesystem and > so sets itself to read only. > Since it is being run as dpmmgr user, and the filesystem is owned by > that user and is mode 0700, I'm at a bit of a loss to explain this. > > Thank you for the CERN link - I've been using the packages from the > slac link, so at least the version of xrootd I have is reasonably up > to date. Unfortunately, I doubt that I can directly use the all-in-one > version without modifying it anyway, since I need to run the services > on non-standard ports - I'm trying to run this initial test xrootd > service on a head node which already hosts a dpm server (and > dpm-xrootd plugins), so I can't use the default ports. > (The style of the configuration files is based on the Example files > provided on the SLAC website. Perhaps the examples need a bit of > updating ;) ) > > Sam > > 2009/5/6 Fabrizio Furano <[log in to unmask]>: >> Hi Sam, >> >> you should specify r/w in the export directive of the data server, writing >> this: >> >> xrootd.export /gridstore4 r/w >> >> Then please verify that you are specifying the correct localroot option. >> >> Moreover, the config files you wrote look really obsolete, and probably >> valid for very old versions. My suggestion is to get a newer package and >> refer to the online documentation to configure it. Things are much simpler >> now, in the sense that fewer directives are needed. >> >> Depending on your preferences, there are two flavors of the bundle which >> you can get: the vanilla one and the 'automatic all-in-one' one. >> Respectively, you can find the first here: >> >> http://xrootd.slac.stanford.edu >> (or you can take the tarball from the last ROOT version) >> >> and the second here: >> >> http://savannah.cern.ch/projects/xrootd >> >> Fabrizio >> >> >> Sam Skipsey wrote: >>> Hello, all: >>> >>> I may be being stupid here, but: >>> >>> I'm in the initial phase of messing around with xrootd here at >>> Glasgow, and I can't seem to get my diskserver to add itself as >>> writeable. >>> >>> The arrangement is: >>> svr025.gla.scotgrid.ac.uk running as a redirection server (xrootd on >>> port 2525 and olbd on 2526) >>> disk042.gla.scotgrid.ac.uk (for example) running as a data server >>> (same services on same ports) >>> >>> The config for the two is: >>> >>> redirector: >>> # >>> # redirectserver.cf >>> # >>> # xrootd >>> xrootd.port 2525 >>> xrootd.fslib /root/20090202-1402/lib/libXrdOfs.so >>> xrootd.export /gridstore4 >>> #oss.readonly >>> odc.manager svr025.gla.scotgrid.ac.uk 2526 >>> odc.trace redirect >>> # olbd >>> olb.port 2526 >>> olb.allow host disk042.gla.scotgrid.ac.uk >>> olb.allow host svr025.gla.scotgrid.ac.uk >>> ofs.redirect remote svr025.gla.scotgrid.ac.uk >>> xrootd.allow host svr025.gla.scotgrid.ac.uk >>> >>> >>> dataserver: >>> # >>> # dataserver.cf >>> # >>> # xrootd >>> xrootd.port 2525 >>> xrootd.fslib /root/20090202-1402/lib/libXrdOfs.so >>> xrootd.export /gridstore4 >>> #oss.readonly >>> odc.manager svr025.gla.scotgrid.ac.uk 2526 >>> # olbd >>> olb.port 2526 >>> olb.subscribe svr025.gla.scotgrid.ac.uk 2526 >>> ofs.redirect remote svr025.gla.scotgrid.ac.uk >>> oft.redirect target >>> >>> >>> However, when disk042 connects to the redirection server, I see: >>> >>> 090506 14:19:21 31690 olb_Manager: server disk042 defaulted r / >>> >>> and on the disk: >>> 090506 14:18:01 001 olb_Meter: Warning! No writable filesystems found; >>> write access and staging prohibited. >>> >>> and, indeed, xrdcp to disk042 fails (but copying from it works perfectly). >>> The exported filesystem (/gridstore4) is writable by the user owning >>> the xrootd processes, however (indeed, it is owned by the same user, >>> with mode 770). >>> >>> This is probably something stupid, but... any help appreciated. >>> >>> Sam Skipsey >>> Glasgow