Ticket #555 (new enhancement)
Separation of cluster-login-config and reactivate is silly
Reported by: | broder | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | The Distant Future |
Component: | login chroot | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: |
Description
I am certainly in favor of modularization of packages, but in the case of separating cluster-login-config and reactivate, it just seems silly. It's hard to imagine a real use for either package outside of the cluster environment, and the two are completely inter-tangled with each other.
Case in point: check out this excellent excerpt from /etc/sudoers:
### BEGIN debathena-cluster-login-config ALL !ALL=!ALL %admin ALL=(ALL) ALL ### END debathena-cluster-login-config ### BEGIN debathena-reactivate Defaults lecture_file=/etc/athena/sudo-error, lecture=always Defaults:%admin lecture_file=/etc/athena/sudo-warning, lecture=once ### END debathena-reactivate
I think we should strongly consider just merging the packages and moving on with our lives.
Change History
comment:2 Changed 14 years ago by jdreed
Now that #848 is done, we have the additional option of punting both c-l-c and reactivate entirely and shoving everything into cluster. I would lean slightly in this direction, because: a) the names of c-l-c and reactivate are meaningless; b) they are not even remotely useful anywhere else (by contrast, someone might want to install cluster-athinfod-config on a pseudo-public machine).
comment:3 follow-up: ↓ 5 Changed 13 years ago by geofft
It *would* be useful to separate debathena-reactivate the snapshotting code from our configuration for it (sketching on su and sudo, hooking unconditionally into all logins, etc.), so you could safely install debathena-reactivate on a non-cluster machine and enable it for certain accounts only.
comment:4 Changed 12 years ago by jdreed
I think I'd like to block this on #388. If we fix c-p-d so that deconfiguring a package undoes the diversions, then we can write a new debathena-cluster-config that Conflicts: c-l-c and reactivate, and as a bonus, we can get rid of 3 years of undiversions.
comment:5 in reply to: ↑ 3 Changed 12 years ago by jdreed
Replying to geofft:
It *would* be useful to separate debathena-reactivate the snapshotting code from our configuration for it (sketching on su and sudo, hooking unconditionally into all logins, etc.), so you could safely install debathena-reactivate on a non-cluster machine and enable it for certain accounts only.
I'm not convinced that a) that's a good idea; b) we want to support it; c) there's any reasonable way to "enable it for certain accounts" that doesn't involve if or case.
comment:6 Changed 12 years ago by jdreed
I think the issue here is not that they should be combined, but that they should be more discrete. It really should modify sudoers in only one place. However, I think I want the getty and sshd features to be in a separate package, so that when I'm testing things (which I frequently do on VTs), I don't clobber myself while upgrading. You _cannot_ install c-l-c from a VT.
Possibly also cluster-athinfod-config and cluster-cups-config and friends.