Hot answers tagged

3

First: you need to indent password: in your playbook, because you want it to be a variable: vars: password: hashed_password If it's not indented then Ansible considers it a play parameter and throws an error because password is not. Second: unless you are setting the password for a user on OSX, you need to provide a hashed value of a password. Follow ...


3

This isn't something you can really control without extremely intrusive testing. You could conceivably attempt to log in as a user with every string you find in their home directory (and sanction the user if you're ever successful), but that's far from reasonable or feasible. You could, though, if this is for secure shell connections, disable password ...


2

Yes, they can. $ id foo uid=1002(foo) gid=1002(foo) groups=1002(foo) $ id bar uid=1003(bar) gid=1003(bar) groups=1003(bar) Changing the primary group of user foo to bar which is the primary group for user bar: $ sudo usermod -g bar foo Now: $ id foo uid=1002(foo) gid=1003(bar) groups=1003(bar) $ id bar uid=1003(bar) gid=1003(bar) groups=1003(bar) ...


2

If you are neither God nor the Pope, you're not infallible, so prone to make mistakes. ;-) Therefore I would create 2 users: A user that can read everything but not change anything: adduser NormalUserName An "Admin" user that needs the sudo command to change anything. adduser AdminUserName adduser AdminUserName adm adduser AdminUserName cdrom adduser ...


1

Yes, it's always a very good idea to have an unprivileged account on the system to use when you do not need admin privileges. On systems with X Window (e.g. KDE, GNOME) this is practically mandatory. If you have console-only access it is recommended anyway to have it -- even if you're working all the time as admin. In fact, you should block remote ssh ...


1

I don't have sufficient rep to comment on Legate's answer, but I wanted to share that this answer helped us with another use case: 1.) account in question is a local service account running an application, not an end user account. 2.) end users ssh in as themselves, and sudo /bin/su <user> to become user and administer application due to an audit ...


1

As written, you can't meet your requirements. The user is going to have to be able to read some files (the shell, ls, etc). However, it seems to me you are massively overcomplicating this. If all you want them to do is to be able to review the directory structure, just give them a dump of ls -lR.


1

The only way to accomplish this without resorting to ACLs is, Permissions set to 750 and your username being a member of every other user's primary group. For instance, lets say you have these users: me user1 otheruser /home will look something like this: drwxr-x--- 2 me me 4096 Mar 3 12:14 me drwxr-x--- 24 user1 user1 4096 Apr ...


1

From the perspective of the user, he has a primary group and 0 or more secondary groups. From the perspective of the group, it has 0 or more members. A group that is the primary group for one or more users can be both a secondary or primary group for other users.



Only top voted, non community-wiki answers of a minimum length are eligible