6 Dec
2009
6 Dec
'09
7:15 p.m.
Hi,
I have just been looking at using perdition as part of a mail migration
between multiple POP3 servers and have it working well with LDAP.
At the moment I have it configured to lookup against the domain part of
the user login and have temporarily added the following attribute to the
domain object in LDAP:
mailhost=192.168.10.81
That works, but I would like to use an existing attribute that already
exists and wouldnt require manually editing the LDAP object everytime a
domain was updated. The problem is this attribute is in the format of:
mailtransport=nexthop:[mda-clusterX.domain.com]
So my query is returning "nexthop:[mdaX.domain.com]". Is there anyway
to get ldap/perdition to retrieve the part of the result thats in the []
brackets? If I could use that part of the LDAP attribute I would only
need to add an entry to the hosts file so that it would use the POP3
server that corresponds with the Mail Delivery server in that attribute?
If theres a trick to accimplish that it would save me alot of work. :)
Thanks.
Jim.
7 Dec
7 Dec
5:05 a.m.
On Sun, Dec 06, 2009 at 07:15:48PM +0000, Jim Tyrrell wrote:
Hi,
I have just been looking at using perdition as part of a mail migration
between multiple POP3 servers and have it working well with LDAP.
At the moment I have it configured to lookup against the domain part of
the user login and have temporarily added the following attribute to the
domain object in LDAP:
mailhost=192.168.10.81
That works, but I would like to use an existing attribute that already
exists and wouldnt require manually editing the LDAP object everytime a
domain was updated. The problem is this attribute is in the format of:
mailtransport=nexthop:[mda-clusterX.domain.com]
So my query is returning "nexthop:[mdaX.domain.com]". Is there anyway
to get ldap/perdition to retrieve the part of the result thats in the []
brackets? If I could use that part of the LDAP attribute I would only
need to add an entry to the hosts file so that it would use the POP3
server that corresponds with the Mail Delivery server in that attribute?
If theres a trick to accimplish that it would save me alot of work. :)
Hi Jim,
I don't believe that is possible to using a configuration "trick".
Though I would be more than happy to hear details of how you would see
such a thing working - it sounds like a feature worth adding.
Alternatively it would be a fairly trivial modification ("hack" :-) to
the source code just to handle the case you have.
9:37 a.m.
Hello,
Jim Tyrrell wrote:
Hi,
I have just been looking at using perdition as part of a mail migration
between multiple POP3 servers and have it working well with LDAP.
At the moment I have it configured to lookup against the domain part of
the user login and have temporarily added the following attribute to the
domain object in LDAP:
mailhost=192.168.10.81
That works, but I would like to use an existing attribute that already
exists and wouldnt require manually editing the LDAP object everytime a
domain was updated. The problem is this attribute is in the format of:
mailtransport=nexthop:[mda-clusterX.domain.com]
So my query is returning "nexthop:[mdaX.domain.com]". Is there anyway
to get ldap/perdition to retrieve the part of the result thats in the []
brackets? If I could use that part of the LDAP attribute I would only
need to add an entry to the hosts file so that it would use the POP3
server that corresponds with the Mail Delivery server in that attribute?
If theres a trick to accimplish that it would save me alot of work. :)
I don't think the trick is possible to at Perdition level, but if you
are using OpenLDAP, you might want to try its rewrite/remap overlay.
That way you don't need to actually modify the data in LDAP database,
but instead configure an additional view / LDAP URI for Perdition use.
Rewrite/remap could probably include only the part between the brackets
by using standard regular expressions. Unfortunately slapo-rwm man page
reminds me of Apache's mod_rewrite; the good thing about it is that it's
extremely configurable. The bad part about it is it's extremely
configurable.
http://www.openldap.org/software/man.cgi?query=slapo-rwm&apropos=0&…
Good luck. I hope this helps.
Best regards,
Janne Pikkarainen
12:38 p.m.
New subject: Compiling
Hi,
I have installed and tested Perdition 1.17 on CentOS 5.4 fine using the
1.17 RPM's - but now I'm trying to install 1.18 via source as there is
no RPM for that yet. I'm getting the following error when trying to
compile Venessa logger:
# make
make all-recursive
make[1]: Entering directory `/root/perdition/vanessa_logger-0.0.8'
Making all in libvanessa_logger
make[2]: Entering directory
`/root/perdition/vanessa_logger-0.0.8/libvanessa_logger'
if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I. -I.. -g -O2 -MT vanessa_logger.lo -MD -MP -MF
".deps/vanessa_logger.Tpo" -c -o vanessa_logger.lo vanessa_logger.c; \
then mv -f ".deps/vanessa_logger.Tpo"
".deps/vanessa_logger.Plo"; else rm -f ".deps/vanessa_logger.Tpo";
exit
1; fi
../libtool: line 466: CDPATH: command not found
../libtool: line 1144: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6 Debian-2.2.6a-4,
but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
Debian-2.2.6a-4
libtool: and run autoconf again.
make[2]: *** [vanessa_logger.lo] Error 1
make[2]: Leaving directory
`/root/perdition/vanessa_logger-0.0.8/libvanessa_logger'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/perdition/vanessa_logger-0.0.8'
make: *** [all] Error 2
I'm not sure what I should be recreating with what. :P Its a standard
CentOS 5.4 install and has libtool-1.5.22-6.1 installed. I tried
compiling and installing libtool 2.2.6 but that didnt fix the issue.
Any pointers appreciated.
Thanks.
Jim.
12:54 p.m.
New subject: Compiling
Hi,
I have installed and tested Perdition 1.17 on CentOS 5.4 fine using the
1.17 RPM's - but now I'm trying to install 1.18 via source as there is
no RPM for that yet. I'm getting the following error when trying to
compile Venessa logger:
My source RPMS build fine on RHEL/CentOS 5.4:
http://www.invoca.ch/pub/packages/perdition/
http://www.invoca.ch/pub/packages/vanessa_adt/
http://www.invoca.ch/pub/packages/vanessa_logger/
http://www.invoca.ch/pub/packages/vanessa_socket/
Regards,
Simon
# make
make all-recursive
make[1]: Entering directory `/root/perdition/vanessa_logger-0.0.8'
Making all in libvanessa_logger
make[2]: Entering directory
`/root/perdition/vanessa_logger-0.0.8/libvanessa_logger'
if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I. -I.. -g -O2 -MT vanessa_logger.lo -MD -MP -MF
".deps/vanessa_logger.Tpo" -c -o vanessa_logger.lo vanessa_logger.c; \
then mv -f ".deps/vanessa_logger.Tpo"
".deps/vanessa_logger.Plo"; else rm -f ".deps/vanessa_logger.Tpo";
exit
1; fi
../libtool: line 466: CDPATH: command not found
../libtool: line 1144: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6 Debian-2.2.6a-4,
but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
Debian-2.2.6a-4
libtool: and run autoconf again.
make[2]: *** [vanessa_logger.lo] Error 1
make[2]: Leaving directory
`/root/perdition/vanessa_logger-0.0.8/libvanessa_logger'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/perdition/vanessa_logger-0.0.8'
make: *** [all] Error 2
I'm not sure what I should be recreating with what. :P Its a standard
CentOS 5.4 install and has libtool-1.5.22-6.1 installed. I tried
compiling and installing libtool 2.2.6 but that didnt fix the issue.
Any pointers appreciated.
Thanks.
Jim.
______________________________________________
Perdition-users mailing list
Perdition-users(a)vergenet.net
http://lists.vergenet.net/listinfo/perdition-users
5:11 p.m.
New subject: Compiling
On Mon, 7 Dec 2009, Jim Tyrrell wrote:
1.17 RPM's - but now I'm trying to install
1.18 via source as there is
no RPM for that yet. I'm getting the following error when trying to
Have you looked at:
http://download.opensuse.org/repositories/home:/horms/CentOS_5/i386/
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony(a)lava.net
9:23 p.m.
New subject: Compiling
On Mon, Dec 07, 2009 at 12:38:15PM +0000, Jim Tyrrell wrote:
Hi,
I have installed and tested Perdition 1.17 on CentOS 5.4 fine using the
1.17 RPM's - but now I'm trying to install 1.18 via source as there is
no RPM for that yet. I'm getting the following error when trying to
compile Venessa logger:
# make
make all-recursive
make[1]: Entering directory `/root/perdition/vanessa_logger-0.0.8'
Making all in libvanessa_logger
make[2]: Entering directory
`/root/perdition/vanessa_logger-0.0.8/libvanessa_logger'
if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I. -I.. -g -O2 -MT vanessa_logger.lo -MD -MP -MF
".deps/vanessa_logger.Tpo" -c -o vanessa_logger.lo vanessa_logger.c; \
then mv -f ".deps/vanessa_logger.Tpo"
".deps/vanessa_logger.Plo"; else rm -f ".deps/vanessa_logger.Tpo";
exit
1; fi
../libtool: line 466: CDPATH: command not found
../libtool: line 1144: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6 Debian-2.2.6a-4,
but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
Debian-2.2.6a-4
libtool: and run autoconf again.
make[2]: *** [vanessa_logger.lo] Error 1
make[2]: Leaving directory
`/root/perdition/vanessa_logger-0.0.8/libvanessa_logger'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/perdition/vanessa_logger-0.0.8'
make: *** [all] Error 2
I'm not sure what I should be recreating with what. :P Its a standard
CentOS 5.4 install and has libtool-1.5.22-6.1 installed. I tried
compiling and installing libtool 2.2.6 but that didnt fix the issue.
Any pointers appreciated.
Strange. As mentioned elsewhere there are RPMs
at
http://download.opensuse.org/repositories/home:/horms/CentOS_5/i386/
and
http://www.invoca.ch/pub/packages/perdition/
http://www.invoca.ch/pub/packages/vanessa_adt/
http://www.invoca.ch/pub/packages/vanessa_logger/
http://www.invoca.ch/pub/packages/vanessa_socket/
But to address your build question, I wonder if running
./autogen.sh helps.
5262
days inactive
5263
days old
6 comments
5 participants
participants (5)
-
Antonio Querubin -
Janne Pikkarainen -
Jim Tyrrell -
Simon Horman -
Simon Matter