Re: aide 0.9, anybody

From: Lupe Christoph (lupe@lupe-christoph.de)
Date: 11/05/02


Date: Tue, 5 Nov 2002 14:14:53 +0100
To: security@freebsd.org
From: lupe@lupe-christoph.de (Lupe Christoph)

Rami, on freebsd-security I reported problems getting aide-0.9 to
compile. Some people seem to have done some work on this, but no one
submitted a port for aide-0.9 (the port is stuck at 0.7).

I have invested some more time in this. Below you find a log describing
what I did, mostly on the CVS version.

freebsd-security, if anybody wants to do this, please follow the
instrauctions on http://www.cs.tut.fi/~rammer/aide.html to get the CVS
version of aide.

Using the CVS version requires one to use the older variants of the
auto* ports, autoconf213 and automake14. Use
  autoheader213; automake14; autoconf213

On Tuesday, 2002-10-29 at 11:22:22 +0100, Lupe Christoph wrote:

> I already overcame some problems in configure with libgcrypt. Who do I
> talk to about updating the port once it installs and works?

Weellll, I kludged configure to do that. Now I have a patch to
configure.in. That file twiddles CPPFLAGS, IMNSHO unnecessarily. This
patch removes the twiddling:

--- configure.in.orig Fri May 31 14:47:07 2002
+++ configure.in Tue Nov 5 11:23:56 2002
@@ -46,7 +46,7 @@
 
 AC_ARG_WITH(extra-includes,
   [ --with-extra-includes Specify additional paths to find headerfiles],
- [ CPPFLAGS="$CFLAGS $withval" ])
+ [ CPPFLAGS="$CPPFLAGS $withval" ])
 AC_ARG_WITH(extra-libs,
   [ --with-extra-libs Specify aditional paths to find libraries],
   [ LDFLAGS="$LDFLAGS $withval" ])
@@ -164,7 +164,6 @@
 fi
 
 CFLAGS="$LD_STATIC_FLAG"
-CPPFLAGS="$LD_STATIC_FLAG"
 
 AC_SUBST(LD_STATIC_FLAG)
 
I believe the first one is a typo, and the second one a thinko ...

Checking CVS version of aide ... That problem is gone.

I confirmed that aide-0.9 has a problem with newer bison versions by
trying it on Debian Testing which also has bison 1.75.

And that is not gone in CVS. Rami, can you please look at this?

bison -y -d -p conf -o conf_yacc.c /usr/home/lupe/aide-cvs/aide/src/conf_yacc.y
/usr/home/lupe/aide-cvs/aide/src/conf_yacc.y:144.23-154.5: type clash (`i' `s') on default action
/usr/home/lupe/aide-cvs/aide/src/conf_yacc.y:154.7: parse error, unexpected ":", expecting ";" or "|"
/usr/home/lupe/aide-cvs/aide/src/conf_yacc.y:217.23: parse error, unexpected ":", expecting ";" or "|"
/usr/home/lupe/aide-cvs/aide/src/conf_yacc.y:251.1-2: parse error, unexpected "%%", expecting ";" or "|"

Using yacc instead of bison -y works OK. Why, then, does configure
insist on bison??? Rami, can you please make the autoconf stuff check
for yacc first?

Also, the CVS version requires GNU make:

"/usr/home/lupe/aide-cvs/aide/src/Makefile", line 267: Need an operator
make: fatal errors encountered -- cannot continue

That line is:
-include $(DEP_FILES)

AFAIR, different makes have different syntax for include. Dunno if
automake can compensate for this.

Now I get this:

In file included from /usr/home/lupe/aide-cvs/aide/src/conf_yacc.y:13:
/usr/home/lupe/aide-cvs/aide/include/db_config.h:302: syntax error before `blkcnt_t'

Which is:
  AIDE_BLKCNT_TYPE bcount;
This gets rewritten by macro expansion:
  blkcnt_t bcount;

This seems to be a copy of st_blocks from the stat struct. But that has:
         int64_t st_blocks; /* blocks allocated for file */

autoconf should include a check for the type of st_blocks.

Next obstacle:

gen_list.c:30: ustat.h: No such file or directory

FreeBSD has no ustat! The code that uses ustat is:

  /*
    Here we should check if we need to add it..
   */

  {
    struct ustat buf;
    if (ustat(fs.st_dev, &buf) != 0 || buf.f_fname[0]==0) {

    } else {

    }

  }

Looks like an incomplete experiment. For now, I'll just remove it.

This was the last block, now I get an aide executable.

BTW, the configure line I used was

./configure --with-zlib --with-config_file=/etc/aide/aide.conf \
--with-gcrypt --enable-forced_configmd --enable-forced_dbmd \
--with-extra-includes=-I/usr/local/include \
--with-extra-libs=-L/usr/local/lib

I'm out of tuits for now, so I can't test the executable right now.

Lupe Christoph

-- 
| lupe@lupe-christoph.de       |           http://www.lupe-christoph.de/ |
| Big Misunderstandings #6398: The Titanic was not supposed to be        |
| unsinkable. The designer had a speech impediment. He said: "I have     |
| thith great unthinkable conthept ..."                                  |
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


Relevant Pages

  • Re: Survey question re sourceforge & cvs
    ... Now how many of you have used the current fc6 version of cvs ... traceroutes to sourceforge are delayed many seconds at the ... Yeah, sure, it's right in the TOS that port 80 is blocked. ... not on outbound connections - there is a differentiation called source ...
    (Fedora)
  • Re: CVS checkout behind firewall proxy
    ... > I'm trying to do a cvs checkout from a debian beast on the company ... > I'm connected to the internet via a proxy firewall. ... Get the admins to open that port. ... network that then translates the traffic over to port 2401. ...
    (Debian-User)
  • Re: CVS removal from the base
    ... the ports tree only has the "latest" version or two; ... So it's entirely possible the "CVS" port maintainer updates the port ... And then we lose a whole lot of what public "good" opinion FreeBSD ...
    (freebsd-current)
  • Re: Survey question re sourceforge & cvs
    ... Gene Heskett wrote: ... Now how many of you have used the current fc6 version of cvs ... via cvs commands since each setup is different. ... Yeah, sure, it's right in the TOS that port 80 is blocked. ...
    (Fedora)