I''m trying to run mongrel_service for a small rails app under Win 2003. I have installed the service and can run with the default local system account fine. However once I change the account to a new custom service account I cannot start the service. Nothing is being logged, in the event log or any of the mongrel logs. The -B switch doesn''t create any debug logs. I know this is going to be a Windows permission that hasn''t been granted it''s just how to track it down? What does work: - local system - Log in as my admin account, use runas to run a command prompt as my new service user - then copy the mongrel_service path/paramters from the registry and run as is (modified as mongrel_rails) - this works fine. Initially I had a warning about the ./log directory but once granted full control all seems fine. - The service account is marked with run as service, ./log and ./tmp have been updated to allow full control for the service account, the account is also a member of the users group (which inherits some default file system ACLs). Note some of these I would not normally do for a least priv account but just to document what I''ve tried. - Adding administrators group to the service account - of course seems to clear the problem. Anything else I can check? Ruby version is 1.8.6 patch level 111 on Win32 Mongrel service 0.3.4
On Mon, Jul 27, 2009 at 11:38 AM, Darren Syzling<dsyzling at gmail.com> wrote:> I''m trying to run mongrel_service for a small rails app under Win > 2003. I have installed the service and can run with the default local > system account fine. However once I change the account to a new custom > service account I cannot start the service. Nothing is being logged, > in the event log or any of the mongrel logs. The -B switch doesn''t > create any debug logs. > > I know this is going to be a Windows permission that hasn''t been > granted it''s just how to track it down? > > What does work: > - local system > - Log in as my admin account, use runas to run a command prompt as my > new service user - then copy the mongrel_service path/paramters from > the registry and run as is (modified as mongrel_rails) - this works > fine. Initially I had a warning about the ./log directory but once > granted full control all seems fine. > - The service account is marked with run as service, ./log and ./tmp > have been updated to allow full control for the service account, the > account is also a member of the users group (which inherits some > default file system ACLs). Note some of these I would not normally do > for a least priv account but just to document what I''ve tried. > - Adding administrators group to the service account - of course seems > to clear the problem. > > Anything else I can check? >Check mongrel_service.log inside ruby/bin folder. With the information stored there I would be able to help you better. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
Luis Lavena wrote:> > Check mongrel_service.log inside ruby/bin folder. > > With the information stored there I would be able to help you better. > >The mongrel_service.log is empty. I''ve granted full control on the log file for the service user in question in case this is an file ACL issue, but nothing being logged. Thanks Darren
On Mon, Jul 27, 2009 at 4:22 PM, Darren Syzling<dsyzling at gmail.com> wrote:> Luis Lavena wrote: >> >> Check mongrel_service.log inside ruby/bin folder. >> >> With the information stored there I would be able to help you better. >> >> > > The mongrel_service.log is empty. I''ve granted full control on the log file > for the service user in question in case this is an file ACL issue, but > nothing being logged. >Ok, that means we are going to go over the runas console debug mode. I''m going to remove the dust my instructions on this: http://rubyforge.org/pipermail/mongrel-users/2008-October/005587.html And pointing to the "guide to debug mongrel_service" http://rubyforge.org/pipermail/mongrel-users/2008-October/005588.html Which links here: http://rubyforge.org/pipermail/mongrel-users/2007-February/003004.html Please let me know if these instructions are not easy to follow, but everything is there to debug the issue. Cheers, -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
2009/7/27 Luis Lavena <luislavena at gmail.com>:> Ok, that means we are going to go over the runas console debug mode. > > I''m going to remove the dust my instructions on this: > > http://rubyforge.org/pipermail/mongrel-users/2008-October/005587.html > > And pointing to the "guide to debug mongrel_service" > > http://rubyforge.org/pipermail/mongrel-users/2008-October/005588.html > > Which links here: > > http://rubyforge.org/pipermail/mongrel-users/2007-February/003004.html > > Please let me know if these instructions are not easy to follow, but > everything is there to debug the issue. >Luis, thanks for your help the instructions are fine, but I''m still not getting to the root of the issue. I understand this is extremely difficult for you to diagnose. I''ve wrestled with these least privilege accounts in the past so I''m aware of the kind of issues that cause apps to fail. Typically I run service accounts with deny local logon and exclude membership from Users - you''ll be surprised the amount of privs that are granted (especially ACLs) on User group membership. Anyway in this case this is a straight user so this shouldn''t be the cause of the issue. So I temporarily added my service account to the ''remote desktop users'' group so I could logon remotely as that user (I''ve also done this from my admin account using runas /user:xxx - but I''m checking all avenues here). Started a console and copied the service executable string for my mongrel_rails service to the console (adjusted to run as a console app) and run as: mongrel_service console single -e development -p 58025 -a 0.0.0.0 -l "log/mongrel.log" \ -P "log/mongrel.pid" -c "<path to my app>" -t 0 -r "public" -n 1024 This works fine - I can connect via port 58025 from my remote browser and the app works fine. Service string in the registry is: "c:/ruby/bin/mongrel_service.exe" single -e development -p 58025 -a 0.0.0.0 -l "log/mongrel.log" -P "log/mongrel.pid" -c "<path to my app>" -t 0 -r "public" -n 1024 However as soon as I attempt to start from the service manager mongrel_service starts and then immediately terminates. No log messages. So I ran up Procmon and tried starting the service to see if I can see any obvious file ACL failures. Again nothing obvious, I can see mongrel_service starting, I can see a set of activity, some registry reads, I don''t see any attempt to open the mongrel log file in ruby\bin as I do when it works as a member of the admin group. I then see the process exit (no obvious errors before this) and the service account''s profile unloads. I thought there might be permission issues on registry keys, but most keys in the registry (and service tree) have permissions set for the Users group, so if my account is a member of this it shouldn''t need anything else. There doesn''t seem to be any issues in the event log, the security event log shows success audits for authentication - the account logging in with auth type 5. I tried granting impersonate rights to the service account - I really doubt this is needed, but some ASP.NET accounts have this - probably more for windows integrated authentication then service based access. But this still failed. Clearly I''m missing something and mongrel_service is encountering some lack of permission since as I said adding the service account to the administrators group the app works fine. Is our server tied down - yes could be pretty tightly, ipsec rules etc. It does have Kaspersky. I may have to grab the code for mongrel_service and attempt to instrument it to see how far it gets. Unless there''s any further debugging steps I can try? Thanks Darren
2009/7/28 Darren Syzling <dsyzling at gmail.com>:> > Clearly I''m missing something and mongrel_service is encountering some > lack of permission since as I said adding the service account to the > administrators group the app works fine. > > Is our server tied down - yes could be pretty tightly, ipsec rules > etc. It does have Kaspersky. I may have to grab the code for > mongrel_service and attempt to instrument it to see how far it gets. > > Unless there''s any further debugging steps I can try? > > Thanks > Darren >After posting yesterday I also came across this thread which looks very similar to the situation I''m encountering: http://www.ruby-forum.com/topic/155315. I wonder if this was issue was resolved? Regards Darren
On Wed, Jul 29, 2009 at 1:03 PM, Darren Syzling<dsyzling at gmail.com> wrote:> 2009/7/28 Darren Syzling <dsyzling at gmail.com>: >> >> Clearly I''m missing something and mongrel_service is encountering some >> lack of permission since as I said adding the service account to the >> administrators group the app works fine. >> >> Is our server tied down - yes could be pretty tightly, ipsec rules >> etc. It does have Kaspersky. I may have to grab the code for >> mongrel_service and attempt to instrument it to see how far it gets. >> >> Unless there''s any further debugging steps I can try? >> >> Thanks >> Darren >> > > After posting yesterday I also came across this thread which looks > very similar to the situation I''m encountering: > http://www.ruby-forum.com/topic/155315. I wonder if this was issue was > resolved? >I believe it was. Can you check and supply the output of servicefb.log? Apologize for the detail but work has been hectic lately. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
Luis Lavena wrote:> I believe it was. > > Can you check and supply the output of servicefb.log? > >I''m not sure 0.3.4 which I''m running logs messages to this log, the thread quoted claimed you had to drop back to 0.3.3? When I experience this issue I don''t get any log written at all.> Apologize for the detail but work has been hectic lately. >No problem, in the meantime I pulled the code myself and simply set the default RunCode to be RunAsService if it couldn''t detect the run context, as opposed to RunAsUnknown. This at least cured the problem and allowed me to start the service as a non admin account. So specifically what I mean is: --- ServiceFB_Utils.bas (revision 1037) +++ ServiceFB_Utils.bas (working copy) @@ -112,7 +112,11 @@ else ''# ok, the first paramenter in the commandline didn''t work, ''# report back so we could send the banner! - result = RunAsUnknown + ''# DS Fix - OpenProcess on a parent to check for services.exe name does not work + ''# when using a non admin account, so here we assume that the user wants to run + ''# as a last ditch attempt to decide the mode we run in. + ''#result = RunAsUnknown + result = RunAsService end if end if This was only a local hack to get it up and running on my side. I didn''t debug too much further but presume OpenProcess on the parent is a privileged operation - so the check to see if the parent is ''services.exe'' fails and then it can''t detect the runmode. If you want me to absolutely confirm this I can. Let me know how you want to move forward. Regards Darren