I've found this to be especially useful on PF+CARP pairs when making
networking changes. Did the interfaces come up properly, did the
routes, did the PF rules upon reboot?
In some virtualized (non-BSD) environments some folks rebuild the
image from scratch from packages and from a source of truce
(puppet/chef repo) to be sure you can always have a clean build.
- mdf
2011/10/11 Dag-Erling Sm=F8rgrav <des@des.no>:
> Mike Brown <mike@skew.org> writes:
>> Also, sometimes things go haywire after a reboot, especially after exten=
ded
>> uptime and updates to the kernel or core libraries, so I'm in the habit =
of
>> only shutting down when necessary. So if I don't see "and then reboot" i=
n an
>> update procedure - and most of the time, security updates don't require =
it -
>> then I don't do it.
>
> Actually, this is an argument in favor of rebooting regularly, or at
> least after every major change, so you know the server will boot
> unassisted if something happens (power outage, cleaning staff tripped
> over the mains cable, etc.) =A0I once spent an entire evening coaxing a
> mission-critical database server back up after a simple disk replacement
> because a predecessor had performed an in-place system upgrade without
> verifying that the new configuration would boot cleanly.
>
> DES
> --
> Dag-Erling Sm=F8rgrav - des@des.no
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or=
g"
>
--=20
--
Matthew Franz
mdfranz@gmail.com
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"