In my current yocto build, no hostname is set by default. This is strange, since within meta/recipes-core/base-files/base-files_3.0.14.bb do_install the hostname is set (if not an empty string):
if [ "${hostname}" ]; then
echo ${hostname} > ${D}${sysconfdir}/hostname
fi
A few lines above the hostname is set to the Machine name:
hostname = "${MACHINE}"
Which is transformed to (within run.do_install):
if [ "" ]; then
echo > /my-path/etc/hostname
fi
Therefore the hostname seems to be not set?
The MACHINE VARIABLE is set of cause and even if i set the hostname to a fixed string, the problem persists:
hostname = "foo"
The recipe is executed by bitbake for sure and the only way to make it set the hostname is by patching like below, which is awful of cause...
echo "foo" > ${D}${sysconfdir}/hostname
I am pretty sure that I am missing something obvious here, but I am not able to track the problem down.
Here is the link to the file I am talking about
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/base-files/base-files_3.0.14.bb?h=krogoth
Would appreciate any help. Thanks!
Never mind...
I found the line of code where I unset the hostname barried deep within one of my own recipes.
Related
I try to read out the current recipe name while chef-client run and to store it in a variable or node attribute wihtin an recipe. Until yet i just found a way storing it into a node attribute but it always fails. This is my code:
ruby_block "Fetch Recipe Name From Run List" do
block do
Chef::Resource::RubyBlock.send(:include, Chef::Mixin::ShellOut)
s = shell_out("echo \"#{node['expanded_run_list']}\" | awk -F '::' '{print substr($3, 1, length($3)-1)}'" )
node.default['sftp-selfmade']['extracted_recipe'] = s.stdout
end
end
extracted_recipe = node['sftp-selfmade']['extracted_recipe']
# To debug the output of the node attribute.
execute 'TEST' do
command "echo \"TEST #{extracted_recipe}\""
end
Output:
* execute[TEST] action run
[execute] TEST
- execute echo "TEST "
Output should be:
- execute echo "TEST <Name-Of-Extracted-Recipe>"
I tried lot's of things as also storing the s.stdout output in a variable but this throws an NoMethodError during compiling stage. Also tried to use stronger values like node.override - this works but only by setting node.normal first and the setting it to node.override but this is not a satisfying solution to do this everytime within cookbook code again for deploying to new hosts. Tried also a solution reloading OHAI. But this also did not work. On a completely new host it also doesn't work after a 2nd chef-client run in case of attributes have been set then after first run.
Is there somebody who can help me out?
Found out the following solution:
expandedrecipe = node['expanded_run_list'].select{ |e| e.include? 'sftp-selfmade' }.first.split('::').last
That does the trick.
Summary:
I am writing a script to check if a directory exists on a remote machine. I need a solution which can allow me to check for that directory and return the result in a usable way. This whole process is automated within a much larger script so I need a functional way to tell the parent script the directory exists or not.
Restrictions:
The tools that I have are limited. $REMOTE_2 can only be accessed through $REMOTE_1. Also, $REMOTE_2 can only be connected via telnet (no ssh available).
Current goal:
I am trying to set a local variable to be then read back to chose a return code. I am open to other options, but this is the closest I've come to a working solution so far.
I realize that $found will take from the parent process, but this is not my desired result and am not sure what syntax I need to return true or false when trying to echo the $found variable.
/usr/bin/expect<<EOF
spawn ssh $USER#$REMOTE_1
expect "*$USER*"
send -- "telnet $REMOTE_2\r"
expect "*login:*"
send -- "root\r"
expect "*$*"
# Everything prior to this can't be changed. Everything after it can be.
send "if \[ -d $DIRECTORY_LOCATION \] ; then found=true; else found=false ; fi\r"
send -- "echo **$found**\r"
expect {
"*true*" {
exit 0
}
"*false*" {
exit 1
}
}
EOF
I believe this type of solution can work, but I am not sure how to use the remote variable that I store within the if statement, later on to allow me to choose which return code to use.
I've been trying to set a variable in a Puppet manifest that can be used across the puppet run. I have the following variables:
$package = 'hello'
$package_ensure = 'present'
$package_version = '4.4.1'
$package_maj_version = '4'
I'm trying to add another variable:
$ensure
using a BASH If statement using the above variables (since this is a source install I can't use an rpm command to see if the hello program is installed):
if [ -d "/opt/${package}${package_maj_version}" ]; then echo present; else echo absent; fi
but, I haven't been able to find a way to do so. I keep getting errors such as:
Error: Could not parse for environment production: Could not match ${package}${package_maj_version}"
Any help on this would be greatly appreciated.
I have been trying to run a shell script at boot time of freebsd. I have read all simmilar questions in stackoverflow and tried. But nothing is worked. This is the sample code that i tried is dummy.
#!/bin/sh
. /etc/rc.subr
name="dummy"
start_cmd="${name}_start"
stop_cmd=":"
dummy_start()
{
echo "Nothing started."
}
load_rc_config $name
run_rc_command "$1"
Saved with name of dummy.
Permissions are -r-xr-xr-x.
in rc.conf file made dummy_enable="YES".
The problem is, when i rebooted my system to test, dummy file is not there. So script is not executing. what else need to do run my dummy script.
SRC:http://www.freebsd.org/doc/en/articles/rc-scripting/article.html#rc-flags
You need to add rcvar="dummy_enable" to your script. At least for FreeBSD 9.1.
Call your script with parameter rcvar to get the enabled status:
# /etc/rc.d/dummy rcvar
# dummy
#
dummy_enable="YES"
# (default: "")
And finally start it with parameter start - this won't start the service/script unless dummy_enable is set in /etc/rc.conf (or /etc/rc.conf.local, or /etc/defaults/rc.conf)
# /etc/rc.d/dummy start
Nothing started.
One possible explanation is that rcorder(8) says:
Within each file, a block containing a series of "REQUIRE", "PROVIDE",
"BEFORE" and "KEYWORD" lines must appear.
Though elsewhere I recall that if a file doesn't have "REQUIRE", "PROVIDE" or "BEFORE", then it will be arbitrarily placed in the dependency ordering. And, it could be that the arbitrary placement differs between the first run up to $early_late_divider and in the second run of those after $early_late_divider.
OTOH, is this a stock FreeBSD, or some variant? I recall reading that FreeNAS saves its configuration somewhere else and recreates its system files on every boot. And, quite possibly that /etc is actually on a ramdisk.
Also, /usr/local/etc/rc.d doesn't come into existence until the first port installing an rc file is installed.
I'm trying to work out the best way to set some environment variables with puppet.
I could use exec and just do export VAR=blah. However, that would only last for the current session. I also thought about just adding it onto the end of a file such as bashrc. However then I don't think there is a reliable method to check if it is all ready there; so it would end up getting added with every run of puppet.
I would take a look at this related question.
*.sh scripts in /etc/profile.d are read at user-login time (as the post says, at the same time /etc/profile is sourced)
Variables export-ed in any script placed in /etc/profile.d will therefore be available to your users.
You can then use a file resource to ensure this action is idempotent. For example:
file { "/etc/profile.d/my_test.sh":
content => 'export MYVAR="123"'
}
Or an alternate means to an indempotent result:
Example
if [[ ! grep PINTO_HOME /root/.bashrc | wc -l > 0 ]] ; then
echo "export PINTO_HOME=/opt/local/pinto" >> /root/.bashrc ;
fi
This option permits this environmental variable to be set when the presence of the
pinto application makes it warrented rather than having to compose a user's
.bash_profile regardless of what applications may wind up on the box.
If you add it to your bashrc you can check that it's in the ENV hash by doing
ENV[VAR]
Which will return => "blah"
If you take a look at Github's Boxen they source a script (/opt/boxen/env.sh) from ~/.profile. This script runs a bunch of stuff including:
for f in $BOXEN_HOME/env.d/*.sh ; do
if [ -f $f ] ; then
source $f
fi
done
These scripts, in turn, set environment variables for their respective modules.
If you want the variables to affect all users /etc/profile.d is the way to go.
However, if you want them for a specific user, something like .bashrc makes more sense.
In response to "I don't think there is a reliable method to check if it is all ready there; so it would end up getting added with every run of puppet," there is now a file_line resource available from the puppetlabs stdlib module:
"Ensures that a given line is contained within a file. The implementation matches the full line, including whitespace at the beginning and end. If the line is not contained in the given file, Puppet appends the line to the end of the file to ensure the desired state. Multiple resources can be declared to manage multiple lines in the same file."
Example:
file_line { 'sudo_rule':
path => '/etc/sudoers',
line => '%sudo ALL=(ALL) ALL',
}
file_line { 'sudo_rule_nopw':
path => '/etc/sudoers',
line => '%sudonopw ALL=(ALL) NOPASSWD: ALL',
}