OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Re; Possible problem in cleanupO
From: Michael Douglass (mikedougdatafoundry.net)
Date: Wed Oct 25 2000 - 18:56:26 CDT

Heh; sorry to flood you, just wanted to make certain that you understood
where we were coming from. If I have the right file, I've rewritten the
function (almost entirely) to use hash tables (since you've got hash table
code included). The algorithm I'm using is to initialize the items hash
(items should actually be renamed 'addrs') with the address passed into
the function. The recursive loop looks at each address in the 'items'
list and expands any that it hasn't seen (tracked by the 'expanded' hash).
When an item is expanded it is removed from the items hash and it's expanded
version is added to the items hash.

Since we keep track of what addresses we've tried to 'expand', we simply
stop once we have tried to expand all addresses once-and-only-once.

Now to test it. :)

On Wed, Oct 25, 2000 at 07:44:54PM -0400, Wietse Venema said:
> Thanks, you can stop now. The solution is to use a completely
> different algorithm, rather than the current one which appends new
> addresses to the existing address list and that expands each address
> list item in order.
>
> Given:
>
> > > alias -> user1,user2
> > > user1 -> user1,user1remotehost.com
> > > user2 -> user2,user2remotehost.com
>
> > initial: alias
>
> Successive passes would give:
>
> > pass 1: user1, user2
> > pass 2: user1, user1remotehost.com, user2, user2remotehost.com
>
> In order to achieve that:
>
> > pass 3: user1, user1remotehost.com, user2, user2remotehost.com
>
> One would have to remember what names have been expanded already.
>
> That will have to be tomorrow. Meanwhile, I suggest that you list
> self-referential virtuals at the end of your address lists.
>
> Wietse
>
>
> Michael Douglass:
> >
> > The problem here is one of logic. The question is when to terminate
> > the recursion. The recursion should be terminated after a pass where
> > no items have been changed in the list. Using the below definitions,
> > here would be a sample recursive run:
> >
> > initial: alias
> > pass 1: user1, user2
> > pass 2: user1, user1remotehost.com, user2, user2remotehost.com
> > pass 3: user1, user1remotehost.com, user2, user2remotehost.com
> >
> > At this point you know you are done since none of your items changed.
> > Stopping once you expand a single element in the list that includes
> > itself makes no sense at all. Using that method you basically do
> > the following:
> >
> > initial: alias
> > pass 1: user1, user2
> > pass 2: user1, user1remotehost.com, user2
> >
> > The current code stops at this point since user1 included user1.
> >
> > I hope we've given enough of an explanation to this problem for someone
> > to take a look at it. Overall we very much like postfix and are pleased
> > beyond belief with our installation. Thanks for the hard work you've
> > have put into this.
> >
> > On Wed, Oct 25, 2000 at 05:59:29PM -0500, Michael Douglass said:
> > > To continue with this thread the problem appears to be one of logic. I
> > > think I've tracked it to cleanup_map1n.c. At line 110 we look to see
> > > if the entry has expanded to itself; if it has, then we exit the entire
> > > expansion process and consider ourselves done. Since there may be other
> > > items yet processed that need to expand, this is bad. Let me give you
> > > a simple case study:
> > >
> > > alias -> user1,user2
> > > user1 -> user1,user1remotehost.com
> > > user2 -> user2,user2remotehost.com
> > >
> > > When 'alias' is processed it is found to map to user1,user2. Next user1
> > > is processed found to map to user1,user1remotehost.com. The flag being
> > > set by the if condition at line 110 terminates the expansion at this
> > > point; this leaves us with a recursive expansion for 'alias' as
> > > user1,user1remotehost.com,user2.
> > >
> > > Our code base is from May; so this might be fixed in a more recent
> > > version. I am going to check the current code to see if there are any
> > > changes to this particular file.
> > >
> > > Thoughts/questions?
> > >
> > > --
> > > Michael Douglass
> > > Chief System Engineer
> > > DataFoundry.net, Inc. (512-794-7123)
> > >
> > > Programmer coming on line... caffeine module: check...
> > > vision module: check... brain module: 37% 90% check
> > >
> > > - from an anonymous programmer/system administrator
> >
> > --
> > Michael Douglass
> > Chief System Engineer
> > DataFoundry.net, Inc. (512-794-7123)
> >
> > Programmer coming on line... caffeine module: check...
> > vision module: check... brain module: 37% 90% check
> >
> > - from an anonymous programmer/system administrator
> >
> >
> >
> 

-- 
Michael Douglass
Chief System Engineer
DataFoundry.net, Inc.  (512-794-7123)

  Programmer coming on line...  caffeine module: check...
     vision module: check...  brain module: 37% 90% check

    - from an anonymous programmer/system administrator