This can also be done via an elevated command prompt using the sc command. The syntax is:
sc config [service name] depend= <Dependencies(separated by / (forward slash))>
Note: There is a space after the equals sign, and there is not one before it.
Warning: depend= parameter will overwrite existing dependencies list, not append. So for example, if ServiceA already depends on ServiceB and ServiceC, if you run depend= ServiceD, ServiceA will now depend only on ServiceD. (Thanks Matt!)
Examples
Dependency on one other service:
sc config ServiceA depend= ServiceB
Above means that ServiceA will not start until ServiceB has started. If you stop ServiceB, ServiceA will stop automatically.
Dependency on multiple other services:
sc config ServiceA depend= ServiceB/ServiceC/ServiceD/"Service Name With Spaces"
Above means that ServiceA will not start until ServiceB, ServiceC, and ServiceD have all started. If you stop any of ServiceB, ServiceC, or ServiceD, ServiceA will stop automatically.
To remove all dependencies:
sc config ServiceA depend= /
To list current dependencies:
sc qc ServiceA
Permissions are a pest.
Basically, you need to make sure that all of those developers can write to everything in the git repo.
Skip down to The New-Wave Solution for the superior method of granting a group of developers write capability.
The Standard Solution
If you put all the developers in a specially-created group, you can, in principle, just do:
chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo
Then change the umask for the users to 002, so that new files get created with group-writable permissions.
The problems with this are legion; if you’re on a distro that assumes a umask of 022 (such as having a common users group that includes everyone by default), this can open up security problems elsewhere. And sooner or later, something is going to screw up your carefully crafted permissions scheme, putting the repo out of action until you get root access and fix it up (i.e., re-running the above commands).
The New-Wave Solution
A superior solution—though less well understood, and which requires a bit more OS/tool support—is to use POSIX extended attributes. I’ve only come to this area fairly recently, so my knowledge here isn’t as hot as it could be. But basically, an extended ACL is the ability to set permissions on more than just the 3 default slots (user/group/other).
So once again, create your group, then run:
setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX
This sets up the extended ACL for the group so that the group members can read/write/access whatever files are already there (the first line); then, also tell all existing directories that new files should have this same ACL applied (the second line).
Hope that gets you on your way.
Best Answer
Delegated permission to install services is going to be a little bit tough. There is a "SC_MANAGER_CREATE_SERVICE" right that can be granted to users on the service control manager (SCM) object in the global object manager.
In Windows versions up to Windows Server 2003, the rights could not be changed on the SCM. Starting in W2K3 SP1, you could change the rights on the SCM.
The API to change the security is SetServiceObjectSecurity, and more information is available here: http://msdn.microsoft.com/en-us/library/aa379589(VS.85).aspx
Some more reference re: the rights that can be granted to the SCM and the default DACL set on the SCM is available here: http://msdn.microsoft.com/en-us/library/ms685981(VS.85).aspx
In short, there's no way to do this w/o writing code. There's no magic registry setting, etc. If you can get somebody to write the code for you, though, it's totally feasible.