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

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

On Fri, Nov 16, 2001 at 05:25:34PM +1100, Bron Gondwana wrote:
> Andrew Arensburger said:
> > On Thu, Nov 15, 2001 at 01:05:01AM +1100, Bron Gondwana wrote:
> > 	To start off with, it sounds as if you want to run ColdSync in
> > daemon mode.
> 
> I have played with that.  It does look like what I want except for the
> "reads all databases on the palm" bit.  Also, it has to run as root and
> change users.  I would prefer to run as another user (and I've noticed
> in the comments here that it's possible to run as another user so long
> as all the per-palm options are for that same user).  I'll give it
> another try though.

	In daemon mode, ColdSync reads /usr/local/etc/palms to find
out which user it should run as, then calls setuid() to set its UID to
that user. It aborts if the setuid() call fails.
	Now, according to POSIX semantics, if your UID is 0, you can
setuid() to anything; but if your UID is 1234 and you setuid(1234),
that'll also succeed. Hence, you should be able to run it as user
"sync", as long as you never try to setuid to any other user.

> I presume that UID is set randomly
> by the Windows HotSync software?

	Yes.

> >> * 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

	Oops! I should have said "/usr/local/etc/coldsync.conf".

> > 	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.
> 
> Sounds reasonable.  Of course it has to deal with the other end palm dying
> or being lost, and replaced in the field. I like 'copy everything every
> time and sort it all out in the wash' because that way I have a history of
> changes pre-parsing.  I don't think the databases are likely to get that
> big on these trials anyway.

	If you want to be clever, you can also check the creation time
and modification number on the database. The modification number
apparently gets incremented each time a modification is made to the
database, and should therefore increase monotonically. The creation
time should be set once and never modified. You can use this as a
heuristic.
	Of course, the "download everything and sort it out later"
approach is more straightforward and less prone to error, even though
it involves more time on the phone.

> >> * 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.
> > 	}
> 
> Yep, though this suffers from the 'have to know type rather than name'
> issue I pointed out above.  Specificially, what if I have two databases
> with known names, but the same type and creator?

	Then they'll be passed to the same conduits.
	Of course, if they have the same creator, then presumably they
belong to the same application. And if they have the same type as
well, then they're databases of the same type.

	If you look in the "TODO" file, you'll see a suggestion to add
a "name:" field to conduit{} blocks, albeit a somewhat
counterintuitive one. The idea is that if you have

	conduit sync {
		type: AAAA/BBBB;
		type: CCCC/DDDD;
		name: Foo;
		name: Bar;
	}

then at least one of the "type:" lines has to match, AND at least one
of the "name:" lines has to match. The reason for this is to allow you
to say "Run this conduit on databases named `Foo', but only if it's a
MondoTool database," and also because "type is AAAA/BBBB or name is
FooDB" can be expressed by having two conduit{} blocks.

> >> * 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.
> 
> I don't particularly worry because I'm never giving them any information,

	At this point, if you want this, your best bet is to add it
yourself. If I were to add this, I'd proceed slowly and cautiously. I
prefer security over features.

> > 	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.
> 
> I can know them at the end of a project, but not always during.  In a
> perfect world, I'd get all the information in the correct order.  I'm
> quickly learning that medical data collection is not a perfect world,
> and all sorts of strange things will be sent in.  The important thing is
> that someone out in the field gets the behaviour they're expecting (my
> end sucks the data off their palm) rather than an obscure error message
> which generates a support phone call in the best case (within Australia),
> and long delays in the worst case (Mexico connections for now).

	Ew, yuck. This sounds like, in effect, the Palm version of a
data-collection form on the web, with all of the associated security
problems.

> > 	I'm not sure what you mean. What does ColdSync want to do that
> > it shouldn't be doing?
> 
> It decides what action (from the command line switches) to take before it
> knows what the remote palm is.  I was originally looking at branching from
> Daemon mode to Backup mode if I found a matching palm.

	You can always override the default behavior by specifying a
custom conduit that does anything you like.

> I guess the issue is what level it's best to deal with this - minimum
> disruption to coldsync and work out how to make conduits handle the
> work I need, or just hack coldsync into something more like my idea of
> the ideal app, while breaking all compatability.  Either way, Open
> Source makes it easier to do things.

	Off the top of my head, it sounds as if the simplest and
quickest thing to do would be to customize the way daemon mode
recognizes users and whatnot, and also write a conduit (either in
Perl, C, or C++) that does everything you want it to do.

> ( of course I _should_ write down all the things I've come across (I
>   believe the 'snum: "*Visor*-G" checksum issue that caused me trouble
>   for a while is fixed now), and write documentation patches - coldsync
>   is better documented than a lot of opensource stuff I've used, but
>   could probably do with more - no such thing as too much doco! )

	Yeah, please send this stuff in (if not a doco patch, then at
least a note saying how the doco sucks).

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
     It's alive. Well, not REALLY, but it was pretty scary, huh.
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.