mkdir dCache cd dCache cp ???/dCache.tar . tar xf dCache.tar cd diskCacheV111/jobs cp dcacheSetup.temp dcacheSetup <edit> dcacheSetup
The steering of the startup procedure is exclusively done by a single setup file. On startup, the system searches for this file in the following order :
The setupfile contains a set of key value pairs separated by the '=' sign. The ${<key>} substitution mechanism may be used to reference keys defined before.
Some of these keys, defined in the setupFile, are mandatory to run the system others have reasonable defaults.
Customizable Parameters
The table below summarizes the key settings in the setupfile.
- java has to be set to define the JVM which should be used. If the variable is not set, the JVM has to be in the PATH when starting dCache.
- dcacheClasses is only needed in development environments to support pluggins. It will be placed at the beginning of the active CLASSPATH to allow overwriting of Classes provided by the cells.jar or the dCache.jar.
- jarDir is the directory where the system assumes to find dCache.jar and cells.jar. It should be set to ${jobs}.
- type needs to be set to either master or pool. In case of 'pool' the pools variable needs to be specified as well.
Chosing master will start all necessary administration cells, including the PnfsManager the PoolManger the FTPDoor the VspDoor and the Ssh Controllers. If master is specified together with the 'pools=<poolListFile>' the master Domain will contain the listed pools as well within one VM.- pnfsMount is needed by the Master Domain to find its way to pnfs. auto may be specified instead of the actually mountpoint to let the dCache find the pnfsMountpoint itself. The auto feature will lead to unexpected effects if more than one Pnfs Filesystem is mounted on that machnine.
- ftpBase is needed by the master Domain only. It defines the root filesystem entrypoint for the FTPDoor. The current implementation tries to add the loginname to the ftpBase to find the users home directory. It falls back to <ftpBase> if the home directory couldn't be found. (MasterDomain only)
- ftpPort defines the ftp listen port. (MasterDomain only).
- vspPort defines the vsp listen port. (MasterDomain only).
- sshPort defines the ssh listen port the system internally uses for administration logins. E.g., the command './dcache login' uses this port. It needs to be specified for the master domain.
Warning : Because this version of the dCache is not assumed to be a production version this door into the system is unsecure in the sense that it allows access for everybody on the master host. There is no password check. Remote hosts don't have access through this port at all.
Remark : The next version of the cells provides a customizable user/group access model for all kind of ssh accesses.- masterPort/masterHost is mandatory as soon as pools are expected to run outside the MasterDomain. An identical pair must be present in the pool and the master setup.
- telnetPort should only be used for debugging purposes of Master and PoolDomains. It allows to inspect the different Domains in cases, the tunnelConnections are not present for whatever reason.
The telnet door is wide open for unauthorized world world access.- spyPort is used by the cells graphical user interface (SPY). It gives access to everybody knowing about the protocol.
Remark This security hole will be closed with the next version of the cells.- pools has to point to the <poolListFile> which defines the names and locations of the particular pools. Only the name of the file must be specified and it's assumed to reside in the 'jobs' directory. The format of this file and the setup of a pool/poolnode is decribed in Administration of Pools.
Variable Name Master Pool java Only if not defined in PATH dcacheClasses For use with pluggins only jarDir ${jobs} ${jobs} keyBase ${jobs} ${jobs} masterPort/masterHost Only if running with multiple Domains type master pool pools Mandatory if pool(s) should run on master as well Mandatory pnfsMount required or set to 'auto' no ftpBase/ftpPort yes no vspPort yes no sshPort yes no spyPort For Cell Gui only (spy) no telnetPort Not recommended Not recommended
The dCache processe(s) can be started as soon as the setupfile and the related <PoolListFiles> on the different hosts are configured.cd ..../jobs ./dcache startThe command has to be executed on each host. The sequence is not significant. It may take up to a minute before all processes could connect to each other.If the startup has been successful, the master domain will print a list of active cells, the 'pool only' domain will simply acknowledge the successful startup. In case of a problem the startup will present the last n lines of the logfile in the hope that the reason for the failure is reported. In any case, the startup procedure will printout the name of the logfile.
Nothing is yet forseen to allow a graceful shutdown of the dCache. The masterDomain can be stopped by./dcache stopIn most cases this should work. In some cases the stop command stucks, in others it leaves behind some dangling threads which may prevent the diskcache from being started again. It is always a good idea to check the process list. The pur PoolDomain can only by stopped by sending the TERM signal to the JVM.
The host, the MasterDomain is running on, is the only Gate into the dCache System. Each user on that host will have unrestricted access to the dCache.cd ..../jobs ./dcache loginFor each user, logged in, the dCache creates a private shell to interact with the system. This shell provides commands to communicate with the CellKernel and with all relevent service cells.Examples
Get a list of active cells
ps -fLists a active cells within the masterDomain together with some details about this cell (from left to right) :
- Name of the Cell.
- [A] for active and [R] for 'in process of being removed'
- Number of messages waiting for this cell.
- Number of threads currently running within this cell.
- Java Class Name of this cell.
- Short status message from this cells.
Get the routing table
routeRoutes to remove domains and cells are displayed.Talking to a cell
The private login shell can connect to any other cell within the whole system. We distinquesh between three different kinds of cells concerning their accessability.
Type Description Address Local Resides in the same Domain as you login Cell <CellName> Remote Resides in a remove Domain <CellName>@<DomainName> Well Known Cell Anywhere <CellName> Well Known Cells are cells which registered themselfs. Currently the PnfsManager, the PoolManager and all pools are 'well known cells'.
The route command (see above) lists all connected Domains and all cells which are well known.
To connect to a different cells :
- Exit the login shell with the exit command. You will end up in the so called dot dot shell.
- Specify your new destination cells :
set dest <cellAddress>See the table above for the cellAddress syntax.
Terminal input is now sent to the specified cells. If the cell doesn't exists or is not reachable, each command will return a NoRouteToCellException. The help command is available for all cells.- To get back you your login shell :
exit set dest localOn a correctly configured system, this shell is only needed for configuring the PoolCells.