[one-users] ONE context package

[ML mail]

Hi Javier,

Thanks for the changes. I am not in a rush so I will test directly with the packages. Let me know when and where the new packages are available and I will make sure to test the .deb one for you and let you know.

Cheers,
ML





On Friday, February 28, 2014 6:21 PM, Javier Fontan <jfontan at opennebula.org> wrote:
 
I've uploaded the scripts to the branch feature-2453 for both deb and
rpm based distros.

DNS_HOSTNAME=yes: gets the first ip and tries to get the dns name with "host"
SET_HOSTNAME=name.of.the.host: sets the hostname

I'll try to create the packages before leaving the office but you can
follow the instructions there in case you want to create them
yourself.


[1] https://github.com/OpenNebula/one/tree/feature-2453/share/scripts/context-packages

On Thu, Feb 27, 2014 at 10:29 PM, ML mail <mlnospam at yahoo.com> wrote:
> Hi Javier,
>
> Thanks for the example with using $NAME in the SET_HOSTNAME context variable
> that for sure helps not having one template per VM. Although I already see
> the next problem, you can't have spaces in your VM name but that's a detail
> :)
>
> I totally agree regarding the dynamic hostname based on the PTR DNS record
> of the VM, it should not be a default but only activated through a context
> variable, like you mention DNS_HOSTNAME variable is fine. Right now no other
> ideas just as simple as possible by doing a reverse lookup on the first/main
> IP of the VM should be enough I would say.
>
> I guess the "host" command would be the one which should always be
> available.  I have seen cases where there was no "dig" installed on a base
> linux installation and "nslookup" is sort of fading out. In the worst case
> if the host command does not exist nothing happens or it could fallback to
> dig.
>
> Greetings,
> ML
>
>
> On Thursday, February 27, 2014 4:27 PM, Javier Fontan
> <jfontan at opennebula.org> wrote:
> On Thu, Feb 27, 2014 at 2:13 PM, ML mail <mlnospam at yahoo.com> wrote:
>
>> You are right I had to define the HOSTNAME variable in the template
>> context
>> and not as a tag in the already running VM. This means that I can't share
>> templates among VMs, which is a bit stupid of course. With this solution
>> you
>> need one template per VM.
>
> Not exactly. The value of custom variables can be a dynamic one [1] so
> for example you can set the hostname to the name of the VM:
>
> SET_HOSTNAME="$NAME"
>
> or even a mix of static and dynamic data:
>
> SET_HOSTNAME="$NIC[IP].domain.com"
>
> [1]
> http://docs.opennebula.org/stable/user/virtual_machine_setup/cong.html#using-template-variables
>
>> I see the issue with the HOSTNAME environment variable which is actually
>> set
>> at bootup of Linux so no problem with me for using a name such as
>> SET_HOSTNAME like you suggest.
>
> Good, I'll go with this.
>
>> What do you think about having that same script also defining the hostname
>> dynamically (if none was defined with the SET_HOSTNAME context variable)
>> based on a DNS reverse lookup if the IP address of the VM has a PTR
>> record?
>
> I think it's a nice feature but it should only be set if the users
> asks for it. For example, if some VM has a hardcoded hostname a user
> does not expect it to be changed in case SET_HOSTNAME is not defined.
> Another variable can be added like DNS_HOSTNAME=yes or even better,
> specifying the IP where to get the name from:
>
> DNS_HOSTNAME="$NIC[IP, NETWORK=\"Public\"]"
>
> Any better idea?
>
> I'm not sure which command to use to do the reverse lookup. One that
> is in most of the distributions like host, nslookup or dig.
>
> Cheers
>
>>
>>
>>
>> On Thursday, February 27, 2014 12:27 PM, Javier Fontan
>> <jfontan at opennebula.org> wrote:
>> Hi,
>>
>> ML, I think you should add it in the template context section, custom
>> variables.
>>
>> I am adding scripts to configure the hostname in the context phase.
>> These are simple scripts (one for rpm and other for deb based distros)
>> that do just what you've commented, call hostname and modify the conf
>> file. [1]
>>
>> I've just found a problem with it and it is calling the configuration
>> variable "HOSTNAME". The shell automatically sets HOSTNAME and even if
>> we don't specify it so it's a bit tricky to check wether the user
>> intents to configure the hostname or leave it as it is.
>>
>> I am proposing to use the custom variable "SET_HOSTNAME" to configure
>> the host name. What do you think?
>>
>> Concerning the addition of scripts in the context package, there is a
>> guide in both the documentation [2] and the source code [3] on how to
>> create custom packages. Having the required dependencies it's fairly
>> easy to add or modify the configuration script you may need.
>>
>> Cheers
>>
>> [1] http://dev.opennebula.org/issues/2453
>> [2]
>>
>> http://docs.opennebula.org/stable/user/virtual_machine_setup/cong.html#generating-custom-contextualization-packages
>> [3]
>>
>> https://github.com/OpenNebula/one/tree/master/share/scripts/context-packages
>>
>> On Thu, Feb 27, 2014 at 8:02 AM, ML mail <mlnospam at yahoo.com> wrote:
>>> Regarding the hostname script that's exactly what I did, I also tried to
>>> redeploy this persistent image. Where exactly did you set the HOSTNAME
>>> variable? I have setted it in the tags of that specific VM (where I would
>>> also add the SSH_PUBLIC_KEY variable). But that might be wrong?
>>>
>>> Regards,
>>> ML
>>>
>>>
>>> On Thursday, February 27, 2014 2:47 AM, "Campbell, Bill"
>>> <bcampbell at axcess-financial.com> wrote:
>>> For item 1, no that should do it, just make sure it's executable and it
>>> should run. (the vmcontext init.d script will run all scripts in the
>>> /etc/one-context.d directory in order).  I set this up for Ubuntu, but
>>> I'm
>>> pretty sure Debian is the same when it comes to setting the hostname.
>>> You
>>> mention you reboot the VM, you may have to redeploy (as the context
>>> script
>>> is already generated from your previous deployment package).
>>>
>>> For item 2, you could include it in your base image, or in the example
>>> provided, add it to the files repository along with that init.sh script,
>>> and
>>> then assign both files to the template.  This way the files will be
>>> included
>>> with the context information, will copy the ##-script over to the
>>> instance,
>>> and restart the vmcontext service.
>>>
>>> ________________________________
>>> From: "ML mail" <mlnospam at yahoo.com>
>>> To: "users" <users at lists.opennebula.org>
>>> Sent: Wednesday, February 26, 2014 11:12:08 AM
>>> Subject: Re: [one-users] ONE context package
>>>
>>> Hi Bill,
>>>
>>> Thanks for your answer and example scripts. I have a few more questions
>>> or
>>> issues regarding your examples:
>>>
>>> - I tried out your small hostname script which I have copied on my Debian
>>> 7
>>> VM under /etc/one-context.d/98-hostname. I have then set in my VM a tag
>>> called HOSTNAME with a value and rebooted the VM. Unfortunately the
>>> hostname
>>> did not get changed. Did I miss something here?
>>>
>>> - I suppose I would have to re-create the one-context package manually if
>>> I
>>> would like to include the aforementioned 98-hostname script in the
>>> official
>>> one-context package, correct? or I could manually copy it into my image
>>> before deploying it?
>>>
>>> Regards,
>>> ML
>>>
>>>
>>>
>>> On Wednesday, February 26, 2014 3:08 PM, "Campbell, Bill"
>>> <bcampbell at axcess-financial.com> wrote:
>>> We don't have the automatic lookup from DNS (that would rely on the DNS
>>> record being created first prior to VM deployment), but we use a script
>>> that
>>> is placed in our base images /etc/one-context.d/ directory that does this
>>> (which relies on option 2 as you mention below, a HOSTNAME context
>>> variable):
>>>
>>> #!/bin/bash
>>>
>>> if [ -f /mnt/context.sh ]; then
>>> . /mnt/context.sh
>>> else
>>> exit 0
>>> fi
>>> hostname $HOSTNAME
>>> echo $HOSTNAME > /etc/hostname
>>>
>>> exit 0
>>>
>>> The above example is for our Ubuntu instances, so it may need to be
>>> modified
>>> for RHEL or SUSE based virtuals, if that's what you use.
>>>
>>> In addition, if using 4.4, use the files datastore and create an
>>> 'init.sh'
>>> script that can then load up additional files that you assign to the
>>> template (so you don't need to manually update each image).  We use an
>>> init.sh script like this to inject new configuration/contextualization
>>> options so we don't need to update our base image very often:
>>>
>>>
>>> #!/bin/sh
>>> #
>>> # OpenNebula Init Script
>>> #
>>> # init.sh
>>> #
>>> # Copies additional context scripts to the appropriate directory
>>> #
>>> ## Set environment
>>> SOURCE=/mnt
>>> DEST=/etc/one-context.d
>>>
>>> if [ -f /etc/redhat-release ]; then
>>> OSVERSION=RHEL
>>> else
>>> OSVERSION=UBUNTU
>>> fi
>>> if [ -f /usr/bin/rsync ]; then
>>> echo "Applying additional contextualization scripts..."
>>> else
>>> if [ "$OSVERSION" != "UBUNTU" ]; then
>>> yum -y install rsync
>>> else
>>> apt-get update && apt-get -y install rsync
>>> fi
>>> fi
>>>
>>> ## Copy Files. This will IGNORE any *.sh files in the source/destination
>>> directories, as all context scripts
>>> ## should NOT have the .sh extension.
>>> for i in $(ls $SOURCE --ignore=*.sh)
>>> do
>>> if [ -f $DEST/$i ]; then
>>> echo "$i exists in context directory. Skipping..."
>>> else
>>> rsync -au $SOURCE/$i /etc/one-context.d/
>>> chown root.root /etc/one-context.d/*
>>> chmod 700 /etc/one-context.d/*
>>> service vmcontext restart
>>> fi
>>> done
>>> exit 0
>>>
>>> This will check the OS Version and install the appropriate package.  It
>>> will
>>> NOT copy any file that has the .sh extension, but if you follow the
>>> context
>>> script standard of ##-<scriptname> then you can add additional context
>>> upon
>>> deployment.  Rudimentary, sure, but works well enough for us.
>>>
>>>
>>> ________________________________
>>> From: "ML mail" <mlnospam at yahoo.com>
>>> To: users at lists.opennebula.org
>>> Sent: Wednesday, February 26, 2014 5:39:46 AM
>>> Subject: [one-users] ONE context package
>>>
>>> Hi,
>>>
>>> I am very happy with the ONE context package for automated
>>> contextualization
>>> on Debian and CentOS but I miss one feature: automatically and manually
>>> setting the hostname of the VM.
>>>
>>> Basically it would be great to have the following two options:
>>>
>>> - automatically set the hostname of the VM based doing a reverse DNS
>>> lookup
>>> on the IP address, for example I have as reverse DNS entry
>>> "one-vm-1-0-16-172.mydomain.com" then the hostname of my VM would be
>>> automatically set to "one-vm-1-0-16-172".
>>> - using a HOSTNAME tag in the VM to manually enter a hostname and
>>> overriding
>>> the automatic hostname attribution described above
>>>
>>> What do you think?
>>>
>>> Regards,
>>> ML
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>>>
>>> NOTICE: Protect the information in this message in accordance with the
>>> company's security policies. If you received this message in error,
>>> immediately notify the sender and destroy all copies.
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>>>
>>> NOTICE: Protect the information in this message in accordance with the
>>> company's security policies. If you received this message in error,
>>> immediately notify the sender and destroy all copies.
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>
>>>
>>
>>
>>
>> --
>> Javier Fontán Muiños
>> Developer
>> OpenNebula - The Open Source Toolkit for Data Center Virtualization
>> www.OpenNebula.org | @OpenNebula | github.com/jfontan

>
>>
>
>
>
> --
> Javier Fontán Muiños
> Developer
> OpenNebula - The Open Source Toolkit for Data Center Virtualization
> www.OpenNebula.org | @OpenNebula | github.com/jfontan
>
>



-- 
Javier Fontán Muiños
Developer
OpenNebula - The Open Source Toolkit for Data Center Virtualization
www.OpenNebula.org | @OpenNebula | github.com/jfontan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20140303/262907e5/attachment-0001.htm>