Re: Rebuilding kernel/system to a state back-in-time?
Ewald Jenisch wrote: Hi, Because of severe problems wrt. a third party app (TSM Backup - see my previous post) I'm looking for a way to compile a kernel/system to a state as it was several weeks ago. To be specific I'd like to build my system/kernel using the source-files of FreeBSD 6.2 as they were back on September 14, 2007. In cvsup there seems to be a feature date=... that should be able to accomplish this. Has anybody out there used it sucessfully? Is specifying date=2007.09.13.23.59.00 together with the default-settings in my stable-cvsup-file *default host= here comes my cvsup-host *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_5 Should be tag=RELENG_6_2 *default delete use-rel-suffix *default compress src-all enough? That should suffice. Anything else to consider? This assumes you're already running 6.2. As long as you don't switch branches (or choose a date before the branch occurred!), you should be good to go. Erik ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rebuilding kernel/system to a state back-in-time?
Quoting Erik Cederstrand [EMAIL PROTECTED]: Should be tag=RELENG_6_2 ... That should suffice. This assumes you're already running 6.2. As long as you don't switch branches (or choose a date before the branch occurred!), you should be good to go. Erik i would agree with erik's advice, as IMO its quite sound (when it comes to operating a server as opposed to a desktop). however, i would add this detail so that there can be some what and why to go with it: RELENG_6_2 will take you to 6.2-RELEASE-p8. it *will* be back in time, but it will be only 'critical' patches since the intial 6.2-RELEASE. IMO, (and forgive me, i generally dont spew my opinions where they arent welcome or asked for), RELENG_6_2 is better for a server over RELENG_6 (aka, -STABLE), as it doesnt include items that are not critically required for secure and stable operation. remember, that the true -STABLE branch has items merged in from -CURRENT (call it back-ported?). let say, you already know that -p8 is the latest 6.2 revision. you get on a server, you log in, and it says 6.2-RELEASE-p8. you already know that this system is up to date. if you log in, and see 6.2-STABLE... you dont immediately know when this system was last rebuilt without doing some other version checks first. i have to be honest, when it comes to managing a farm full of servers, i like my visual version checks... the same way i like my women: easy. cheers, -- Jonathan Horne DFWLP Network Consulting Services [EMAIL PROTECTED] http://www.dfwlp.com 214.287.4373 - mobile This message was sent using IMP, the Internet Messaging Program. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rebuilding kernel/system to a state back-in-time?
Jonathan Horne wrote: ... IMO, (and forgive me, i generally dont spew my opinions where they arent welcome or asked for), RELENG_6_2 is better for a server over RELENG_6 (aka, -STABLE), as it doesnt include items that are not critically required for secure and stable operation. remember, that the true -STABLE branch has items merged in from -CURRENT (call it back-ported?). let say, you already know that -p8 is the latest 6.2 revision. you get on a server, you log in, and it says 6.2-RELEASE-p8. you already know that this system is up to date. if you log in, and see 6.2-STABLE... you dont immediately know when this system was last rebuilt without doing some other version checks first. i have to be honest, when it comes to managing a farm full of servers, i like my visual version checks... the same way i like my women: We're going off-topic now, but you have a point. I'm not going to argue if STABLE is better than release branches on servers, but I think it would be useful to record the CVS date somewhere by default (I know you can do this manually via src/sys/conf/newvers.sh). Sometimes the p8, prerelease #4 or even kern.osreldate is too low resolution. uname -a just exposes the build date of the kernel, not the date of the sources. Maybe a sysctl like: sysctl kern.oscvsdate: 20071105224900 Erik ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
