Edited wiki page through web user interface.
This commit is contained in:
parent
af8f298717
commit
f9e1a6fb25
|
@ -32,6 +32,10 @@ If a larger number of nodes are used, say more than five to ten, it will be a ha
|
||||||
|
|
||||||
The easiest solution that comes to mind is to use a central configuration or instruction file on the central server. Nodes will be able to access this file, read its contents and act accordingly.
|
The easiest solution that comes to mind is to use a central configuration or instruction file on the central server. Nodes will be able to access this file, read its contents and act accordingly.
|
||||||
|
|
||||||
|
== Node status ==
|
||||||
|
|
||||||
|
If a larger number of nodes are used, it would be nice if some simple overview could be generated about the current status of nodes and the overal progress of the entire process.
|
||||||
|
|
||||||
== Locking of items through SSH ==
|
== Locking of items through SSH ==
|
||||||
|
|
||||||
According to many sources on the Internet, the only reliable solution to *atomic* locking is to use the 'mkdir' command to create a file. The fun thing is that this is also true if 'mkdir' is executed through SSH.
|
According to many sources on the Internet, the only reliable solution to *atomic* locking is to use the 'mkdir' command to create a file. The fun thing is that this is also true if 'mkdir' is executed through SSH.
|
||||||
|
|
Loading…
Reference in New Issue