Managing Chef

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:

SSH into the Chef server

ssh cinc-01-inf-ops.c.gitlab-ops.internal

Create the user:
Terminal window
```
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
copy the private key generated by Chef for this user, which needs to be shared with the user

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:

Add the user to the admin group::
Terminal window
```
knife group add user USERNAME admins
```
Check that the user is in the admin group:
Terminal window
```
knife group show admins
```

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

Remove the default key:

sudo -i chef-server-ctl delete-user-key _username_ default

Create a new default key:

sudo -i chef-server-ctl add-user-key _username_ --key-name default

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

To remove a Chef key, 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.
add the user databag:
Terminal window
```
knife data bag from file users keysersoze.json
```
The lack of path before the JSON file is intended. If the command is successful it will output a message like this: Updated data_bag_item[users::keysersoze]

create the user on staging:

knife ssh -aipaddress 'roles:gitlab-staging-base' 'sudo chef-client'

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 example, search actions 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 the command:

rake add_node_secrets[<new node fqdn>, <role with vault>]