On Mon, 2006-07-17 at 05:33, Ralf Corsepius wrote: > Well, the way rt is packaged in FE is supposed to be compliant to the > FHS, GCS, the Fedora Packaging Guidelines, and is a valid rt3 > configuration without any special tweaks applied. > > If "add-ons" can't cope with it, they are simply bugged. OK, but given a choice between a working program and following today's fashion in file locations, I'll stick to the working version, thank you. To that end it would be helpful if you could bundle the perl module dependencies in some way that would allow them to be installed with an RPM while using the stock rt3 version instead of the packaged one. > > The Centos version > First of all, I don't care what Centos OS does ... also, I could not > find any package on centos.org, so I presume you are referring to a 4th > party packaging something. Yes, as documented in the expected place - linked from http://wiki.bestpractical.com/index.cgi?InstallationGuides along with all the other packaged versions. You don't have to guess about it. > > also has a separate rt-mail-dispatcher package > > that lets you set up rt.yourdomain.com > > This would require to setup a virtual domain and to somehow reflect this > virtual domain to DNS. This is way beyond what any rpm can do and will > always require manual sysadmin intervention. > > > and then mail to > > queuename@xxxxxxxxxxxxxxxxx without having to add aliases > > for every queue. > I strongly doubt this rpm to be functional. It requires a DNS name and configuration in sendmail to accept that name (as does any mail host). What the RPM provides is a .procmailrc file for the rt user, some perl scripts, and documentation for how to set up a virtusertable entry to direct all mail for the domain to the rt user where procmail will do the rest, mapping the username to an RT queue. If you don't do it this way you have to add pipe-to-program aliases for every queue you create. -- Les Mikesell lesmikesell@xxxxxxxxx
