Manage users and groups

[rcrowley]

Generated blueprints should be able to create users and groups based on those present on the system that ran blueprint-create(1).

[rcrowley]

It may make sense, after conversation in IRC with Ian Chilton, to manage SSH authorized keys, too.

[ichilton]

maybe other .dotfiles in users home directories too?

[flores]

I was thinking about contributing this feature request after parsing /etc/passwd, but how should we determine who are legitimate users and who aren't? Should we save their shadow password if that user isn't using keys?

[rcrowley]

@flores, I'm not sure the answer to any of your questions. My first desire is to keep noise low so to that end I'd take almost any excuse to leave a user/group out of the blueprint. Beyond that, I can see arguments for and against managing interactive users, passwords, authorized keys, and other config files.

[wizonesolutions]

I have a use case for this. When applying a Puppet module generated by Blueprint, the lack of users and groups therein causes some of the declarations to fail. I'm adding them in manually for now, but users associated with Apache virtual hosts (users and groups owning the document root directories, the directory itself at least) and ones associated with system services should be captured.

Here's an example:

err: /Stage[main]/Fillpdf-service::Files/File[/etc/authbind/byuid/118]/ensure: change from absent to file failed: Could not set 'file on ensure: Could not find user tomcat6 at /home/vagrant/devops/blueprints-puppet/modules/fillpdf-service/manifests/init.pp:1963

[tels7ar]

My sense as a brand new blueprint user is that some minimal amount of user account management support would be good. In particular, in my infrastructure I usually want to ensure that a handful of key user accounts are installed on every system and have the ability to log in to the box.

Thus for this I would want the accounts to exist, and possibly for ssh keys for those uses to be set up. I don't care about any other user information such as dotfiles.

[rcrowley]

I wonder if a good compromise is to ensure that the users and groups that own the files included in the blueprint exist. That is, Blueprint would make no attempt at comprehensively managing users or groups but would do the bare minimum to ensure its own success. Thoughts?

[wizonesolutions]

Yeah, that'd be fine with me.

Re. SSH keys, one important thing is trusted APT trusted GPG keys. I can paste a sample in another issue if you want.

[silid]

I'd like to see some ability to manage users and groups. For example, if I'd like to add a user and give him admin rights, or revoke a users admin rights, I'd like to be able to deploy that change with blueprint.

[rcrowley]

@wizonesolutions One of the reasons Blueprint places files before installing packages is so that APT and Yum repositories and their GPG public keyrings are present before APT and Yum are invoked. Please do open an issue if this behavior isn't working properly.

[rcrowley]

@silid Across the board, Blueprint punts on the removing and revoking of configuration. For example, it doesn't support removing files or packages. This is both a severe limitation and not a big deal: the majority of Blueprint users deploy to EC2 or similarly flexible provider and prefer to provision new instances rather than reconfigure old ones.

Still, that doesn't mean I don't want to support removing files, packages, and hopefully users and groups, too. I just want to set expectations appropriately: it may be a while.

[winstonford]

Just to clarify, does this mean that blueprint supports users and groups who own files, but does not support removing and revoking users and groups?

[rcrowley]

@winstonford correct, Blueprint is not able to remove and resources (users, groups, files, or packages).

[winstonford]

On origin server I adduser testuser as root, touch testfile and chown testuser testfile. Then I create a blueprint and bootstrap.sh, tar.gz it and scp to destination server and bash bootstrap.sh. Apache is there with correct vhosts.confs, but lastlog shows no testuser. Am I doing something wrong? Is there a way to show users in a blueprint?

[rcrowley]

You're not doing anything wrong. Blueprint just doesn't manage user and group resources at all. It assumes (and you can argue for days whether this is a good assumption) that users and groups come from packages or some other source.

[winstonford]

Got it. Use case is a user who only does rsync. All he has is a cron job in etc and an ssh key. Any recommendations? How do you setup users? I dig the overall philosophy of blueprint. Have never understood the alternative philosophy where machine state is re-recorded in some other language. Creates more work to achieve what in many cases is already done, and invites the errors that come with double entry.

[rcrowley]

We never got to a satisfactory user/group policy when we were working on Blueprint. Blueprint's been on life-support for more than two years.

[winstonford]

Yea, that's what it looks like. I was hopin I might inspire you to breath some life back into it. I can elaborate over a different channel if you're interested.

[rcrowley]

Realistically, no. I think the state-of-the-art in development environments and their relationship with production operations is moving in a different direction. Feel free to email me at r@rcrowley.org if you like, though.