On Mar 24, 2009, at 12:31 PM, joel r wrote: > > On Mon, Mar 23, 2009 at 2:56 PM, joel r <[email protected]> wrote: >> On Sun, Mar 22, 2009 at 2:33 AM, Luke Kanies <[email protected]> >> wrote: >>> >>> On Mar 21, 2009, at 11:59 AM, joel r wrote: >>> >>>> >>>> >>>> On Sat, Mar 21, 2009 at 1:40 PM, Paul Nasrat >>>> <[email protected]> wrote: >>>> But you really should target master for new features like this. >>>> >>>> Sure. I've just rebased against master. >>> >>> Is this code online? I don't see it in your git repo. >> >> It's online now. >> >>>> Also rather than a monolithic patch could you post individual >>>> patches, see >>>> >>>> http://reductivelabs.com/trac/puppet/wiki/DevelopmentLifecycle >>>> >>>> Sorry, I really should have read this document before submitting my >>>> patch. >>>> >>>> >>>>> The code is up at http://github.com/finalprefix/puppet/tree/0.24.7-win >>>> . >>>>> >>>>> I'd love any feedback you might have! >>>> >>>> How are you finding running it on windows, there are a bunch of >>>> path >>>> issues I know that need to be cleaned up to run puppet. >>>> >>>> Well Facter tries to run domainname and dnsdomainname, which don't >>>> exist on windows. I'll probably patch Facter in a bit. >>>> >>>> Further, I've been focused on the providers, and I've been running >>>> them using the standalone puppet command. At the moment, puppetd >>>> doesn't work because fork is not implemented in ruby on Windows. >>>> The >>>> win32-process gem has an implementation of fork for windows. >>>> Perhaps >>>> it will solve the problem. >>> >>> Which of the existing types and providers do you expect to >>> eventually >>> work on Windows? >> >> I'm looking at adding support for windows ACLs to files, and doing >> what I can to support packages on Windows. Windows doesn't have >> package managers quite like apt / yum. But I might be able to get >> something done to support msi. >> >> Additionally, I'm looking at support for the registry, and basic >> directory service support. I think these would be new providers. >> >>> I expect that most of those that use forking wouldn't work on >>> Windows >>> anyway, but which of them that use fork would you want to use? >> >> None of these providers would need forking. I guess I was trying to >> get puppetd to work with as few changes as possible, which was why I >> tried to get fork and pipes to work. More on that below. >> >>>> Daemonization on puppetd will also require puppet to be a windows >>>> service. Again, there's a gem for this called win32-service. >>>> >>>> I also need to figure out how to get non inheritable pipes for >>>> lines >>>> 78 and 79 of lib\puppet\external\event-loop\event-loop.rb: >>>> # prevent file descriptor leaks >>>> @notify_src.fcntl(Fcntl::F_SETFD, Fcntl::FD_CLOEXEC) >>>> @notify_snk.fcntl(Fcntl::F_SETFD, Fcntl::FD_CLOEXEC) >>>> >>>> I attempt to run puppet using "puppet test.pp", and the fcntl calls >>>> throws: >>>> >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\lib\puppet >>>> \external\event-loop\event-loop.rb:78:in `initialize': >>>> uninitialized >>>> constant Fcntl::F_SETFD (NameError) >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\lib\puppet >>>> \external\event-loop\event-loop.rb:31:in `new' >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\lib\puppet >>>> \external\event-loop\event-loop.rb:31:in `default' >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\lib\puppet >>>> \external\event-loop\event-loop.rb:35:in `current' >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\lib\puppet >>>> \external\event-loop\event-loop.rb:285:in `initialize' >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\lib\puppet\util >>>> \settings.rb:532:in `new' >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\lib\puppet\util >>>> \settings.rb:532:in `set_filetimeout_timer' >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\lib\puppet\util >>>> \settings.rb:341:in `parse' >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\lib\puppet >>>> \application.rb:215:in `run' >>>> c:\ruby-1.8.7\lib\ruby\gems\1.8\gems\puppet-0.24.7\bin\puppet:68 >>>> c:\ruby-1.8.7\bin\puppet:19:in `load' >>>> c:\ruby-1.8.7\bin\puppet:19 >>>> >>>> I tried commenting out those two lines, and things worked fine. >>> >>> Nice - we've got problems going both directions. Unixes inherit too >>> many, and Windows can't inherit them at all? >> >>> It should be straightforward to block these out for Windows boxen. >> >> Daemonizing puppet on windows would not involve forking. We would >> make >> puppet run as a windows service, probably using win32-service. If we >> did, there should be no process invocations to inherit any pipes, and >> so we could just skip these lines on Windows configurations. >> Daemonizing would probably need some restructuring/additions in the >> daemonizing code, since windows use callbacks to signal >> start/stop/pause to a service. >> >> I believe it is possible for a spawned process to inherit pipes on >> Windows by passing the right flags. As I've mentioned earlier, >> IO.pipe >> does not by default use the O_NOINHERIT flag, so the resulting pipe >> should be inheritable. Whereas windows doesn't fork, there's an >> implementation of fork in win32-process that tries to fake it as >> closely as possible. However, the child process it spawned was not >> able to write back to the parent using the write handle provided by >> IO.pipe. I need to explore this a bit more. > > The pipes being used here are in the event loop code. My understanding > is that they are used to wake up the select call at > lib/puppet/external/event-loop/event-loop.rb:127. It's possible to > inherit pipes using CreateProcess and some flags on windows. But > Puppet on windows will not daemonize using a call to CreateProcess. > And it is seems it is not using the pipes to talk to any other > process, correct? If so, I'm thinking there should be no problem > bypassing lines 78 and 79 (which set the CLOEXEC flag) for windows in > lib/puppet/external/event-loop/event-loop.rb. Please let me know if > you think this is the wrong thing to do.
That should be ok. We should probably contribute the patches upstream, although I expect upstream has changed a bit and we haven't updated or anything. > > Next, I migrate my few tests to rspec :-) Great. -- Always behave like a duck - keep calm and unruffled on the surface but paddle like the devil underneath. -- Jacob Braude --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
