Re: [rt-users] Email delay on ticket creation - sending to www user?
I thought this was solved, but I was wrong - see below: On 3/11/09 2:02 PM, Bill Cole rtusers-20090...@billmail.scconsult.com wrote: Now the bad case: Mar 10 08:56:51 rt3-curis-com postfix/pickup[214]: 6D778843F4: uid=70 from=www Mar 10 08:56:51 rt3-curis-com postfix/cleanup[231]: 6D778843F4: message-id=rt-3.8.1-228-1236689811-14.30085-...@curis.com Mar 10 08:56:51 rt3-curis-com postfix/qmgr[219]: 6D778843F4: from=w...@rt3.curis.com, size=998, nrcpt=1 (queue active) Mar 10 08:56:51 rt3-curis-com postfix/pickup[214]: 7C66B843F5: uid=70 from=www Mar 10 08:56:51 rt3-curis-com postfix/cleanup[231]: 7C66B843F5: message-id=rt-3.8.1-212-1236685553-104.30085-...@curis.com Mar 10 08:56:51 rt3-curis-com postfix/qmgr[219]: 7C66B843F5: from=w...@rt3.curis.com, size=1232, nrcpt=3 (queue active) Mar 10 08:56:51 rt3-curis-com postfix/smtp[234]: 6D778843F4: to=d...@curis.com, relay=[mailserver].curis.com[10.2.0.20], delay=0, status=sent (250 2.0.0 49b66393-000b34c3 Message accepted for delivery) Mar 10 08:56:51 rt3-curis-com postfix/smtp[235]: 7C66B843F5: to=d...@curis.com, relay=[mailserver].curis.com[10.2.0.20], delay=4257, status=sent (250 2.0.0 49b66393-000b34c4 Message accepted for delivery) Mar 10 08:56:51 rt3-curis-com postfix/smtp[235]: 7C66B843F5: to=de...@curis.com, relay=[mailserver].curis.com[10.2.0.20], delay=4257, status=sent (250 2.0.0 49b66393-000b34c4 Message accepted for delivery) Mar 10 08:56:51 rt3-curis-com postfix/smtp[235]: 7C66B843F5: to=rcur...@curis.com, relay=[mailserver].curis.com[10.2.0.20], delay=4257, status=sent (250 2.0.0 49b66393-000b34c4 Message accepted for delivery) Mar 10 08:56:51 rt3-curis-com postfix/qmgr[219]: 6D778843F4: removed Mar 10 08:56:51 rt3-curis-com postfix/qmgr[219]: 7C66B843F5: removed Here, 6D778843F4 wakes up Postfix to the presence of 7C66B843F5, whose message-id and delay value point at it having been submitted 71 minutes earlier with 2A4DE8438B. And from /var/log/httpd/error.log Which seems to be 4 hours ahead... UTC vs EDT? I wouldn't expect to see that discrepancy on MacOS X... [Tue Mar 10 11:45:54 2009] [info]: rt-3.8.1-212-1236685553-588.30085-...@curis.com #30085/1657 - Scrip 3 On Create Autoreply To Requestors (/opt/rt3/bin/../lib/RT/Action/SendEmail.pm:302) [Tue Mar 10 11:45:54 2009] [info]: rt-3.8.1-212-1236685553-588.30085-...@curis.com sent To: mbo...@curis.com (/opt/rt3/bin/../lib/RT/Action/SendEmail.pm:333) [Tue Mar 10 11:45:54 2009] [info]: rt-3.8.1-212-1236685553-104.30085-...@curis.com #30085/1657 - Scrip 4 On Create Notify AdminCcs (/opt/rt3/bin/../lib/RT/Action/SendEmail.pm:302) [Tue Mar 10 11:45:54 2009] [info]: rt-3.8.1-212-1236685553-104.30085-...@curis.com sent Bcc: d...@curis.com, de...@curis.com, rcur...@curis.com (/opt/rt3/bin/../lib/RT/Action/SendEmail.pm:333) And that answers the why? question. RT is sending that message with Bcc's (normal) which resulted in it not being ready for pickup back when 2A4DE8438B went out. [Tue Mar 10 11:45:54 2009] [info]: Ticket 30085 created in queue 'Facilities' by mbo...@curis.com (/opt/rt3/bin/../lib/RT/Ticket_Overlay.pm:659) [Tue Mar 10 12:56:13 2009] [info]: Successful login for dens from 10.2.2.9 (/opt/rt3/share/html/autohandler:273) [Tue Mar 10 12:56:51 2009] [info]: rt-3.8.1-228-1236689811-14.30085-...@curis.com #30085/1660 - Scrip 2 On Owner Change Notify Owner (/opt/rt3/bin/../lib/RT/Action/SendEmail.pm:302) [Tue Mar 10 12:56:51 2009] [info]: rt-3.8.1-228-1236689811-14.30085-...@curis.com sent To: d...@curis.com (/opt/rt3/bin/../lib/RT/Action/SendEmail.pm:333) My RT_SiteConfig.PM Set($rtname, curis.com); Set($Organization, curis.com); Set($WebBaseURL, http://rt3.curis.com;); Set($OwnerEmail , 'de...@curis.com'); Set($CanonicalizeEmailAddressMatch , '@rt3\.curis\.com$'); Set($CanonicalizeEmailAddressReplace , '@curis.com'); Set($WebPath, /rt); Set($CorrespondAddress, 'corresp...@curis.com'); Set($CommentAddress , 'comm...@curis.com'); Set($SendmailPath, /usr/sbin/sendmail); Set($MessageBoxWrap, SOFT); Set($UseFriendlyToLine, 0); Set($NotifyActor, 1); Set($MessageBoxRichText, 0); Set($SMTPDebug, 1); Set($MyTicketsLength, 30); Set($DefaultSummaryRows, 30); You *MIGHT* be able to get better behavior by adjusting the mail parameters that RT is using. The defaults are reasonable for Real Sendmail and for the sendmail compatibility interface of Postfix as Postfix is commonly configured on many Linux and *BSD systems, but it is really not suited for the modified (and somewhat old) Postfix that Apple ships on MacOS X with a desktop-oriented configuration. You might find that using 'sendmail' instead of 'sendmailpipe' for $MailCommand and adjusting $SendmailArguments (no -t) makes the whole issue vanish. On 3/19/09 9:21 AM, Derek Cunningham de...@curis.com wrote: Sure enough, it was the postfix configuration. Thanks for suggesting it Bill - I just put default Postfix (not Apple
Re: [rt-users] Email delay on ticket creation - SOLVED
On 3/12/09 10:45 AM, Bill Cole rtusers-20090...@billmail.scconsult.com wrote: Derek Cunningham wrote, On 3/12/09 8:30 AM: Hi Bill, I really appreciate your time and helpful answers. They have certainly pointed me in the right direction, and I'll update the list when I have it solved. It's been a bit of a challenge to make this run on Mac OS X, all kinds of different preinstalled software points to that it 'should' work easily, but time and time again I find myself fighting against what should be simple config changes that have been harder to solve than I though it should be. It is useful to keep in mind that Apple acts strategically, even when it looks like they are just being sloppy. MacOS X *Server* is a premium-priced product and has very few truly secret differences from the standard version of MacOS X that comes with a personal Mac, it is mostly a matter of configuration; the desktop version of the system is aggressively configured towards use as a personal computer that is almost exclusively used through the GUI by one person at a time. The Postfix config is an example of this, and if you want Postfix on a Mac to behave like a normal server instance of Postfix, you should either replace it altogether or at least fix the lack of wakeup settings in master.cf. That may also require you to watch out for Apple regressing the change in future updates, but it won't break anything that already works. At least I have some much more focused searches to make about the postfix config. I will try changing RT's $MailCommand and $SendmailArguments first and see if that makes the difference. Well, despite my digression on that option I think that is a second-best approach. It is something one might try if one does not have administrative control of the mail subsystem or has some need to keep the no-wakeup model. The 'sendmailpipe' option for $MailCommand is a much more efficient approach, and I wouldn't suggest switching to 'sendmail' on a high-volume RT machine. I'm not even sure that change will solve the queue delay problem completely. My hypothesis is that it will avoid the problem by serializing the queueing of messages for multiple recipients so that the Postfix 'pickup' process can't win a parallel race with a 'sendmail -oi -t' process that has to parse multiple recipients out of a Bcc header. Sure enough, it was the postfix configuration. Thanks for suggesting it Bill - I just put default Postfix (not Apple) times for wakeup on pickup, qmgr and flush in the master.cf, Apple sets them to -. I had already enabled pickup, which had things partially working, but missed qmgr and flush. Thanks for the assist! I now happily have RT 3.8.1 running on Mac OS X 10.4 client. In all reality, most services needed to make it all happen were in place, but needed to be activated and slightly reconfigured. None of it was too difficult, but none of it was exactly 'out of the box' either... -Derek ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Email delay on ticket creation
Hi Bill, I really appreciate your time and helpful answers. They have certainly pointed me in the right direction, and I'll update the list when I have it solved. It's been a bit of a challenge to make this run on Mac OS X, all kinds of different preinstalled software points to that it 'should' work easily, but time and time again I find myself fighting against what should be simple config changes that have been harder to solve than I though it should be. At least I have some much more focused searches to make about the postfix config. I will try changing RT's $MailCommand and $SendmailArguments first and see if that makes the difference. Thanks again, -Derek Cunningham On 3/11/09 6:37 PM, Bill Cole rtusers-20090...@billmail.scconsult.com wrote: Kenneth Marshall wrote, On 3/11/09 2:27 PM: On Wed, Mar 11, 2009 at 02:02:15PM -0400, Bill Cole wrote: Derek Cunningham wrote, On 3/10/09 10:54 AM: Hi If I have gone about posting my question the wrong way please let me know. Should I add my RT_SiteConfig.pm file in addition to these logs? The autoreply goes out right away, but I'm getting a lengthy delay on only the admincc messages, and only sometimes when a user submits a new request by email. It doesn't seem to matter who the user is. If anybody sees anything helpful in my log entries please tell me. If I should be including info from another log, please tell me. I would have suspected a postfix config problem, but I'm suspecting my RT config because this only happens during the condition that a user submits a new request via email. It's not primarily RT, it's primarily Postfix. I am using RT 3.8.1 on Mac OSX (10.4), postfix/sendmail to relay to our main email server with SMTP. RT is working great except for these email delays. [...] You *MIGHT* be able to get better behavior by adjusting the mail parameters that RT is using. The defaults are reasonable for Real Sendmail and for the sendmail compatibility interface of Postfix as Postfix is commonly configured on many Linux and *BSD systems, but it is really not suited for the modified (and somewhat old) Postfix that Apple ships on MacOS X with a desktop-oriented configuration. You might find that using 'sendmail' instead of 'sendmailpipe' for $MailCommand and adjusting $SendmailArguments (no -t) makes the whole issue vanish. We have been using RT since 3.2 with postfix versions 1.x and later and this sort of problem speaks to a misconfiguration of the postfix system, not a problem with the age of the release. The sendmail compatibility even in the earliest postfix releases has no problem with the way RT submits E-mail. I would recommend checking your postfix configurations. Good luck. The age is a tangential issue, but when working with Postfix on MacOS X it is helpful to know that one is dealing with an Apple-modified 2.1.x rather than Dr. Venema's 2.5.x and that the default configuration on MacOS X is an afterthought for a personal desktop system that almost never uses it. One can really fix that Postfix by replacing it with a standard modern version, adapt it to more normal use by changing the config, or adjust things that use it (like RT) to go around its flaws. I may be wrong, but I think that by using 'sendmail' instead of 'sendmailpipe' in RT, the envelope splitting task is done upstream in the Mail::Mailer part of a MIME::Entity object rather than being handed off to the sendmail binary called with a '-t' argument. That should prevent the circumstance where messages end up sitting in the queue waiting for the next external event to trigger pickup. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Email delay on ticket creation
#30085/1660 - Scrip 2 On Owner Change Notify Owner (/opt/rt3/bin/../lib/RT/Action/SendEmail.pm:302) [Tue Mar 10 12:56:51 2009] [info]: rt-3.8.1-228-1236689811-14.30085-...@curis.com sent To: d...@curis.com (/opt/rt3/bin/../lib/RT/Action/SendEmail.pm:333) My RT_SiteConfig.PM Set($rtname, curis.com); Set($Organization, curis.com); Set($WebBaseURL, http://rt3.curis.com;); Set($OwnerEmail , 'de...@curis.com'); Set($CanonicalizeEmailAddressMatch , '@rt3\.curis\.com$'); Set($CanonicalizeEmailAddressReplace , '@curis.com'); Set($WebPath, /rt); Set($CorrespondAddress, 'corresp...@curis.com'); Set($CommentAddress , 'comm...@curis.com'); Set($SendmailPath, /usr/sbin/sendmail); Set($MessageBoxWrap, SOFT); Set($UseFriendlyToLine, 0); Set($NotifyActor, 1); Set($MessageBoxRichText, 0); Set($SMTPDebug, 1); Set($MyTicketsLength, 30); Set($DefaultSummaryRows, 30); On 3/5/09 5:13 PM, Derek Cunningham de...@curis.com wrote: Hi all, I have not posted to this list in a long time. I was quite stumped for a long time trying to get sendmail configured properly on Mac OS X (client) and I finally did... So, I have a new install of RT 3.8.1 on FreeBSD (Mac OS X). I'm having trouble with what seems to be random delays in the email notifications to admincc's when a user emails in a new request. I am having a great deal of trouble figuring out where the delay is coming from, I have googled and searched RT's wiki, and I'm not coming up with anything, so I'm turning to the list for help. Most actions that generate email, the email is delivered immediately. When a user submits an email to RT that is creating a new ticket, their autoreply email is sent immediately, but then the notice to us (the admincc's) has a 'delay=5235' or other random high number in it. Performing another action in RT that generates another email makes both the new email and the as-yet-undelivered email be delivered immediately. I captured all the info I could from mail.log and httpd/system.log, and there wasn't anything related in system.log. I'm open to any ideas. In this case the delay time was set to 5842. I have seen it set to other times, usually in the thousands. If we aren't paying close attention to RT a new ticket can go unnoticed for sometimes 40 minutes, sometimes well over 2 hours... from /var/log/mail.log Mar 5 13:59:11 rt3-ourcompany-com postfix/smtpd[429]: connect from mailserver.ourcompany.com[10.2.0.20] Mar 5 13:59:11 rt3-ourcompany-com postfix/smtpd[429]: 63F9B83254: client=mailserver.ourcompany.com[10.2.0.20] Mar 5 13:59:11 rt3-ourcompany-com postfix/cleanup[432]: 63F9B83254: message-id=c5d58b2c.9f31%theu...@ourcompany.com Mar 5 13:59:11 rt3-ourcompany-com postfix/qmgr[239]: 63F9B83254: from=theu...@ourcompany.com, size=1980, nrcpt=1 (queue active) Mar 5 13:59:11 rt3-ourcompany-com postfix/smtpd[429]: disconnect from mailserver.ourcompany.com[10.2.0.20] Mar 5 13:59:14 rt3-ourcompany-com postfix/pickup[422]: 2D92F83275: uid=70 from=www Mar 5 13:59:14 rt3-ourcompany-com postfix/cleanup[432]: 2D92F83275: message-id=rt-3.8.1-408-1236279553-905.30082-...@ourcompany.com Mar 5 13:59:14 rt3-ourcompany-com postfix/qmgr[239]: 2D92F83275: from=w...@rt3.ourcompany.com, size=1814, nrcpt=1 (queue active) Mar 5 13:59:14 rt3-ourcompany-com postfix/smtp[437]: 2D92F83275: to=theu...@ourcompany.com, relay=mailserver.ourcompany.com[10.2.0.20], delay=0, status=sent (250 2.0.0 49b02102-000ac917 Message accepted for delivery) Mar 5 13:59:14 rt3-ourcompany-com postfix/qmgr[239]: 2D92F83275: removed Mar 5 13:59:15 rt3-ourcompany-com postfix/local[433]: 63F9B83254: to=facilit...@rt3.ourcompany.com, relay=local, delay=4, status=sent (delivered to command: /opt/rt3/bin/rt-mailgate --queue facilities --action correspond --url http://localhost/rt) Mar 5 13:59:15 rt3-ourcompany-com postfix/qmgr[239]: 63F9B83254: removed Above is the user submitting the request Mar 5 15:36:35 rt3-ourcompany-com postfix/pickup[491]: ECAAF833A0: uid=70 from=www Mar 5 15:36:36 rt3-ourcompany-com postfix/cleanup[492]: ECAAF833A0: message-id=rt-3.8.1-408-1236279553-1271.30082-...@ourcompany.com Mar 5 15:36:36 rt3-ourcompany-com postfix/qmgr[239]: ECAAF833A0: from=w...@rt3.ourcompany.com, size=2284, nrcpt=3 (queue active) Mar 5 15:36:36 rt3-ourcompany-com postfix/smtp[494]: ECAAF833A0: to=de...@ourcompany.com, relay=mailserver.ourcompany.com[10.2.0.20], delay=5842, status=sent (250 2.0.0 49b037d4-000acb38 Message accepted for delivery) Mar 5 15:36:36 rt3-ourcompany-com postfix/qmgr[239]: ECAAF833A0: removed Above is the user's request being relayed to us admincc's Mar 5 15:36:55 rt3-ourcompany-com postfix/pickup[491]: AA81C833AB: uid=70 from=www Mar 5 15:36:55 rt3-ourcompany-com postfix/cleanup[492]: AA81C833AB: message-id=rt-3.8.1-487-1236285414-1997.30082-...@ourcompany.com Mar 5 15:36:55 rt3-ourcompany-com postfix/qmgr[239]: AA81C833AB: from=w...@rt3.ourcompany.com, size=1003, nrcpt
[rt-users] Email delay on ticket creation
/../lib/RT/Action/SendEmail.pm:302) [Thu Mar 5 18:59:14 2009] [info]: rt-3.8.1-408-1236279553-1271.30082-...@ourcompany.com sent Bcc: d...@ourcompany.com, de...@ourcompany.com, rcur...@ourcompany.com (/opt/rt3/bin/../lib/RT/Action/SendEmail.pm:333) [Thu Mar 5 18:59:14 2009] [info]: Ticket 30082 created in queue 'Facilities' by theu...@ourcompany.com (/opt/rt3/bin/../lib/RT/Ticket_Overlay.pm:659) Above is user's request being created in httpd log Other messages have delay=0 or delay=1. Where do I go looking next? Thanks -Derek Cunningham de...@curis.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: sa...@bestpractical.com Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] Notify Owner on Steal
Hi, I have been away from the lists for a few years. I just got RT 3.8.1 up and running, and we are switching over from 1.0.7 (!). I miss a function from 1.0.7 where, when a ticket was stolen, the old owner would get an email. I found the archive here: http://www.gossamer-threads.com/lists/rt/users/79968?do=post_view_flat#79968 Without reposting the whole thing, that seems to bring up the issue, but I don't see an actual fix in there. I also looked through the wiki, but again I didn't find my fix. Assuming a ticket is owned by somebody (not Nobody), when I 'steal' the ticket from them and reassign it, the notification only goes to the new owner, not the old owner. Admittedly I'm new to scrips but I don't see how to add this function. We are still in late 'setup and testing' mode on the new RT, so any advice or maybe a config setting I missed will be accepted humbly. I am running RT 3.8.1 on Mac OS X 10.4. Thanks to everyone who has helped maintain RT over the years! Thanks, -Derek ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] RT on Mac OS X Server 10.4
I installed RT 3.4.5 on Mac OS X 10.4.3 client and have been able to get everything except mail delivery working right. Installation was a blend of the instructions on the RT wiki manual install page and OS X install page. I didn't install perl or apache, and the fixdeps/CPAN stuff worked great except one module I had to force install. I found the entire installation to go very smooth and easy. It was easier than I expected (on the third try).I'd love to hear how different people got email delivery working on OSX 10.4 client.We prefer having RT run on a separate machine, since it requires a lot of customization and we won't be running software update on the machine (who knows what Apple might decide to udpate!) and we decided it didn't require Xserve hardware and we had other spare hardware laying around, so a 10.4 client based installation on a standalone was the way to go for us. I also read that it is much more difficult to install on Server than on Client, that certainly influenced our decision. (think headless mac mini, cheap unix workstation!) Right now it's up and running on a Pismo G3 Powerbook, sitting up above my desk on a shelf with a wireless network connection. As soon as I can figure out how to get email delivery working I'll put RT on something more robust... I have a pretty good step by step instructions sheet built for OS X 10.4 client but haven't posted it yet since it's not fully functional yet...Hope this helps. If anyone can help me configure postfix/email/RT please give me a shout!We are currently using RT 1.0.7 on a Beige G3 Tower running OS X Server 10.0. Built about 6-7 years ago, it is nearing time to upgrade hardware and software...-DerekOn Jun 22, 2006, at 2:37 PM, Jason Fouks wrote:Mike,I somehow managed to get all of the perl scripts installed and it appears that the make testdeps found all of them. I then followed the instructions to add the following lines to the http config files only after I created the domain name in server admin. Location / RewriteEngine On RedirectMatch permanent (.*)/$ $1/index.html AddDefaultCharset UTF-8 SetHandler perl-script PerlHandler RT::Mason /LocationWhen you pull up the page it lists the following as the error message.The server encountered an internal error or misconfiguration and was unable to complete your request.Looking at the logs I get the following message having to do with Mason. What am I missing on this whole thing? [Thu Jun 22 13:03:16 2006] [error] Can't locate RT/Mason.pm in @INC (@INC contains: /System/Library/Perl/5.8.6/darwin-thread-multi-2level /System/Library/Perl/5.8.6 /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 /Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level /Network/Library/Perl/5.8.6 /Network/Library/Perl /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 . /usr/ /usr/lib/perl) at (eval 6) line 3.\n[Thu Jun 22 13:03:16 2006] [error] Undefined subroutine RT::Mason::handler called.\n[Thu Jun 22 13:03:16 2006] [error] Can't locate RT/Mason.pm in @INC (@INC contains: /System/Library/Perl/5.8.6/darwin-thread-multi-2level /System/Library/Perl/5.8.6 /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 /Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level /Network/Library/Perl/5.8.6 /Network/Library/Perl /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 . /usr/ /usr/lib/perl) at (eval 6) line 3.\n[Thu Jun 22 13:03:16 2006] [error] Undefined subroutine RT::Mason::handler called.\nThis has honestly been the most difficult installation of open source software I have ever run into. I am going to have to try a reinstall just so I understand it more once I get it up and running.Thanks much for any help that you can provide me. I really do appreciate it.JasonPS: Server config: OS X 10.4.6, Xcode 2.2 if I remember right.On Jun 1, 2006, at 8:55 PM, Dunne wrote:Could you possibly send me an error log from a failed install? Are you using the MySQL version that is bundled with OS X or did you run a standalone install?Mike-- Original Message --From: Jason Fouks [EMAIL PROTECTED]Date: Thu, 1 Jun 2006 20:03:31 -0500 When I installed 10.4.6 server along with Xcode 2.2 I tried using CPAN to get the any of the perl modules working and none of the perl modules seemed to go successfully. I was working with this article I found on the internet and failed at it using these directions. (https://portal.aero.und.edu/docs/general/rtosx)JasonOn Jun 1, 2006, at 12:18 PM, Michael Dunne wrote: Howdy, I managed to get it running on OS X4.6 client. Which modules are you havingdifficulty with?MikeOn 6/1/06 12:54 PM, "Jason Fouks" [EMAIL PROTECTED] wrote: I am running 10.4.6 on a test box. I am trying to get the
