Hi all,
There’s a problem in Makefile which has to be handled in
the future release:
nod As mentioned before on this list, the installation procedure needs
to be gutted before we’re ready for a release.
In addition, DB_DBA and DB_DBA_PASSWORD are taken from config file,
though I believe it’s not the proper place to keep that data.
To make the installation reasonably not painful, the DBA and
DBA_Password need to be somewhere we can get to them as perl variables
(rather than environment variables. we want to avoid passing them on the
comandline)
What about getting use of autoconf/automake?
Autoconf scares me. That doesn’t mean I won’t use it, but it’s a
heavyweight tool that’s rather complex and obtuse. Also, I suspect
it might complicate the win32 port somewhat, though that’s based on a
hunch, not on any actual facts. I’d be thrilled to have something
autoconf-like that’s written in perl, if it exists. I’d definitely take
a good long look at a contributed autoconfiscation of RT’s install
process, if someone was feeling so bold. Frankly, I’m not convinced
that a Makefile is really the right option for a large tool that’s
entirely in perl, but I don’t actually have a better proposal at this
point.
Best,
Jesse
»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Howdy!
I’m separating these two threads as I think they may go two very
different places.On Fri, 2002-10-11 at 09:41, Jesse Vincent wrote:
In addition, DB_DBA and DB_DBA_PASSWORD are taken from config file,
though I believe it’s not the proper place to keep that data.
To make the installation reasonably not painful, the DBA and
DBA_Password need to be somewhere we can get to them as perl variables
(rather than environment variables. we want to avoid passing them on the
comandline)
How about at least using an encrypted PW? That’s always bothered me,
too, just not so much I’d done anything about it.
Cheers!
–j
Jim Meyer, Geek At Large purp@acm.org
How about at least using an encrypted PW? That’s always bothered me,
too, just not so much I’d done anything about it.
An encrypted password would need to be decryptable by RT’s tools using
only the information in the config file. Which completely defeats the
purpose of the encryption…and it gives the user a false sense
of security.
Part of the cleanup for a proper installation procedure will be
pulling the DBA user and DBA password out of the main config file.
They’re only needed on setup, not at runtime. But RT’s database
password needs to be available to RT’s tools.
In 3.0, the cli and mail gateway will talk to the RT server, rather
than loading their own libraries and talking straight to the database.
This will mean that RT no longer needs to run setgid. Which should help
some 
-j
»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
What about getting use of autoconf/automake?
Autoconf scares me. That doesn’t mean I won’t use it, but it’s a
heavyweight tool that’s rather complex and obtuse. Also, I suspect
it might complicate the win32 port somewhat, though that’s based on a
hunch, not on any actual facts. I’d be thrilled to have something
autoconf-like that’s written in perl, if it exists. I’d definitely take
a good long look at a contributed autoconfiscation of RT’s install
process, if someone was feeling so bold. Frankly, I’m not convinced
that a Makefile is really the right option for a large tool that’s
entirely in perl, but I don’t actually have a better proposal at this
point.
I haven’t looked at win32 port, is it not using Cygwin?
Under Cygwin, autotools work fine.
I was scared too, though bold enough to put it into my working
project, which was already quite big.
It takes some time to get used to autotools. And of course it’s slower
because of tons of shell scripts. But then it saves tons of
developer’s time.
There’s only one beginner’s guide that I could find in the net:
http://sources.redhat.com/autobook/
I’m eager to help, but I’m not the autotools guru, I only started
using them few months ago.
Cheers,
Stan
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
What about getting use of autoconf/automake?
Autoconf scares me.
It does not, however, scare me, at least to the extent that I know it.
I autoconfiscated the Makefile for 2.0.15pre1; attached it the
configure.in and Makefile.in that I used. It worked for my install.
To use it, do:
$ autoconf
$ ./configure --help
The proper invocation of configure (with the correct options, which are
pretty obvious from the --help output) will produce a Makefile with the
appropriate settings. I’ve tested it by modifying the original Makefile
such that it contains all the settings I needed to modify, moving it to
Makefile.orig, running configure, and then diffing Makefile and
Makefile.orig.
All of the appropriate rt variables are --with variables, with defaults
and descriptions taken from the Makefile:
Features and packages:
–disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
–enable-FEATURE[=ARG] include FEATURE [ARG=yes]
–with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
–without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
–x-includes=DIR X include files are in DIR
–x-libraries=DIR X library files are in DIR
–enable and --with options recognized:
–with-rt-path=PATH Name of the directory you want to install RT in (default: /opt/rt2)
–with-rt-lib-path=PATH Name of the directory you want to install RT libraries in (default: $RT_PATH/lib)
–with-rt-etc-path=PATH Name of the directory you want to install RT config in (default: $RT_PATH/etc)
–with-rt-bin-path=PATH Name of the directory you want to install RT binaries in (default: $RT_PATH/bin)
–with-rt-man-path=PATH Name of the directory you want to install RT man pages in (default: $RT_PATH/man)
–with-mason-html-path=PATH Name of the directory you want to be the HTML::Mason docroot (default: $RT_PATH/WebRT/html)
–with-destdir=PATH path where RT will eventuall reside (if different from $RT_PATH)
–with-rt-group=GROUP chgrp all files to GROUP (default: rt)
–with-bin-owner=OWNER User that should own rt binaries (default root)
–with-libs-owner=OWNER User that should own all of RT’s libraries (default root)
–with-libs-group=GROUP Group that should own rt binaries (default bin)
–with-rt-log-path=PATH Name of the directory in which you want logs to appear (default: /tmp)
–with-db-type=TYPE what sort of database RT trys to talk to (default: mysql)
–with-db-home=PATH where the database’s commandline tools live (default: /usr)
–with-db-dba=USER name of the DB user with permission to create new databases (default: root)
–with-db-dba-password=TYPE password for $DB_DBA
–with-db-host=HOSTNAME FQDN of database server (default: localhost)
–with-db-port=PORT Port on which the database server on $DB_HOST listen
–with-db-rt-host=HOSTNAME FQDN of database server (default: localhost)
–with-db-database=DBNAME name of the rt database (default: rt2)
–with-db-rt-user=DBUSER name of database user (default: rt_user)
–with-db-rt-pass=PASSWORD password for $DBUSER (default: rt_pass)
–with-web-user=USER name of web server (default: www)
–with-web-group=GROUP group of web server (default: rt)
There is some room for improvement (I only had an hour to do this – my
train ride is only an hour ;), like using the standard --libdir for what
is --with-rt-lib-dir, and the same for rt-bin-path, rt-man-path, and so
on. Patches welcome, of course.
Finally, I have not been following RT 2.1 development, so I have no idea
if/how this will translate to it.
(darren)
We are not who we think we are.
We are not who others think we are.
We are who we think others think we are.
– Anonymous
configure.in (5.69 KB)
Makefile.in (13 KB)
At 13:18 11/10/2002 -0400, Jesse Vincent wrote:
Part of the cleanup for a proper installation procedure will be
pulling the DBA user and DBA password out of the main config file.
They’re only needed on setup, not at runtime. But RT’s database
password needs to be available to RT’s tools.
Slash and a few other funky web-based perl thingies use the DBIx::Password
to manage this.
Basically, it creates a name → db connection “password” file and stores it
in the module directory.
This way, applications just have to use the name of the service to obtain a
DB handle.
Doesn’t really help security wise, but as you pointed out the best you can
do with passwords in this scenario is make sure the files they’re in are
protected properly.
Olly
I autoconfiscated the Makefile for 2.0.15pre1; attached it the
configure.in and Makefile.in that I used. It worked for my install.
Great start!
Next step is to get use of automake benefits.
Let it handle all dull tasks like directories creation, chown,
chmod etc. But it requires to turn the whole makefile inside out.
Perhaps, it’s better to do it in 2.1 branch.
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
Slash and a few other funky web-based perl thingies use the DBIx::Password
to manage this.
Basically, it creates a name → db connection “password” file and stores it
in the module directory.
This way, applications just have to use the name of the service to obtain a
DB handle.
DBIx::Password - Allows you to create a global password file for DB passwords - metacpan.org
I took a look at this a while back and it seems to just add a layer of
complexity, without any real benefits.
-j
»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
What about getting use of autoconf/automake?
Autoconf scares me.
It does not, however, scare me, at least to the extent that I know it.
I autoconfiscated the Makefile for 2.0.15pre1; attached it the
configure.in and Makefile.in that I used. It worked for my install.
To use it, do:
$ autoconf
$ ./configure --help
Ooh. very neat. Is there a way to get configure to pick up defaults
from, say, an existing RT config file? Pure autoconf doesn’t really
help in the upgrade case 
J
»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
- Jesse Vincent jesse@bestpractical.com [2002-10-11 15:24]:> On Fri, Oct 11, 2002 at 02:17:07PM -0400, darren chamberlain wrote:
To use it, do:
$ autoconf
$ ./configure --help
Ooh. very neat. Is there a way to get configure to pick up defaults
from, say, an existing RT config file? Pure autoconf doesn’t really
help in the upgrade case
Hm… autoconf will read cache files, but other than that I don’t
believe it does. How does the current process handle updgrading, other
than with explicit (and specialized) update scripts?
(darren)
How is it possible to find meaning in a finite world, given my waist
and shirt size?
– Woody Allen
I haven’t looked at win32 port, is it not using Cygwin?
Under Cygwin, autotools work fine.
The current win32 port that I maintain use native, Win32 Perl58,
Apache2 and Mysql4.
It was found that Cygwin has a rather serious performance penalty
on IO-bound operations; and because Apache2’s design, a native
win32 environment looks like a boon.
That said, GNU-Win32 distribution from sf.net may offer native
autoconf, too, if we decide to go that route. And Win32 dists
can always just pack the resulting binaries up, instead of going
through the config process, as long as the source code as made
available.
Thanks,
/Autrijus/
To use it, do:
$ autoconf
$ ./configure --help
Ooh. very neat. Is there a way to get configure to pick up defaults
from, say, an existing RT config file? Pure autoconf doesn’t really
help in the upgrade case
Hm… autoconf will read cache files, but other than that I don’t
believe it does. How does the current process handle updgrading, other
than with explicit (and specialized) update scripts?
Well, part of the plan for 3.0 is to have something like postfix’ config
file extractor…
But right now, with 2.1, an upgrade grabs everything from the current
config file. (there isn’t currently a method for appending new things to
the config file, but that’s a relatively easy thing.
(darren)
–
How is it possible to find meaning in a finite world, given my waist
and shirt size?
– Woody Allen
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
Hi,
I’ve attached several files that attempt to cleanup the autoconfiscation
process that’s been introduced. There’s still a bit of work to do, but this
snapshot is complete and still (I think) an improvement.
Attached files:
1) configure.ac
This is the replacement for configure.in. Newer versions of autoconf
seem to favour this name. Drop in root dir of distribution.
2) config.layout
The default directory layout for installation. Used when ./configure
is run. Drop in root dir of distribution.
3) rt_*.m4
These are macros used by configure.ac. They should be dropped in a
new directory (m4/). Before running autoconf, invoke aclocal -I m4.
This builds aclocal.m4, which autoconf actually gets the macros from.
I've gotten into the habit of building the ./configure script with
'aclocal -I m4 && autoconf'.
At the present, none of the existing *.in files need to be adjusted; I’ve
mapped all the internal substitution variables to the existing ones for now.
Areas that still need attention:
a) The database configuration. Ugh. (I’ve at least cleaned up the argument
descriptions displayed during ./configure --help for now).
b) Makefile. Maybe include install-sh, and use @install@ instead of the
cp/chown/chgrp gymnastics currently in place. 
c) Substitution variable renaming. A topic for another day.
Hope this helps,
rt_subst_expanded_arg.m4 (356 Bytes)
configure.ac (5.36 KB)
rt_enable_layout.m4 (996 Bytes)
rt_expand_var.m4 (444 Bytes)
rt_layout.m4 (2.38 KB)
config.layout (1.22 KB)
I’ve attached several files that attempt to cleanup the
autoconfiscation process that’s been introduced. There’s still a bit
of work to do, but this snapshot is complete and still (I think) an
improvement.
This is a huge improvement over my version. Good work!
(darren)
I have discovered that all human evil comes from this, man’s being
unable to sit still in a room.
– Blaise Pascal
Thanks. Applied.
Areas that still need attention:
a) The database configuration. Ugh. (I’ve at least cleaned up the
argument descriptions displayed during ./configure --help for now).
Actually working on some of this tonight. Database config is being
decoupled a bit. You’ll mostly configure in autoconf and then run a
database creation tool later.
b) Makefile. Maybe include install-sh, and use @install@ instead of
the cp/chown/chgrp gymnastics currently in place. 
nod install-sh ought to get us a large part of the way there. What’s
the standard way to handle a boatload of file installations? find -exec?
c) Substitution variable renaming. A topic for another day.
nod once the rest of it stabilizes a bit, this will be easy
Hope this helps,
»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
At 08:33 PM 18/11/2002 -0500, Jesse Vincent wrote:
Areas that still need attention:
a) The database configuration. Ugh. (I’ve at least cleaned up the
argument descriptions displayed during ./configure --help for now).
Actually working on some of this tonight. Database config is being
decoupled a bit. You’ll mostly configure in autoconf and then run a
database creation tool later.
Cool. Sounds like a nice approach. For the database configuration, I’d
consider looking at how they do the --with-suexec options in Apache 2. I’m
also cargo-culting most of this stuff.
b) Makefile. Maybe include install-sh, and use @install@ instead of
the cp/chown/chgrp gymnastics currently in place. :)
nod install-sh ought to get us a large part of the way there. What’s
the standard way to handle a boatload of file installations? find -exec?
Sadly, I think you need to list everything explicitly in the Makefile and
use install for each individual file. So far I’ve used automake on our
internal projects which does the hard work for us (although we still have
to list all the files).
As an aside, I’ve noticed that the file permissions on the files
distributed in the tarball are a little wacky. For example, ./configure
isn’t executable. In general, don’t rely on anything other than ./configure
being executable. Anything other than that, mark executable at ./configure
time (see how I set that up for initdb) if they’re needed before
installation. This applies especially when CVS is involved. Maybe in the
‘roll the distribution step’, include a step that goes something like:
% find -type f | xargs chmod 644 &&
find -type d | xargs chmod 755 &&
chmod 755 configure
Permissions that should apply to files only after installation should be
set using ‘install’.
Cheers,
- Andrew “off to try out 2.1.48” Snare