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. Next, I migrate my few tests to rspec :-) - Joel. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
