Custom Query (894 matches)

During a client run, after removing an unmanaged entry (with -r), the entry still shows as unmanaged at the end of the run despite the fact that FindExtra? is called after the package removal.

This patch fixes two issues:

• Sudoers file now gets created properly ($user ALL=(ALL) ALL). Ideally this plugin would also create command, alias and host entries, but that would be a bit difficult with the default file backend IMO.
• Sudoers and .ssh/authorized_key generation shouldn't require 'rootlike'. If you want the changes to be global, there's no reason to use that file.

Patch is against 0.9.4.

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).