[one-users] ONE context package

Liu, Gene Gene.Liu at alcatel-lucent.com
Mon Mar 3 12:53:05 PST 2014


It works well on RHEL6.5. Thanks!

BTW, can these scripts be set run at first boot only? We do not need
recreate/overwrite these settings each time VM reboot.

Thanks!

Gene Liu
On 14-03-03 06:53 AM, Javier Fontan 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
> <mailto: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 <mailto: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
>     <mailto: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 <mailto:jfontan at opennebula.org>> wrote:
>     > On Thu, Feb 27, 2014 at 2:13 PM, ML mail <mlnospam at yahoo.com
>     <mailto: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 <http://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 <mailto: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
>     <mailto: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
>     <mailto: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 <mailto:mlnospam at yahoo.com>>
>     >>> To: "users" <users at lists.opennebula.org
>     <mailto: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
>     <mailto: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 <mailto:mlnospam at yahoo.com>>
>     >>> To: users at lists.opennebula.org <mailto: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
>     <http://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 <mailto: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 <mailto:Users at lists.opennebula.org>
>     >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>     >>
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Users mailing list
>     >>> Users at lists.opennebula.org <mailto: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 <mailto:Users at lists.opennebula.org>
>     >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Users mailing list
>     >>> Users at lists.opennebula.org <mailto: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 <http://www.OpenNebula.org> | @OpenNebula |
>     github.com/jfontan <http://github.com/jfontan>
>
>     >
>     >>
>     >
>     >
>     >
>     > --
>     > Javier Fontán Muiños
>     > Developer
>     > OpenNebula - The Open Source Toolkit for Data Center Virtualization
>     > www.OpenNebula.org <http://www.OpenNebula.org> | @OpenNebula |
>     github.com/jfontan <http://github.com/jfontan>
>     >
>     >
>
>
>
>     -- 
>     Javier Fontán Muiños
>     Developer
>     OpenNebula - The Open Source Toolkit for Data Center Virtualization
>     www.OpenNebula.org <http://www.OpenNebula.org> | @OpenNebula |
>     github.com/jfontan <http://github.com/jfontan>
>
>
>
>
>
> -- 
> Javier Fontán Muiños
> Developer
> OpenNebula - The Open Source Toolkit for Data Center Virtualization
> www.OpenNebula.org <http://www.OpenNebula.org> | @OpenNebula |
> github.com/jfontan <http://github.com/jfontan>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20140303/94fc03c4/attachment-0002.htm>


More information about the Users mailing list