We use chef to provision our boxes but most of our deployments are onto windows, as such infrastructure for our linux boxes isn't all there; because of this I can't log on using my own user/password.
The mechanisms for allowing login only work on windows (it's just not a priority for doing it on linux at the moment) and we only have root passwords and I don't have access to that (rightfully so).
However I could create a user during the chef run, I've looked but to be honest they're all kinda confusing, so I thought I'd ask and hope someone with experience might have a better solution.
How do I create a user with admin access so I can ssh in and do what needs to be done on the box via chef?
Best guidance I can give:
Use the user resource to create the user and then the sudo cookbook to add this user to the sudoers list.
User resource documentation
A stackoverflow question on the password attribute
Sudo cookbook
So you should end up with a cookbook containing the following:
metadata.rb
[...] # stripped usual lines for cookbook name version
depends 'sudo' # add the dependency to use only one cookbook
attributes/default.rb:
default['user_to_create'] = "user3536548" # took you SO account here
default['authorization']['sudo']['users'] << node['user_to_create'] # Add the defined user in the array (using attribute to avoid duplication of user name), this avoid overwriting entries from other recipes and as the attribute is initialized as an empty array it will be ok anyway.
recipes/default.rb
user node['user_to_create'] # create the user, see the doc for details
include_recipe 'sudo' # include the sudo recipe to take advantages of the atrtibutes above.
Related
I am currently using Chef's Jenkins supermarket cookbook to deploy an instance of Jenkins. As part of that deployment, my recipe includes installing Jenkins, installing specific plugin versions, enabling security and creating an Administrator account for Jenkins.
I'm currently using a single recipe file for this. The script that is executed to enable security and create the Administrator account is as follows:
jenkins_script 'activate global security' do
command <<-EOH.gsub(/^ {4}/, '')
import jenkins.model.*
import hudson.security.*
def instance = Jenkins.getInstance()
def hudsonRealm = new HudsonPrivateSecurityRealm(false)
hudsonRealm.createAccount("Administrator","administrator_passwd")
instance.setSecurityRealm(hudsonRealm)
instance.save()
def strategy = new GlobalMatrixAuthorizationStrategy()
strategy.add(Jenkins.ADMINISTER, "Administrator")
instance.setAuthorizationStrategy(strategy)
instance.save()
EOH
notifies :restart, 'runit_service[jenkins]', :immediately
end
The script activates security, creates the Jenkins Administrator user with a password, and then restarts the Jenkins instance. From what I understand, the jenkins_script resource executes Java or Groovy command against the Jenkins master, and is not idempotent.
As the script is not idempotent, if the recipe is run on the node subsequent times after the initial run, the chef-client run fails as security is already enabled and the Administrator user has already been created.
My thoughts are to move this security enablement script to its' own recipe file, and then specify the recipe for security in the node's run list if enabling security is required. If security has already been enabled, we simple don't add / remove the security recipe from the run list.
Is this a sound approach to working around this problem?
If this is a sound approach, should it be as simple as just
creating another ruby file, dumping the security code in it, and
adding it to the node's run list after the recipe for the initial
Jenkins install?
You don't have to restart Jenkins to configure security.
When configuring security there are a few considerations you have to take into account. One is that it almost always works the first run, but you want to make sure that on repeated runs it continues to successfully apply desired changes.
There is an attribute for the executor protocol which defaults to remoting and you'll see warnings all over about using it because it is less secure and has been deprecated. Other options are https or ssh, with the latter being the option we decided to go with. If you configure it as the protocol but the SSH key provided to be used isn't associated with a user (user has to be created and then an SSH public key associated with them) then it will fall back to using anonymous (part of the cookbook) and so you need to ensure you either do all your "privileged" operations like plugin installation and reconfiguration scripts before you enable authentication, or ensure you have the authentication pre-configured to request SSH so that it immediately kicks in when the authentication is turned on.
In the case of implementation of the monitoring database oracle control method requires a standard application username and password explicitly. How to bypass the need to enter in clear text password to log into the database oracle, which is visible in the screen OP5 Monitor and Nagios configuration file system.?
There are several possibilities.
Generic solution
Use the $USERnn$ macros, which are defined in resources.cfg. More information on how to use this feature: https://kb.op5.com/display/DOC/Macros#Macros-Custommacros
The USER macros are not visible in the graphical user interface, but can be read by anyone having access to the resources.cfg configuration file.
For Naemon documentation on user macros see http://www.naemon.org/documentation/usersguide/macrolist.html#user
Specific solution for the check_oracle plugin (if that is what you are using)
Specify the credentials in an auth file. From the help text for the plugin:
-f <auth-file> can be used instead of -u <username> -p <password>. If both
options are used the <auth-file> will override -u/-p. The <authfile> should
be a textfile (readable by the nrpe-user) containing two rows. File format:
username=<username>
password=<password>
Solution specific to OP5 Monitor
Use custom variables prefixed with OP5SECRET. Unfortunately, these are not very well documented, but take a look at the Standalone VMware ESXi virtualization host management pack which uses this feature.
Full disclosure: I work as Development Team Lead at OP5.
I am currently trying to automate the process of bamboo remote agent installation and uninstallation. I have run into a problem in regards to adding and removing capabilities.
What I am trying to automate:
(The following is what I do on the bamboo server via the GUI, I want to do this on the remote agent machine via bash script.)
I install the remote agent on a VM machine, then start it up. I go to the bamboo interface and click on the newly created agent's name.
I add a custom capability type, for the key I put 'buildserver' and for the value I put the name of the agent.
I add an 'Executable' capability of type 'Command' with Executable label 'cygwin' and path 'C:\cygwin64\bin\bash'
I navigate to the git executable, and remove it by clicking 'delete.' <--- (the problem step)
what I've done.
I have looked here and found a way to automate steps 1-3 using the following "bamboo-capabilities.properties" file:
buildserver="AGENTNAME"
system.builder.command.cygwin="C:\cygwin64\bin\bash"
However I am stuck on how I would remove the git capability (step 4.) I've tried something appending something like this to the file:
system.git.executable=""
but it does not seem to do anything. Does anyone know how I would do this? There seems to be very little documentation about this online.
Thanks very much.
I never found a way to get around this, but I found a workaround. I later learned the point of removing git in my situation was to allow a shared capability that was also called git to take precedence. My workaround was to set the non-shared capability to the value of the shared capability. I am not 100% sure that this does the same thing, and I am not in a position to test it yet, but as a capability seems to be only a key-value pair I don't see why it wouldn't.... will update if anything breaks.
I am planning on using a local repository, using only TortoiseSVN's "create repository here" feature.
The repo is created and I can read and write to it just fine. The problem is that I can't get authentication to work. I thought I wanted Windows authentication, but I actually want the simple text-file based authentication so I can force the current system user (i.e. any person can be using the same Windows account and I want to differentiate between them) to provide their name and password. I haven't found any information on how to do this without svnserve running.
So far, I have modified svnserve.conf like this:
anon-access = read
auth-access = write
password-db = passwd
realm = LocalOnly
I didn't mess with the [sasl] section.
I also modified passwd:
[users]
harry = teH0wLIpW0gyQ
I am trying to use encrypted passwords created with a simple perl script. However, regardless of what I do with the repo (i.e. including writing to the repo), I am never prompted for a password.
I tried clearing TortoiseSVN's authentication cache since I do connect to a remote repo, but this didn't matter at all.
Has anyone tried this and succeeded? Or is it not possible without svnserve?
Not possible without svnserve - it takes care of the challenge/response.
Try Subversion Edge. you can edit the file you are mentioning using the GUI provided by the tool. It uses its own http server(not svnserve or IIS).
Unfortunately your best bet with a local repository is to use your file system permissions. A simple and free option for a server (that's easy to manager) would be VisualSVN Server. You can hang it off or a workstation or drop it on a public webserver somewhere. I now have mine setup with a reverse proxy with IIS7 so it's integrated with the rest of my web site.
So when I create a debian package, I am able to write a post-installation shell script that runs just fine. Currently mine is configured to do
echo "Please enter your MySQL Database user (default root)"
read MYSQL_USER
echo "Please enter the MySQL Database user password (default root)"
read -s MYSQL_PASS
DBEXIST=0
CMD="create database lportal;use lportal;"
(mysql -u$MYSQL_USER -p$MYSQL_PASS -e "$CMD") || ((DBEXIST++))
if [ $DBEXIST -ne 0 ]; then
echo "Setup finished, but MySQL already has an lportal table. This could be from a previous installation of Liferay. If you want a fresh installation of this bundle, please remove the lportal table and reinstall this package."
fi
This works fine for Ubuntu. However, I can't seem to get user input to work with RPMs for Fedora. Is there a good way to take user input? From what I understand, RPMs were designed not to allow interactive installs. However I can't see a better way to do this..
Is there possibly a way to automatically find local MySQL settings without asking the user? Otherwise, what's the best way to ask for user input?
Okay I've resolved this without a real answer -- basically from what I understand, I have two options -- one is a wrapper script like Bind or CUPS uses. It's not considered good packaging practice though, and I'm still unsure how to go about doing it. Better is just to assign default values in the %POST script, and create a firstrun flag. The first time the user launches the software, it prompts for configuration settings.