Hello I am entertaining the idea of putting some time and effort into making Facter and Puppet run on MS Windows. Call me crazy ... Does anyone know anything about the issues that I''m likely to face? What are the major stumbling blocks? Initially I''d be happy just getting File to work, this would be of tremendous value. I''m guessing that Facter will require the most work? After that Puppet''s job should be fairly trivial on each client box, yeah? Cheers Jesse _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
在 11 April , 2007，01:16，Jesse Reynolds 写道：> I am entertaining the idea of putting some time and effort into > making Facter and Puppet run on MS Windows. Call me crazy ...You're not crazy, but what you're suggesting is crazy. Actually, I think having provisional support for Puppet in Windows is definitely a good thing. Do you think you would prefer to work on this alone or with one or more other developers? I think support for Windows would have to come up to the bar in terms of functionality as well as stability for it to be pronounced part of the official and stable release. I think we'd be happy to publicize it as a work-in-progress, especially if that might attract other developers to help with the project. It's a big job, though. The primary problem being that every other platform Puppet runs on is a somewhat pure descendent of UNIX, so most of the exec or system calls would have to be rewritten for a different command interpreter and some of it might be tricky (pipelines and redirects won't work the same for sure). The other option would be to package bash or something along with puppet, which seems like an unwieldy proposition. Puppet providers, of course, require the systems they provide an interface for (the apt provider requires apt, etc), but in addition to this, shell commands like "tar", "echo", and "make" might be required for parts of puppet that aren't modular like the providers are. I'm saying this after just a cursory glance at the code looking for stumbling blocks.> Does anyone know anything about the issues that I'm likely to face? > What are the major stumbling blocks? > > Initially I'd be happy just getting File to work, this would be of > tremendous value. > > I'm guessing that Facter will require the most work? After that > Puppet's job should be fairly trivial on each client box, yeah?The differences in the filesystems may present unexpected problems, especially in terms of permissions, linking and other slickery. Trying to sort out how to deal with converting permissions from chmod- style permissions to any of the Microsoft-friendly filesystems is sure to at least deserve discussion on-list before deciding on particular policies. To some extent, though, I think it's hard to see those problems from a distance, so again, it would be very helpful if someone were doing active development in this area. Beyond this, considering the broader notion of Windows support, the stumbling blocks might be said to be as numerous or at least as numerous as the stumbling blocks we've experienced in the past under different descendants of UNIX, which, in glancing at the ticket database, seem to be of various sizes, shapes and colors, both forseen and unforseen. I think your tack is probably a good one, though: working toward providing basic support of File under Windows might be a good way to test the waters and see exactly how difficult this could be. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Wed, April 11, 2007 12:16 am, Jesse Reynolds wrote:> Hello > > I am entertaining the idea of putting some time and effort into > making Facter and Puppet run on MS Windows. Call me crazy ... > > Does anyone know anything about the issues that I''m likely to face? > What are the major stumbling blocks?The framework itself should not be all that difficult to port. The big question is what you want to accomplish on Windows. File management should be pretty straightforward, I would think, since I use native Ruby for almost everything, but user and package management, for instance, will likely be quite a bit harder.> Initially I''d be happy just getting File to work, this would be of > tremendous value. > > I''m guessing that Facter will require the most work? After that > Puppet''s job should be fairly trivial on each client box, yeah?I have no real idea how hard Facter will be. I would think you could just add windows-specific resolution mechanisms and it would just work. I don''t *think* this is a huge amount of work, but I have so little experience with Windows that I have no real idea. I''m certainly willing to do absolutely everything I can to support work in this area. -- Luke Kanies http://reductivelabs.com
This has been on my wish list since I started using Puppet 3 months ago :). I would love to see this happen and am happy to help with the port to Windows if help is wanted, I have done a lot of porting / development of cross-platform code with java and perl, so I hope I can be useful here. I have coded with ruby on and off over the last 5 years and am very comfortable with a handful of other languages as well. I agree that getting the File type to work is a great place to start, my second choice would be exec and then tidy .. after that a registry type would probably be pretty useful. I know that refactoring Puppet to use platform independent file handling code could be a big task, with perl I would use File::Spec for this, not sure what the Ruby equivalent is. I think Ruby has a nice stable interface to Win32 API calls like perl does, so that the user / group / etc calls can be coded easily as can forking and running new processes (for exec). The mid-to long-term issue becomes then how to either isolate the Win port so that it uses a separate enough code base from *nix puppet that no integration is needed or change mainline puppet to use a platform-independent API for OS-specific functionality that can be easily fleshed out on a per platform basis (like the perl module File::Spec does for example). At one point I even made a simple cross platform daemonize module for perl that would fork/exec a server process into the background on *nix or create a Win32 service out of a process, register the service, and then use Win32 service control calls to start / stop it on Win32. All the above issues are certainly things we don''t have to worry much about until there is a working Windows port of puppet :) that doesn''t concern itself about working on anything but Win32. Ready to help once the details of where this code will be initially stored etc are worked out. - Max On 4/11/07, Jesse Reynolds <jesse@va.com.au> wrote:> Hello > > I am entertaining the idea of putting some time and effort into > making Facter and Puppet run on MS Windows. Call me crazy ... > > Does anyone know anything about the issues that I''m likely to face? > What are the major stumbling blocks? > > Initially I''d be happy just getting File to work, this would be of > tremendous value. > > I''m guessing that Facter will require the most work? After that > Puppet''s job should be fairly trivial on each client box, yeah? > > Cheers > Jesse > > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users > > >
On Wed, 2007-04-11 at 17:32 -0400, Max wrote:> The mid-to long-term issue becomes > then how to either isolate the Win port so that it uses a separate > enough code base from *nix puppet that no integration is needed or > change mainline puppet to use a platform-independent API for > OS-specific functionality that can be easily fleshed out on a per > platform basis (like the perl module File::Spec does for example).To get started, you might want to try and get things working on cygwin first - at least that''ll give you basic tools that some of the code might depend on and a Unixy environment. It would be really interesting to see where exactly the problems lie in porting puppet to Windows. David
On 12/04/2007, at 1:31 AM, Benjamin C. Kite wrote:> > 在 11 April , 2007，01:16，Jesse Reynolds 写道： > >> I am entertaining the idea of putting some time and effort into >> making Facter and Puppet run on MS Windows. Call me crazy ... > > You''re not crazy, but what you''re suggesting is crazy. > > Actually, I think having provisional support for Puppet in Windows is > definitely a good thing. Do you think you would prefer to work on > this alone or with one or more other developers?Here I know I am not crazy. I definitely do not want to do this alone!> > I think support for Windows would have to come up to the bar in terms > of functionality as well as stability for it to be pronounced part of > the official and stable release. I think we''d be happy to publicize > it as a work-in-progress, especially if that might attract other > developers to help with the project.Sure. Note that I''m not a windows programmer and usually try and stay away from the platform as much as possible, preferring the safety of mac os x and unix. I''m also pretty new to Ruby so I''ll puddle about in my sandbox with it for a while. And I doubt I''ll have time to do much more than work on the File bit.> > It''s a big job, though. The primary problem being that every other > platform Puppet runs on is a somewhat pure descendent of UNIX, so > most of the exec or system calls would have to be rewritten for a > different command interpreter and some of it might be tricky > (pipelines and redirects won''t work the same for sure). The other > option would be to package bash or something along with puppet, which > seems like an unwieldy proposition.Yep, understand.> > Puppet providers, of course, require the systems they provide an > interface for (the apt provider requires apt, etc), but in addition > to this, shell commands like "tar", "echo", and "make" might be > required for parts of puppet that aren''t modular like the providers > are. I''m saying this after just a cursory glance at the code looking > for stumbling blocks.Yes of course. But I still think it''d be valuable to include partial support for windows in puppet, then at least you can manage configuration files for applications deployed on your windows servers, etc.> >> Does anyone know anything about the issues that I''m likely to face? >> What are the major stumbling blocks? >> >> Initially I''d be happy just getting File to work, this would be of >> tremendous value. >> >> I''m guessing that Facter will require the most work? After that >> Puppet''s job should be fairly trivial on each client box, yeah? > > The differences in the filesystems may present unexpected problems, > especially in terms of permissions, linking and other slickery. > Trying to sort out how to deal with converting permissions from chmod- > style permissions to any of the Microsoft-friendly filesystems is > sure to at least deserve discussion on-list before deciding on > particular policies. To some extent, though, I think it''s hard to > see those problems from a distance, so again, it would be very > helpful if someone were doing active development in this area.Yep, so hopefully some of us can at least get File working on windows and then reassess where we''re at.> > Beyond this, considering the broader notion of Windows support, the > stumbling blocks might be said to be as numerous or at least as > numerous as the stumbling blocks we''ve experienced in the past under > different descendants of UNIX, which, in glancing at the ticket > database, seem to be of various sizes, shapes and colors, both > forseen and unforseen.Indeed.> > I think your tack is probably a good one, though: working toward > providing basic support of File under Windows might be a good way to > test the waters and see exactly how difficult this could be.Cheers! Jesse _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On 12/04/2007, at 7:00 AM, Luke Kanies wrote:> > On Wed, April 11, 2007 12:16 am, Jesse Reynolds wrote: >> Hello >> >> I am entertaining the idea of putting some time and effort into >> making Facter and Puppet run on MS Windows. Call me crazy ... >> >> Does anyone know anything about the issues that I''m likely to face? >> What are the major stumbling blocks? > > The framework itself should not be all that difficult to port. The > big > question is what you want to accomplish on Windows. File management > should be pretty straightforward, I would think, since I use native > Ruby > for almost everything, but user and package management, for > instance, will > likely be quite a bit harder.Cool. The first complaint you get when you run puppetd on windows is about the "require ''syslog''" in puppet/lib/util/log/rb - I''m guessing syslog is something only present in Ruby on UNIX platforms. Maybe it will need to use log4r instead of syslog ? I''m not sure they are like for like...> >> Initially I''d be happy just getting File to work, this would be of >> tremendous value. >> >> I''m guessing that Facter will require the most work? After that >> Puppet''s job should be fairly trivial on each client box, yeah? > > I have no real idea how hard Facter will be. I would think you > could just > add windows-specific resolution mechanisms and it would just work.Actually facter does run, just produces about five facts (facterversion, hostname, ps - wrong I think, rubysitedir, and rubyversion). Should be simple to add operatingsystem to this and then we''ve got enough to do simple testing of puppet File meddling.> > I don''t *think* this is a huge amount of work, but I have so little > experience with Windows that I have no real idea. I''m certainly > willing > to do absolutely everything I can to support work in this area.Great! If this goes anywhere, would it make sense to make a branch on puppet''s subversion for the "windows port"? Would you consider merging it into the trunk at some point, even if it only allowed a subset of puppet''s functionality to work on Windows? Cheers Jesse _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Dave, On 4/11/07, David Lutterkort <dlutter@redhat.com> wrote:> To get started, you might want to try and get things working on cygwin > first - at least that''ll give you basic tools that some of the code > might depend on and a Unixy environment. > > It would be really interesting to see where exactly the problems lie in > porting puppet to Windows. >Good idea :), that should be pretty straight forward, pretty heavy requirement to depend on Cygwin but certainly should make for an easy port; with the /proc-based registry reading will make monitoring registry keys easy and nice to have the *nix style paths available for accessing windows directories. Jesse, you want to talk about this port on or off list to maybe come up with a list of tasks we could divide or would you prefer we just code a POC independently and then talk once we (and anyone else interested) has some experience with coding Puppet on Windows? Or should we just start that thread on the dev list? - Max
On 12/04/2007, at 7:32 AM, Max wrote:> This has been on my wish list since I started using Puppet 3 months > ago :). I would love to see this happen and am happy to help with the > port to Windows if help is wanted, I have done a lot of porting / > development of cross-platform code with java and perl, so I hope I can > be useful here. I have coded with ruby on and off over the last 5 > years and am very comfortable with a handful of other languages as > well.Excellent!> > I agree that getting the File type to work is a great place to start, > my second choice would be exec and then tidy .. after that a registry > type would probably be pretty useful.Fair enough.> > I know that refactoring Puppet to use platform independent file > handling code could be a big task, with perl I would use File::Spec > for this, not sure what the Ruby equivalent is. I think Ruby has a > nice stable interface to Win32 API calls like perl does, so that the > user / group / etc calls can be coded easily as can forking and > running new processes (for exec). The mid-to long-term issue becomes > then how to either isolate the Win port so that it uses a separate > enough code base from *nix puppet that no integration is needed or > change mainline puppet to use a platform-independent API for > OS-specific functionality that can be easily fleshed out on a per > platform basis (like the perl module File::Spec does for example). At > one point I even made a simple cross platform daemonize module for > perl that would fork/exec a server process into the background on *nix > or create a Win32 service out of a process, register the service, and > then use Win32 service control calls to start / stop it on Win32.My hope, and I don''t know how naive this is, would to have the same code run on windows and unix platforms. It seems people have already gone to much trouble to do posix type stuff on the windows platform. The RubyInstaller for windows (http://RubyInstaller.RubyForge.org/) includes the following gems to this end: log4r, win32-clipboard, win32-dir, win32-eventlog, win32-file, win32- file-stat, win32-process, win32-sapi, win32-sound, windows-pr. No doubt we''ll still run into trouble however.> > All the above issues are certainly things we don''t have to worry much > about until there is a working Windows port of puppet :) that doesn''t > concern itself about working on anything but Win32. > > Ready to help once the details of where this code will be initially > stored etc are worked out.Yeah, not sure about that. Perhaps a branch could be set up on the puppet subversion, or I could set up a subversion repository for this separately I suppose. Jesse _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On 12/04/2007, at 1:33 PM, Max wrote:> Dave, > > On 4/11/07, David Lutterkort <dlutter@redhat.com> wrote: >> To get started, you might want to try and get things working on >> cygwin >> first - at least that''ll give you basic tools that some of the code >> might depend on and a Unixy environment. >> >> It would be really interesting to see where exactly the problems >> lie in >> porting puppet to Windows. >> > > Good idea :), that should be pretty straight forward, pretty heavy > requirement to depend on Cygwin but certainly should make for an easy > port; with the /proc-based registry reading will make monitoring > registry keys easy and nice to have the *nix style paths available for > accessing windows directories.With Ruby you do use the unix style paths for accessing windows directories already, so that''s not a problem. You can include the c:/ or not, eg: irb(main):005:0> File.exists?("/WINDOWS") => true irb(main):006:0> File.exists?("c:/WINDOWS") => true ... irb(main):009:0> File.exists?("/WINDOWS/system32") => true> > Jesse, you want to talk about this port on or off list to maybe come > up with a list of tasks we could divide or would you prefer we just > code a POC independently and then talk once we (and anyone else > interested) has some experience with coding Puppet on Windows? > > Or should we just start that thread on the dev list?Good point. Perhaps I should join the dev list and we take this thread there? _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
--On Wednesday, April 11, 2007 7:04 PM -0700 David Lutterkort <dlutter@redhat.com> wrote:> It would be really interesting to see where exactly the problems lie in > porting puppet to Windows.While that might be interesting, I personally think the cost/benefit ration is really not very good. I''d like to see more continued focus on making Puppet better in the arenas that it is already in. There is still much to be done.
On 12/04/2007, at 3:04 PM, Digant C Kasundra wrote:> --On Wednesday, April 11, 2007 7:04 PM -0700 David Lutterkort > <dlutter@redhat.com> wrote: > >> It would be really interesting to see where exactly the problems >> lie in >> porting puppet to Windows. > > While that might be interesting, I personally think the cost/ > benefit ration > is really not very good. I''d like to see more continued focus on > making > Puppet better in the arenas that it is already in. There is still > much to > be done.In my current contract at the University of Sydney they are keen to have something like puppet help with configuration management of config files for applications running on Windows servers, and they''re prepared to put something back into the puppet project. ... I''d hope that if a few of us work on making puppet work (partially) on windows that this won''t stop existing efforts to improve puppet on already supported OS''s. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Apr 11, 2007, at 10:12 PM, Jesse Reynolds wrote:> > On 12/04/2007, at 3:04 PM, Digant C Kasundra wrote: > >> --On Wednesday, April 11, 2007 7:04 PM -0700 David Lutterkort >> <dlutter@redhat.com> wrote: >> >>> It would be really interesting to see where exactly the problems >>> lie in >>> porting puppet to Windows. >> >> While that might be interesting, I personally think the cost/ >> benefit ration >> is really not very good. I''d like to see more continued focus on >> making >> Puppet better in the arenas that it is already in. There is still >> much to >> be done. > > In my current contract at the University of Sydney they are keen to > have something like puppet help with configuration management of > config files for applications running on Windows servers, and > they''re prepared to put something back into the puppet project. ... > I''d hope that if a few of us work on making puppet work (partially) > on windows that this won''t stop existing efforts to improve puppet > on already supported OS''s.Not at all, more people with understanding of puppet''s internals can only be a huge boon to the project. -Blake
--On Thursday, April 12, 2007 3:12 PM +1000 Jesse Reynolds <jesse@va.com.au> wrote:> In my current contract at the University of Sydney they are keen to have > something like puppet help with configuration management of config files > for applications running on Windows servers, and they''re prepared to put > something back into the puppet project. ... I''d hope that if a few of us > work on making puppet work (partially) on windows that this won''t stop > existing efforts to improve puppet on already supported OS''s.Well, if there is an interest in actually *using* this for Windows than that''s different. I was thinking it was more of a porting exercise just for kicks. Best of luck! Perhaps if time permits later this year, I''ll help out where possible.
Jesse Reynolds wrote:> > On 12/04/2007, at 7:32 AM, Max wrote: > >> I know that refactoring Puppet to use platform independent file >> handling code could be a big task, with perl I would use File::Spec >> for this, not sure what the Ruby equivalent is. I think Ruby has a >> nice stable interface to Win32 API calls like perl does, so that the >> user / group / etc calls can be coded easily as can forking and >> running new processes (for exec). The mid-to long-term issue becomes >> then how to either isolate the Win port so that it uses a separate >> enough code base from *nix puppet that no integration is needed or >> change mainline puppet to use a platform-independent API for >> OS-specific functionality that can be easily fleshed out on a per >> platform basis (like the perl module File::Spec does for example). At >> one point I even made a simple cross platform daemonize module for >> perl that would fork/exec a server process into the background on *nix >> or create a Win32 service out of a process, register the service, and >> then use Win32 service control calls to start / stop it on Win32. > > My hope, and I don''t know how naive this is, would to have the same > code run on windows and unix platforms. It seems people have already > gone to much trouble to do posix type stuff on the windows platform. > The RubyInstaller for windows (http://RubyInstaller.RubyForge.org/) > includes the following gems to this end: > > log4r, win32-clipboard, win32-dir, win32-eventlog, win32-file, > win32-file-stat, win32-process, win32-sapi, win32-sound, windows-pr. > > No doubt we''ll still run into trouble however. >I think one of the really interesting problems there will be imo are in the area of package management as windows doesn´t really use a standardized packagesystem like rpm or dpkg and such. On the one hand there ist the MSI-systemem which works fairly decent if the packages are built accurately (which can´t even be said about all native MS apps..), on the other hand there ist a shitload of "3rd party" installers/packagers (InstallShield, Nullsoft Installer, Wise, Inno, etc.. just the ones that came straight to mind) that incorporate different mechanisms to install software quietly, IF utilized by the software producers/packagers. So you can´t even rely on the fact that the standardized option for "quiet install" will work for every package built with the same packaging system - which is pita as I found out while packaging all our internally used software for automated distribution. In quite a few cases I ended up converting the unwilling software in question to a MSI file just to encorporate the "quiet install" option without which automated installation is not possible at all.. I´ll be glad to help in that department (package handling) if the windows port should ever arrive there. Yes, I know this will be one of the problems adressed in a later state, after filehandling/ registry and such but I just wanted to mention this.>> >> All the above issues are certainly things we don''t have to worry much >> about until there is a working Windows port of puppet :) that doesn''t >> concern itself about working on anything but Win32. >> >> Ready to help once the details of where this code will be initially >> stored etc are worked out. > > Yeah, not sure about that. Perhaps a branch could be set up on the > puppet subversion, or I could set up a subversion repository for this > separately I suppose. > > Jesse >I´d really like that so we could toy with some ideas.. Simon> > ------------------------------------------------------------------------ > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
Definitely not just for kicks :), the group I work for really want a tool that can do CM/auditing/sysadmin automation for both Unix and Win systems; the commercial alternatives are not as useful or comprehensive or, more importantly, open, so integration becomes very painful with some of them. Tripwire in the auditing arena for example - enterprise [SNMP enabled] version is $100k+ and all it does is watch and report on changes and the SNMP traps that it sends out just summarize changes it found on a system .. no file names, just numbers of changes by level of important .. blech! There are many heterogeneous IT groups that I know would love to have ONE tool for both Win and Unix CM :). - Max On 4/12/07, Digant C Kasundra <digant@stanford.edu> wrote:> --On Thursday, April 12, 2007 3:12 PM +1000 Jesse Reynolds > <jesse@va.com.au> wrote: > > > In my current contract at the University of Sydney they are keen to have > > something like puppet help with configuration management of config files > > for applications running on Windows servers, and they''re prepared to put > > something back into the puppet project. ... I''d hope that if a few of us > > work on making puppet work (partially) on windows that this won''t stop > > existing efforts to improve puppet on already supported OS''s. > > Well, if there is an interest in actually *using* this for Windows than > that''s different. I was thinking it was more of a porting exercise just > for kicks. Best of luck! Perhaps if time permits later this year, I''ll > help out where possible. > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
On Wed, Apr 11, 2007 at 04:00:05PM -0500, Luke Kanies wrote:> I have no real idea how hard Facter will be. I would think you could just > add windows-specific resolution mechanisms and it would just work.I had a quick look at doing this a while ago, the initial issue was that factor relies on uname for a lot of its data. I wasn''t sure if it was best to do a complete fork and use WMI to pull the same basic data out - bad because every facter release requires patch porting, put everything in to the same file and do OS checking and make calls based on that ("Am I running on Windows? No? Assume uname is fine") - which has a lot of code duplication, or do some kind of table lookup based on if the machine is running Windows or not. Dean -- Dean Wilson http://www.unixdaemon.net Profanity is the one language all programmers understand --- Anon
On Wed, April 11, 2007 4:32 pm, Max wrote:> > I know that refactoring Puppet to use platform independent file > handling code could be a big task, with perl I would use File::Spec > for this, not sure what the Ruby equivalent is.I''ve been pretty careful throughout Puppet to use File::SEPARATOR instead of ''/'', and File.join() instead of ''/'', so this should actually be far easier than you might expect. I''d say try it. See if the tests pass. I know some things will fail --- I don''t check to see if the ''syslog'' library exists, for instance, which will cause a failure. But it shouldn''t be as hard as I''ve made it out to be. The rest I''ll comment on when I return next week. -- Luke Kanies http://reductivelabs.com
On Wed, April 11, 2007 10:27 pm, Jesse Reynolds wrote:> > Cool. The first complaint you get when you run puppetd on windows is > about the "require ''syslog''" in puppet/lib/util/log/rb - I''m guessing > syslog is something only present in Ruby on UNIX platforms. Maybe it > will need to use log4r instead of syslog ? I''m not sure they are like > for like...I should probably switch to log4r in general.> Actually facter does run, just produces about five facts > (facterversion, hostname, ps - wrong I think, rubysitedir, and > rubyversion). Should be simple to add operatingsystem to this and > then we''ve got enough to do simple testing of puppet File meddling.That''s more what I figured.>> I don''t *think* this is a huge amount of work, but I have so little >> experience with Windows that I have no real idea. I''m certainly >> willing >> to do absolutely everything I can to support work in this area. > > Great! > > If this goes anywhere, would it make sense to make a branch on > puppet''s subversion for the "windows port"? Would you consider > merging it into the trunk at some point, even if it only allowed a > subset of puppet''s functionality to work on Windows?Yeah, that''d probably be the best place to start. If you want to get started right away, Ben could probably sset you up with a branch and commit access; else I''ll do it when I get back. -- Luke Kanies http://reductivelabs.com
On Thu, April 12, 2007 12:12 am, Jesse Reynolds wrote:> > In my current contract at the University of Sydney they are keen to > have something like puppet help with configuration management of > config files for applications running on Windows servers, and they''re > prepared to put something back into the puppet project. ... I''d hope > that if a few of us work on making puppet work (partially) on windows > that this won''t stop existing efforts to improve puppet on already > supported OS''s.This is exactly my perspective -- Windows support will arrive when someone pays me to do it or does it themsevlves, but I would not do it on my own time. I will, however, do everything I can to senable this support. (I''m using a broken browser, so I can''t really tell if this email is legible.) -- Luke Kanies http://reductivelabs.com
On Apr 11, 2007, at 10:33 PM, Max wrote:> > Good idea :), that should be pretty straight forward, pretty heavy > requirement to depend on Cygwin but certainly should make for an easy > port; with the /proc-based registry reading will make monitoring > registry keys easy and nice to have the *nix style paths available for > accessing windows directories. > > Jesse, you want to talk about this port on or off list to maybe come > up with a list of tasks we could divide or would you prefer we just > code a POC independently and then talk once we (and anyone else > interested) has some experience with coding Puppet on Windows? > > Or should we just start that thread on the dev list?I''d like to keep this on the main lists, so please start a thread on the dev list. I expect there''ll be various design decisions that will affect the rest of Puppet. -- It has recently been discovered that research causes cancer in labratory rats. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Apr 11, 2007, at 10:36 PM, Jesse Reynolds wrote:> > Yeah, not sure about that. Perhaps a branch could be set up on the > puppet subversion, or I could set up a subversion repository for > this separately I suppose.I''m happy with a branch and giving commit access to those who are interested in working on this (maybe after the first patch or something). I don''t think it makes sense to require a separate repository -- I certainly want to support this as much as possible. -- Talent hits a target no one else can hit; Genius hits a target no one else can see. -- Arthur Schopenhauer --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Apr 12, 2007, at 10:05 AM, Dean Wilson wrote:> > I had a quick look at doing this a while ago, the initial issue was > that > factor relies on uname for a lot of its data. I wasn''t sure if it > was best > to do a complete fork and use WMI to pull the same basic data out - > bad > because every facter release requires patch porting, put > everything in to the same file and do OS checking and make calls > based on > that ("Am I running on Windows? No? Assume uname is fine") - which > has a > lot of code duplication, or do some kind of table lookup based on > if the > machine is running Windows or not.We could have a simple fact that says whether we''re a Windows machine or a unix-like machine ("posix"?), and make most of the existing facts depend on being posix systems. Facter has support for making this work, I''ve just never worked on restricting the current set of facts to being skipped on non-Unix- like systems. -- I have never met a man so ignorant that I couldn''t learn something from him. --Galileo Galilei --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com