[Spambayes] A most peculair problem with SB 1

[Robert Neuschul]

Tony

This is going to take some time to respond to since there are now 
several issues cropping up. To keep things a bit simpler I shall deal 
with each of them as distinct reply messages.

You will note that my root message concerned itself explicitly with the 
installation and use of SB on Windows 2003. In your message you ask if 
things are different on 2003 - and the answer is yes: very different in 
all sorts of ways. 

For a systems administrator on 2003 things such as Active Directory, 
User Controls, Securities and Permissions, ACLs and Group Policies have 
all changed in a number of ways that are now far more consistent and 
logical [for example Exchange and Active Directory are now properly 
integrated - if Exchange is installed and one creates a new user logon 
for the lan one has automatically created an Exchange account - 
Exchange 'objects' are system objects, and vice versa - see below for 
more on this], and in many many regards these elements of 2003 now have 
much more in common with standard LDAP/X400/X500 and Unix-style 
processes and procedures than they do with previous Windows 2000 
servers. 
In addition, as implied above, 2003 is now almost entirely object 
oriented in its "thinking" and in its management. The top level objects 
are the forests, zones and domains, making Administration across 
multiple failover servers much simpler [but also much more powerful] 
and more logical.

The issue of installing a service, and where that service should look 
for its configuration data, and where and how it should store any 
output data or logging is therefore a fraught one. The one thing that 
one can say with great certainty is that none of these things should 
ever be stored in the user data or user profile areas - the handling of 
these areas by Windows 2003 is now - like so much else - completely 
different, and that handling will vary depending upon the precise 
combination of network and server settings in use. That 
variability/changeability is utterly crucial to the statement that 
services data should not be stored there.

All sorts of things *will* go pear shaped if an advanced or non-default 
systems/network configuration is in use - for example when the user who 
installs SB has Administrator rights and is using terminal services to 
the server to install a product such as Spambayes, and also has the 
equivalent of roaming profiles [now deprecated as a method - there are 
alternative and better ways of doing the same thing] with cached local 
proxying from a workstation [aka Offline working mode] - then all their 
/subsequent/ session data from the roaming [non terminal] login ends up 
in the system-defined directory called \\domain\servername\Users and 
will fail to synchronise with the matching directory called 
\\server\Documents and Settings\User\Application Data\Spambayes, which 
Spambayes will have created during its install. 

That issue relating to the user data config area will get significantly 
more complex and nasty when there are 2 or more servers in use with 
automated failover between them: synchronisation of data and services - 
replication - in the event of a failure in what we used to call the PDC 
under Win 2000 is now capable of being fully automated - but will only 
work reliably if data and configurations are in places which the 
participating replication partner systems understand - and C:\Documents 
and Settings\User_Name\Application Data is not generally considered to 
be one of those safe places.

Service data [whether config or output] is - at least in my opinion - 
normally best stored either within a subdirectory of the directory 
structure of the application itself - in this case that would be 
somewhere such as c:\Python23\Spambayesconfig  - or in a location 
within the Windows tree such as %SYSTEMROOT%\System32\Spambayesconfig 
or similar. 
I'd also suggest that log files should not be sent to temp directories 
which get scavenged by 2003, and that the WMI interface be used to send 
warnings etc to the Windows Application Event log.

That way, synchronisation and failover and backup and versioning can 
all proceed correctly without impact on the performance of SB.

As a part of the changes in the way 2003 is designed and works, 
securities and permissions are somewhat changed as well: and in turn 
the way in which services are allowed to interact with both the wider 
system [which now logically includes any additional 2003 servers within 
the forest/zone/domain] and the desktop and any network resources has 
also changed. I can't tell you precisely how they've changed because 
this isn't my area of exertise and I therefore haven't looked into the 
programming of these services.

Hope this begins to clarify some of the issues. Sorry if there's any 
ambiguity or obscurity - if you have any questions please ask and 'll 
endeavour to answer them.
Other parts of my answer to follow later :-)

Robert