Coder Social home page Coder Social logo

puppetlabs-accounts's Introduction

accounts

Table of Contents

  1. Description
  2. Setup - The basics of getting started with accounts
  3. Usage - Configuration options and additional functionality
  4. Reference - An under-the-hood peek at what the module is doing and how * Data Types
  5. Limitations - OS compatibility, etc.
  6. License
  7. Development - Guide for contributing to the module

Description

The accounts module manages resources related to login and service accounts.

This module works on many UNIX/Linux operating systems. It does not support configuring accounts on Microsoft Windows platforms.

Setup

Beginning with accounts

Declare the accounts::user defined type for each local user you want to manage:

node default {
  accounts::user { 'dan': }
  accounts::user { 'morgan': }
}

The above example creates accounts, home directories, and groups for dan and morgan in the default node group.

Usage

Declare user accounts

accounts::user { 'bob':
  uid      => '4001',
  gid      => '4001',
  group    => 'staff',
  shell    => '/bin/bash',
  password => '!!',
  locked   => false,
}

Customize the home directory

A simple bashrc and bash_profile rc file is managed by Puppet for each account. These rc files add some simple aliases, update the prompt, add ~/bin to the path, and source the following files (which are not managed by this module) in the following order:

  1. /etc/bashrc
  2. /etc/bashrc.puppet
  3. ~/.bashrc.custom

Account holders can customize their shells by managing their bashrc.custom files. In addition, the system administrator can make profile changes that affect all accounts with a bash shell by managing the '/etc/bashrc.puppet' file.

To install an email foward, configure the .forward file by using the forward_content or forward_source parameters.

Lock accounts

Lock accounts by setting the locked parameter of an account to true.

For example:

accounts::user { 'villain':
  comment => 'Bad Person',
  locked  => true
}

The accounts module sets the account to an invalid shell appropriate for the system Puppet is managing and displays the following message if a user tries to access the account:

$ ssh villain@centos56
This account is currently not available.
Connection to 172.16.214.129 closed.

Manage SSH keys

Manage SSH keys with the sshkeys attribute of the accounts::user defined type. This parameter accepts an array of public key contents as strings.

Example:

accounts::user { 'jeff':
  comment => 'Jeff McCune',
  groups  => [
    'admin',
    'sudonopw',
  ],
  uid     => '1112',
  gid     => '1112',
  sshkeys => [
    'ssh-rsa AAAAB3Nza...== [email protected]',
    'ssh-dss AAAAB3Nza...== [email protected]',
  ],
}

The module supports placing sshkeys in a custom location. If you specify a value for the sshkey_custom_path attribute of the accounts::user defined type, the module will place the keys in the specified file. The module will only manage the specified file and not the full path. If you set purge_sshkeys to true, and you have also set a custom path, it will only purge the ssh keys in the custom path.

Example:

accounts::user { 'gerrard':
  sshkey_custom_path => '/var/lib/ssh/gerrard/authorized_keys',
  sshkey_group       => 'root',
  sshkey_owner       => 'root',
  shell              => '/bin/zsh',
  comment            => 'Gerrard Geldenhuis',
  groups             => [
    'engineering',
    'automation',
  ],
  uid                => '1117',
  gid                => '1117',
  sshkeys            => [
    'ssh-rsa AAAAB9Aza...== [email protected]',
    'ssh-dss AAAAB9Aza...== [email protected]',
  ],
  password           => '!!',
}

Setting sshkey_custom_path is typically associated with setting AuthorizedKeysFile /var/lib/ssh/%u/authorized_keys in your sshd config file.

Data in Hiera

The accounts module supports storing all account data in Hiera.

Example:

accounts::group_defaults:
  system: true
accounts::group_list:
  admins: {}
  users:  {}
accounts::user_defaults:
  groups: [ 'users' ]
  managehome: true
  system:     false
accounts::user_list:
  admin:
    groups: ['admins', 'users']
  joe:
    sshkeys:
      - &joe_sshkey 'ssh-rsa ... [email protected]'
  sally:
    sshkeys:
      - &sally_sshkey 'ssh-rsa ... [email protected]'
  dba:
    sshkeys:
      - *joe_sshkey
      - *sally_sshkey
    system: true
