We currently have bitkeeper installed on a host where it’s true that the license has expired, in some sense. Rather than possibly damage the existing installation, I’d like to clone all of its repos to a different host. The latter has an instance of bk installed: bk-6.1.3 20150310145524 for x86-glibc213-linux.
What steps should I take to get that 6.1.3 installation to bk-7.3.2 for x86_64-glibc223-linux ?
So, it seems to be listening on 5562, 5563, 5546, 5547. My plan was to get the 2nd instance up to , then run the following, against each of those ports:
bk clone -sALL 192.168.0.191:
I’ve instructions on installing a fresh copy of 7.3.2, but I wasn’t sure if those would apply, where what is essentially an upgrade is concerned.
If the license has expired on the old machine, then running a ‘bk clone’ isn’t going to work since bk-6.1.3 on the old machine won’t have a license to read the data.
I would suggest you install bk on the new machine and then use rsync to copy over all of the repositories. Then you can use the same script to start the bkd’s on the new machine to make them accessible.
For validation, I suggest running ‘bk repocheck’ on each repository on the new machine to make sure it is able to read and parse all of them.
If you do want to run ‘bk clone’ then I suggest adding --upgrade to make sure they get rewritten using the latest repository format.
Ok, when you speak of running rsync, I’m not sure exactly what you mean. I know the command, but are there particular options that I should use? Which folders on the old host should I target?
The host that I’m looking to move the repos to already has bk installed. It’s on 6.1.3. How do I go about getting it to bk-7.3.2 for x86_64-glibc223-linux ?
Perhaps I just should have said: copy the data from the old machine to the new one. I would use rsync to do that copy.
rsync -av oldmachine:/path /path-on-new
That machine probably has a /etc/init.d/bitkeeper init script that starts the bkds. It reads the /var/local/bitkeeper/repositories file to see which bkd’s to start and puts the pids in ‘run’.
If you have a link that points to complete instructions for getting bk-7.3.2 installed, could you send that over, please? I’m still wondering if the installer will simply overwrite the version that’s there on the new host, if one or more processes need to be stopped, ahead of running the installer, etc.
Where you wrote “Install instructions are linked from the download page”, I’m afraid this didn’t really make sense to me. I see nothing that looks to be that link, any where on the current page (Licensing Issue)
Another concern has come up for me, also. A number of our hosts (including the one that I’m looking to move the bk data and instance to… let’s call it “targethost”) are running nfsroot-based setups. For example (this is from targethost):
df -h | grep ‘/usr’
/dev/sda5 94G 12G 82G 13% /usr/local
While “/” is nfsrooted:
192.xx.yy.zz:/home/nfsroot/wheezy 120G 32G 88G 27% /
On all hosts:
which bk
/usr/bin/bk
So, my concern is that upgrading bk on targethost will make it such that users of other hosts (who also have their “/usr” sitting on 192.xx.yy.zz:/home/nfsroot/wheezy) will suddenly start trying to hit bk-6.1.3 data with a bk-7.3.2 binary.
Does this make sense? Is 7.3.2 backward compatible to the extent that it will make this a non-issue?
bk clone -sTHERE bk://bkbits.net/bk/bugfix
cd bugfix/src
bk -U^G co
make p image
cd utils
# there will be a file here like
# bk-7.3.2-x86_64-glibc223-linux.bin
# that is your install image, run that as root and install it
Arrg! I was logged in as root and running the command from /root, so I didn’t expect to have a permissions problem. It’s this blasted nfsroot setup: makes it such that “/root” is on a read-only filesystem.
Oh, and I would actually prefer to use pre-made binaries. 'Still not clear, though, on that “Install instructions are linked from the download page”, from your earlier message.
The nfsroot thing is still a major concern for me. I really don’t want to have folks on my team locked out of bk, but
Ok, I need to get this done, so that our Devs are not locked out of bitkeeper. So, I decided to try and just push ahead with building from source.
I was hoping to install to a location other than the one that’s on the nfsrooted filesystem. I created a /var/local/bitkeeper7 folder, and started working from there, but the installer is trying to work against the blasted nfsrooted stuff and having trouble, of course, because the target filesystem is read-only:
192.xx.yy.zz:/var/local/bitkeeper7# bk clone -sTHERE bk://bkbits.net/bk/bugfix
lockfile: /root/.bk/lease is not writable.
Clone bk://bkbits.net/bk/bugfix
-> file:///var/local/bitkeeper7/bugfix
. 0% | |
lockfile: /root/.bk/lease is not writable.
lockfile: /root/.bk/lease is not writable.
. 5% |= |
lockfile: /root/.bk/lease is not writable.
lockfile: /root/.bk/lease is not writable. |
lockfile: /root/.bk/lease is not writable.= |
lockfile: /root/.bk/lease is not writable.=========================== |
. 100% |==============================|
lockfile: /root/.bk/lease is not writable.
lockfile: /root/.bk/lease is not writable.
lockfile: /root/.bk/lease is not writable.
I’m thinking, at this point, that it might be best to run “”/etc/init.d/bitkeeper stop" on the host that has those daemons up and rsync off the entire “/var/local/bitkeeper” folder to a backup location. Then, run the bk7 installer on that host and on the 192.xx.yy.zz that’s nfsroot-sharing out a root partition to a number of others, and, finally, bring up bk7.
My concerns are likely obvious, but how does this course of action sound?
download the 64-bit installer that matches your machine
right under those see the link labeled “Installation Instructions”, click that
Read the part about the “Command Line Installer”
There is no need to install as root. Install as some user that doesn’t have permissions to mess up /usr/bin. The installer gives you a directory and tries to create a symlink for ‘bk’. You can put those wherever you want. Copy the directory to /usr/libexec/bitkeeper-7.3.2 and then put a symlink to /usr/libexec/bitkeeper/7.3.2/bk on your PATH in a place where it will only impact this machine while testing.
This is running the old bk which needs to get a license, but you don’t have a writable HOME directory.
Note that bk-6.1.3 can’t read repositories created by the bk-7.x series. We have a new disk layout for a huge performance win. So you can’t clone the bk source with your old bk. bk-7.0 was released in 2015.
If you wanted to build from source, then you need to download the source tarball from the downloads area on the webpage.
And, yeah, I figured we were dealing with very old software, but most of the infrastructure that I’m wrestling with is state of the art, circa 2004. I’m part of a team that’s working on upgrading things, but we all started, within the past month or so. Fun, fun.
Ok, I managed to get 7.3.2 installed on the alternate host. I’m wondering about the bit-clone option, again, though: will it work to run the bk7.3.2 executable against the bk6 host, to clone off to the alternate host? To cut-over, we could then just run “/etc/init.d/bitkeeper stop” on the old server and “/etc/init.d/bitkeeper start” on the new one.
bk-7.3.2 should be able to read and write all your existing repositories and it won’t upgrade them unless you clone with --upgrade so it shouldn’t prevent your older bk from running.
Also, the newer bkd should be fully compatible with the older clients.
So it is my belief you can upgrade that bk without breaking anything. So yeah stop the old bkd’s and start the new ones and then start testing.
When you are fully upgraded then doing a --upgrade on your main repositories is a good idea because it is a big performance win.