DistOS-2011W FWR - Revision history

Freetonik: /* References */

2011-03-03T02:08:27Z

References

← Older revision		Revision as of 02:08, 3 March 2011
Line 336:		Line 336:

	=References=		=References=

			* Debian http://www.debian.org/
			* Unison http://www.cis.upenn.edu/~bcpierce/unison/
			* OpenSSH http://www.openssh.com/
			* Apache http://www.apache.org/
			* Watcher https://github.com/splitbrain/Watcher

Freetonik at 02:06, 3 March 2011

2011-03-03T02:06:06Z

← Older revision		Revision as of 02:06, 3 March 2011
Line 334:		Line 334:

	In this particular instance, I can say that pseudo-distributed web-server works pretty well with small number of clients. Minor changes are being synced almost seamlessly, major changes from different contributors can be stored separately (assuming some version control system is in place) or merged. There are a lot of ideas to try under this setup. Potentially, if all the clients be visible on the internet under single name, then the web-server could really be distributed.		In this particular instance, I can say that pseudo-distributed web-server works pretty well with small number of clients. Minor changes are being synced almost seamlessly, major changes from different contributors can be stored separately (assuming some version control system is in place) or merged. There are a lot of ideas to try under this setup. Potentially, if all the clients be visible on the internet under single name, then the web-server could really be distributed.

			=References=

Freetonik at 01:58, 3 March 2011

2011-03-03T01:58:59Z

← Older revision		Revision as of 01:58, 3 March 2011
Line 326:		Line 326:

	The only thing central server's needed for is, actually, internet-access to some data, generated by clients. But if the goal of community doesn't include this requirement, central server is no longer needed. It is important to choose the right of clients' interconnections in this case, but the good thing is: we no longer need officials!		The only thing central server's needed for is, actually, internet-access to some data, generated by clients. But if the goal of community doesn't include this requirement, central server is no longer needed. It is important to choose the right of clients' interconnections in this case, but the good thing is: we no longer need officials!

			=Conclusions=

			I learned that many good and useful things can be built with present tools and technology. Things like Facebook, Twitter, Dropbox only support this thought – none of them contributed anything truly revolutionary technology-wise, yet they are very successful projects. I believe there are many possibilities of building great distributed systems, but it is only a question of engineering, not necessarily invention.

			While setting this system up I understood, how easy it is to move towards more distributed configuration, and everyone should be able to do so, at least for the sake of data safety (backups). Even though the technology is here and it is available, people still trust companies or corporations to do this for them. There is no reason why is there are mediators between people and any useful technology.

			In this particular instance, I can say that pseudo-distributed web-server works pretty well with small number of clients. Minor changes are being synced almost seamlessly, major changes from different contributors can be stored separately (assuming some version control system is in place) or merged. There are a lot of ideas to try under this setup. Potentially, if all the clients be visible on the internet under single name, then the web-server could really be distributed.

Freetonik: /* What now? */

2011-03-01T16:55:22Z

What now?

