On 10/02/2010 22:55, T wrote:
Great suggestions once again - I did verify that it was at least
running the plink.exe binary when under LocalSystem by having the
service run "plink.exe> C:\plinkoutput.txt" - this worked fine. And,
as I mentioned, it's now working just fine when running under a
regular admin account. So, I think that's going to be my solution to
avoid any further issues. My best guess at this point (as you
mentioned), is that plink.exe is doing _something_ network-related
that LocalSystem doesn't have the privileges to do - what exactly it
is, I have no idea. I may play around with it some more later, but
running the service under an admin account should be a perfectly
acceptable solution.
Also, I will be writing other Python apps that the service will be
executing - so it goes without saying that I'll be including a log to
file option :) Thanks again for all your guys' help!
I'm not sure if this has been said already, but a reasonably common
approach to services is to create a user specifically for the
service and grant it exactly the privs / perms it needs (once you
work out what they are). You then assign it a generated password,
eg a GUID which you don't even try to remember: simply cut-and-paste
it in. Then create the service to run under that user.
That way you don't have the service running under
some local Administrator account with the associated risk
of its being subverted and gaining more control than you
want. Nor do you have it running as a real user whose
password might change for any reason, leaving you with
a service which won't start up.
I don't remember at this moment whether such a user's profile
is automatically loaded in the process when the service starts
or whether you have to do the LoadUserProfile thing.
TJG
--
http://mail.python.org/mailman/listinfo/python-list
