[Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set

[Martin Nagy]

On Wed, 2009-08-26 at 09:29 -0400, Rob Crittenden wrote:
> Martin Nagy wrote:
> > On Tue, 2009-08-25 at 16:39 -0400, Rob Crittenden wrote:
> >> This adds 2 new options to the installer so the user can select the 
> >> numeric starting point for uidnumbers and gidnumbers.
> >>
> >> This also adds a new option to the template system, eval(). You can have 
> >> the python interpreter evaluate a statement and include the result in 
> >> the template output.
> >>
> >> rob
> > 
> > So, first I see this:
> >> -uidNumber: 999
> >> -gidNumber: 1001
> >> +uidNumber: $UIDSTART
> >> +gidNumber: $GIDSTART
> > 
> > And then later I see this:
> >> -dnaNextValue: 1100
> >> +dnaNextValue: eval($UIDSTART+1)
> 
> Right, $UIDSTART is the uid for the admin user.
> 
> > [snip]
> >> -dnaNextValue: 1100
> >> +dnaNextValue: eval($GIDSTART+3)
> 
> $GIDSTART = admins group
> $GIDSTART+1 = ipauserse group
> $GIDSTART+2 = editors group
> 
> So the next available gid is $GIDSTART+3. Now we could leave it as 
> $GIDSTART in the dna config and it would do the right thing at runtime 
> if that would be less confusing.
> 
> > 
> > This seems to be inconsistent, is this intentional? More inconsistencies
> > I can see are in the command line option parser where you use 1100 as
> > default for both UIDSTART and GIDSTART. In the man page you state the
> > default is 1000 for both.
> 
> Yeah, that is a goof. It should be 1000.
> 
> > For the evaluation code, I feel it is a tad more complex than it has to
> > be. Also, the pattern seems to be too greedy. I'd suggest that you use
> > the sub() function instead, here's an example:
> > 
> >>>> str = "Something, something, something, eval(foo). Something,
> > something, something, eval(bar)."
> >>>> foo = "dark side"
> >>>> bar = "complete"
> >>>> pattern = re.compile('(eval\s*\(([^)]*)\))')
> >>>> pattern.sub(lambda x: eval(x.group(2)), str)
> > 'Something, something, something, dark side. Something, something,
> > something, complete.'
> > 
> > This also allows eval() to work more times on one line (also notice the
> > [^)]* which makes sure we don't accept something like "eval(foo) bar)".
> > I'm also of the opinion that we do abort the installation if the eval()
> > fails, because that would be a clear bug. If we keep it quiet we might
> > see a more cryptic error instead.
> 
> I see what you are getting at but your code doesn't work. It doesn't 
> actually evaluate the lines (I specifically want to do math). I should 
> also note that the re module doesn't count parenthesis so it will almost 
> always not do the right thing with nested parens, this is why I do it 
> line-by-line.

Ah, sorry, had a bug in there. The sub function should have been called
like this:
>>> pattern.sub(lambda x: str(eval(x.group(2))), string)
and the math will work (you have to use a variable with a different name
than I used before). I forgot to wrap the eval() statement into str().
Since you mentioned the paren counting, I also realized that a better
pattern would be '(eval\s*\(([^()]*)\))'. But this still creates a
problem, if you use "eval(foo + (2 * 4))" then the code will try to
evaluate "foo + ". This is really a messy business. I'm not sure how to
solve this simply without the use of a parser. But still, your code
would be IMO even more dangerous.

> 
> Sure, we can quit the install if you'd prefer.
> 
> rob

Martin