Skip to content

Latest commit

 

History

History
116 lines (79 loc) · 4.45 KB

manage-chef.md

File metadata and controls

116 lines (79 loc) · 4.45 KB
Raw

Managing Chef

Table of Contents

[TOC]

Add a user to the chef server

To add a user you will need ssh and root access to the chef server.

The steps to create a new chef user are:

  1. ssh into the chef server
    • ssh cinc-01-inf-ops.c.gitlab-ops.internal
  2. run sudo -i chef-server-ctl user-create USERNAME FIRSTNAME SURNAME GITLAB_EMAIL $(openssl rand -hex 20)
    • where all-caps words should be replace with the real user information
    • see NOTE below if surname contains white-spaces
  3. copy the private key generated by chef for this user, which needs to be shared with the user
  4. add the user to gitlab organization
    • sudo -i chef-server-ctl org-user-add gitlab USERNAME

NOTE* If you're adding a user with spaces in it, the chef-server-ctl user-create wrapper has a parsing bug. You can work around it like this:

sudo /opt/opscode/embedded/bin/knife opc user create username\
Firstname 'Surname With Spaces' gitlab_email $(openssl rand -hex 20)\
-c /etc/opscode/pivotal.rb

Grant chef admin rights to a user

For a user that was already created and added to the chef server, another chef admin can complete this task locally on their machine:

  • Run knife group add user USERNAME admins.
  • Run knife group show admins to check that the user is in the admin group.

Rotate chef key

To do this it will be necessary to create a new keypair. Because of how chef behaves the key has to be called default

  • ssh into the chef server
  • run sudo -i chef-server-ctl delete-user-key _username_ default to remove the default.
  • run sudo -i chef-server-ctl add-user-key _username_ --key-name default to create a new default key.
  • copy the private key generated by chef for this user.

If default is not declared chef will use the fingerprint of the key as a name. This will end up breaking chef execution as it will not be able of finding this key. To check if the user is correctly setup after the key rotation run this command:

$ bundle exec knife user show _username_
display_name: NAME
email:        gitlab email
first_name:   _Firstname_
last_name:    _Surname_
middle_name:
public_key:   -----BEGIN PUBLIC KEY-----
XXXX
-----END PUBLIC KEY-----

username:     _username_

if the public_key field is missing it means that the key will not be found by chef.

Remove a chef key from the server

  • run chef-server-ctl delete-user-key USERNAME default

Create a staging user

For this example we'll use the username "keysersoze".

  • Create a data bag in data_bags/users called keysersoze.json by copying an existing one. Make sure gitlab-staging is in the roles.
  • Run knife data bag from file users keysersoze.json. The lack of path before the json file is intended. If the command is successful it'll output a message like this: Updated data_bag_item[users::keysersoze]
  • Run knife ssh -aipaddress 'roles:gitlab-staging-base' 'sudo chef-client' to create the keysersoze user on staging.

Upgrade the chef-client version across the fleet

The chef-client version installed is managed through the Chef omnibus package and as such we will be controlling it using the omnibus_updater cookbook. The versions chef-client are currently managed via an environment override.

override_attributes(
  :omnibus_updater => {
    :version => '12.5.1'
  }
)

Troubleshoot chef weirdness

Some times you need to understand why a knife command fails with ruby errors. The best way to figure out what is going on is to enable debugging output for the knife commnand:

bundle exec knife user -VV show _username_

This will dump a lot of output, and in case of a ruby exception it will also print the full trace.

Another interesting step to run when troubleshooting is checking what commands were sent to chef, to do so just grep nginx access log for relevant information

For ex, search accions performed by a given user:

grep '"janedoe"' /var/log/opscode/nginx/access.log

Then look for POST or PUT methods to sample changes.

Problem with not encrypted vault item during chef run

Following error can occur <role>/<vault> is not encrypted with your public key. Contact an administrator of the vault item to encrypt for you! when you are trying to add role (role with vault) with vaults to new node (new node). If node or role does not have them, following error can occur.

In this case you have to execute command - rake add_node_secrets[<new node fqdn>, <role with vault>].