I''m playing around with puppet 0.24.6 on Fedora 10. It appears that the service type doesn''t support the new upstart way of doing things ... only the old sysvinit way. Has anyone seen any effort towards providing support or simply some decent work arounds? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
John Florian wrote:> I''m playing around with puppet 0.24.6 on Fedora 10. It appears that > the service type doesn''t support the new upstart way of doing > things ... only the old sysvinit way. Has anyone seen any effort > towards providing support or simply some decent work arounds?What do you need to work around? Isn''t Upstart, from a userspace perspective, completely backwards compatible with SysV init? Can you cite your specific issues? Regards James Turnbull -- Author of: * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/)
> What do you need to work around? Isn''t Upstart, from a userspace > perspective, completely backwards compatible with SysV init? > > Can you cite your specific issues?Yes and no; or at least that''s my understanding. From what I''ve seen it can be used in such a way that it appears to be sysvinit compatible, but it doesn''t have to be. For example, I can drop a file with the following contents into /etc/event.d on a Fedora 10 box and it will behave as a service, even though the traditional /etc/rcN.d directories are not populated at all: # /etc/event.d/example start on stopped rc2 start on stopped rc3 start on stopped rc4 stop on runlevel 0 stop on runlevel 1 stop on runlevel 6 respawn exec /usr/bin/example_daemon --arg1 --arg2 From the CLI, I can manage this service with things like: initctl start example initctl stop example initctl status example What I''ve done this far in puppet is: exec { "example-service": command => "initctl start example", onlyif => "initctl status example | grep -qv running", } So maybe it''s wrong to expect the service type to handle this. Maybe we need a specific upstart type instead? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
John Florian wrote:> initctl start example > initctl stop example > initctl status example > > > What I''ve done this far in puppet is: > > exec { "example-service": > command => "initctl start example", > onlyif => "initctl status example | grep -qv running", > } > > > So maybe it''s wrong to expect the service type to handle this. Maybe > we need a specific upstart type instead? > > >An upstart provider for the service type should be fine. It should be relatively easy to develop. If you don''t want to develop yourself can you please log a feature request and I''ll knock something up. Cheers James -- Author of: * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 17, 5:18 pm, James Turnbull <ja...@lovedthanlost.net> wrote:> An upstart provider for the service type should be fine. It should be > relatively easy to develop. If you don''t want to develop yourself can > you please log a feature request and I''ll knock something up. > > Cheers > > James > > -- > Author of: > * Pulling Strings with Puppet > (http://www.amazon.com/gp/product/1590599780/) > * Pro Nagios 2.0 > (http://www.amazon.com/gp/product/1590596099/) > * Hardening Linux > (http://www.amazon.com/gp/product/1590594444/)I''m not sure I''m up to developing this myself just yet as I''m very new to puppet and haven''t done any ruby thus far. I was about to create a feature request, but then realized what you were saying about adding upstart as a provider to the service type. I''m not sure that''s exactly what''s needed. It''s what I need, but perhaps would be wrong for other uses of upstart. Upstart by design is event driven, so you can have things like this: # This task is run whenever the Control-Alt-Delete key combination is # pressed. Usually used to shut down the machine. start on control-alt-delete exec /sbin/shutdown -r now "Control-Alt-Delete pressed" Here''s another example from Fedora 10 that shows even more diversity: start on fedora.serial-console-available * stop on runlevel [016] instance pre-start script # script portion removed for brevity end script exec /sbin/agetty /dev/$1 $2 vt100-nav post-stop script # script portion removed for brevity end script I found the following page to be a quick, but informative read on some of the capabilities: http://upstart.ubuntu.com/getting-started.html --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Dec 18, 2008 at 6:00 AM, John Florian <john.florian@dart.biz> wrote:> I''m not sure I''m up to developing this myself just yet as I''m very new > to puppet and haven''t done any ruby thus far. I was about to create a > feature request, but then realized what you were saying about adding > upstart as a provider to the service type. I''m not sure that''s > exactly what''s needed. It''s what I need, but perhaps would be wrong > for other uses of upstart. Upstart by design is event driven, so you > can have things like this: > > # This task is run whenever the Control-Alt-Delete key combination is > # pressed. Usually used to shut down the machine. > > start on control-alt-delete > > exec /sbin/shutdown -r now "Control-Alt-Delete pressed" > > > Here''s another example from Fedora 10 that shows even more diversity: > > start on fedora.serial-console-available * > stop on runlevel [016] > > instance > pre-start script > # script portion removed for brevity > end script > exec /sbin/agetty /dev/$1 $2 vt100-nav > post-stop script > # script portion removed for brevity > end script > > I found the following page to be a quick, but informative read on some > of the capabilities: http://upstart.ubuntu.com/getting-started.htmlMany of those concepts don''t currently map cleanly into Puppet''s model. There''s no reason they can''t, the model could be extended to cover these concepts. However, the way that should happen is to add providers to types which are already in Puppet''s model, and create new generic types to cover the other concepts. Since Puppet is to some extent an abstraction layer, we should strive to use/create generic abstractions rather than create a bunch of specific stuff (like an "upstart" type). Anyway, there''s nothing wrong with building support for this sort of thing incrementally; why not make a provider for the service type that uses some of upstart''s capabilities and ignores the rest? As for whether you are up to developing a provider: trust me, you probably are. The best way to stop being new to both Puppet and Ruby is to pick a task that is both useful, slightly complex without being far too difficult, and interesting to you. This sounds like it could be just the thing for you. --Paul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---