Find the answer to your Linux question:
Results 1 to 3 of 3
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Question Interest in tool for generating user account rpm?

    I don't think there exists any online tool that takes user account information (passwd, shadow, group) and returns an rpm that can be used to install the user account on any redhat-based system.

    Is there interest? I'm aware that many would not use this because of the requirement to upload passwd/shadow file information to create the package....I'm thinking for many sysadmins, this is an acceptable risk, especially if you use ssh keys instead of account passwords. If there is enough interest, I'm thinking about making a tool available for testing. I will add a function to create a second rpm that will grant sudo privileges. I can say that over the years, I would have really appreciated a tool like this being available. Please provide feedback!

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Hi and welcome

    I have seen user accounts via package management.
    The advantages are consistency and fast deploy on newly installed machines.
    Users in local files are also more "foolproof" and have a lighter footprint compared to e.g. accounts in ldap (although this can also be a viable option.)

    Your tool would need some kind of backend db and management capabilities.
    Simply entering username, uid, pw, private key, etc and outputting a rpm is not enough.
    One would very quickly loose overview: Duplicate usernames, which users are deprecated, etc
    So it might be better, if your tool would be feed from e.g. a ldap query and then output all rpms at once and with a higher rpm package version.

    But in general, I wouldnt use rpms for account management purposes.
    - They are too static. What if the user wants a different env or shell on certain systems? What if (s)he shall be able to escalate to root on e.g. the db machines, but not on the webservers?
    - They are limited to redhat machines. You never know, if e.g. a freebsd machine for firewall purposes or opensolaris for zfs is needed.
    - These rpms are then highly confidential data, as they contain private keys and password hashes.

    What we do -and this is also my recommendation- is to maintain user accounts via a configuration management tool like puppet or chef.
    The accounts are part of hiera or databags in a central, revision controlled repository and then subject to whatever you want puppet/chef to do with them.
    chef/puppet will then make sure, that any account modification, deletion or creation is done on any managed system.
    You must always face the curtain with a bow.

  3. #3
    I am not planning to keep track of each account created using the tool. It will be up to the requestor to increment the version/revision level, as well as keeping UIDs/GIDs consistent. In my experience, 99% of users never change their shell or env anyway. My reason for keeping user account and sudo rpms separate is exactly the situation you posed...where a user does not get root access to all systems.

    The vast majority of linux usage (especially in the cloud) is redhat-based, so that is where I am concentrating.....I am not worried about a multi-distro solution.

    I am aware of the security implications...and I'm assuming that requested accounts won't contain private keys anyway (public keys are fine), and that the system will delete all requested accounts (and uploaded information) within 24 hours, so that nothing is kept on the system longer than that.

    In my experience, there are a lot more companies doing account maintenance by hand than are using puppet/chef/LDAP/AD to manage accounts. All of those software suites are ugly to set up, and ugly to maintain, and if you have less than a certain number of Linux instances, weight of the solution is not worth the time cost of setup and maintenance.

    In short, I'm targeting those who already do this by hand and could use a boost in installing/uninstalling user accounts across their instances.

  4. $spacer_open

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts