Re: CVS server upgrade?

[Spiro Trikaliotis]

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?

[Jim.Hyslop]

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. () 
Columnist, C/C++ Users Journal () 




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS server upgrade?

[Jim.Hyslop]

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. () 
Columnist, C/C++ Users Journal () 




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS server upgrade?

[Mark D. Baushke]

-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?

[Spiro Trikaliotis]

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?

[David R. Chase]

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

RE: CVS server upgrade?

[Courier]

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. ()
> Columnist, C/C++ Users Journal ()
>



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS server upgrade?

[Jim.Hyslop]

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. () 
Columnist, C/C++ Users Journal () 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs