Close is trying to create a directory called ‘bugfix’ in the current directory and you don’t have write permission to create that directory.
But do you really need to build from source? I would recommend just using one of the pre-made binary images.
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
192.xx.yy.zz:/home/nfsroot/wheezy 120G 32G 88G 27% /
Is likely the setup for a number of our hosts. “/usr/bin/bk” is on that filesystem.
More info on our current setup (that 192.xx.yy.zz host, in particular):
192.xx.yy.zz:which bk
/usr/bin/X11/bk
192.xx.yy.zz:bk version
…
BitKeeper version is bk-6.1.3 20150310145524 for x86_64-glibc213-linux
…
192.xx.yy.zz:cd /home/nfsroot/wheezy/usr/bin
192.xx.yy.zz:ls -al bk
lrwxrwxrwx 1 root root 21 Apr 16 2015 bk -> /usr/lib/bitkeeper/bk
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?
- goto bitkeeper.org
- click Download
- see the Linux header
- 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.
Thanks. I’ll run with this…
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.
Thanks. We’ll give it a go.
'More trouble:
On the old host, I found bk to be listening on ports 5562, 5563, 5546, and 5547.
1035 2647 0.0 0.0 12208 1252 ? Ss Sep01 0:16 bk bkd -D -l/var/local/bitkeeper/log/system.log -P/var/local/bitkeeper/run/pid.system -d -p5562 -xcd -xpush
1036 2652 0.0 0.0 12208 1248 ? Ss Sep01 0:01 bk bkd -D -l/var/local/bitkeeper/log/system-alpha.log -P/var/local/bitkeeper/run/pid.system-alpha -d -p5563 -xcd -xpush
998 2657 0.0 0.0 5876 1016 ? Ss Sep01 0:02 bk bkd -D -l/var/local/bitkeeper/log/eng-dev.d.log -P/var/local/bitkeeper/run/pid.eng-dev.d -d -p5546 -C -xpush
997 2662 0.0 0.0 5876 1016 ? Ss Sep01 0:03 bk bkd -D -l/var/local/bitkeeper/log/client-dev.d.log -P/var/local/bitkeeper/run/pid.client-dev.d -d -p5547 -C -xpush
And nc, run from the new host shows:
/var/local/bkrepos# nc -vz 192.168.0.191 5562
bk0.gamelogic.com [192.168.0.191] 5562 (?) open
/var/local/bkrepos# nc -vz 192.168.0.191 5563
bk0.gamelogic.com [192.168.0.191] 5563 (?) open
…
Yet, when I try to run “bk clone” against those ports, I get:
$ bk clone -sALL 10.205.6.21:5562
clone: can’t find repository
I am going to assume that the mismatching IP addresses in your post are just something related to your networking config.
That bkd is probably running in a directory containing all of your repositories so the URL you want to be using on the bk command line is something like: bk://10.205.6.21:5562/REPO (see ‘bk help url’ for info about that)
It might help to point a web browser at this port. It should give you a web interface that lets you browse those repositories.
Yeah, that 10.205.6.21 was a mistake. The target host is at 192.168.0.191. There are restrictions on flow of traffic such that I’m not able to hit, via a web browser.
Where you have “REPO” in the URL that you listed, I’m guessing I should replace that with system or system-alpha or one of the other strings that appear int the ps output that I sent over (system or system-alpha or eng-dev.d or client-dev.d). At any rate, everything that I’ve tried to put in, after the “:5562” has generated the following error:
ERROR-BAD CMD: cd is disabled for this bkd using -x
Here’s one of the calls that I attempted:
$ bk clone -sALL bk://192.168.0.191:5562/system
I’d like to just clone all of the repos, in one shot, if that’s possible.
Try just:
bk clone -sALL bk://192.168.0.191:5562
If that doesn’t work go figure out where that bkd is running and find the path to the repository. Look at the url manpage.
It isn’t possible. As I have been saying. Just copy the files directly. Personally, I would use rsync(1).
I looked at the url man page, earlier, and it didn’t really make any sense to me, where all of this is concerned. I am not at all familiar with bitkeeper and have no idea how to “figure out where that bkd is running”, aside from what I’ve already found out: it’s running on the 192.168.0.191 host that I’ve referenced and “ps -ef” shows it listening no the ports that I listed.
You wrote of copying the files with rsync, but you also mentioned doing a “bk clone”. I figured the latter would be preferable, because it would allow me to clone the repos off to a different host, ahead of trying to upgrade bk on 192.168.0.191, without having to stop the daemons. On these old hosts that I’m working with, I’ve had trouble with some things not coming up properly, after being stopped.
But, I’ll try just stopping the daemons, anyway, just rsync’ing over the entire “/var/local/bitkeeper” folder, and restarting.
I rsync’d the data over, but on the new host, there is no “/etc/init.d/bitkeeper”. Will it be ok to just copy that script over from the old host? Is there anything else that I should grab, besides that?
Look inside that script to see how it runs. Sometimes people hardwire the stuff in the script but sometimes there is an external file that it reads and you would need that too.
Ok, I took a look at the script. As far as variables getting set goes, it has only that “read user dir opts” line and “VAR=/var/local/bitkeeper”. The rest is pretty much the case statement that I’m guessing is there, by default.
I’m having a little trouble with getting the daemons started. “/etc/init.d/bitkeeper start” gives me:
tibor:(12:05:35):/etc/init.d/bitkeeper start /usr/local/bk7.3.2
/etc/init.d/bitkeeper: line 15: cd: /big1/bk/system: No such file or directory
/etc/init.d/bitkeeper: line 15: cd: /big1/bk/system-alpha: No such file or directory
/etc/init.d/bitkeeper: line 15: cd: /big1/bk/eng-dev.d: No such file or directory
/etc/init.d/bitkeeper: line 15: cd: /big1/bk/client-dev.d: No such file or directory
This bit, from the script, I don’t (the “read user dir opts”, part, more precisely) understand:
“while read user dir opts” …
I only got “/var/local/bitkeeper”, with my rsync. I understood what you said about there possibly being an external file, but don’t see where this entire “/big1/bk/…” tree is referenced. I could certainly rsync over that tree, but can’t place it at “/big1”, because “/” is read-only on this nfsroot’d host.
Is there a bk configuration file of some sort that I can modify, such that instead of “/big1/bk/…”, the files under that tree reside in and are looked for in, say, “/var/local/bitkeeper”?
Here the thing. That script isn’t part of a BitKeeper install. We can only guess what is in it. It was likely created by copying and modifying the example in the ‘bkd’ man page (‘bk help bkd’).
The default script has a file called /var/bitkeeper/repositories that contains the list of pathnames where a bkd should be started. It appears your file will be found at /var/local/bitkeeper/repositories.
You should be able to copy that big1 directory to another location and then edit that file to point to the new location.
In this case, you appear to have one bkd per repository and all of them read-only. Given what I see here I would have started a single bkd at the /big1/bk directory and have the user add the repository name to the URL, but given that you are trying to replicate the machine and change as little as possible I guess you should leave that part alone.
I think we’re good on this one. Thank you for your help.