How to purge network-manager (requires reboot) ?

[Sandra Schlichting]

Hi all =)

I would like to purge the following packages

network-manager

network-manager-gnome

network-manager-pptp

network-manager-pptp-gnome

but the problem is, that I suppose a reboot is required for the NIC's no longer to be manged by network-manager?

How would you work around this?

Hugs,

Sandra

[Krzysztof Wilczynski]

Hi Sandra,


[...]

but the problem is, that I suppose a reboot is required for the NIC's no longer to be manged by network-manager?

I am not sure why would it require a restart, hm... I am used to making sure that the service is stopped, packaged purged and then you only need to make sure that static IP configuration is in place. Sometimes you need to get rid of the udev rules file, but not often.

KW

[Sandra Schlichting]

Hi Krzysztof

I am not sure why would it require a restart, hm... I am used to making sure that the service is stopped, packaged purged and then you only need to make sure that static IP configuration is in place. Sometimes you need to get rid of the udev rules file, but not often.

Great. Then that problem is solved.

Thanks =)

Hugs,

Sandra =)

 

[jcbollinger]

Like Krzysztof, I'm not certain that a reboot is required.  On the other hand, Network Manager is a tricky and sometimes pesky little beast, so maybe a reboot really is required.  I can't advise you on avoiding a reboot, but if you really do need one, then you can probably make Puppet schedule one using something along these lines:

exec { 'reboot-soon':
  command => '/usr/bin/nohup /sbin/shutdown -r +5 &',
  provider => 'sh',
  subscribe => Package['network-manager'],
  refreshonly => true,
}

That will reboot the system whenever Puppet changes the 'network-manager' package (which must already have been declared elsewhere).  The five-minute delay designated by the "+5" argument serves two purposes:

1. To allow the Puppet run to complete before the reboot (see also below)
2. To give an admin who happens to be logged in a chance to cancel the restart

With respect to the delay time, there is an unavoidable race condition here, because you can't really predict how much longer Puppet will take to finish up, especially if the system is heavily loaded.  You can largely mitigate that, however, by ensuring that Exec['reboot-soon'] is applied after all other resources.  Although I'm not a great fan of run stages, this looks like a good use case for them.


John

[Sandra Schlichting]

Hi John

That is a very interesting solution!

I had to look up what "provider" and "refreshonly" did. They seam to be very useful for other situations as well!

Thanks =)

Hugs,

Sandra