include ::accounts

Reference

See REFERENCE.md

Data types

Accounts::Group::Hash

A hash of group data suitable for passing as the second parameter to ensure_resources.

Accounts::Group::Provider

The allowed values for the provider attribute. Currently, this is:

  • aix
  • directoryservice
  • groupadd
  • ldap
  • pw
  • windows_adsi

Accounts::Group::Resource

A struct of group attributes suitable for passing as the third parameter to ensure_resource.

Accounts::User::Expiry

Allows either 'absent' or a YYY-MM-DD datestring.

Accounts::User::Hash

A hash of user data suitable for passing as the second parameter to ensure_resources.

Accounts::User::Iterations

The iterations attribute allows any positive integer, optionally expressed as a string.

Accounts::User::Name

Allows strings up to 32 characters long that begin with a lower case letter or underscore, followed by lower case letters, digits, underscores, or dashes, and optionally ending in a dollar sign. See useradd(8)

Accounts::User::PasswordMaxAge

Maximum number of days a password may be used before it must be changed. Allows any integer from -1 to 99999. See user resource.

Accounts::User::Resource

A struct of user attributes suitable for passing as the third parameter to ensure_resource.

Accounts::User::Uid

Allows any integer from 0 to 4294967295 (232 - 1), optionally expressed as a string.

Limitations

For an extensive list of supported operating systems, see metadata.json

Changes from pe_accounts

The accounts module is designed to take the place of the pe_accounts module that shipped with PE versions 2015.2 and earlier. Some of the changes include the removal of the base class, improving the validation, and allowing more flexibility regarding which files should or should not be managed in a user's home directory.

For example, the .bashrc and .bash_profile files are not managed by default but allow custom content to be passed in using the bashrc_content and bash_profile_content parameters. The content for these two files as managed by pe_accounts can continue to be used by passing bashrc_content => file('accounts/shell/bashrc') and bash_profile_content => file('accounts/shell/bash_profile') to the accounts::user defined type.

License

This codebase is licensed under the Apache2.0 licensing, however due to the nature of the codebase the open source dependencies may also use a combination of AGPL, BSD-2, BSD-3, GPL2.0, LGPL, MIT and MPL Licensing.

Development

Acceptance tests for this module leverage puppet_litmus. To run the acceptance tests follow the instructions here. You can also find a tutorial and walkthrough of using Litmus and the PDK on YouTube.

If you run into an issue with this module, or if you would like to request a feature, please create an issue. Every Tuesday the Puppet Content and Tooling team has office hours in the Puppet Community Slack for about an hour, starting at 1400 (GMT+1).

If you have problems getting this module up and running, please contact Support.

If you submit a change to this module, be sure to regenerate the reference documentation as follows:

puppet strings generate --format markdown --out REFERENCE.md

puppetlabs-accounts's People

Contributors

arjenz avatar bastelfreak avatar bmjen avatar chelnak avatar clairecadman avatar coreycook8 avatar daianamezdrea avatar david22swan avatar davids avatar eimlav avatar eputnam avatar ggeldenhuis avatar gspatton avatar haus avatar hunner avatar jonnytdevops avatar jordanbreen28 avatar lionce avatar lukasaud avatar malikparvez avatar mdklapwijk avatar mentat avatar michaeltlombardi avatar pmcmaw avatar rajat-puppet avatar ramesh7 avatar sanfrancrisko avatar sheenaajay avatar tphoney avatar wpowell-ossg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

puppetlabs-accounts's Issues

$Accounts::User::PasswordMaxAge fails when value is set to zero

Describe the Bug

Setting Accounts::User::PasswordMaxAge variable to zero results in a fail.

Expected Behavior

User password max age should be set to zero (or in some cases, the password check is disabled)

The documentation states that the minimum value is zero. I've not found the check/validation for password_max_age where it fails when the value is zero.

Steps to Reproduce

Hiera data:

user:
  test:
    ensure: present
    password_max_age: 0

