[one-users] ONE context package

[ML mail]

Nice work, I've tested the debian package and setting the hostname dynamically based on the PTR DNS entry works perfectly!

Cheers,
ML





On Monday, March 3, 2014 12:53 PM, Javier Fontan <jfontan at opennebula.org> wrote:
 
Here they are:

http://dev.opennebula.org/attachments/download/768/one-context_4.5.0.deb
http://dev.opennebula.org/attachments/download/769/one-context_4.5.0.rpm

Remember to set DNS_HOSTNAME=yes to use the DNS name or SET_HOSTNAME to fix the name manually.





On Mon, Mar 3, 2014 at 10:52 AM, ML mail <mlnospam at yahoo.com> wrote:

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
>
>


-- 
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/a53f21d8/attachment-0002.htm>