← Older revision		Revision as of 16:55, 1 March 2011
Line 323:		Line 323:


	We already have a pretty useful system that suits at least ~~for~~ one use-case: collaborative web-development. But how about democracy and republic? We still need some officials to be elected, but what should they do? Since everything now belongs to everyone, the only responsibility left is to look after central server. This job is important, but not crucial: even if elected official does a bad data synchronization and then issues "rm -rf /" on central server, the data is not lost and the system still works (especially if some interconnection between clients' exist as described above). So we can elect officials, but don't really worry about risks.		We already have a pretty useful system that suits at least one use-case: collaborative web-development. But how about democracy and republic? We still need some officials to be elected, but what should they do? Since everything now belongs to everyone, the only responsibility left is to look after central server. This job is important, but not crucial: even if elected official does a bad data synchronization and then issues "rm -rf /" on central server, the data is not lost and the system still works (especially if some interconnection between clients' exist as described above). So we can elect officials, but don't really worry about risks.

	The only thing central server's needed for is, actually, internet-access to some data, generated by clients. But if the goal of community doesn't include this requirement, central server is no longer needed. It is important to choose the right of clients' interconnections in this case, but the good thing is: we no longer need officials!		The only thing central server's needed for is, actually, internet-access to some data, generated by clients. But if the goal of community doesn't include this requirement, central server is no longer needed. It is important to choose the right of clients' interconnections in this case, but the good thing is: we no longer need officials!

Freetonik: /* What now? */

2011-03-01T16:54:56Z

What now?

← Older revision		Revision as of 16:54, 1 March 2011
Line 323:		Line 323:


	We already have pretty useful system that suits at least for one use-case: collaborative web-development. But how about democracy and republic? We still need some officials to be elected, but what should they do? Since everything now belongs to everyone, the only responsibility left is to look after central server. This job is important, but not crucial: even if elected official does a bad data synchronization and then issues "rm -rf /" on central server, the data is not lost and the system still works (especially if some interconnection between clients' exist as described above). So we can elect officials, but don't really worry about risks.		We already have a pretty useful system that suits at least for one use-case: collaborative web-development. But how about democracy and republic? We still need some officials to be elected, but what should they do? Since everything now belongs to everyone, the only responsibility left is to look after central server. This job is important, but not crucial: even if elected official does a bad data synchronization and then issues "rm -rf /" on central server, the data is not lost and the system still works (especially if some interconnection between clients' exist as described above). So we can elect officials, but don't really worry about risks.

	The only thing central server's needed for is, actually, internet-access to some data, generated by clients. But if the goal of community doesn't include this requirement, central server is no longer needed. It is important to choose the right of clients' interconnections in this case, but the good thing is: we no longer need officials!		The only thing central server's needed for is, actually, internet-access to some data, generated by clients. But if the goal of community doesn't include this requirement, central server is no longer needed. It is important to choose the right of clients' interconnections in this case, but the good thing is: we no longer need officials!

Freetonik: /* What now? */

2011-03-01T16:54:28Z

What now?

← Older revision		Revision as of 16:54, 1 March 2011
Line 312:		Line 312:
	git push –verbose $sPathToRemoteGit master –receive-pack=’git receive-pack’ >> $sGitLogFile 2>&1		git push –verbose $sPathToRemoteGit master –receive-pack=’git receive-pack’ >> $sGitLogFile 2>&1
	}		}

	echo “{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{” >> $sGitLogFile 2>&1		echo “{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{” >> $sGitLogFile 2>&1
	echo $(date +%F[%T]) ” = STARTING TIME of common-push ” >> $sGitLogFile 2>&1 # Time stamp the start of processing		echo $(date +%F[%T]) ” = STARTING TIME of common-push ” >> $sGitLogFile 2>&1 # Time stamp the start of processing

Freetonik at 16:53, 1 March 2011

2011-03-01T16:53:46Z

@@ Line 263: / Line 263: @@
   fi
-Summarize the report, point to future work.
+=What now?=
-=References=
+Each client was running its own httpd and a every modification triggers fwr.sh script to sync with central server. This modifies data on central server, and these modifications trigger fwr.sh to sync with all clients consecutively. This configuration works pretty fast, but more increase in number of clients will lead to major time delays and potential inconsistencies.
-Give references in proper form (not just URLs if possible, give dates of access).
+Each client can create its own list of clients in 'fwr_clients' file and synchronize with them without touching central server by issuing 'fwr.sh csync'. Different topologies can be used depending on workload and frequencies of synchronizations.

Freetonik: /* Configuration */

2011-02-28T07:16:21Z

Configuration

@@ Line 125: / Line 125: @@
 * sshd (open-ssh daemon allowing remote connections from clients)
 * httpd (apache web-server)
-* incrond (monitoring system, syncs data on every modification)
+* watcher.py (monitoring system, syncs data on every modification)
 The following files should be present in /home/username on central server:
@@ Line 131: / Line 131: @@
 * fwr/www (citizen-site, not public)
 * fwr/www_tourist (tourist-site, public)
 * .ssh/authorized_keys (clients' keys)
 * .ssh/known_hosts (clients' hosts)
@@ Line 158: / Line 159: @@
 Now the contents of /home/username/fwr/www (which is the main citizen site) is available at http://website.com/fwr, and contents of /home/username/fwr/www_tourist (which is public citizen site) available at http://website.com/fwr_tour, where 'website.com' is server's public domain name. The citizen site must be protected on server side, so appropriate settings in /home/username/fwr/www/.htaccess must be added and .htaccess file should be ignored at synchronization. This will be described later.
 Much safer approach is to avoid putting fwr-citizen-site on public server altogether (as described in the general scheme in the beginning).
 ===inotify + pyinotify===
@@ Line 173: / Line 174: @@
   wget https://github.com/splitbrain/Watcher/tarball/master && tar zxvf master
 Make the following changes to watcher.ini:
@@ Line 185: / Line 235: @@
   python watcher.py start -c watcher.ini
-to be continued
+==fwr.sh==
 =Conclusion=

Freetonik: /* Client */

2011-02-28T02:25:55Z

Client

← Older revision		Revision as of 02:25, 28 February 2011
Line 107:		Line 107:


	6. Install inotify-based utility (optional):		6. Install watcher (or another inotify-based utility) (optional):

	Install Python, pyinotify, python-argparse		Install Python, pyinotify, python-argparse

Freetonik: /* Central server */

2011-02-28T02:25:13Z

Central server

← Older revision		Revision as of 02:25, 28 February 2011
Line 71:		Line 71:
	Download and unpack Watcher		Download and unpack Watcher

	wget https://github.com/splitbrain/Watcher/tarball/master && tar zxvf master		wget https://github.com/splitbrain/Watcher/tarball/master --no-check-certificate && tar zxvf master

	==Client==		==Client==