[one-users] SCRIPTS_REMOTE_DIR clarification

Wed Oct 20 08:56:09 PDT 2010

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
<igor.rosenberg at atosresearch.eu> 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: tinova79 at gmail.com [mailto:tinova79 at gmail.com] On Behalf Of Tino Vazquez
> Sent: miércoles, 20 de octubre de 2010 17:17
> To: Igor Rosenberg
> Cc: Rich Wellner; users at lists.opennebula.org
> 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
> <igor.rosenberg at atosresearch.eu> 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: users-bounces at lists.opennebula.org [mailto:users-bounces at lists.opennebula.org] On Behalf Of Rich Wellner
>> Sent: miércoles, 20 de octubre de 2010 16:54
>> To: users at lists.opennebula.org
>> 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<tiagosbatista at gmail.com>  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
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>