Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: dev

[Bug 1184] code refactoring in acl.c

 

 

exim dev RSS feed   Index | Next | Previous | View Threaded


pdp at exim

Mar 19, 2012, 3:19 PM

Post #1 of 7 (636 views)
Permalink
[Bug 1184] code refactoring in acl.c

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1184




--- Comment #1 from Phil Pennock <pdp [at] exim> 2012-03-19 22:19:47 ---
Has this continued to run in production without issues?

How extensive would you say your use of the ACL facilities is?

Have you tried running the test suite to look for regressions?

I'm just trying to get a feel for the risk involved; skimming the patch, it
looks sane.

Hrm, our test suite could probably do with a performance-testing system so we
can A/B test performance of, eg, "ACL logic evaluation".


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


tlyons at ivenue

Mar 30, 2012, 6:51 AM

Post #2 of 7 (591 views)
Permalink
Re: [Bug 1184] code refactoring in acl.c [In reply to]

On Mon, Mar 19, 2012 at 3:19 PM, Phil Pennock <pdp [at] exim> wrote:

> Have you tried running the test suite to look for regressions?

I have experienced little success trying to run the test suite. I
have an nfs mounted home directory with root squash, so I copy it to
the local harddrive. In order to run the test suite, I had to create
a second user, not my login name. That seems to be the basic
requirements (and manually adding /sbin:/usr/sbin to the path).

But then I get slight errors on each test. This is typical output:

Basic/0004 Caseful address blocking
===============f test-stdout-munged with stdout/0004 failed
Line 6 of "test-stdout-munged" does not match line 6 of "stdout/0004".
----------
220 the.local.host.name ESMTP Exim 4.77_1102-226c389 Tue, 2 Mar 1999
09:44:33 +0000
----------
220 the.local.host.name ESMTP Exim x.yz Tue, 2 Mar 1999 09:44:33 +0000
===============
1 difference found.
"test-stdout-munged" contains 114 lines; "stdout/0004" contains 114 lines.

So is it safe to say that the test suite should only be run on
official releases and not arbitrary points on the git tree? Or should
I be calling runtest with the update command to update the test status
files? That seems like it kinda defeats the point of tests :-/

...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

Mar 30, 2012, 1:43 PM

Post #3 of 7 (590 views)
Permalink
Re: [Bug 1184] code refactoring in acl.c [In reply to]

On 2012-03-30 at 06:51 -0700, Todd Lyons wrote:
> But then I get slight errors on each test. This is typical output:
>
> 220 the.local.host.name ESMTP Exim 4.77_1102-226c389 Tue, 2 Mar 1999
> 09:44:33 +0000
> ----------
> 220 the.local.host.name ESMTP Exim x.yz Tue, 2 Mar 1999 09:44:33 +0000

So the version number should have been changed in the tested binary by
patchexim.

Looks as though the last changes were by me in October when I found that
the new version numbers generated by the build system were not handled
by the test suite, so I fixed the tests to run as part of the release
process.

Further, it looks like I missed some other output formats.
runtest normalises output. Looks like the regexp isn't matching that
version string. The underscore is the problem.

I've fixed patchexim to handle this variant too.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


tlyons at ivenue

Mar 30, 2012, 2:10 PM

Post #4 of 7 (589 views)
Permalink
Re: [Bug 1184] code refactoring in acl.c [In reply to]

On Fri, Mar 30, 2012 at 1:43 PM, Phil Pennock <pdp [at] exim> wrote:
> On 2012-03-30 at 06:51 -0700, Todd Lyons wrote:
>> But then I get slight errors on each test.  This is typical output:
>>
>> 220 the.local.host.name ESMTP Exim 4.77_1102-226c389 Tue, 2 Mar 1999
>> 09:44:33 +0000
>> ----------
>> 220 the.local.host.name ESMTP Exim x.yz Tue, 2 Mar 1999 09:44:33 +0000
>
> So the version number should have been changed in the tested binary by
> patchexim.
>
> Looks as though the last changes were by me in October when I found that
> the new version numbers generated by the build system were not handled
> by the test suite, so I fixed the tests to run as part of the release
> process.
>
> Further, it looks like I missed some other output formats.
> runtest normalises output.  Looks like the regexp isn't matching that
> version string.  The underscore is the problem.
>
> I've fixed patchexim to handle this variant too.

