sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] User/Group Account Management Proposal
- From: "Sergey A. Lipnevich" <sergey AT sourcemage.org>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] User/Group Account Management Proposal
- Date: Mon, 09 Jan 2006 16:40:07 -0500
David Kowis wrote:
tracked and automatically removed. In my own twisted little mind, if they're automatically added then they should be automatically removed when they're no longer in use. For example: I install postgresql, the user postgres is created, I didn't know that this user is created, but nonetheless it's there. After dispelling postgresql, because I decided that mysql is a better venue for the software I'm working on/with, the postgres user remains on the system. What I'm proposing is that the users get tracked somehow. If a spell needs the user it's added, upon compile or resurrect. If the spell has that user and it is dispelled, then the user should also vanish, unless, of course, it's being used by another spell.For development and debugging this might be a good idea (I'm not sure), but in production it's out of the question that existing account is automatically deleted. I believe that no production system would survive even an internal audit if such a functionality is in use. For an account to be deleted, one would have to ensure that, at the minimum, no files are owned by it, and no log ever mention it, and this is already too much to ask from a packaging system.
For your particular problem, maybe having a single "database" account is a better solution. Or, to use the same account for all services (we're talking development and debugging still). So, if account name is externalized from the spell so that an administrator such as yourself can set the account for it to use, this would be a good feature. For testing, you could have said "spells samba, postgresql, mysql, and bind all use account xyz" and then delete account xyz after testing is complete.
Sergey.
-
[SM-Discuss] User/Group Account Management Proposal,
David Kowis, 01/09/2006
-
Re: [SM-Discuss] User/Group Account Management Proposal,
Sergey A. Lipnevich, 01/09/2006
- Re: [SM-Discuss] User/Group Account Management Proposal, Jeremy Blosser (emrys), 01/09/2006
- Re: [SM-Discuss] User/Group Account Management Proposal, Eric Sandall, 01/10/2006
-
Re: [SM-Discuss] User/Group Account Management Proposal,
Robert Figura, 01/09/2006
-
Re: [SM-Discuss] User/Group Account Management Proposal,
David Kowis, 01/09/2006
-
Re: [SM-Discuss] User/Group Account Management Proposal,
Robert Figura, 01/09/2006
- Re: [SM-Discuss] User/Group Account Management Proposal, Ladislav Hagara, 01/09/2006
- Re: [SM-Discuss] User/Group Account Management Proposal, Eric Sandall, 01/10/2006
-
Re: [SM-Discuss] User/Group Account Management Proposal,
Robert Figura, 01/09/2006
-
Re: [SM-Discuss] User/Group Account Management Proposal,
David Kowis, 01/09/2006
- Re: [SM-Discuss] User/Group Account Management Proposal, Robert Figura, 01/09/2006
-
Re: [SM-Discuss] User/Group Account Management Proposal,
David Kowis, 01/09/2006
- Re: [SM-Discuss] User/Group Account Management Proposal, Eric Sandall, 01/10/2006
-
Re: [SM-Discuss] User/Group Account Management Proposal,
Sergey A. Lipnevich, 01/09/2006
Archive powered by MHonArc 2.6.24.