The problem I have this… is when I go to update Perl from a repository, it’ll break the install and overwrite the update from CPAN. My concern isn’t how to use CPAN, my problem is having to use it at all, due to the nature of running a RHEL/CentOS system… RedHat & CentOS release patches & updates via RPM. Doing source installs on those systems is a nuisance due to the possibility of RPM’s overwriting such installs. Additionally, doing an update from CPAN will often try to upgrade Perl to the latest version of Perl, which again, RHEL/CentOS do not use on purpose. My point is, I don’t want to break my entire systems perl libraries that are installed via RPM. It will mess with the systems in ways that I cannot count on two hands. If OTRS creates an RPM for download and advertises it for use with RHEL/CentOS 5, then maybe it should truly work with those systems out of the box. If I had the .spec file or .src.rpm I’d recompile the RPM to use the older version that is the default for CentOS/RHEL. Which brings up the second question I had… Why the need for the newer version? What is required that isn’t in the older version? Regards, Tony E. Manager of Hosting Services CWIE, LLC From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Michiel Beijen Sent: Sunday, November 01, 2009 7:17 AM To: User questions and discussions about OTRS. Subject: Re: [otrs] Perl CGI version problem Hi Tony, In this case you could best install the latest CGI version using CPAN. execute the following as root: # perl -MCPAN -e shell cpan> install CGI this will install the latest CGI version right off the CPAN. -- Michiel Beijen R&D OTRS AG Norsk-Data-Str 1. 61352 Bad Homburg Deutschland T: +31 (0) 6457 42418 F: +49 (0) 9421 56818-18 I: http://www.otrs.com/ Business Location: Bad Homburg, Country Court: Bad Homburg, Commercial register: 10751, Tax ID: 003 240 97505 Chairman of the Board: Burchard Steinbild, Managing Board: André Mindermann (CEO), Martin Edenhofer CU@ IIR Service Desk Forum in Mainz (Germany) and get to know more about OTRS at booth no. 12 from Nov 24-25, 2009! On Sun, Nov 1, 2009 at 10:50 AM, Tony Evans mailto:tonye@cwie.net> wrote: Hi there, I'm running CentOS 5.4 and downloaded and installed OTRS 2.4.5 via the RPM available on your site. When running ./bin/otrs.checkModules, I get the following issue: ./ otrs.checkModules o CGI............................failed!!! Version 3.15 installed but 3.33 or higher is required! Perl::CGI comes with the base Perl package in RedHat based distros such as CentOS... Thus, rpm -qa | grep -i '^perl-5' perl-5.8.8-27.el5 However, no matter what software repository I use with 'yum', there is no higher version upgrade for Perl. So there's no possible way for me to use mod_perl with CentOS/RHEL 5.* because OTRS' requirement is too high. Is there a way to make it work? What is the requirement that is in version 3.33 and not the lower 3.15 version that OTRS makes use of? At this time, it is pointless for me to upgrade OTRS from 2.3.x or else I suffer breaking and slowing down my OTRS installation. Regards, Tony E. Manager of Hosting Services CWIE, LLC --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/

I am guessing there’s no resolution to this. My point is this: I do not want to run anything but .rpm’s. Yes, I know how to, and can utilize CPAN, but chose not to do so. If I run “yum upgrade” or “up2date” on my systems with .rpm installed Perl packages, any CPAN update I do, may potentially become overwritten. RedHat/CentOS systems are designed this way for a reason, ease of updates. Another problem with CPAN: it may decide that it needs a newer version of Perl or other module than what I have installed. Again, I want to keep my stock RPM’s. My two cents: don’t market something for CentOS/RedHat Enterprise Linux server systems if they do not work 100% with stock RPM installs. NOWHERE during the installation does it mention that my Perl::CGI version is too low to use mod_perl. I didn’t find out until I ran the Support Assessment tool under the admin section. Had I been forewarned that I’d have to use CPAN, maybe then I could have opted for another OS. But then, I wouldn’t be using RHEL/CentOS RPM’s then would I? </rant> Thank you for your time, Tony E. From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Michael Mayaka Sent: Monday, November 02, 2009 9:51 PM To: User questions and discussions about OTRS. Subject: Re: [otrs] Perl CGI version problem Hi Tony, Am using CentOS 5; Oracle 10g and Apache...otrs 2.4.5 is working "Perfectly Well" on my system; am actually running multiple instances! I installed the following modules using cpan on my system: =>CGI DBI Date::Pcalc DBD::Oracle Digest::MD5 LWP::UserAgent MIME::Base64 MIME::Tools Mail::Internet Net::DNS Net::POP3 Net::LDAP Net::SMTP Authen::SASL GD GD::Text GD::Graph GD::Graph::lines GD::Text::Align XML::Parser PDF::API2 Compress::Zlib Apache2::Reload=> =>Note:! I prefer to use the source tarball as opposed to the rpm Michael