Errors with the following:
Evaluation Error: Error while evaluating a Resource Statement, Accounts::User[test]: parameter 'password_max_age' expects an Accounts::User::PasswordMaxAge = Integer[1, 99999] value, got Integer[0, 0]

Environment

  • Version 8.1.0
  • Platform RHEL7, RHEL8

#466

managehome option not fully implemented.

It appears that managehome = false does not do anything other then tell the module to not manage .ssh dirs.

I would expect this to tell it to ignore all defaults/settings for managed home directories. Is this something that was planned this way or not fully implemented?

thanks

Remove "managehome" hard coded value when deleting a user

Use Case

When deleting a user in puppet, this workaround causes this line to never resolve to true, preventing the -r flag from being added to the userdel cmd. While purge_user_home exists to delete the user's home directory, this leaves the user's mail spool in the /var/spool/mail directory which would otherwise be deleted if you could set managehome to true.

Describe the Solution You Would Like

Being that the referenced issue is resolved, I would like to have the option to set managehome to true so that the users mail spool is not left hanging.

Describe Alternatives You've Considered

I was able to achieve the same result but setting sshkey_custom_path equal to the mail spool path but this is not a long term solution.

parameter 'user_list' entry '<username>' entry 'password' expects a String value, got Sensitive[String]

Describe the Bug

When using a sensitive string for the password for a user in accounts::user_list it gives the following error:
parameter 'user_list' entry '<username>' entry 'password' expects a String value, got Sensitive[String]

Expected Behavior

Set the password for whatever is in the sensitive string.
This should work because the password entry accepts sensitive strings as the documentation says this.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Use a sensitive string as password with accounts::user_list

Environment

  • Accounts module version: 8.1.0
  • Puppetserver version: 8.2.1
  • Platform: Ubuntu 22.04 LTS
  • tragiccode-azure_key_vault v3.3.0

Additional Context

I am trying to get a secret from Azure Key Vault and set it as the users password.
I am using the tragiccode-azure_key_vault module to get the secret from Azure Key Vault.
The Azure Key Vault module is working for other (custom) Puppet modules.

In the node Hiera yaml for the node I do a lookup on the password as follows:

accounts::user_list:
  '<username>':
      ensure: 'present'
      password: "%{alias('<username>-unix-password-hash')}"

I am also converting it to a sensitive string because otherwise I get "Redacted" as my password (in /etc/shadow). I do this with the following in my node Hiera yaml:

lookup_options:
  '^.*-unix-password-hash':
    convert_to: 'Sensitive'

Is accounts::group broken?

I'm still learning my way around puppet so forgive me if this is not really an issue but is the accounts::group class mentioned in the example files broken because it is not defined anywhere?

Please tell me this is the case because I have been banging my head against a wall trying to get this working!

๐Ÿ˜ข

$home/.vim directory conflict

If $managehome==true, then module does much helpful things like manges .bashrc and ssh keys. It's really helpful.
But also it creates $home/.vim directory, and this resource declaration conflicts with modules? that manages vim. For example: 'ghoneycutt-vim'
As far as I can see, your module doesn't manages any vim configurations, so maybe you can remove $home/.vim declaration, or add another hiera variable (managevim for example) to disable this? I would be really appreciated.

Duplicate Key in multi-user causes Duplicate Declaration

Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: Accounts::Manage_keys[ssh-rsa FOOBAR user1@computer] is already declared in file /tmp/modules/accounts/manifests/home_dir.pp:80; cannot redeclare at /tmp/modules/accounts/manifests/home_dir.pp:80 at /tmp/modules/accounts/manifests/home_dir.pp:80:7  at /tmp/modules/accounts/manifests/user.pp:111 on node macbrookpro.local

Accounts::Manage_keys needs to use the username as part of the evaluation to avoid duplication errors like this

group {'admins':}
group {'users':}
@accounts::user {
  'user1':
    ensure  => present,
    comment => 'User 1',
    shell   => '/bin/bash',
    groups  => ['admins'],
    sshkeys => [
      'ssh-rsa FOOBAR user1@computer',
    ],
    tag     => 'admins',
}
@accounts::user {
  'user2':
    ensure  => present,
    comment => 'User 2',
    shell   => '/bin/bash',
    groups  => ['users'],
    sshkeys => [
      'ssh-rsa FOOBAR user1@computer',
      'ssh-rsa HELLOWORLD user2@computer',
    ],
    tag     => 'users',
}

