Re: CVS server upgrade?
Hello, * On Mon, Feb 02, 2004 at 03:00:35PM -0500 Jim.Hyslop wrote: In order to minimize the impact on the users, we took the original server off-line just long enough to create the tarball. As soon as the tar was complete, we restarted the server in read-only mode (create an empty CVSROOT/writers file to make the whole repository read-only). Thus, people could still check out and browse the repository, but they couldn't check anything in (and thus throw the two repositories out of sync). not that I would recommend it, but: But about 1. Taking the CVS repository offline 2. Create the tarball 3. Take the CVS repository online with full access (!) 4. do anything needed to move to the new server 5. When everything is working fine, take the (original) repository offline again 6. Now perform an rsync between the two repositories 7. Take the new one online (with changing DNS entries and the like). Would this make sense, or could 6. break something that was made with 4.? I understand that this procedure seems more risky, but it seems to me that this should work, too, shouldn't it? Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS server upgrade?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Spiro Trikaliotis [EMAIL PROTECTED] writes: Hello, * On Mon, Feb 02, 2004 at 03:00:35PM -0500 Jim.Hyslop wrote: In order to minimize the impact on the users, we took the original server off-line just long enough to create the tarball. As soon as the tar was complete, we restarted the server in read-only mode (create an empty CVSROOT/writers file to make the whole repository read-only). Thus, people could still check out and browse the repository, but they couldn't check anything in (and thus throw the two repositories out of sync). not that I would recommend it, but: But about 1. Taking the CVS repository offline 2. Create the tarball 3. Take the CVS repository online with full access (!) 4. do anything needed to move to the new server 5. When everything is working fine, take the (original) repository offline again 6. Now perform an rsync between the two repositories 7. Take the new one online (with changing DNS entries and the like). Would this make sense, or could 6. break something that was made with 4.? Sure #6 could break something for #4, this is why it is considered useful to test our your commitinfo, loginfo, verifinfo, and taginfo scripts to be sure they wok regardless of the platform. Your steps should work okay. I understand that this procedure seems more risky, but it seems to me that this should work, too, shouldn't it? I have had occasion to move repositories from one machine to another a number of times over the years. I typically put something into the commitinfo script that denies any commits to the repository unless the `hostname` matches what I expected. I have also used 'rsync' (or CVSup soemtimes) to create mirror copies of the repository. 0. Assume you have two machines oldbox.example.com and newbox.example.com and that everyone checks out using cvsbox.example.com which happens to be a DNS CNAME that points to oldbox.example.com. 1. Mirror the repository to a slave server (newbox) that will become the master eventually. On oldbox.example.com do the following: rsync --exclude '#cvs*' --exclude ',*,' --blocking-io \ --recursive --perms --owner --group --times --links \ --delete --stats /path/to/your/current/cvsroot/directory \ newbox.example.com:/path/to/your/new/cvsroot/directory doing this rsync a few times in succession, I would expect to eventually not see any additional files copied. At that point, you have your functional mirror for testing and/or deployment. 2. test the new repository for the ability to checkout a tree any commits to this version of the repository will likely fail due to your commitinfo trigger test for the filename. It is up to you if you want to allow test commits to this test repository or not. I typically have a 'debugging' repository and module for this purpose. 3. Modify the the commitinfo trigger on the master repository, so that only commits to the mirror are allowed. This will have the effect of making the current master repository a read-only mirror that will not allow commits. 4. Repeat step #1 to effectively make the 'slave server' become the new master. 5. Alter your DNS so that cvsbox.example.com has a CNAME record that points to nwebox.example.com instead of oldbox.example.com. You are now done and should be able to retire the oldbox.example.com fairly soon. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAH3QF3x41pRYZE/gRAr1/AJ9O4UiJuuUT8X9fqXy1uIrUCyRbWQCfYkiq VmXvIkOZCyVpaAMgnU3P55I= =3wCu -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS server upgrade?
David R. Chase [mailto:[EMAIL PROTECTED] wrote: Just wondering what minor problems you had, just in case they might pertain to other peoples' migration strategies (or my own someday)? Well, our situation was much more complex than Courier's. Not only did we upgrade the server hardware, we went from FreeBSD to a Sun workstation, and upgraded the server version from a very old 1.10.[something] to 1.11.5 We have several remote repositories that mirror portions of the main repository, and our main repository mirrors portions of the remote repositories. We also have developed a client/server utility (LCVS - Leitch extensions to CVS) that runs in conjunction with CVS, to provide some functionality that the stock CVS program doesn't - the ability for users to change their own passwords, or the ability to execute an 'ls' command in the current directory, for example. Most of the minor glitches we encountered had to do with porting the LCVS utility to Sun, while maintaining FreeBSD compatibility (the remote repositories still run FreeBSD). Setting up permissions is sufficiently different on Sun than on FreeBSD (don't ask me the details - I'm not a UNIX sysadmin) that we had to do some fine-tuning. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com/) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS server upgrade?
Spiro Trikaliotis [mailto:[EMAIL PROTECTED] wrote: not that I would recommend it, but: But about 1. Taking the CVS repository offline 2. Create the tarball 3. Take the CVS repository online with full access (!) 4. do anything needed to move to the new server 5. When everything is working fine, take the (original) repository offline again 6. Now perform an rsync between the two repositories 7. Take the new one online (with changing DNS entries and the like). Would this make sense, or could 6. break something that was made with 4.? That would work, as long as nobody checked anything into the new server. We decided to err on the side of safety, rather than take the chance that one of our 150 or so users might discover the new server and check into it when they shouldn't. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com/) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS server upgrade?
Hello Jim, * On Tue, Feb 03, 2004 at 09:28:59AM -0500 Jim.Hyslop wrote: Spiro Trikaliotis [mailto:[EMAIL PROTECTED] wrote: not that I would recommend it, but: [...] Would this make sense, or could 6. break something that was made with 4.? That would work, as long as nobody checked anything into the new server. We decided to err on the side of safety, rather than take the chance that one of our 150 or so users might discover the new server and check into it when they shouldn't. A good point, I did not think about this case. I think that's the reason why I said not that I would recommend it. ;-) Thanks, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS server upgrade?
Courier [mailto:[EMAIL PROTECTED] wrote: Here is I would like to do: I will take currently cvs server off line, then tar the whole Repository, then bring up a new system and cp and untar Repository on new server. Our cvs server is a stand alone server. All my users are accessing via pserver. I don't have any problems with username and their password migrations, but just concerned about cvs Repository. When we upgraded our server, we took a similar approach. We scheduled a dry-run of the process ahead of time, just to make sure there were no problems and to work out any unforeseen problems. The dry run proved very valuable, because there _were_ some minor things we had overlooked. This saved us the time (and embarassment) of cutting off our users from the repository multiple times. In order to minimize the impact on the users, we took the original server off-line just long enough to create the tarball. As soon as the tar was complete, we restarted the server in read-only mode (create an empty CVSROOT/writers file to make the whole repository read-only). Thus, people could still check out and browse the repository, but they couldn't check anything in (and thus throw the two repositories out of sync). After we were satisfied the new server was up and running properly, we simply did a DNS switch on the server name (the name the users see is an alias to the actual machine name). -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com/) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS server upgrade?
Jim, Thank you. That is what I have in mind. Good things about our cvs server is locally. Thus I have schedule for down time about and works with couple developers when new cvs server back on line for testing and double check very things are ok. Again thank you very much for your comments. C- Courier [mailto:[EMAIL PROTECTED] wrote: Here is I would like to do: I will take currently cvs server off line, then tar the whole Repository, then bring up a new system and cp and untar Repository on new server. Our cvs server is a stand alone server. All my users are accessing via pserver. I don't have any problems with username and their password migrations, but just concerned about cvs Repository. When we upgraded our server, we took a similar approach. We scheduled a dry-run of the process ahead of time, just to make sure there were no problems and to work out any unforeseen problems. The dry run proved very valuable, because there _were_ some minor things we had overlooked. This saved us the time (and embarassment) of cutting off our users from the repository multiple times. In order to minimize the impact on the users, we took the original server off-line just long enough to create the tarball. As soon as the tar was complete, we restarted the server in read-only mode (create an empty CVSROOT/writers file to make the whole repository read-only). Thus, people could still check out and browse the repository, but they couldn't check anything in (and thus throw the two repositories out of sync). After we were satisfied the new server was up and running properly, we simply did a DNS switch on the server name (the name the users see is an alias to the actual machine name). -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com/) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS server upgrade?
Jim, Just wondering what minor problems you had, just in case they might pertain to other peoples' migration strategies (or my own someday)? Thanks! David R. Chase Senior Unemployed Software Developer ; ) - Original Message - From: Jim.Hyslop [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 02, 2004 3:00 PM Subject: RE: CVS server upgrade? Courier [mailto:[EMAIL PROTECTED] wrote: Here is I would like to do: I will take currently cvs server off line, then tar the whole Repository, then bring up a new system and cp and untar Repository on new server. Our cvs server is a stand alone server. All my users are accessing via pserver. I don't have any problems with username and their password migrations, but just concerned about cvs Repository. When we upgraded our server, we took a similar approach. We scheduled a dry-run of the process ahead of time, just to make sure there were no problems and to work out any unforeseen problems. The dry run proved very valuable, because there _were_ some minor things we had overlooked. This saved us the time (and embarassment) of cutting off our users from the repository multiple times. In order to minimize the impact on the users, we took the original server off-line just long enough to create the tarball. As soon as the tar was complete, we restarted the server in read-only mode (create an empty CVSROOT/writers file to make the whole repository read-only). Thus, people could still check out and browse the repository, but they couldn't check anything in (and thus throw the two repositories out of sync). After we were satisfied the new server was up and running properly, we simply did a DNS switch on the server name (the name the users see is an alias to the actual machine name). -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com/) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
