Re: [boinc_dev] Suspected cpid hash collisions for newly installed clients on Linux
hi Christian yes that is exactly what I was doing initially, except 1. the Account_ file has my weak auth instead of the full auth. 2 as I have already said, the remote_hosts.cfg and gui_rpc_auth.cfg files have been customised But it is this set up that is causing me problems, hence my thought to introduce a minimal client state file to pre-empt the cpid -- just to be clear I have not given the client a minimal client_state.xml yet, it my next thing to try, with a pre-filled cpid in it, I still do not understand why your clusters are working, and my diskless workstations are getting the server confused... R~~ On 24 January 2017 at 09:35, Christian Beer <christian.b...@aei.mpg.de> wrote: > On 23.01.2017 22:27, trueriver wrote: > > As for the network booting machines, I already have a script running in > the initrd that sets up the boinc directories ready for the client to be > started. At present I give the client exactly the same files it gets from > the post install trigger, plus an account_xml file so that it thinks it > is already connected to a project. > > Sudden thought: will the client get confused by having an account_xml > file but no client_state.xml ?? I have just realised I am giving it a > combination of files that would not occur in normal use, so even though I > believe that SHOULD work, it is a corner case that may not have been tested > in development > > If you want to attach to a project right after startup automatically you > only need an account_.xml file. The client_state.xml should not be > transfered. This file saves the state of a specific client on a specific > machine. There should be no information in there that you need to copy over > to a new computer. > > See here: http://boinc.berkeley.edu/wiki/Creating_custom_installers and > here http://boinc.berkeley.edu/wiki/Initialization_files on how to prime > the Client with a project account or an account manager. > > Btw: In our Cluster environment we supply a basic account_*.xml right > after installing the distribution supplied package which works very nice. > The content is like this: > > PROJECT_MASTER_URL > 12345678901234567890123456789012 > > This should do the same as the project_init.xml described in the links > above. > > Regards > Christian > ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Suspected cpid hash collisions for newly installed clients on Linux
hi Christian thanks for your reply. I will look at the relevant threads on the devs forum, but I don't initially see how the scenarios you describe apply to either of my situations. For one thing the CLI (Debian Jessie) boxes do not have virtual network devices, and have exactly one network card, which must be running for the initrd to exit to systemd (because they are diskless, initrd needs a working network to find its nfs root file system). This is a fairly simple boot process which I think I understand (base system, sshd, and boinc; nothing else). I am not so confident about knowing what goes on when the Mint boxes boot up - virtual box is mentioned but I believe only to say that various modules are not being loaded as we are not in a virtual environment. But thanks for the tip, it is something I must check out I do see the issue if huge clusters generated new host records every time they booted up: I understand now the devs motivation for moving away from having a brand new cpid on each boot. I see why my changes are therefore not ones that you would want in the official release. I certainly would not claim to "understand" .deb packages, but I do know enough to add to an existing post-install script. As for the network booting machines, I already have a script running in the initrd that sets up the boinc directories ready for the client to be started. At present I give the client exactly the same files it gets from the post install trigger, plus an account_xml file so that it thinks it is already connected to a project. Sudden thought: will the client get confused by having an account_xml file but no client_state.xml ?? I have just realised I am giving it a combination of files that would not occur in normal use, so even though I believe that SHOULD work, it is a corner case that may not have been tested in development... you said > > The occasional problems you see might stem from the fact that the > network may not be working at the time when the BOINC Client tries to > get the MAC address and uses a random host-CPID instead. > > random would work for me, as it would be different each time. It must default to a _deterministic_ host-CPID to create collisions with older hosts. The suggestion on the Prime Grid forum was that it hashes the data directory with the MAC address, and that if the MAC is missing for any reason then, as the data directory is constant you always get the same hash Thanks for the links to the post on the dev forum, and to the formal description of the hash, I am off to read them now warm regards River~~ ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Suspected cpid hash collisions for newly installed clients on Linux
ut it does seem random whether it picks up thew history of its own hardware, or of one of the other machines. I am not sur about this yet, I am still collecting data. In any case, my preference would be to start each freshly booted machine as a new machine on the PG server, allowing me to merge them manually (I have been around long enough to remember when that was the norm after a re-install, and personally I preferred that). If I do not turn a machine on for months on end, when it is powered up I want it to be at the default location, not wherever that physical hardware was located last time it was used. I do understand the this old behaviour changed because of specific requests from users who had their own reasons for wanting hardware continuity. I am fairly sure there is at least one bug here, possbily a different bug in the two scenarios. I find it interesting that so far, in ten months, there has not yet been a case of confusion between a laptop and a desktop -- at some poiunt the different hardware becomes sufficiently different to avoid ambiguity. So, FIRST I believe there is a bug that means that cpid is sometimes independent of the MAC address. SECOND, I am requesting a user-selectble option that allows a user, at instll time, to choose to switch hardware-continuity on or off. I believe the second could be achieved by asking a question in the post-install trigger, and if the user wanted hardware continuity off, the script would create a cpid based on a freshly generated uuid. There could even be a three way option: hardware based, based on hostname, or based on a fresh-every install cpid (the latter not beng a hash of anything on the system but a random based uuid with the punctuation stripped out). This option would not be offered where the post install trigger found a pre-existing stare file with a pre-existing cpid. As a work-around, that same option would solve the issues created if there is, in fact, a bug in the client-generated cpid routine. Unless you guys can suggest a good reason why not, I intend to make this change to the .deb on my own system, and see what happens. I have spent too much time clearing up the messes that false allegations of "abandonment" make -- by which I mean when tasks on a different set of hardware get marked as abandoned. If you know of a reason why this idea is unwise, as a home project, please let me know in the next few days. I am also offering this to you as something you may (or may not) want to roll out more generally. I also do not know about making a bug report. This effect comes and goes, and I can think I have an effective way to avoid it (as with buying new USB dongles) then that can fall in a heap. I cannot (yet) produce a definitive recipe to reliably demonstrate this effect, so up to know I have not filed a bug report. Do you think I should? I would value your thoughts on any of the above. And if it does turn out to be provoked by me in a way I have not yet thought of, I would be glad to know that, too. Is there anything else you need to know from me at this time? River~~ On 22 January 2017 at 15:17, Steffen Möller <steffen_moel...@gmx.de> wrote: > Gianfranco is the more active one on the boinc Debian+Ubuntu packages, > but, anyway, I do not think the other readers on this list mind you > telling us about your concerns right here, in particular since this may > also be relevant for packages of other distributions. So, go ahead. > > Steffen > > > On 22/01/2017 14:45, Christian Beer wrote: > > Hi, > > > > if this is a packaging related problem than it's better to directly > > contact the package maintainer but the Debian maintainer is also reading > > this email list so you may try it out here before opening a Debian bug > > report. > > > > Regards > > Christian > > > > On 21.01.2017 18:44, trueriver wrote: > >> hi everyone, > >> > >> before I launch into a description and some questions, may I check this > is > >> the right place to ask about problems that seem to occur with running > Boinc > >> on multiple Linux machines? > >> > >> I am wondering, in particular, if the install triggers in the .deb can > be > >> improved to avoid a particular issue. I may be offering to assist with > >> that, depending what the issue turns out to be. > >> > >> So, is this the right place to ask, and if not can you kindly signpost > me > >> to the right place please? > >> > >> regards, > >> River~~ > >> ___ > >> boinc_dev mailing list > >> boinc_dev@ssl.berkeley.edu > >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > >> To unsubscribe, visit the above URL and > >&g
Re: [boinc_dev] is this the right place to ask about...
or of one of the other machines. I am not sur about this yet, I am still collecting data. In any case, my preference would be to start each freshly booted machine as a new machine on the PG server, allowing me to merge them manually (I have been around long enough to remember when that was the norm after a re-install, and personally I preferred that). If I do not turn a machine on for months on end, when it is powered up I want it to be at the default location, not wherever that physical hardware was located last time it was used. I do understand the this old behaviour changed because of specific requests from users who had their own reasons for wanting hardware continuity. I am fairly sure there is at least one bug here, possbily a different bug in the two scenarios. I find it interesting that so far, in ten months, there has not yet been a case of confusion between a laptop and a desktop -- at some poiunt the different hardware becomes sufficiently different to avoid ambiguity. So, FIRST I believe there is a bug that means that cpid is sometimes independent of the MAC address. SECOND, I am requesting a user-selectble option that allows a user, at instll time, to choose to switch hardware-continuity on or off. I believe the second could be achieved by asking a question in the post-install trigger, and if the user wanted hardware continuity off, the script would create a cpid based on a freshly generated uuid. There could even be a three way option: hardware based, based on hostname, or based on a fresh-every install cpid (the latter not beng a hash of anything on the system but a random based uuid with the punctuation stripped out). This option would not be offered where the post install trigger found a pre-existing stare file with a pre-existing cpid. As a work-around, that same option would solve the issues created if there is, in fact, a bug in the client-generated cpid routine. Unless you guys can suggest a good reason why not, I intend to make this change to the .deb on my own system, and see what happens. I have spent too much time clearing up the messes that false allegations of "abandonment" make -- by which I mean when tasks on a different set of hardware get marked as abandoned. If you know of a reason why this idea is unwise, as a home project, please let me know in the next few days. I am also offering this to you as something you may (or may not) want to roll out more generally. I also do not know about making a bug report. This effect comes and goes, and I can think I have an effective way to avoid it (as with buying new USB dongles) then that can fall in a heap. I cannot (yet) produce a definitive recipe to reliably demonstrate this effect, so up to know I have not filed a bug report. Do you think I should? I would value your thoughts on any of the above. And if it does turn out to be provoked by me in a way I have not yet thought of, I would be glad to know that, too. Is there anything else you need to know from me at this time? River~~ On 22 January 2017 at 15:17, Steffen Möller <steffen_moel...@gmx.de> wrote: > Gianfranco is the more active one on the boinc Debian+Ubuntu packages, > but, anyway, I do not think the other readers on this list mind you > telling us about your concerns right here, in particular since this may > also be relevant for packages of other distributions. So, go ahead. > > Steffen > > > On 22/01/2017 14:45, Christian Beer wrote: > > Hi, > > > > if this is a packaging related problem than it's better to directly > > contact the package maintainer but the Debian maintainer is also reading > > this email list so you may try it out here before opening a Debian bug > > report. > > > > Regards > > Christian > > > > On 21.01.2017 18:44, trueriver wrote: > >> hi everyone, > >> > >> before I launch into a description and some questions, may I check this > is > >> the right place to ask about problems that seem to occur with running > Boinc > >> on multiple Linux machines? > >> > >> I am wondering, in particular, if the install triggers in the .deb can > be > >> improved to avoid a particular issue. I may be offering to assist with > >> that, depending what the issue turns out to be. > >> > >> So, is this the right place to ask, and if not can you kindly signpost > me > >> to the right place please? > >> > >> regards, > >> River~~ > >> ___ > >> boinc_dev mailing list > >> boinc_dev@ssl.berkeley.edu > >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > >> To unsubscribe, visit the above URL and > >> (near bottom of page) enter your email address. > > > > _
[boinc_dev] is this the right place to ask about...
hi everyone, before I launch into a description and some questions, may I check this is the right place to ask about problems that seem to occur with running Boinc on multiple Linux machines? I am wondering, in particular, if the install triggers in the .deb can be improved to avoid a particular issue. I may be offering to assist with that, depending what the issue turns out to be. So, is this the right place to ask, and if not can you kindly signpost me to the right place please? regards, River~~ ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