Group['admins'] -> Accounts::User<| tag == 'admins' |>
Group['users'] -> Accounts::User<| tag == 'users' |>

Accounts::User<| tag == 'admins' |>
Accounts::User<| tag == 'users' |>

Users' $HOME/.bash_profile file does not identify itself as "Managed by Puppet"

Use Case

The ~/.bash_profile file does not identify itself as "Managed by Puppet."

Describe the Solution You Would Like

The ~/.bash_profile should have comments inside the file that indicate the file is managed by Puppet.

Additional Context

Shouldn't every file managed by puppet make it clear (usually at the top) that it's being managed by Puppet configuration?

#426

Forced command in ssh key with absolute path does not work

Describe the Bug

Force command with full path does not work in ssh key.

Expected Behavior

When I would like to add a forced command with full path to the script, I got back Unmatched double quote raised exception. Please look example below.

Steps to Reproduce

Steps to reproduce the behavior:

  accounts::user { 'testuser':
    ensure      => present,
    group       => 'nogroup',
    shell       => '/bin/bash',
    managehome  => true,
    home_mode   => '0700',
    sshkeys     => [
      'no-port-forwarding,no-x11-forwarding,no-agent-forwarding,command="/usr/local/bin/test-script.sh" ssh-rsa AAAAB3NzaC1yc2EAAAADA........u7wbFJn testuser@localhost'
    ],
  }

Environment

  • Puppet Agent version v7.20.0
  • puppetlabs-accounts version v7.3.0
  • Platform Ubuntu 22.04

Additional Context

If I skip per (/) sign from value of command, there is no error, but full absolute path is mandatory for forced command.

The key '["name"]' is declared more than once

Describe the Bug

