Dear all, We think /var/tmp is a good default for these scripts, since it is persistent, and since they are prone to be changed (when changed in the front-end).
Nevertheless, the SCRIPTS_REMOTE_DIR, in oned.conf, can change the default location for these remotes scripts. Best regards, -Tino -- Constantino Vázquez Blanco | dsa-research.org/tinova Virtualization Technology Engineer / Researcher OpenNebula Toolkit | opennebula.org On Wed, Oct 20, 2010 at 5:56 PM, Tiago Batista <[email protected]> wrote: > I have to agree with you... I was bitten by a script that looks at > /tmp from time to time and cleans up old files... > > The location of such files do not belong at all on the temporary > paths, to me they look more like scripts that should live on the > libexec dir, on a shared directory, or on the home of the oneadmin > user... Given that adding a host should be as simple as possible, I > would second a path like ~/.one_scripts > > Any thoughts on this? > > Tiago > > On Wed, Oct 20, 2010 at 4:25 PM, Igor Rosenberg > <[email protected]> wrote: >> Hi Tino, >> I'm not sure why those scripts are considered temporary... >> 1 - If they're not temporary, why would the folder need to be called tmp? >> You seem to be referring to those scripts as "default remote". BTW, if >> they're not temporary, no need to check for their existence, as there is no >> reason for them to disappear. >> 2 - If indeed they're temporary, why does opennebula need them more than >> once? Using /tmp only makes sense if it's for a use-once-and-forget call. >> Just thoughts without looking at any doc. >> Regards >> Igor >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Tino >> Vazquez >> Sent: miércoles, 20 de octubre de 2010 17:17 >> To: Igor Rosenberg >> Cc: Rich Wellner; [email protected] >> Subject: Re: [one-users] SCRIPTS_REMOTE_DIR clarification >> >> Dear all, >> >> We are moving the default remote script dir to /var/tmp for the >> upcoming 2.0 release to take advantage of its persistency. >> >> OpenNebula looks to the modification time of the scripts in the >> front-end to copy them in case they have modifications. It doesn't >> check the remote hosts, but being the scripts in /var/tmp and copying >> them upong "onehost create" (as it is now) should be enough for a >> reasonable functioning. >> >> Thought? >> >> Regards, >> >> -Tino >> >> -- >> Constantino Vázquez Blanco | dsa-research.org/tinova >> Virtualization Technology Engineer / Researcher >> OpenNebula Toolkit | opennebula.org >> >> >> >> On Wed, Oct 20, 2010 at 5:09 PM, Igor Rosenberg >> <[email protected]> wrote: >>> Hello, >>> >>>> I think one should look at the remote dir and transfer the files >>>> again if they are missing, this would not be very expensive and >>>> would prevent people from running across this problem. >>> >>> I support this request. We had the same problem yesterday with some >>> executables missing from /tmp/one/ ; I was quite surprised I had to copy >>> them myself (in my case it was sufficient). >>> Regards >>> Igor >>> >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Rich Wellner >>> Sent: miércoles, 20 de octubre de 2010 16:54 >>> To: [email protected] >>> Subject: Re: [one-users] SCRIPTS_REMOTE_DIR clarification >>> >>> I tried onehost sync and nothing happened. I ended up changing the >>> remote dir to /var/tmp/one and touching the source directory. Things >>> got transferred and I was good from there. >>> >>> I think one should look at the remote dir and transfer the files again >>> if they are missing, this would not be very expensive and would prevent >>> people from running across this problem. >>> >>> rw2 >>> >>> On 10/20/10 6:08 AM, Tino Vazquez wrote: >>>> Hi Tiago, >>>> >>>> You can force the copy of the probes with "onehost sync". >>>> >>>> Regards, >>>> >>>> -Tino >>>> >>>> -- >>>> Constantino Vázquez Blanco | dsa-research.org/tinova >>>> Virtualization Technology Engineer / Researcher >>>> OpenNebula Toolkit | opennebula.org >>>> >>>> >>>> >>>> On Wed, Oct 20, 2010 at 11:39 AM, Tiago Batista<[email protected]> >>>> wrote: >>>>> Hello all >>>>> >>>>> I am getting errors from the (VMM_)IM drivers, from oned.log: >>>>> >>>>> Wed Oct 20 10:15:11 2010 [InM][I]: Monitoring host fpa1.ieeta.pt (1) >>>>> Wed Oct 20 10:15:11 2010 [InM][I]: Command execution fail: >>>>> /tmp/one/im/run_probes xen >>>>> Wed Oct 20 10:15:11 2010 [InM][I]: STDERR follows. >>>>> Wed Oct 20 10:15:11 2010 [InM][I]: bash: /tmp/one/im/run_probes: No >>>>> such file or directory >>>>> Wed Oct 20 10:15:11 2010 [InM][I]: ExitCode: 127 >>>>> Wed Oct 20 10:15:11 2010 [InM][E]: Error monitoring host 1 : MONITOR >>>>> FAILURE 1 Could not monitor host fpa1.ieeta.pt. >>>>> Wed Oct 20 10:15:57 2010 [ReM][D]: HostPoolInfo method invoked >>>>> Wed Oct 20 10:15:57 2010 [ReM][D]: VirtualMachinePoolInfo method invoked >>>>> Wed Oct 20 10:16:11 2010 [VMM][I]: Monitoring VM 11. >>>>> Wed Oct 20 10:16:11 2010 [VMM][D]: Message received: LOG - 11 Command >>>>> execution fail: /tmp/one/vmm/xen/poll one-11 >>>>> Wed Oct 20 10:16:11 2010 [VMM][D]: Message received: LOG - 11 STDERR >>>>> follows. >>>>> Wed Oct 20 10:16:11 2010 [VMM][D]: Message received: LOG - 11 bash: >>>>> /tmp/one/vmm/xen/poll: No such file or directory >>>>> Wed Oct 20 10:16:11 2010 [VMM][D]: Message received: LOG - 11 ExitCode: >>>>> 127 >>>>> Wed Oct 20 10:16:11 2010 [VMM][D]: Message received: POLL FAILURE 11 - >>>>> >>>>> >>>>> Now, the /tmp on the paths points to the SCRIPTS_REMOTE_DIR variable >>>>> on oned.conf. Do I need to put those scripts on the specified >>>>> directory or is one supposed to create them during runtime? If so, >>>>> where can I find them? >> ------------------------------------------------------------------ >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive >> this e-mail in error, please notify the sender immediately and destroy it. >> As its integrity cannot be secured on the Internet, the Atos Origin >> group liability cannot be triggered for the message content. Although >> the sender endeavours to maintain a computer virus-free network, >> the sender does not warrant that this transmission is virus-free and >> will not be liable for any damages resulting from any virus transmitted. >> >> Este mensaje y los ficheros adjuntos pueden contener informacion confidencial >> destinada solamente a la(s) persona(s) mencionadas anteriormente >> pueden estar protegidos por secreto profesional. >> Si usted recibe este correo electronico por error, gracias por informar >> inmediatamente al remitente y destruir el mensaje. >> Al no estar asegurada la integridad de este mensaje sobre la red, Atos Origin >> no se hace responsable por su contenido. Su contenido no constituye ningun >> compromiso para el grupo Atos Origin, salvo ratificacion escrita por ambas >> partes. >> Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor >> no puede garantizar nada al respecto y no sera responsable de cualesquiera >> danos que puedan resultar de una transmision de virus. >> ------------------------------------------------------------------ >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >> > _______________________________________________ > Users mailing list > [email protected] > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > _______________________________________________ Users mailing list [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
