Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] create_account & create_group placement

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: Eric Sandall <eric AT sandall.us>
  • Cc: SM Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] create_account & create_group placement
  • Date: Tue, 9 Aug 2005 12:06:26 -0700

On Tue, Aug 09, 2005 at 11:12:01AM -0700, Eric Sandall wrote:
> On Tue, 9 Aug 2005, Sergey A. Lipnevich wrote:
> > I agree with this. However, the suggestion was to improve the casting
> > process, not to store complete account info in spells. Mapping between
> > accounts and number-ids can be kept centrally, but the instruction to
> > create a specific account/group may be part of the spell in a systematic
> > way. In comparison with init scripts, central ID map and installation
> > routine would be similar to smgl_init code included in every script, but
> > having some kind of pointer to create an account in a spell would be
> > equal to presence of init.d/<script> and init.d/<script>.conf files.
>
> One of the points of moving it out of Sorcery was so the Grimoire Team
> could update the IDs without a new Sorcery release as well as modify
> the account setup, again, without modifying Sorcery.
>
> Creating a specific account/group is already there in a systematic
> method: use `create_account` where you want the accounts created. If
> you're wanting the account creation to always happen in the same place
> then we just need to write down that `create_account` should be called
> in file <blargh> if it's going to be called at all.

I think the disagreement isn't over what to call the use of a function
versus a variable in DETAILS. I think it's between whether or not
account creation is common enough to pollute the DETAILS namespace which
would require sorcery modification. Init scripts are about as common as
user creation, I think -- the point I think the sorcery team would make
is that the less that has to be parsed in sorcery itself the better.
Variables have to be explicitly checked -- functions don't. In a
general movement toward modularity, the init script handling might be
moved out into grimoire functions too -- I think that's one design goal
the sorcery team is trying to do. For these two reasons, I suspect
without a design realignment, we would want to keep as much as possible
out of DETAILS. On the other hand, the point of DETAILS is to include
as much "basic handling" as to make the vast majority of programs
installable without any helpers. This is why downloading is handled in
DETAILS and spell metainformation goes in it, so I'm not sure what the
sorcery team would want.

Personally, I think account creation could be considered "a dependency",
and we might want to have depends_account "user" [ "group" ] and
depends_group "group". This might allow user account creation and
deletion to be handled by the dependency resolution system where we can
integrate it into dispel's fancy understanding of dependencies -- or we
can create user spells that create the account on install and delete it
on dispel, say smgl-user-named, smgl-usergroup-nobody-nogroup provides
SMGL-USER-NOBODY + SMGL-GROUP-NOGROUP, which might involve no changes in
sorcery itself.

Another thing we can do is add support to sorcery for arbitrary code
dependencies -- to support "users" "usergroups" "groups"
"kernelmodules", etc, and call them instead of spells, "potions", that
we can add abstractly to the grimoire so as not to have to support them
separately within sorcery.

Just some ideas ... :)

Seth

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454 E082 99F0 69DC FDCE E733

Attachment: pgpJeRuqM6KkL.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page