Re: Migrating Apache Subversion to a new Ubuntu machine - how?

[Bo Berglund <bo...@gmail.com>]

On Sun, 10 Oct 2021 03:42:30 -0400, Nico Kadel-Garcia <nk...@gmail.com> wrote:

>> PS:
>> Is it possible to just move the existing hard drive over to the new computer and
>> start it up? Or clone the content to the new computer's drive?
>> I do have a lot of other stuff that needs migration too...
>
>Maybe? You'd need to mount it, and a 10 year old hard drive is
>questionable at best. I'd use rsync: Ensure that you have SSH access
>from the new host to the old host, and you should be able to use rsync
>to copy material and run svnsync efficiently. And look up "svn
>hotcopy" for copying the basic Subversion configuration for copying
>over to a new server.

UPDATE: To close this thread

So I have done the migration now and it was basically painless, although time
consuming because of the way I did it...

1) I figured out a way to create space on the new PC disk drive from within the
pre-installed Windows 10. This was the easy part. I left 40 GB for Windows 10
and got about 450 GB free space.

2) Then I spent a bunch of time figuring out how to boot both my old PC and the
new one from USB live media.
Turned out to be impossible on the old eMachine PC but I *could* boot it from a
DVD disk with Ubuntu ISO. But no USB drive...

The new PC uses UEFI so it took a while to get the USB Ubuntu media to boot,
until I found the correct way to modify UEFI settings to allow it.

3) Then I ran the Live DVD on my old PC and using GParted I could clone the
partitons on that to a USB connected hard drive, I also made the partition on
the target smaller.

4) Booting the new PC from a live USB with Ubuntu 20 I could install it in
multi-boot fashion on the new PC in the now freed up space. I let it use just as
much partition space as is needed for Ubuntu plus a bit more.

5) Next I started Ubuntu on the new PC and using GParted I copied over the old
PC Ubuntu partition to the new PC hard disk after connecting the USB disk to it.

6) Finally once that was done I also updated the GRUB boot loader so it also
included the old server in the boot menu.

7) With all that done I could boot into the migrated Ubuntu 18.04 server on the
new hardware and it did run!
So I could do the apt full-upgrade to get all new stuff and it announced that it
was ready for a dist-upgrade too.
Did that and now the server is 20.04 and all I have checked works fine.

8) Final stop:
I now reprogrammed the port forwards on my router to go towards the new server
rather than the old off-line server.

And the next svn sync operation from the main server came through successfully
and it is back in operation but on a new hardware system and running Ubuntu
20.04 rather than 18.04.

My websites also work fine using the existing LetsEncrypt certificates.



-- 
Bo Berglund
Developer in Sweden

Re: Migrating Apache Subversion to a new Ubuntu machine - how?

[Nico Kadel-Garcia <nk...@gmail.com>]

On Tue, Nov 16, 2021 at 6:15 PM Bo Berglund <bo...@gmail.com> wrote:
>
> On Sun, 10 Oct 2021 03:42:30 -0400, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>
> >> PS:
> >> Is it possible to just move the existing hard drive over to the new computer and
> >> start it up? Or clone the content to the new computer's drive?
> >> I do have a lot of other stuff that needs migration too...
> >
> >Maybe? You'd need to mount it, and a 10 year old hard drive is
> >questionable at best. I'd use rsync: Ensure that you have SSH access
> >from the new host to the old host, and you should be able to use rsync
> >to copy material and run svnsync efficiently. And look up "svn
> >hotcopy" for copying the basic Subversion configuration for copying
> >over to a new server.
>
> UPDATE: To close this thread
>
> So I have done the migration now and it was basically painless, although time
> consuming because of the way I did it...
>
> 1) I figured out a way to create space on the new PC disk drive from within the
> pre-installed Windows 10. This was the easy part. I left 40 GB for Windows 10
> and got about 450 GB free space.
>
> 2) Then I spent a bunch of time figuring out how to boot both my old PC and the
> new one from USB live media.
> Turned out to be impossible on the old eMachine PC but I *could* boot it from a
> DVD disk with Ubuntu ISO. But no USB drive...

I'd have mirrored that content to a VM on the Windows box. Tastes var,
but I'm glad this worked out for you.

> The new PC uses UEFI so it took a while to get the USB Ubuntu media to boot,
> until I found the correct way to modify UEFI settings to allow it.
>
> 3) Then I ran the Live DVD on my old PC and using GParted I could clone the
> partitons on that to a USB connected hard drive, I also made the partition on
> the target smaller.
>
> 4) Booting the new PC from a live USB with Ubuntu 20 I could install it in
> multi-boot fashion on the new PC in the now freed up space. I let it use just as
> much partition space as is needed for Ubuntu plus a bit more.
>
> 5) Next I started Ubuntu on the new PC and using GParted I copied over the old
> PC Ubuntu partition to the new PC hard disk after connecting the USB disk to it.
>
> 6) Finally once that was done I also updated the GRUB boot loader so it also
> included the old server in the boot menu.
>
> 7) With all that done I could boot into the migrated Ubuntu 18.04 server on the
> new hardware and it did run!
> So I could do the apt full-upgrade to get all new stuff and it announced that it
> was ready for a dist-upgrade too.
> Did that and now the server is 20.04 and all I have checked works fine.

I'm glad this also worked completely in-polace. I've run into older
filesystems with older operating systems that did not behave
gracefully when updated in plac.

> 8) Final stop:
> I now reprogrammed the port forwards on my router to go towards the new server
> rather than the old off-line server.
>
> And the next svn sync operation from the main server came through successfully
> and it is back in operation but on a new hardware system and running Ubuntu
> 20.04 rather than 18.04.
>
> My websites also work fine using the existing LetsEncrypt certificates.

Yay! I admit that I've pretty much given up on HTTPS based access to
Subversion, years ago, and use svn+ssh by preference, partly because
of tendencies of httpd admins to try and build the kitchen sink into
its configuration.