Hi Tony, First of all, let me state that I understand your issues with using cpan versus your systems package manager. I also prefer to be 100% RPM, or DEB if that is your poison. Would it help you if we'd create RPMs for the perl modules that are not available? Internally, we have discussed this before, it is a lot of work to maintain though. We'd have similar issues with Ubuntu 9.04 and 8.10, that ship a version of PDF::API2 that is broken. There's no easy way to get around that without using CPAN, or jumping through hoops to install a package from 9.10 or 8.04, that does not have the issue. I might have an alternative for you. For convenience, we ship some pure-perl modules (those are architecture independent) in otrs/Kernel/cpan-lib. Files in this directory are added to the @INC in perl, and are chosen by OTRS over any existing modules installed on your system, but they wouldn't affect any other Perl app running on your system. In the next release (2.5.x) we have decided to add CGI.pm there, too, just so we know that the CGI version on all OTRS's would be the same. You also might want to add CGI.pm to Kernel/cpan-lib - this would not interfere with your system's package manager but does provide OTRS with an up-to-date version. You can download the file from our source control system: http://source.otrs.org/viewvc.cgi/otrs/Kernel/cpan-lib/CGI.pm?revision=1.19&... Because CGI does not adhere to the default My::Module format used by most Perl modules, CGI.pm should go right in the cpan-lib directory. Hope this helps for you, and please give us your feedback. ((enjoy)) - Michiel Beijen R&D OTRS AG Norsk-Data-Str 1. 61352 Bad Homburg Deutschland T: +31 (0) 6457 42418 F: +49 (0) 9421 56818-18 I: http://www.otrs.com/ Business Location: Bad Homburg, Country Court: Bad Homburg, Commercial register: 10751, Tax ID: 003 240 97505 Chairman of the Board: Burchard Steinbild, Managing Board: André Mindermann (CEO), Martin Edenhofer CU@ IIR Service Desk Forum in Mainz (Germany)http://www.otrs.com/en/news-and-press/news-details/article/translate-to-engl...and get to know more about OTRS at booth no. 12 from Nov 24-25, 2009! On Tue, Nov 3, 2009 at 11:48 PM, Tony Evans wrote:

I am guessing there’s no resolution to this.

My point is this: I do not want to run anything but .rpm’s. Yes, I know how to, and can utilize CPAN, but chose not to do so. If I run “yum upgrade” or “up2date” on my systems with .rpm installed Perl packages, any CPAN update I do, may potentially become overwritten. RedHat/CentOS systems are designed this way for a reason, ease of updates. Another problem with CPAN: it may decide that it needs a newer version of Perl or other module than what I have installed. Again, I want to keep my stock RPM’s.

My two cents: don’t market something for CentOS/RedHat Enterprise Linux server systems if they do not work 100% with stock RPM installs. NOWHERE during the installation does it mention that my Perl::CGI version is too low to use mod_perl. I didn’t find out until I ran the Support Assessment tool under the admin section. Had I been forewarned that I’d have to use CPAN, maybe then I could have opted for another OS. But then, I wouldn’t be using RHEL/CentOS RPM’s then would I?

</rant>

Thank you for your time,

Tony E.

*From:* otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] *On Behalf Of *Michael Mayaka *Sent:* Monday, November 02, 2009 9:51 PM

*To:* User questions and discussions about OTRS. *Subject:* Re: [otrs] Perl CGI version problem

Hi Tony,