Are there more places with underscores that need to be touched? It
still fails on what looks like what should be something replaced:

Basic/0001 Basic configuration setting
===============f test-stdout-munged with stdout/0001 failed
From line 22 of "test-stdout-munged" and line 22 of "stdout/0001" the
files are different.
----------
warn_message_file = CALLER_HOME/test/warnmsg_file
----------
warn_message_file = /home/exim/test/warnmsg_file
===============
1 difference found.
"test-stdout-munged" contains 22 lines; "stdout/0001" contains 22 lines.

Thanks for the answers Phil. :-)

...Todd
--
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. -- Martin Golding

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


pdp at exim

Mar 30, 2012, 5:34 PM

Post #5 of 7 (584 views)
Permalink
Re: [Bug 1184] code refactoring in acl.c [In reply to]

On 2012-03-30 at 14:10 -0700, Todd Lyons wrote:
> Are there more places with underscores that need to be touched? It
> still fails on what looks like what should be something replaced:

($parm_caller,$pwpw,$parm_caller_uid,$parm_caller_gid,$pwquota,$pwcomm,
$parm_caller_gecos, $parm_caller_home) = getpwuid($>);
# ...
print "Program caller is $parm_caller, whose group is $parm_caller_group\n";
print "Home directory is $parm_caller_home\n";
# ...
s/\Q$parm_caller_home\E/CALLER_HOME/g; # NOTE: these must be done

You probably need, for user "foo" running the tests, to have the tests
checked out and run somewhere under "foo"'s home directory. Since the
testing also needs to be mounted in an area which needs setuid, you may
need the home directory to be somewhere not in the usual place. I have
/usr/globnix/homes/exim-build/ for this, so that /home can remain
protected.

When I first ran the tests, I found a whole bunch of undocumented
assumptions and updated test/README with anything I found. I encourage
folks to continue along this path.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


jgh146exb at wizmail

Apr 2, 2012, 1:54 PM

Post #6 of 7 (570 views)
Permalink
[Bug 1184] code refactoring in acl.c [In reply to]

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1184

Jeremy Harris <jgh146exb [at] wizmail> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #522 is|0 |1
obsolete| |




--- Comment #2 from Jeremy Harris <jgh146exb [at] wizmail> 2012-04-02 21:54:46 ---
Created an attachment (id=554)
--> (http://bugs.exim.org/attachment.cgi?id=554)
Code refactoring for verify= parse in acl (updated)

Let's hear it for test suites. I'd broken the verify=
sender=altperson [at] altdomai parsing, which was spotted by case 0029 - and also
the case-independent parsing of verify= WHATEVER. New patch attached; it
still requires the acceptance of new output for case 0027 - there's a slight
loss in debug information output.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##


jgh146exb at wizmail

Apr 3, 2012, 5:28 PM

Post #7 of 7 (571 views)
Permalink
[Bug 1184] code refactoring in acl.c [In reply to]

------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1184

Jeremy Harris <jgh146exb [at] wizmail> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #554 is|0 |1
obsolete| |




--- Comment #3 from Jeremy Harris <jgh146exb [at] wizmail> 2012-04-04 01:28:10 ---
Created an attachment (id=555)
--> (http://bugs.exim.org/attachment.cgi?id=555)
Code refactoring for verify= parse in acl (updated x2)

Essentially the same coding error in another place, affecting the callout=
parsing. Plus a really stupid thinko.

Fixing those tidies up most of the testsuite cases. Of particular interest in
the outstanding ones, though, is:

Basic/0376 callout verification (with caching)
===============f test-stdout-munged with stdout/0376 failed
Line 370 of "test-stdout-munged" does not match line 370 of "stdout/0376".
----------
MAIL FROM:<pmsend [at] a>
----------
MAIL FROM:<>
===============
Line 436 of "test-stdout-munged" does not match line 436 of "stdout/0376".
----------
MAIL FROM:<pmsend [at] b>
----------
MAIL FROM:<>
===============
2 differences found.
"test-stdout-munged" contains 442 lines; "stdout/0376" contains 442 lines.

Continue, Update & retry, Quit? [Q] c
Script completed

for which, if I read correctly, the testcase is doing a
postmaster_mailfrom= callout but the results are set up for a blank from.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

exim dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.