Re: [coldsync-hackers] Automated Daemon with different actions for different palms.

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

On Thu, Nov 15, 2001 at 01:05:01AM +1100, Bron Gondwana wrote:
> I have maybe 200 Handspring Visors out in the field.  They all have modems
> in them, and are used to collect data.  This data is for many different
> projects.  At the moment, they dial a modem on a Win98 box running the
> standard hotsync software, which hopefully has accounts for all of them,
> and they sync data.  If this fails, they drop the connection unhappily.

	To start off with, it sounds as if you want to run ColdSync in
daemon mode.

> What I'd like is the following couple of bits of magic:
> 
> * ID either purely on username, or on username and user_id (only username
>   if no user_id has been entered in the config file)

	Since the Visor doesn't have a usable serial number[1], they
all show up with the dummy serial number "*Visor*", and ColdSync
decides which one it's dealing with based on the username and user ID.
	The reason for using both is that multiple people can have the
same name. It wouldn't do to have two users named John Smith share a
configuration, just because they share a name.

[1] Unless Handspring has fixed this in newer models.

> * Action taken depends on the username, i.e. backup, restore, full sync.

	You can specify a .coldsyncrc-like config file in
/usr/local/etc/palms . This allows you to specify a set of conduits to
run. If you don't want to perform a full sync, you can just override
this.
	Currently, there is no way to say "make a backup of FooDB" or
"restore /data/BarDB.pdb". You can, of course, write an external
Sync-flavored conduit for this, but perhaps a better way would be to
reuse the backup and restore code, and add two built-in conduits. Grep
for "DummyConduit" in src/conduit.c to see how to do this.

	On the other hand, this is probably suboptimal for your
purposes: a full backup does just that: it copies the entire database
from the Palm to the desktop, so if a user has a 3000-record database,
then all 3000 records are transferred.
	What would be better for your purposes would be one-way
variants of the generic conduit, which implement
palm-overwrites-desktop and desktop-overwrites-palm. I think the
easiest way to do this would be to subclass GenericConduit. You should
be able to inherit everything, and only override the SyncRecord
method.
	This way, if the user has a 3000-record database and only
changes one of them, then only that record is transferred.

> * Options are also available in the config.  I.E. for palms on which all
>   data is being collected into 'Foo' database, I would like to only backup
>   data in 'Foo', then disconnect the modem (some people are dialing from
>   Mexico to Australia, so line time is a premium).

	You can do this with a configuration similar to the following:

	conduit sync {
		type: XXXX/YYYY;	# Creator/type for "Foo" database
		path: /path/to/foo-conduit;
	}

	conduit sync {
		type: */*;		# Matches everything

		# No "path:" line, so this does nothing.
	}

	There is currently no way to prevent ColdSync from fetching
the list of all databases on the Palm.

> * If a username is not recognised, a default behaviour should be possible,
>   either a single default, or based on username (i.e. FooP234 username will
>   take the action for Foo).

	ColdSync doesn't do this, mainly because I don't like the
security implications.
	If you look at the "while ((palment = getpalment())" loop in
src/coldsync.c, you'll see how it determines whether an entry in
/usr/local/etc/palms matches the Palm at the other end of the current
connection or not. This code really ought to be put into a separate
function, and is known to be buggy, so feel free to suggest
improvements.
	For your purposes, I think the thing to do would be to declare
that a field whose value is "+" (by analogy with the truck-sized
security hole in Solaris) is a wildcard. Thus, the entry
	+|+|+|dataguy|+|/usr/local/libdata/collector.rc
would mean "if no other entry has matched so far, setuid() to user
`dataguy' and use /usr/local/libdata/collector.rc as the config file."
	However, bear in mind that doing this means that anyone can
dial in to your modem and poison your database with bogus data. If you
know who the data collectors are, which Palms they're using, and what
their user names and IDs are, you can have one entry per person.

	Oh, one more thing: currently, the config file format doesn't
allow you to include other config files. In other words, if twenty
people use a particular conduit to synchronize the "Foo" database, and
you want to change that, you need to edit twenty config files.
	Until this is fixed, you can always use m4 to generate
people's config files from a template.

> * Part of 'Backup only' is that I never send any data back to the palm, so
>   that nobody can set a Visor up with the same user/password pair and get
>   confidential information (this is patient data) out of the modem.
>   Another reason to leave Windows HotSync.

	See above.

> My question for the list - has anyone done anything this?  I've read
> through quite a lot of the coldsync code over the past few days, and
> played with a couple of options.  Unfortunately, the way the code is
> now means that coldsync is quite committed to exactly what it wants
> to do _before_ it knows who the palm is - or even opens a connection.

	I'm not sure what you mean. What does ColdSync want to do that
it shouldn't be doing?

> I guess the other question - is it worth me trying to re-architect
> this for everyone else (would anyone else be likely to use per-palm
> actions in a server only environment)?

	Yes, I think so. I'd like for ColdSync to be something you
could reasonably use to provide centralized syncing services for a
whole company.

> My other option is basically to murder coldsync.c.  I really don't
> like parser.y and the structs.

	What don't you like? If you have a better suggestion, I'm all
ears.

> Of course what would be left would be just the backup section, but
> written to assume options in the config file instead of on the
> command line.

	Take a look at the v2.2.4 snapshot, which has an options{}
section in the config file.

	I hope this answers some of your questions. If not, feel free
to ask.
	I do have one request, though: you are, of course, free to rip
out big honking chunks of ColdSync and replace them with your own. But
if you make your version incompatible with the standard version at
ooblick.com and distribute it to third parties, I'd like to ask that
you call your version something else, so that people don't mistakenly
assume that the two versions will work the same way.
	(In the best of all possible worlds, of course, we'd work out
some way of making the standard version do what you need it to, and
avoid gratuitous forking.)

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
 I am not the sysadmin you are looking for... move along, move along.
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.