Am using CentOS 5; Oracle 10g and Apache...otrs 2.4.5 is working "Perfectly Well" on my system; am actually running multiple instances! I installed the following modules using cpan on my system: =>CGI DBI Date::Pcalc DBD::Oracle Digest::MD5 LWP::UserAgent MIME::Base64 MIME::Tools Mail::Internet Net::DNS Net::POP3 Net::LDAP Net::SMTP Authen::SASL GD GD::Text GD::Graph GD::Graph::lines GD::Text::Align XML::Parser PDF::API2 Compress::Zlib Apache2::Reload=>

=>Note:! I prefer to use the source tarball as opposed to the rpm

Michael

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/

I agree with you all on having dependencies embedded but this lack with the meaning of os's update tools beeing in many case used to cover security and bug issue... So how could one reconcile that problems ? I'll use CPAN or yum released file ... On Wed, Nov 4, 2009 at 7:24 PM, Tony Evans wrote:

Hi Michiel,

I really like the idea of including them in OTRS in otrs/Kernel/cpan-lib. That makes sense, and is completely sane. I was unaware OTRS would chose from that directory over the systems own files, and it makes me happy to utilize this option. It would make snagging a module and making it accessible to OTRS that much easier.

I appreciate your attention to my issues with system versioning, and addressing the issue. It goes to show what a quality product you have, and how great your team is.

Many Thanks,

Tony Evans

Manager of Hosting Services

CWIE, LLC., Hosting Services Team

*From:* otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] *On Behalf Of *Michiel Beijen *Sent:* Wednesday, November 04, 2009 12:53 AM *To:* User questions and discussions about OTRS. *Subject:* Re: [otrs] Perl CGI version problem

Hi Tony,

First of all, let me state that I understand your issues with using cpan versus your systems package manager. I also prefer to be 100% RPM, or DEB if that is your poison.

Would it help you if we'd create RPMs for the perl modules that are not available? Internally, we have discussed this before, it is a lot of work to maintain though. We'd have similar issues with Ubuntu 9.04 and 8.10, that ship a version of PDF::API2 that is broken. There's no easy way to get around that without using CPAN, or jumping through hoops to install a package from 9.10 or 8.04, that does not have the issue.

I might have an alternative for you. For convenience, we ship some pure-perl modules (those are architecture independent) in otrs/Kernel/cpan-lib. Files in this directory are added to the @INC in perl, and are chosen by OTRS over any existing modules installed on your system, but they wouldn't affect any other Perl app running on your system. In the next release (2.5.x) we have decided to add CGI.pm there, too, just so we know that the CGI version on all OTRS's would be the same.

You also might want to add CGI.pm to Kernel/cpan-lib - this would not interfere with your system's package manager but does provide OTRS with an up-to-date version. You can download the file from our source control system: http://source.otrs.org/viewvc.cgi/otrs/Kernel/cpan-lib/CGI.pm?revision=1.19&... Because CGI does not adhere to the default My::Module format used by most Perl modules, CGI.pm should go right in the cpan-lib directory.

Hope this helps for you, and please give us your feedback.

((enjoy)) - Michiel Beijen R&D

OTRS AG Norsk-Data-Str 1. 61352 Bad Homburg Deutschland

T: +31 (0) 6457 42418 F: +49 (0) 9421 56818-18 I: http://www.otrs.com/

Business Location: Bad Homburg, Country Court: Bad Homburg, Commercial register: 10751, Tax ID: 003 240 97505 Chairman of the Board: Burchard Steinbild, Managing Board: André Mindermann (CEO), Martin Edenhofer

CU@ IIR Service Desk Forum in Mainz (Germany)http://www.otrs.com/en/news-and-press/news-details/article/translate-to-engl...and get to know more about OTRS at booth no. 12 from Nov 24-25, 2009!

On Tue, Nov 3, 2009 at 11:48 PM, Tony Evans wrote:

I am guessing there’s no resolution to this.

My point is this: I do not want to run anything but .rpm’s. Yes, I know how to, and can utilize CPAN, but chose not to do so. If I run “yum upgrade” or “up2date” on my systems with .rpm installed Perl packages, any CPAN update I do, may potentially become overwritten. RedHat/CentOS systems are designed this way for a reason, ease of updates. Another problem with CPAN: it may decide that it needs a newer version of Perl or other module than what I have installed. Again, I want to keep my stock RPM’s.

