> On Sul, 2004-12-26 at 18:18, Larry McVoy wrote: >> The other answer, which I'm happy to consider, is to come up with a >> unique >> id on a per host basis and use that for the leases. That's not a fun >> task, >> does anyone have code (BSD license please) which does that?
> libuuid does that on straight statistical probability - what properties > do you want your id to have ?
Simply storing the first hostname used in a dot file for subsequent reuse on client side, would be even easier I guess. That would be basically the same strategy as used by ssh with regard to host keys. It wouldn't even perhaps make protocol changes necessary. But still not a perfect solution... (Remember the times you have delete something from .ssh/known_hosts).
> Simply storing the first hostname used in a dot file for subsequent > reuse on client side, would be even easier I guess.
You mean localhost.localdomain? 8-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
>> Simply storing the first hostname used in a dot file for subsequent >> reuse on client side, would be even easier I guess.
> You mean localhost.localdomain? 8-)
No the first value that worked in the whole setup of course. And I said it clearly that would be just a workaround because uniqueness can be established in the easiest way on the side of the part which is interested in the persistency - the server peer not the client. "Simple" http servers do it by sending cookies around. Other call it "tokens".
On Mon, Dec 27, 2004 at 12:13:55AM +0100, Martin Dalecki wrote: > No the first value that worked in the whole setup of course. And I > said it clearly that would be just a workaround because uniqueness > can be established in the easiest way on the side of the part which > is interested in the persistency - the server peer not the client.
actually, the bk lease server could give out id's and those could be caches in ~/.bk<whatever> --- server side it could be a counter that you just xor with some s3kr1t value and then blind using a hash or cryto-function, something good-enough (statistically unlikely to break) is all that is required, it doesn't have to be perfect surely? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> On Mon, Dec 27, 2004 at 12:13:55AM +0100, Martin Dalecki wrote:
>> No the first value that worked in the whole setup of course. And I >> said it clearly that would be just a workaround because uniqueness >> can be established in the easiest way on the side of the part which >> is interested in the persistency - the server peer not the client.
> actually, the bk lease server could give out id's and those could be > caches in ~/.bk<whatever> --- server side it could be a counter that > you just xor with some s3kr1t value and then blind using a hash or > cryto-function, something good-enough (statistically unlikely to > break) is all that is required, it doesn't have to be perfect surely?
Right that's precisely what's called a cookie or token. But it would involve a change in the on-wire protocol.
> The other answer, which I'm happy to consider, is to come up with a unique > id on a per host basis and use that for the leases. That's not a fun task, > does anyone have code (BSD license please) which does that?
MAC of eth0? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
>> The other answer, which I'm happy to consider, is to come up with a >> unique >> id on a per host basis and use that for the leases. That's not a fun >> task, >> does anyone have code (BSD license please) which does that?
On Sun, Dec 26, 2004 at 09:31:11PM -0300, Horst von Brand wrote: > > The other answer, which I'm happy to consider, is to come up with a unique > > id on a per host basis and use that for the leases. That's not a fun task, > > does anyone have code (BSD license please) which does that?
> MAC of eth0?
As others have pointed out that won't work.
I'm trying to remember why we get leases on a per host basis and I think it is for a simple reason, NFS. We update the leases in your home directory and if your home directory is nfs mounted then we can corrupt the leases file due to races (yes, we saw this all the time when we had one leases file). So we stick the leases for a particular host in that host's file. -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> "NFS fails at the goal of allowing a computer to access files over a > network as if they were on a local disk. In many ways, NFS comes close > to the objective, and in certain circumstances (detailed later), this > is acceptable. However, the subtle differences can cause subtle bugs > and greater system issues. The widespread misconception about the > compatibility and transparency of NFS means that it is often used > inappropriately, and often put into production when better, more > acceptable solutions exist."
> I don't know of a proper solution, other then writing in big letters > in the documentation about the circumstances under which you can shoot > yourself in > the feet.
And that, my friends, is the difference between a project which is a hobby and a project which is a product. We don't have the option of saying "this doesn't work". -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> On Sun, Dec 26, 2004 at 09:31:11PM -0300, Horst von Brand wrote: >>> The other answer, which I'm happy to consider, is to come up with a >>> unique >>> id on a per host basis and use that for the leases. That's not a >>> fun task, >>> does anyone have code (BSD license please) which does that?
>> MAC of eth0?
> As others have pointed out that won't work.
> I'm trying to remember why we get leases on a per host basis and I > think > it is for a simple reason, NFS.
"NFS fails at the goal of allowing a computer to access files over a network as if they were on a local disk. In many ways, NFS comes close to the objective, and in certain circumstances (detailed later), this is acceptable. However, the subtle differences can cause subtle bugs and greater system issues. The widespread misconception about the compatibility and transparency of NFS means that it is often used inappropriately, and often put into production when better, more acceptable solutions exist."
I don't know of a proper solution, other then writing in big letters in the documentation about the circumstances under which you can shoot yourself in the feet.
> On Mon, Dec 27, 2004 at 03:40:38AM +0100, Martin Dalecki wrote:
>> I don't know of a proper solution, other then writing in big letters >> in the documentation about the circumstances under which you can shoot >> yourself in >> the feet.
> And that, my friends, is the difference between a project which is a > hobby > and a project which is a product. We don't have the option of saying > "this > doesn't work".
Fully agreed. And those are the reasons why the completely non professional solutions, which I never saw in deployment of course... like ... for example the pure hobby-student-project ClearCase are going to the extent of requiring you to run their own networked filesystem if running on Linux. They do it simply out of fun and for educational purposes and because they where to dumb to find much easier solution which are out there ready and waiting. They simply don't have to deal with something as exceptional as customers. They love to spend about 10 man years to develop a reliable networked filesystem which is OS minor version specific like burning money for heat...
In article <20041227024346.GA3...@work.bitmover.com> you wrote: > And that, my friends, is the difference between a project which is a hobby > and a project which is a product. We don't have the option of saying "this > doesn't work".
Thats why more and more commercial solutions do not use licensing services or dongles anymore. It just introduces to much failure possibilities.
Larry McVoy writes: > Has anyone else been shut down because of lease.openlogging.org being down > and if so what version of BK were you running please?
Yes, I had bk pull and bk export fail for me yesterday. If I did a bk pull it would sit there for a while and then put up a window saying it couldn't get to lease.openlogging.org. If I clicked OK, after a while another window would come up with a similar message (but I didn't read it carefully).
> It is true that both servers are at our offices so if the network had been > down you would have been out of luck.
I did a traceroute and it looked like a network problem. From memory it stopped after about 10 hops, and it seems to be 17 hops to openlogging.org from here now.
My setup is possibly a little unusual, and may be causing problems for your lease code: I have my BK repos on a firewire-attached disk, which I move from machine to machine - specifically, it commutes between home and work with me.
On Sun, 26 Dec 2004, Martin Dalecki wrote: >A hostname simply isn't a fixed attribute of a host anymore.
It is on properly setup and maintained machines.
The problem are all those people writing programs that think they are doing the world a favor by screwing with the hostname and various other settings for us... there's no reason for dhcp to change my hostname. At least on linux, no dhcp implementation touches /etc/hosts. (Solaris has screwed up the hosts file for years.)
These are the same machines that don't have FQDN's as the first name per entry in /etc/hosts (which pisses off many incarnations of glibc.) *grin*
--Ricky
PS: When you're off-line, /etc/resolv.conf shouldn't have any nameservers listed. They aren't going to be connectable.
>I don't know of a proper solution, other then writing in big letters >in the documentation about the circumstances under which you can shoot >yourself in >the feet.
>Where is NFSv4?
The problem is the protocol, it's the fact that the directory is shared among more than one machine. It's the false assumption that a given location is unique to just one machine. Yes, I've fallen into this mess too. (And I wasn't using NFS, btw.)
On Mon, 27 Dec 2004, Martin Dalecki wrote: >for example the pure hobby-student-project ClearCase are going to the >extent of requiring you to run their own networked filesystem if running >on Linux.
WTF are talking about? MVFS is required *everywhere* you want to use dynamic views... solaris, aix, hpux, windows, and *yes* LINUX.
And MVFS is not 100% filesystem -- it's part fs, part db, part proxy, ... (it's just weird, but I like it.)
On Sun, Dec 26, 2004 at 09:19:00AM -0800, Larry McVoy wrote: > On Sun, Dec 26, 2004 at 10:43:13AM -0600, James Bottomley wrote: > > On Sun, 2004-12-26 at 08:27 -0800, Larry McVoy wrote: > > > I suspect that your hostname changes when you disconnect. Leases are > > > issued on a per host basis. If you make your hostname constant when > > > you unplug it should work. If it doesn't, let us know.
> > Well, that's a new one, but no, I have a fixed hostname which dhcp is > > forbidden from changing.
> Let's do a little poll here to find out if it is specific to you or if > this is a problem that everyone is having. Could we get people who > use BK disconnected to stand up and be counted? Does this work for > anyone?
> For James, could you do a little debugging please? Run the following > when you are plugged in and it works and also when it doesn't:
> bk getuser > bk getuser -r > bk gethost > bk gethost -r > bk dotbk
> We'll track it down and fix it if it is a problem on our end. This stuff > is supposed to work, we certainly haven't intentionally caused a problem.
Larry,
I have never been able to use BK in disconnected mode, which is very annoying.
It fails to connect to lease.openlogging.org as James describes.
Is disconnected operation supposed to work ? It didnt seem so.
> On Sun, 26 Dec 2004, Martin Dalecki wrote: >> A hostname simply isn't a fixed attribute of a host anymore.
> It is on properly setup and maintained machines.
> The problem are all those people writing programs that think they are > doing > the world a favor by screwing with the hostname and various other > settings > for us... there's no reason for dhcp to change my hostname. At least > on > linux, no dhcp implementation touches /etc/hosts. (Solaris has screwed > up > the hosts file for years.)
> These are the same machines that don't have FQDN's as the first name > per > entry in /etc/hosts (which pisses off many incarnations of glibc.) > *grin*
So what would happen to somebody who put their BK files on a portable drive and carried it from home to work. That's a perfectly reasonable thing to do, both for security and for speed reasons, but it would appear to cause problems.
On Wed, 29 Dec 2004, Kyle Moffett wrote: >So what would happen to somebody who put their BK files on a portable >drive and carried it from home to work. That's a perfectly reasonable >thing to do, both for security and for speed reasons, but it would appear >to cause problems.
First, the license(s) are stored in the user's home directory (~/.bk/lease) per hostname. If you move to a completely different machine, then, yes, there will need to be a lease for that machine.
What you are describing is no different from the NFS case. It doesn't matter that the media has physically moved; it's still visible to multiple, unique hosts. Each host(name) will need it's own lease.
