[one-users] ONE context package
ML mail
mlnospam at yahoo.com
Mon Mar 3 23:57:00 PST 2014
While running the script at first boot only is not a bad idea, you will have to think about the case where you change the hostname or change the DNS PTR entry.... Your VM would be stuck with the old hostname. So if you go this way there should be at least a check in the script to see if the hostname or DNS PTR entry have changed, if yes adapt the /etc/hostname and if not do nothing...
Regards,
ML
On Monday, March 3, 2014 9:53 PM, "Liu, Gene" <Gene.Liu at alcatel-lucent.com> wrote:
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> 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
>
>
>_______________________________________________
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/d6044f07/attachment-0002.htm>
More information about the Users
mailing list