Modify ↓
Ticket #919 (closed enhancement: fixed)
Account.py: Outdated/lacking documentation and other problems
Reported by: | m4z <[email protected]…> | Owned by: | desai |
---|---|---|---|
Priority: | minor | Milestone: | Bcfg2 1.2.0 Release |
Component: | bcfg2-doc | Version: | 1.0 |
Keywords: | Cc: |
Description
This is about 1.0.1 (rev5075), but trunk only differs in terms of comment characters (afaict).
1.) I tried to switch on the Account plugin today, but it didn't like me:
chaos:~ # bcfg2-server -dv Failed to load repos: /var/lib/bcfg2/Account, /var/lib/bcfg2/Account/ssh Failed to instantiate plugin Account Loading experimental plugin(s): Packages NOTE: Interfaces subject to change service available at https://chaos:6789 serving bcfg2-server at https://chaos:6789 serve_forever() [start] Handled 152 events in 0.419s
After creating the Account directory:
chaos:~ # bcfg2-server -dv Loading experimental plugin(s): Packages NOTE: Interfaces subject to change service available at https://chaos:6789 serving bcfg2-server at https://chaos:6789 serve_forever() [start] Failed to read file /var/lib/bcfg2/Account/ssh Handled 156 events in 0.134s
So, I created the ssh subdirectory. Only later did I find out that the "ssh" part is simply a misleading error message (and that directory neither does need to exist nor help in getting rid of the error):
except: self.logger.error("Failed to load repos: %s, %s" % \ (self.data, "%s/ssh" % (self.data))) ^^^^ ?!? raise Bcfg2.Server.Plugin.PluginInitError
2.) The (old and new) docs mention "rootlist", this should be "rootlike".
3.) A lot of other info (and example code) is missing. This is what I learned from the code (please use it as a basis for documentation enhancements if it is any good; it might be completely wrong):
Files below Account/: * <username>.key: Format: The SSH public key for user <username>. If the user is in the "rootlike" or "superusers" group, these keys will be appended to /root/.ssh/authorized_keys. * useraccess: Format: "user:hostname" on each line. Describes who may login where (via PAMs /etc/security/limits.conf). Everybody else will be denied access.(?) Example: If Alice should be able to access host "foo", Bob should access "foo" and "bar": alice:foo.example.com bob:foo.example.com bob:bar.example.com * rootlike: Format: "user:hostname" on each line. Describes who will be allowed root access where. The user may login via public key and use sudo. Example: If Chris should be root only on host "foo": chris:foo.example.com * superusers: Format: usernames, separated by spaces or newlines. (Any whitespace that makes pythons split() happy.) Describes who will be allowed root access on all hosts. The user may login via public key and use sudo. Example: Daniel, Eve and Faith are global admins: daniel eve faith * static.passwd, static.group: Format: Lines from /etc/passwd or /etc/group These entries are appended to the passwd and group files (in addition to the auto-generated entries from "useraccess", "rootlike" and "superusers" above) without doing anything else. * dyn.passwd, dyn.group Format: Lines from /etc/passwd or /etc/group Similar to "static.*" above, but for entries that are managed "on the network" (yp, LDAP, ...), so it is most likely periodically (re)filled. * static.limits.conf: Format: Lines from /etc/security/limit.conf These limits will be appended to limits.conf (in addition to the auto-generated entries from "useraccess", "rootlike" and "superusers" above). * static.sudoers: Format: Lines from /etc/sudoers These lines will be appended to to sudoers file (in addition to the auto-generated entries from "useraccess", "rootlike" and "superusers" above).
Attachments
Change History
Note: See
TracTickets for help on using
tickets.
Added in 101383e1cd9dd6e4d4f3ba8064de3a2ca1130835. Thanks for the updates!