After updating puppet from 8.4.0 to 8.5.0 I get
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: The key '["name"]' is declared more than once (file: /etc/puppetlabs/code/environments/production/modules/accounts/types/user/resource.pp

locked => true not working?

Describe the Bug

Setting parameter locked to true does not change default shell for user

Expected Behavior

According to the documentation, setting locked => true should set the user shell to something invalid, it does not..

Steps to Reproduce

Create a user with the Accounts module
Set the user to locked
Verify shell set in /etc/passwd

Environment

Puppet: 6.28.0
Accounts: 7.2.0

Additional Context

Initially i wanted to remove the user accounts, but i could not find a way to do this (no ensure => absent parameter), is this even possible?
Then i went with locking the accounts, but this does not change the shell, and thus does nothing as far as i can tell?

Added random strings in key comments

Describe the Bug

It generates random strings in the key comment section, ie below - luigi_ssh-rsa_[email protected]_6bbd0f3daa6a944dcf5be78dbe171d1c
cat /home/xunil/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCU6RPX1CY+WB2wU6pWU6Nkb7HTE6qaFymT31o/m1F6KUkgU9xxbTWEhqbzU1t1m5QaEJT6YYDm9UjFtP19Y6q6phkWGH+8HJtOeJ8nEezsXM0nl3erSj8Tnyhq7fc8aAm+GYdSdtq+SnRojFeAeGAGS3aE6JExYsh6wjZ0uBEEzq88nm6vgIxm00m7htUSdkHHL+Z+VMMsX4xpDLH/zCaRVesOuSO1Dd919ttLyZffrzF3P98LXa7sTS5p44I9k2YyxJ3lcBxj4cuq0OmtNGnd7bBH6gzPrIrZC7d/TsNHNyc4F7LfkiyFUxXr5khphto//XLsw/gL1rNj1tB42qxtbcouu7VbMNQTgj7QFUtQ1DKuR7bSB1s3iJ54Xo4dcLJyQna+bXtt/CghcTf/iHWfWNvCZkzh06JP5DY6HxVJQP2GueRnUxs7zlqDRlAbhW02RyypEtpnzUFdmwItiLvfkzrJtBbjao8/nJO+EVJUPB2vIJjqDbYxJMEgJI/dMks= [email protected]_6bbd0f3daa6a944dcf5be78dbe171d1c

Expected Behavior

It should have a clear ssh key without a random string so easy to make a condition. If rerun the puppet, it keeps generating a new one.
type key_fingerprint key_comment
ie 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCU6RPX1CY+WB2wU6pWU6Nkb7HTE6qaFymT31o/m1F6KUkgU9xxbTWEhqbzU1t1m5QaEJT6YYDm9UjFtP19Y6q6phkWGH+8HJtOeJ8nEezsXM0nl3erSj8Tnyhq7fc8aAm+GYdSdtq+SnRojFeAeGAGS3aE6JExYsh6wjZ0uBEEzq88nm6vgIxm00m7htUSdkHHL+Z+VMMsX4xpDLH/zCaRVesOuSO1Dd919ttLyZffrzF3P98LXa7sTS5p44I9k2YyxJ3lcBxj4cuq0OmtNGnd7bBH6gzPrIrZC7d/TsNHNyc4F7LfkiyFUxXr5khphto//XLsw/gL1rNj1tB42qxtbcouu7VbMNQTgj7QFUtQ1DKuR7bSB1s3iJ54Xo4dcLJyQna+bXtt/CghcTf/iHWfWNvCZkzh06JP5DY6HxVJQP2GueRnUxs7zlqDRlAbhW02RyypEtpnzUFdmwItiLvfkzrJtBbjao8/nJO+EVJUPB2vIJjqDbYxJMEgJI/dMks= [email protected]'

Steps to Reproduce

Steps to reproduce the behavior:

  1. In the manifest,
  lookup('users', Hash, 'hash').each | String $username, Hash $attrs | {
    accounts::user { $username:
      * => $attrs,
    }
  }
  1. In the heira data.
users:
  'luigi':
    sshkeys:
      - 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCU6RPX1CY+WB2wU6pWU6Nkb7HTE6qaFymT31o/m1F6KUkgU9xxbTWEhqbzU1t1m5QaEJT6YYDm9UjFtP19Y6q6phkWGH+8HJtOeJ8nEezsXM0nl3erSj8Tnyhq7fc8aAm+GYdSdtq+SnRojFeAeGAGS3aE6JExYsh6wjZ0uBEEzq88nm6vgIxm00m7htUSdkHHL+Z+VMMsX4xpDLH/zCaRVesOuSO1Dd919ttLyZffrzF3P98LXa7sTS5p44I9k2YyxJ3lcBxj4cuq0OmtNGnd7bBH6gzPrIrZC7d/TsNHNyc4F7LfkiyFUxXr5khphto//XLsw/gL1rNj1tB42qxtbcouu7VbMNQTgj7QFUtQ1DKuR7bSB1s3iJ54Xo4dcLJyQna+bXtt/CghcTf/iHWfWNvCZkzh06JP5DY6HxVJQP2GueRnUxs7zlqDRlAbhW02RyypEtpnzUFdmwItiLvfkzrJtBbjao8/nJO+EVJUPB2vIJjqDbYxJMEgJI/dMks= [email protected]'
      - 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCXXgsjIZYtY1Sk3D961fuW+ht9TeX3NfVfEO7cwxuqnFpZP3xATbLvPbXTRe2xXc3kheTT1id039IBb4/AFSQWaYxkH8dUv6cQxcZvbcQQ5aljqI8UZQdiNCX2Mrq42OViF0RbAKH+ofjCELG/hzdDxj/iYgF10u05bCRN9Z7LhwHMCRL8ODTO91sIu1KdHm67cdGmqoi5bx8yBs1IctWwBoDQqqtnKAtiGFQOSSQln9A5MgBk9bj+Nrh9FlAojoHe5ivC5pYBduROoI+ONoeVwHxBjj3tzN7NkxXNcf28vpQem63QCVHxmRvLHVKUdis0VXkTKyHlHOpRoKu6G+Ev0xdLT+P4KVEqb4o0Cr/5QYmI7V//DUMjWauUZVD0uu3ZKxZP5FJvMpYFBdmRneH9x+c1GWTIFJLMg592kgOpZDUmPuhF9k0vagZsww3aTi7Io4N3E/Vmcst5jXT+S364o9SIjd4W64BFaRmidtc7GatT8ZJV7G1Sro+6Vypfo8M= [email protected]'

Environment

puppet6-release-6.0.0-23.el8.noarch
puppet-agent-6.28.0-1.el8.x86_64
in
Red Hat Enterprise Linux release 8.7 (Ootpa)

Additional Context

Using this module version.
mod 'puppetlabs-accounts', '8.1.0'

The documentation doesn't mention that it generates a random string, or any options to get rid of those strings.

Default Value for $gid

What are your thoughts on making the default value for $gid to be equal to $uid (rather than undef?)

Error: Failed to apply catalog: Resource type 'Ssh_authorized_key' was not found

Describe the Bug

When include class accounts and the operating system is Debian 12 bookworm
I get:
Error: Failed to apply catalog: Resource type 'Ssh_authorized_key' was not found

Expected Behavior

working

Steps to Reproduce

Environment

  • puppetlabs-accounts (v8.1.0)
  • Debian 12.1

Describe the Bug

When include class accounts and the operating system is Debian 12 bookworm
I get:
Error: Failed to apply catalog: Resource type 'Ssh_authorized_key' was not found

Expected Behavior

working

Steps to Reproduce

classes:

  • accounts

accounts::user_defaults:
groups: [ 'users' ]
managehome: true
system: false

accounts::user_list:
slima:
groups: [ 'adm', 'sudo' ]
sshkeys:
- &kamil_sshkey 'ssh-ed25519 key'

Environment

  • puppetlabs-accounts (v8.1.0)
  • Debian 12.1

Additional Context

On Debian 11 working.

Users password created everyrun

Every time the agent runs it executes:

Notice: /Stage[main]/Profiles::Base/Accounts::User[someuser]/User[someuser]/password: created password

Here is my class declaration:

accounts::user { 'ssa': uid => '469', gid => '469', shell => '/bin/bash', managehome => true, home => '/export/home/someuser', password => 'somepassword', locked => false, }

How can I stop this?

Newly added SSH key is not deployed if managehome attribute is set to false

Describe the Bug

Adding another ssh key under a user who already has one, after already having deployed the first one successfully, does not detect the new keys if managehome: false.

Expected Behavior

Each of the keys defined for a user

accounts::user_list:
  admin:
    managehome: false
    sshkeys:
      - &joe_sshkey 'ssh-rsa AAA[...]dn1 comment'
      - &shmoe_sshkey 'ssh-rsa AAA[...]cn2 another comment'

to be deployed to the user's ~/.ssh/authorized_keys regardless of other attributes. Multiple keys deployed successfully.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Paste mod 'puppetlabs-accounts', '7.3.0' and mod 'puppetlabs-stdlib', '8.2.0' into <root_of_project>/Puppetfile
  2. Go to <root_of_project>/data/nodes/server01.yaml
  3. Paste in the following configuration:
---
accounts::user_list:
  admin:
    comment: "42"
    managehome: false
    ignore_password_if_empty: true
    password: ''
    sshkeys:
      - &joe_sshkey 'ssh-rsa AAA[...]dn1 comment'
  1. Go to <root_of_project>/manifests/server01.pp
  2. Ensure it contains include ::accounts
node 'server01' {
  class { 'foo': }                 # use foo module
  include ::accounts
}
  1. Deploy with r10k
  2. Run puppet agent -tv on server01
  3. Observe how joe_sshkey is added to ~/.ssh/authorized_keys
  4. Go back to <root_of_project>/data/nodes/server01.yaml and add a new key under the same user's sshkeys:
- &shmoe_sshkey 'ssh-rsa AAA[...]cn2 another comment'

Final contets of <root_of_project>/data/nodes/server01.yaml:

---
accounts::user_list:
  admin:
    comment: "42"
    managehome: false
    ignore_password_if_empty: true
    password: ''
    sshkeys:
      - &joe_sshkey 'ssh-rsa AAA[...]dn1 comment'
      - &shmoe_sshkey 'ssh-rsa AAA[...]cn2 another comment'
  1. Deploy with r10k
  2. Run puppet agent -tv on server01
  3. Observe that no mention of shmoe_sshkey is made, which leaves it absent.

Environment

  • Puppet version 6.28.0
  • puppetlabs-accounts version 7.3.0
  • puppetlabs-stdlib version 8.2.0

Additional Context

Contents of <root_of_project>/hiera.yaml:

---
version: 5
defaults:
  datadir: data
  data_hash: yaml_data
hierarchy:
  - name: "Per-node data (yaml version)"
    path: "nodes/%{::trusted.certname}.yaml"
  - name: "Per-OS defaults"
    path: "os/%{facts.os.family}.yaml"
  - name: "Other YAML hierarchy levels"
    path: "common.yaml"

Contents of ~/.ssh/authorized_keys on serverf01:

# HEADER: This file was autogenerated at 2022-10-26 16:26:59 +0200
# HEADER: by puppet.  While it can still be managed manually, it
# HEADER: is definitely not recommended.
ssh-rsa AAA[...]dn1 admin_ssh-rsa_comment

The same appears to be the case when we avoid Hiera altogether and define the sshkeys ONLY in <root_of_project>/manifests/server01.pp:

node 'server01' {
  include ::accounts
  class { 'foo': }                 # use foo module
  accounts::user { 'admin':
    comment => 'Testing from pp file',
    managehome => false,
    ignore_password_if_empty => true,
    password => '',
    sshkeys => [
      'ssh-rsa ssh-rsa AAA[...]dn1 comment',
      'ssh-rsa AAA[...]cn2 another comment',
    ],
  }
}

Failure if $create_group is set to false

If $create_group is set to false, puppet run fails with the following error:
Could not find resource 'Group[username]' for relationship on 'User[username]

This is because in Line 123
if $ensure == 'present' { Group[$name] -> User[$name] }

Here even if you have $create_group=false, it will try to establish a relationship between the group and user.

Similarly, line 139
require => [ User[$name], Group[$name] ],

Here the group resource is required even if $create_group=false

User's home directory is changed when $managehome => false and $HOME is in non-standard location

Describe the Bug

Even when managehome => false, the non-root user's home directory will be changed if the user's home directory is in a non-standard location.

Expected Behavior

User's home directory shouldn't be changed when managehome=>false under any circumstances.

Steps to Reproduce

Steps to reproduce the behavior:

1. useradd -m -d /mnt/brian brian
Accounts::User{'brian':
  ensure => present,
  managehome => false,
}
Accounts::User[brian]/User[brian]/home: home changed '/mnt/brian' to '/home/brian' (corrective)

Environment

  • Pppet 7.29.1
  • Red Hat EL 8.8
  • puppetlabs-accounts@main (08c59a4)

Additional Context

I think that the user defined type wrongly assumes that all account home directories will be under /home/${name}. There are some instances where this is not the case, such as the mongod user provide by mogodb-enterprise-server package.

One workaround is to provide the $home => /path/to/real/homedir to the user defined type but this is a bit clunky.

Add support for sk-ssh-ed25519 keys

The ssh_authorized_keys_line_parser function does not yet parse "sk-ssh-ed25519" keys.

Solution

In the file accounts/lib/puppet/functions/accounts_ssh_authorized_keys_line_parser.rb change the following line:
matched = str.match(%r{((sk-ecdsa-|ssh-|ecdsa-)[^\s]+)\s+([^\s]+)\s+(.*)$})
to:
matched = str.match(%r{((sk-ssh-ed25519|sk-ecdsa-|ssh-|ecdsa-)[^\s]+)\s+([^\s]+)\s+(.*)$})

Alternative

Why have this check in the first place? If I want to shoot myself in the foot, let me.

Expiry parameter should support a value of negative one.

Use Case

Expiry can be a date, a number of days since January 01, 1970 or a value of -1 to indicate that the account never expires.

Describe the Solution You Would Like

Accounts::User::Expiry should allow the value of -1.

Additional Context

I'm not sure how to add a negative one to the regex pattern but it should be a simple matter for someone who knows regex.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.