Version v3.7.0 of the documentation is no longer actively maintained. The site that you are currently viewing is an archived snapshot. For up-to-date documentation, see the latest version.
Admin
User
Pigsty requires an OS user with passwordless ssh and sudo on all managed nodes.
Naming Convention
Usually we’ll choose a name such as dba or admin for this purpose,
but avoid using root or postgres:
While possible, using root as admin user is not recommended for security reasons.
DBSU (postgres by default) should NOT be used as admin user.
It will cause unexpected security issues.
If you are using a different dbsu user, avoid using it as admin user as well.
Provide Password
The nopass requirement is optional if you can accept the password prompt for every ssh and sudo command.
You can use the -k|--ask-pass when running playbook to prompt for the ssh password.
And use -K|--ask-become-pass to prompt for the sudo password.
Create Admin User
It’s user/vendor’s responsibility to create & deliver such an admin user during server provisioning stage. But if you don’t have such an admin user, or that user is restricted, you can create one with pigsty itself:
Assuming you have a root or existing admin user on the node, you can create an admin user with pigsty itself.
It will leverage the existing admin to create a new admin user.
It will create a dedicated dba (uid=88) user described by the following parameters,
with sudo / ssh properly configured.
| Name | Description | Default |
|---|---|---|
node_admin_enabled |
enable node admin user | true |
node_admin_uid |
uid of node admin user | 88 |
node_admin_username |
name of node admin user | dba |
Sudo Privileges
All the admin user should have passwordless sudo privileges on all managed nodes.
In case you want to configure an admin user with passwordless sudo privileges from scratch:
To manually allow a user to execute sudo commands without password:
Create a sudoers file for your admin user (assume vagrant, replace with your name choice):
Assume your admin user name choice is dba, then /etc/sudoers.d/dba content would be
Ansible relies on sudo to execute commands with root privileges on managed nodes.
So on environments where sudo is not available (like inside a slim container), you may have to install sudo first.
SSH
Your current user should have nopass ssh access to all managed nodes as corresponding admin user.
Your current user can be the admin user itself, but not required as long as you can ssh as the admin user.
SSH configuration is Linux 101, but we will cover the basics here in case you are not familiar with it:
Generate SSH Key
Generate an SSH key pair if you don’t have one
Pigsty will do that for you if you don’t have a key pair, during the bootstrap stage.
Copy SSH Key
You’ll need to distribute your generated public key remote (and local) servers, and put
it into the ~/.ssh/authorized_keys file of the admin user on all nodes.
The ssh-copy-id util can be used.
Copy the public key to all managed nodes, ssh-copy-id or add to ~/.ssh/authorized_keys manually.
You can use sshpass tool to pass the password directly without prompting, but it’s dangerous:
Using Alias
When direct ssh access is not available (due to jumpserver, other port, credentials, etc…), consider:
Configure SSH aliases in ~/.ssh/config, and put custom parameters for the alias there.
And reference the alias in the inventory, use ansible_host to specify the real ssh alias.
SSH parameters can be used directly in ansible, Check Ansible Inventory Guide for details.
Check Accessibility
Your should be able to access all managed nodes with nopass ssh via your current user from admin node.
And the remote user (admin user) should have the privilege to run nopass sudo commands.
Run this command on admin node to all managed nodes:
if there’s no password prompt or error raised, nopass ssh/sudo is working as expected.