Hi, I''m working on a method to manage packages which require a reboot after being installed. I''m curious how other people are handling this problem. Consider the resource: pkg_deploy { "MacOSXUpdCombo10.4.9Intel.dmg": alias => macosx1049 } I''d like to only install the package under if the following conditions are met: - No user is logged into the console. - No user logs in while the package is being installed. - The computer will be rebooted after configuration ends. So, I''m thinking of defining a new resource which includes a console locking class. In Mac OS X, the contents of /var/run are purged every boot, so I''m planning to prevent login by touching a file which a login hook looks for. The hook will do something like: [ -e /var/run/nologin ] && killall loginwindow So, to lock the console down if nobody is logged in: class lock-console { exec { "nologin": command => "touch /var/run/nologin", creates => "/var/run/nologin", unless => "who | grep console" } } Then, I''ll define a package helper: define package_reboot { include lock-console pkg_deploy {"MacOSXUpdCombo10.4.9Intel.dmg": require => Exec["nologin"], alias => macosx1049, } } This should take care of only installing the package if nobody is logged into the console (who | grep console) and the login process is prevented (touch /var/run/nologin), but I''m struggling to find a way to reboot the machine after all other configuration has completed. Perhaps something like notify => Service["reboot"], and define a logical service to reboot the machine? Ideas? Cheers, -- Jeff McCune The Ohio State University Department of Mathematics Systems Manager _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Apr 30, 2007, at 10:38 AM, Jeff McCune wrote: [...]> Perhaps something like notify => Service["reboot"], and define a > logical > service to reboot the machine? > > Ideas?The short answer is: Here be dragons. At least, trying to do that cross-platform is insanely painful. With HP-UX, for example, the best I could ever get was to attempt a shutdown, give it 30 seconds or so, and then do a straight reboot -- I literally never figured out how to do an automated shutdown. The real question here is, how do you trigger a reboot at the right time? Do you want to reboot as soon as the package is installed? Once everything is done? Etc. I think rebooting is going to have to be treated specially by Puppet; my guess is that we''ll need builtin support on the client for rebooting, and there''ll need to be some kind of magical way to say "reboot this system". I have no idea what that should look like though. Any ideas? -- The most likely way for the world to be destroyed, most experts agree, is by accident. That''s where we come in; we''re computer professionals. We cause accidents. --Nathaniel Borenstein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
在 3 May , 2007,18:26,Luke Kanies 写道:> I think rebooting is going to have to be treated specially by Puppet; > my guess is that we'll need builtin support on the client for > rebooting, and there'll need to be some kind of magical way to say > "reboot this system". > > I have no idea what that should look like though. Any ideas?My first gut reaction is that it should be a fairly simple declaration which really just sets a flag and executes the reboot last; always last. Maybe an option to not reboot if there are errors in the rest of the manifest that don't stop the update. reboot { "bind": ensure => "true" abort = > "onerror"} Ordering wise, I suppose you could also make it depend on another type, which might imply that that type (and its dependencies) are a sufficient condition for the reboot. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 4, 2007, at 11:35 AM, Benjamin C. Kite wrote:> > My first gut reaction is that it should be a fairly simple > declaration which really just sets a flag and executes the reboot > last; always last. Maybe an option to not reboot if there are errors > in the rest of the manifest that don''t stop the update. > > reboot { "bind": > ensure => "true" > abort = > "onerror"} > > Ordering wise, I suppose you could also make it depend on another > type, which might imply that that type (and its dependencies) are a > sufficient condition for the reboot.Hmm, having a special-purpose reboot resource probably *is* the best way to do it, and just set it up so it only runs if something sends it an event. It''d be weird, though, because it''d be a singleton -- you could really only ever have one reboot instance, right? Or would it make sense to have multiple ways of thinking about rebooting? The nice thing about doing it this way is that then it''s easy to have different providers for every platform, of course. -- Anyone who considers arithmatical methods of producing random digits is, of course, in a state of sin. --John Von Neumann --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
在 4 May , 2007,17:04,Luke Kanies 写道:> Hmm, having a special-purpose reboot resource probably *is* the best > way to do it, and just set it up so it only runs if something sends > it an event. > > It'd be weird, though, because it'd be a singleton -- you could > really only ever have one reboot instance, right? Or would it make > sense to have multiple ways of thinking about rebooting?I'm not sure I'd want to have them conflict or even throw a warning if there were. As an example, if an OS X system update has 2 packages that require a reboot, there's no need to interpret that as anything other than one reboot, ultimately, but that doesn't mean we should restrict how many times in the manifest a reboot is requested. Your comment also raises the question of halt vs. reboot and, ultimately, perhaps, of runlevels, which may be a logical and fruitful place to take things. Frankly, I've been at only a few sites where runlevels were utilized to any miraculous advantage, but certainly there are people out there who use them more craftily than most of the default OS distros with System V init. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Luke Kanies wrote:> On May 4, 2007, at 11:35 AM, Benjamin C. Kite wrote: >> My first gut reaction is that it should be a fairly simple >> declaration which really just sets a flag and executes the reboot >> last; always last. Maybe an option to not reboot if there are errors >> in the rest of the manifest that don''t stop the update. >> >> reboot { "bind": >> ensure => "true" >> abort = > "onerror"} >> >> Ordering wise, I suppose you could also make it depend on another >> type, which might imply that that type (and its dependencies) are a >> sufficient condition for the reboot. > > Hmm, having a special-purpose reboot resource probably *is* the best > way to do it, and just set it up so it only runs if something sends > it an event. > > It''d be weird, though, because it''d be a singleton -- you could > really only ever have one reboot instance, right? Or would it make > sense to have multiple ways of thinking about rebooting? > > The nice thing about doing it this way is that then it''s easy to have > different providers for every platform, of course.Yeah, I like having a provider which behaves as a singleton. It''ll be fairly easy to write, on Mac OS X and most platforms, it''s just shutdown -r now. The trick is ordering. I''d like to ensure the reboot resource happens after all other configuration takes place. Is there currently a way to do that, or will we have to add that as well? -- Jeff McCune Systems Manager The Ohio State University Department of Mathematics _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 4, 2007, at 4:16 PM, Benjamin C. Kite wrote:> > I''m not sure I''d want to have them conflict or even throw a warning > if there were. As an example, if an OS X system update has 2 > packages that require a reboot, there''s no need to interpret that as > anything other than one reboot, ultimately, but that doesn''t mean we > should restrict how many times in the manifest a reboot is requested.I''m not sure; I expect there are build procedures out there that require multiple reboots. The only real question is whether we need to support rebooting immediately. I expect however we do reboots, they''ll have to be treated somewhat magically by transactions -- either they get sorted last, or the transaction halts itself and prepares for the impending reboot. I expect we''ll need flexibility here -- people should be able to say whether the reboot should happen at the end or immediately. "Immediately" would require some hackage to the topsort, though, because there''s currently no guarantee that a given resource is sorted immediately after another, and it''s unclear what this would mean if you had multiple resources dependent upon a single reboot resource set for immediate reboot. Would it reboot on each changed resource, or just the last one?> Your comment also raises the question of halt vs. reboot and, > ultimately, perhaps, of runlevels, which may be a logical and > fruitful place to take things.I''d start without any of that, and see how it works out. It''d probably be a bad idea to make it impossible to add support for runlevels, but I''d be surprised if anyone ever used them.> Frankly, I''ve been at only a few sites where runlevels were utilized > to any miraculous advantage, but certainly there are people out there > who use them more craftily than most of the default OS distros with > System V init.Yeah, but I''d be surprised if the craftiness were really necessary. -- If all the world''s a stage, I want to operate the trap door. -- Paul Beatty --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hi, Luke Kanies wrote:> I expect we''ll need flexibility here -- people should be able to say > whether the reboot should happen at the end or immediately. > "Immediately" would require some hackage to the topsort, though, > because there''s currently no guarantee that a given resource is > sorted immediately after another, and it''s unclear what this would > mean if you had multiple resources dependent upon a single reboot > resource set for immediate reboot. Would it reboot on each changed > resource, or just the last one?I''ll add another wrinkle - scheduling reboots for a defined outage window. This might work its way upstream, scheduling reboot-requiring changes to be applied during the outage window as well. Something to think about, -- Bob
On May 6, 2007, at 1:49 PM, Jeff McCune wrote:> > Yeah, I like having a provider which behaves as a singleton. It''ll > be fairly easy to write, on Mac OS X and most platforms, it''s just > shutdown -r now.On HP-UX, ''shutdown'' is a script that calls killall, I believe, which kills everything except processes named ''shutdown'', except that it always seemed to kill the processes I had, even when they were named shutdown, and killall was stupid enough that when its parent process died, it also died, which then killed the shutdown process, which consistently left you in a not-quite-down state, where your only option was a physical reboot. I''m not saying that other OSes are as stupid as HP-UX is (was?) about this, but I wouldn''t be surprised. At least on HP-UX, the whole OS is set up with assumptions about automation (i.e., you won''t do any), which makes any automation pretty darn painful.> The trick is ordering. I''d like to ensure the reboot resource > happens after all other configuration takes place. Is there > currently a way to do that, or will we have to add that as well?This''ll all have to be done specially. Hopefully Allen can help me optimize the topsort in such a way that I can add hooks to get reboots sorted right after their dependencies or at the end of the transaction, depending on the options. Jeff, are you willing to create this ''reboot'' type, since you''re the one who appears to need it in this case? I can help get it sorted correctly, possibly starting with a guarantee that it will run last, and plan for supporting immediate reboots when we can. -- Q: How many surrealists does it take to screw in a lightbulb? A: Two. One to hold the giraffe and the other to fill the bathtub with brightly colored machine tools. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 7, 2007, at 10:53 AM, Bob Apthorpe wrote:> > I''ll add another wrinkle - scheduling reboots for a defined outage > window. This might work its way upstream, scheduling reboot-requiring > changes to be applied during the outage window as well. > > Something to think about,I expect this will be done by scheduling the work (using Puppet''s existing scheduling abilities), and rebooting as a result. -- The hypothalamus is one of the most important parts of the brain, involved in many kinds of motivation, among other functions. The hypothalamus controls the "Four F''s": 1. fighting; 2. fleeing; 3. feeding; and 4. mating. -- Psychology professor in neuropsychology intro course --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> Jeff, are you willing to create this ''reboot'' type, since you''re the > one who appears to need it in this case? I can help get it sorted > correctly, possibly starting with a guarantee that it will run last, > and plan for supporting immediate reboots when we can.I sure am. I''ll start looking at it now, though I foresee I won''t have it well tested for a few weeks with my current workload. In the meantime, if you can keep the sorting issue in the back of your head, that''d be great. Cheers, -- Jeff McCune The Ohio State University Department of Mathematics Systems Manager _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 8, 2007, at 9:24 AM, Jeff McCune wrote:> > I sure am. I''ll start looking at it now, though I foresee I won''t > have > it well tested for a few weeks with my current workload. > > In the meantime, if you can keep the sorting issue in the back of your > head, that''d be great.I expect we''d start by only allowing reboot resources to be sorted at the end, since that''s pretty easy to handle, then we can have, as a later feature, the ability to immediately reboot. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- (attributed to) Brian W. Kernighan (unconfirmed) --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 5/8/07, Luke Kanies <luke@madstop.com> wrote:> > On May 8, 2007, at 9:24 AM, Jeff McCune wrote: > > > > I sure am. I''ll start looking at it now, though I foresee I won''t > > have > > it well tested for a few weeks with my current workload. > > > > In the meantime, if you can keep the sorting issue in the back of your > > head, that''d be great. > > I expect we''d start by only allowing reboot resources to be sorted at > the end, since that''s pretty easy to handle, then we can have, as a > later feature, the ability to immediately reboot. >I think it''d also be sane to keep it from honoring a reboot in a broken configuration (i.e. if it''s unable to get a config from puppetmaster, don''t do reboots). I can picture endless reboot loops without this. -Blake _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 14, 2007, at 8:24 PM, Blake B wrote:> > I think it''d also be sane to keep it from honoring a reboot in a > broken configuration (i.e. if it''s unable to get a config from > puppetmaster, don''t do reboots). I can picture endless reboot > loops without this.Well, if it can''t get a config from the master, it won''t know it''s supposed to reboot. I think this would work the same as any other -- if it has failed dependencies, it won''t reboot. -- To define recursion, we must first define recursion. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> On May 14, 2007, at 8:24 PM, Blake B wrote: >> I think it''d also be sane to keep it from honoring a reboot in a >> broken configuration (i.e. if it''s unable to get a config from >> puppetmaster, don''t do reboots). I can picture endless reboot >> loops without this. > > Well, if it can''t get a config from the master, it won''t know it''s > supposed to reboot. > > I think this would work the same as any other -- if it has failed > dependencies, it won''t reboot.Well, maybe he means the cached configuration? But presumably whatever it cached is already OK. I don''t *think* there''s the possibility of a problem here, but I may be wrong, only thinking about it for a moment. -- Jeff McCune The Ohio State University Department of Mathematics Systems Manager _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 15, 2007, at 2:04 PM, Jeff McCune wrote:> Well, maybe he means the cached configuration? But presumably > whatever > it cached is already OK. I don''t *think* there''s the possibility of a > problem here, but I may be wrong, only thinking about it for a moment.You''re correct -- there shouldn''t be a possibility of a problem. The only real question is whether any failure should be enough to halt the reboot, or just a failure of its dependencies. -- Men never do evil so completely and cheerfully as when they do it from a religious conviction. --Blaise Pascal --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> On May 15, 2007, at 2:04 PM, Jeff McCune wrote: > >> Well, maybe he means the cached configuration? But presumably >> whatever >> it cached is already OK. I don''t *think* there''s the possibility of a >> problem here, but I may be wrong, only thinking about it for a moment. > > You''re correct -- there shouldn''t be a possibility of a problem. > > The only real question is whether any failure should be enough to > halt the reboot, or just a failure of its dependencies.I think only a failure of the dependents should halt a reboot, with clear documentation in the type I''ve yet to write informing users to link things that may be affected by the reboot into the dependency tree. It''ll complicate the reboot type quite a bit because I ultimately only want to install system updates if I''m sure the machine will be rebooted immediately after the configuration run. If all required resources pass their tests, then how would I know it''s not OK to install the update if an unrelated resource fails, preventing the reboot? Should there be two types, one to "require" a "rebootable" configuration, one to notify the reboot that it should happen? Maybe something like: package { "MacOSX-10.4.9-Update.dmg": require => Rebootable[now], notify => Reboot[now] } Thoughts? -- Jeff McCune The Ohio State University Department of Mathematics Systems Manager _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 16, 2007, at 3:38 PM, Jeff McCune wrote:> > I think only a failure of the dependents should halt a reboot, with > clear documentation in the type I''ve yet to write informing users to > link things that may be affected by the reboot into the dependency > tree. > > It''ll complicate the reboot type quite a bit because I ultimately only > want to install system updates if I''m sure the machine will be > rebooted > immediately after the configuration run. If all required resources > pass > their tests, then how would I know it''s not OK to install the > update if > an unrelated resource fails, preventing the reboot? > > Should there be two types, one to "require" a "rebootable" > configuration, one to notify the reboot that it should happen? Maybe > something like: > > package { "MacOSX-10.4.9-Update.dmg": > require => Rebootable[now], > notify => Reboot[now] > } > > Thoughts?Interesting; so you''d have something like a global boolean that said whether the machine was ok to reboot on this run, and only if that were true would anything that requires a reboot get installed. Clearly your goal here is to use this to not exacerbate failures -- if a single package that requires a reboot fails, you don''t want to install 10 more packages that also require a reboot -- but I can immediately see how this almost functions as a pre- hook. Hmm. I think this should end up being automatic -- if you depend on a reboot instance, then it generates a pre-reboot instance and sets up an inverse relationship with that (e.g., Package[A] notifies Reboot [now], so Reboot[now] autogenerates Rebootable[now] and automatically sets up Package[A] to depend on Rebootable[now]). You can do all of this with the existing code pretty easily. However, what you can''t do easily do is retroactively fail a resource, which is what you''d need to do -- if any resource that has a notify relationship to Reboot[now] fails, then you need to retroactively fail Rebootable[now] so that all other resources with this pair of relationships will consider themselves failed. The only way I can see to do that is to add some kind of special case, either for reboots in specific or for this kind of relationship pair in general. Frankly, I don''t see an easy way to do that, though. Interesting. -- What''s the good of having mastery over cosmic balance and knowing the secrets of fate if you can''t blow something up? -- Terry Pratchett, "Reaper Man" --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com