home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / c / condor40.zip / CONDOR / doc / install / install.me < prev    next >
Text File  |  1989-10-18  |  13KB  |  483 lines
  1. .nr si 3n
  2. .he 'CONDOR INSTALLATION GUIDE''%'
  3. .fo 'Version 4.0.0'''
  4. .+c
  5. .(l C
  6. .sz 14
  7. CONDOR INSTALLATION GUIDE
  8. .)l
  9. .sp .5i
  10. .sh 1 GENERAL
  11. .pp
  12. This document explains how to create and install
  13. .i condor
  14. from the source.
  15. To do this, you will need the capability of becoming super user
  16. on all of the machines where you want condor to run.
  17. We also assume that you are familiar with local procedures for
  18. creating unix\**
  19. .(f
  20. \**UNIX is a trademark of AT&T.
  21. .)f
  22. accounts, and allocating user and group id numbers.
  23. In addition, if you wish to use NFS\**
  24. .(f
  25. \**NFS is a trademark of Sun Microsystems.
  26. .)f
  27. to share some of the
  28. .i condor 
  29. executables and libraries between machines, you will
  30. need to be familiar with exporting and importing
  31. NFS file systems.
  32. .sh 1 "OPERATIONS IN A HETEROGENEOUS ENVIRONMENT"
  33. .pp
  34. Most local area networks contain a variety of machine and
  35. operating system types.
  36. To maximize the sharing of resources,
  37. .i condor
  38. attempts to provide some interoperability between the various
  39. machine architectures and operating systems.
  40. This does add some complication to the
  41. .i condor
  42. code, and will require some consideration by the person creating
  43. and installing the
  44. .i condor
  45. executables.
  46. .pp
  47. .i Condor
  48. is designed so that all of the various machines may reside in a single
  49. .q resource
  50. pool.
  51. All of the
  52. .i condor
  53. daemons communicate through XDR\**
  54. .(f
  55. \**XDR is a trademark of Sun Microsystems.
  56. .)f
  57. library routines, and are thus compatible even between
  58. machines which use different byte ordering.
  59. Users of a machine of any particular architecture and operating system
  60. type will be able to submit jobs to be run on other architecture and
  61. operating system combinations.
  62. (Of course those jobs will need to be compiled and linked for the
  63. appropriate target architecture/operating system combination.)
  64. .(b
  65. .TS
  66. box;
  67. c s s
  68. l l l.
  69. Supported Architecture and Operating System Combinations
  70. Architecture    Operating System    Description
  71.  
  72. VAX    ULTRIX    Vax running Ultrix
  73. VAX    BSD43    Vax running 4.3BSD
  74. MC68020    SUNOS32    Sun 3 running SunOs3.2
  75. SPARC    SUNOS32    Sun 4 running SunOs3.2
  76. SPARC    SUNOS40    Sun 4 running SunOs4.0
  77. I386    DYNIX    Sequent symmetry running Dynix\**
  78. MIPS    ULTRIX    DECstation 3100 running Ultrix
  79. .TE
  80. .)b
  81. .(f
  82. \**Symmetry and Dynix are a trademarks of Sequent Computer Systems.
  83. .)f
  84. .sh 1 "INSTALLATION OVERVIEW"
  85. .pp
  86. If you use NFS, you can extract the
  87. .i condor
  88. source on a single machine, and then mount object and executable
  89. file trees on machines of the various types for which you wish to
  90. compile
  91. .i condor.
  92. Alternatively, you can distribute the source tree to the appropriate
  93. machines using
  94. .q rcp
  95. or
  96. .q rdist .
  97. .pp
  98. Once you have compiled executables suitable for the machines you wish
  99. to include in your
  100. .i condor
  101. pool, you will need to make those executables available on the
  102. member machines.
  103. There are a number of possible ways to do this.
  104. When you create the executables they will be placed in a
  105. directory called <releasedir>, (details on how to set this pathname
  106. will be given later).
  107. To include the machine where you did the compilation in the pool, 
  108. you might set <releasedir> to be a well known directory, or create
  109. a symbolic link to a well known directory.
  110. For other machines in the pool, you might choose to use the compilation
  111. machine as a fileserver; in this case you can use NFS to mount <releasedir>
  112. in a well known place.
  113. If the machines to be in the
  114. .i condor
  115. pool already have some of their executables remotely mounted
  116. from fileservers, you might want to distribute the executables
  117. from <releasedir> to those fileservers using
  118. .q rcp
  119. or
  120. .q rdist .
  121. .pp
  122. Each machine which is a member of the
  123. .i condor
  124. pool will need to have a
  125. .q condor
  126. account.
  127. If you use NFS, it will be necessary for all of the
  128. .q condor
  129. accounts to share common user and group id's.
  130. .i Condor
  131. must have its own group id.
  132. Group id's such as 
  133. .q daemon
  134. or
  135. .q bin
  136. are not suitable for use by
  137. .i condor.
  138. Each
  139. .q condor
  140. account will need a home directory containing 3 subdirectories,
  141. .q log ,
  142. .q spool ,
  143. and
  144. .q execute .
  145. A script is provided which will create these directories with
  146. the proper ownership and mode.
  147. If you choose to have these directories remotely mounted, be sure each
  148. .i condor
  149. machine has its own private version of these directories.
  150. Each 
  151. .q condor
  152. account will have two files in the home directory called
  153. .q condor_config
  154. and
  155. .q condor_config.local .
  156. .q Condor_config
  157. may be shared via NFS, but
  158. .q condor_config.local
  159. should be private.
  160. .i Condor
  161. users will need to access the
  162. .i condor
  163. .q bin
  164. and
  165. .q lib
  166. directories.
  167. These may also be shared with remotely mounted file systems.
  168. Finally, each member machine will need to start the
  169. .i condor
  170. daemons at boot time.
  171. This will be done by placing an entry in
  172. .q /etc/rc
  173. or
  174. .q /etc/rc.local
  175. which starts the
  176. .q condor_master .
  177. The master will determine which daemons should be run on its machine,
  178. and will monitor their health, restarting them and mailing system
  179. personnel about problems as necessary.
  180. .pp
  181. In addition to the member machines, you will need to designate one
  182. machine to act as the
  183. .q "central manager" .
  184. The central manager will run two extra daemons which communicate with
  185. and coordinate the daemons on all member machines.
  186. These daemons will also be started and monitored by the master.
  187. .sh 1 "CREATING AND DISTRIBUTING EXECUTABLES"
  188. .np
  189. Create a user account for
  190. .q condor ,
  191. and set up a condor group as well.
  192. Change directory to the condor home directory and run as
  193. .q condor ,
  194. e.g. 
  195. .q "su condor" .
  196. .np
  197. Extract the
  198. .q CONDOR
  199. directory from the distribution file, e.g.
  200. .q "uncompress Condor.tar.Z" ,
  201. then
  202. .q "tar xf Condor.tar" .
  203. .np
  204. If you wish to make executables for an architecture/operating system
  205. other than the machine where you have extracted the tape,
  206. you will need to either copy the files to the
  207. .q compilation
  208. machine, or preferably remotely mount them via NFS.
  209. In any case, all the condor files should have owner
  210. .q condor ,
  211. and group
  212. .q condor .
  213. You should always be running as
  214. .q condor
  215. when you make condor executables.
  216. .np
  217. .q Cd
  218. to the
  219. .q CONDOR
  220. directory, and edit
  221. .q GENERIC/condor_config .
  222. Set
  223. .q CONDOR_HOST
  224. to the hostname where the
  225. central manager daemons will run.
  226. We recommend setting this up as a network alias,
  227. so you can easily change which machine
  228. runs the central manager daemons later.
  229. Set
  230. .q CONDOR_ADMIN
  231. to the electronic mailing address of the person responsible for
  232. maintenance of
  233. .i condor
  234. at your site.
  235. We recommend setting this to a mailing list, again so you
  236. can easily change who the actual recipient is at a later date.
  237. Set
  238. .q RELEASEDIR
  239. to the pathname where you want condor users
  240. to access the executables and libraries.
  241. This should probably not be the condor source directory.
  242. .np
  243. Create an object tree for the specific architecture/operating system type
  244. for which you are creating executables.
  245. Do this by running
  246. .q "NewArch <ARCH> <OPSYS>"
  247. in the
  248. .q CONDOR
  249. directory.
  250. The
  251. .q ARCH
  252. and
  253. .q OPSYS
  254. arguments must be chosen from the above table.
  255. This will create a directory called
  256. .q "<ARCH>_<OPSYS>"
  257. containing subdirectories for all of the
  258. .i condor
  259. object files.
  260. .np
  261. .q Cd
  262. to the
  263. .q "<ARCH>_<OPSYS>"
  264. directory and compile all of the
  265. .i condor
  266. programs by typing
  267. .q "make opt=release" .
  268. .np
  269. If you want to make the executables accessible via a symbolic link,
  270. or by distributing to a fileserver, you can edit the template
  271. .q INSTALL
  272. script to do this for your situation.
  273. If you will be using the compilation machine as a fileserver for
  274. .i condor
  275. executables, you should grant the necessary permissions in
  276. .q /etc/exports .
  277. .np
  278. You will also need to install the
  279. .i condor
  280. man pages.
  281. These will be found in
  282. .q CONDOR/doc/man/{manl,catl} .
  283. The exact commands will vary somewhat depending on the situation at your site.
  284. If you mount your man pages on a shared fileserver, they may look something
  285. like this:
  286. .(q
  287. rcp manl/* <fileserver>:/usr/man/manl
  288. .br
  289. rcp catl/* <fileserver>:/usr/man/catl
  290. .)q
  291. .np
  292. To make and install executables for other architecture/operating system
  293. types, go back to step 3.
  294. .sh 1 "ADDING MEMBER MACHINES TO THE CONDOR POOL"
  295. .lp
  296. Complete the following steps on each machine you want to add to the
  297. condor resource pool.
  298. Add the machine which will act as the
  299. .q "central manager"
  300. first.
  301. N.B. all of the steps in setting up a member of the condor pool will
  302. require you to operate as the super user.
  303. .np
  304. Create an account for
  305. .q condor
  306. on the member machine.
  307. Be sure to use the same user and group id's on all member machines.
  308. .np
  309. If you are planning to access the condor executables on this machine
  310. via a remotely mounted file system, make sure that file system is
  311. currently mounted,
  312. and that there is an appropriate entry in
  313. .q /etc/fstab
  314. so that it will get mounted whenever the machine is booted.
  315. .(b L
  316. For example on a Sun 3 running SunOs 3.2 the fstab entry might look something
  317. like:
  318. .(q
  319.     <fileserver>:<some path>/MC68020_SUNOS32/release <RELEASEDIR> nfs ro 0 0
  320. .)q
  321. .)b
  322. .np
  323. Run the script
  324. .q Condor.init .
  325. This will link
  326. .q condor_config
  327. to a site specific version of that file,
  328. and create the
  329. .q log ,
  330. .q spool ,
  331. and
  332. .q execute
  333. directories with correct ownership and permissions.
  334. .np
  335. Run the script
  336. .q Condor.on .
  337. This will create and edit
  338. .q condor_config.local
  339. setting
  340. .q START_DAEMONS
  341. to
  342. .q True
  343. so that the condor daemons are able to run,
  344. then it will actually start them.
  345. .np
  346. At this point the member machine should be fully operational.
  347. On all machines you should find the
  348. .q condor_master ,
  349. .q condor_startd ,
  350. and
  351. .q condor_schedd
  352. running.
  353. Machines which run the X window system,
  354. should also be running the
  355. .q condor_kbdd .
  356. Additionally the
  357. .q "central manager"
  358. machine should be running the
  359. .q condor_collector
  360. and
  361. .q condor_negotiator .
  362. You can check to see that the proper daemons are runing with
  363. .(q
  364. ps -ax | egrep condor
  365. .)q
  366. You should also run
  367. .q condor_status
  368. to see that the new machine shows up in the resource pool.
  369. If you wish to run some trivial jobs to check operation of
  370. all the
  371. .i condor
  372. software, example user programs and a
  373. .q "job description"
  374. file have been compiled and are provided in the 
  375. .q <ARCH>_<OPSYS>/client
  376. directory.
  377. .np
  378. Add lines to
  379. .q /etc/rc
  380. or
  381. .q /etc/rc.local
  382. which will start
  383. .q condor_master
  384. at boot time.
  385. .(b L
  386. The entry will look something like this:
  387. .(l
  388. if [ -f /usr/uw/condor/bin/condor_master ]; then
  389.         /usr/uw/condor/bin/condor_master; echo -n ' condor'   >/dev/console
  390. fi
  391. .)l
  392. .)b
  393. Note: do not attempt to run this command now,
  394. condor is already running.
  395. .sh 1 EXAMPLE
  396. .pp
  397. Figure 1 presents a simplified version of how
  398. .i condor
  399. is made and installed at the University of Wisconsin.
  400. We keep all of the
  401. .i condor
  402. source, objects, and the master copies of the executables on
  403. .q shorty
  404. which is a
  405. Sequent Symmetry machine running Dynix.
  406. Users on all of our machines access the
  407. .i condor
  408. executable and library directories as
  409. .q /usr/uw/condor/{bin,lib} .
  410. In some cases this is accomplished by a symbolic link to the
  411. <releasedir>, and in other cases it is done by a remote file
  412. system mount either directly to shorty, or to a copy on a
  413. separate fileserver.
  414. .pp
  415. The <releasedir> for the I386_DYNIX version of the executables and
  416. libraries is
  417. .q ~condor/CONDOR/I386_DYNIX/release
  418. on shorty.
  419. Shorty's users access those executables and libraries via
  420. a symbolic link as
  421. .q /usr/uw/condor/{bin,lib} .
  422. .pp
  423. We use
  424. .q Bugs
  425. which is a Vax running BSD4.3
  426. to create the
  427. .i condor
  428. software for vaxen running 4.3 by remotely mounting
  429. .q ~condor/CONDOR
  430. from shorty.
  431. From within the
  432. .q CONDOR
  433. directory on bugs, we were able to run
  434. .q "NewArch VAX BSD43
  435. creating the
  436. .q VAX_BSD43
  437. directory tree.
  438. The <releasedir> for the VAX_BSD43 version of the executables and
  439. libraries is
  440. .q ~condor/CONDOR/VAX_BSD43/release.
  441. We distribute that to a fileserver for use by all of the 4.3 vaxen
  442. in the department, including bugs.
  443. Users on these machines access the
  444. .i condor
  445. software as
  446. .q /usr/uw/condor/{bin,lib}
  447. just like on shorty, but this time it is through a remote file system.
  448. .(b
  449. .GS C
  450. file example.grn
  451. 3 8
  452. 4 12
  453. height 3.0
  454. .GE
  455. .)b
  456. .sh 1 "Copyright Information"
  457. .lp
  458. Copyright 1986, 1987, 1988, 1989 University of Wisconsin
  459. .lp
  460. Permission to use, copy, modify, and distribute this software and its
  461. documentation for any purpose and without fee is hereby granted,
  462. provided that the above copyright notice appear in all copies and that
  463. both that copyright notice and this permission notice appear in
  464. supporting documentation, and that the name of the University of
  465. Wisconsin not be used in advertising or publicity pertaining to
  466. distribution of the software without specific, written prior
  467. permission.  The University of Wisconsin makes no representations about
  468. the suitability of this software for any purpose.  It is provided "as
  469. is" without express or implied warranty.
  470. .lp
  471. THE UNIVERSITY OF WISCONSIN DISCLAIMS ALL WARRANTIES WITH REGARD TO
  472. THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
  473. FITNESS. IN NO EVENT SHALL THE UNIVERSITY OF WISCONSIN  BE LIABLE FOR
  474. ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  475. WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
  476. ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
  477. OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  478. .lp
  479. .ta 10n
  480. Authors:    Allan Bricker and Michael J. Litzkow,
  481. .br
  482.     University of Wisconsin, Computer Sciences Dept.
  483.