Ticket #555 (new enhancement)

Opened 11 years ago

Last modified 8 years ago

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:1 Changed 10 years ago by geofft

Possibly also cluster-athinfod-config and cluster-cups-config and friends.

comment:2 Changed 10 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 9 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 8 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 8 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 8 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.

Note: See TracTickets for help on using tickets.