My two cents: don’t market something for CentOS/RedHat Enterprise Linux server systems if they do not work 100% with stock RPM installs. NOWHERE during the installation does it mention that my Perl::CGI version is too low to use mod_perl. I didn’t find out until I ran the Support Assessment tool under the admin section. Had I been forewarned that I’d have to use CPAN, maybe then I could have opted for another OS. But then, I wouldn’t be using RHEL/CentOS RPM’s then would I?

</rant>

Thank you for your time,

Tony E.

*From:* otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] *On Behalf Of *Michael Mayaka *Sent:* Monday, November 02, 2009 9:51 PM

*To:* User questions and discussions about OTRS. *Subject:* Re: [otrs] Perl CGI version problem

Hi Tony,

Am using CentOS 5; Oracle 10g and Apache...otrs 2.4.5 is working "Perfectly Well" on my system; am actually running multiple instances! I installed the following modules using cpan on my system: =>CGI DBI Date::Pcalc DBD::Oracle Digest::MD5 LWP::UserAgent MIME::Base64 MIME::Tools Mail::Internet Net::DNS Net::POP3 Net::LDAP Net::SMTP Authen::SASL GD GD::Text GD::Graph GD::Graph::lines GD::Text::Align XML::Parser PDF::API2 Compress::Zlib Apache2::Reload=>

=>Note:! I prefer to use the source tarball as opposed to the rpm

Michael

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/

Your syntax is a little off.... If this was an upgrade, you may also want to make sure your users table is not 'users' instead of 'system_user2' also. $Self->{DatabaseDSN} = "DBI:ODBC:driver={SQL Server};Server=server\SQLEXPRESS,1433;database=OTRS;uid=otrsuser;pwd=123456;"; $Self->{"Database::Type"} = 'mssql'; $Self->{DatabaseUserTable} = 'users'; Daniel From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Luis Fernando Giraldo Galeano Sent: Wednesday, November 04, 2009 3:29 PM To: User questions and discussions about OTRS. Subject: [otrs] Problem install OTRS and MS SQL Server 2005 Express Excuse me I do not speak English only Spanish. I'm installing OTRS 2.4.5 with MSSQL 2005 and is showing me the following error ERROR: OTRS-CGI-10 Perl: 5.10.0 OS: MSWin32 Time: Wed Nov 4 15:25:56 2009 Message: [Microsoft][Administrador de controladores ODBC] No se encuentra el nombre del origen de datos y no se especificó ningún controlador predeterminado (SQL-IM002) Traceback (1368): Module: Kernel::System::DB::new (v1.105.2.1) Line: 188 Module: Kernel::System::Web::InterfaceAgent::Run (v1.43.2.1) Line: 143 Module: C:/Archivos de programa/OTRS/OTRS/bin/cgi-bin/index.pl (v1.88) Line: 48 To connect to the database I am using the following command $Self->{DatabaseDSN}="DBI:ODBC:otrs={SQL Server};Server=99MESA03\SQLEXPRESS,1433;database=otrs;uid=sa;pwd=123456;"; $Self->{"Database::Type"}='mssql'; $Self->{DatabaseUserTable}='System_user2'; It is where my problem might help me. Cordialmente, Luis Fernando Giraldo G. Auxiliar Mesa de Ayuda Cooperativa San Pio X - COOGRANADA Tel. (054) 571 81 82 Ext. 111 E-mail lgiraldo@coogranada.com.co mailto:lgiraldo@coogranada.com.co "Las opiniones contenidas en este mensaje no necesariamente coinciden con las posiciones institucionales de la Cooperativa COOGRANADA. La informacion y todos sus anexos es confidencial y privilegiada y solo puede ser utilizada por sus destinatarios. Si por error usted recibe este mensaje le ofrecemos disculpas, solicitamos eliminarlo de inmediato, notificarle de su error a la persona que lo envio y abstenerse de utilizar su contenido" P Antes de imprimir este e-mail piense si realmente es necesario hacerlo, el medio ambiente se lo agradecerá ********************************************************************** This email and any files transmitted with it are confidential and intended for use only by the individual or entity named above. If you are not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, dissemination, distribution, copying of this communication, or unauthorized use is strictly prohibited. Please notify us immediately by reply email and then delete this message from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Randolph County Government. This email and any file attachments have been scanned for potential viruses; however, the recipient should check this email for the presence of viruses and/or malicious code. Randolph County accepts no liability for any damage transmitted via this email.