Re: [rt-users] Frustrating attempts to install RT3.8 from RPM

[Gary Greene]

The CentOS version is currently 3.8.1, so they're not really a good fit at
this time. The SuSE ones are 3.8.8. If you're still interested in them, I
can put them on a server outside my office for download (bandwidth at work
is lacking.)

Far as I know, the changes in /etc are marked config noreplace, however,
changing them to config save is fairly easy in the srpm.


On 3/11/10 5:24 PM, "Wes Modes"  wrote:

> That is nice to see that you made a well-crafted rpm that you can be
> proud of.   I wonder what would happen if a later version of RT3 became
> available via EPEL.  Would it nicely replace the files (maybe moving
> stuff to rpmsave's)  or would all hell break loose?
> 
> What RT3 version is your centos rpm build?
> 
> When and where would your centos rpm be available to play with?
> 
> W.
> 
> On 11/3/2010 4:45 PM, Gary Greene wrote:
>> The CentOS ones follow the RH way of directory layout, with the caveat that
>> I chose to put the other modules that normally get pulled in via cpan in the
>> perl5 site_lib hierarchy to assure that a rouge update from rpmforge or
>> upstream CentOS would be able to be installed without odd file conflicts.
>> 
>> The SuSE ones I did slightly differently as I think having the main RT stuff
>> strewn around /usr a little odd. The CPAN stuff is in the perl5 site_lib
>> hierarchy as before, but the main HTML/Mason templates/RT only specific
>> modules/plugins stuff are in /srv/www/htdocs/rt. Configuration stuff is in
>> /etc/rt and the plugin configuration directory is /etc/rt/local/...
>> 
>> If I were to do over the CentOS ones, I'd likely do the same as I did with
>> SuSE.
>> 
>> On 3/11/10 4:36 PM, "Wes Modes"  wrote:
>> 
>>> I presume that is CentOS5.  That would make me very happy as CentOS RPMs
>>> should work for RHEL.
>>> 
>>> One thing I adore about well-built packages is that things are placed in
>>> the right location for the OS.  For instance, the RT3 rpms put all the
>>> config files in /etc, all the perl modules in the perl modules dir, and
>>> the various tools in /usr/bin and /usr/sbin.
>>> 
>>> Is yours built that way, or does it keep to the Best Practical distro
>>> locations?
>>> 
>>> i guess this means that no one has a solution to the problem I observed
>>> with the rpm bundle I did find, ya?
>>> 
>>> Wes
>>> 
>>> 
>>> On 11/3/2010 11:52 AM, Gary Greene wrote:
 Agreed. This is why I spent a week with cpan2rpm and built packages for
 both
 openSuSE (which we're transitioning to) and CentOS.
 
 
 On 3/11/10 11:21 AM, "Wes Modes"  wrote:
 
> Paul, sounds like you aren't a long term fan of Fedora, RHEL, or CentOS,
> so I'm guessing yum feels like an inconvenience to you, especially when
> it seems to be getting in the way of your desired install.
> 
> I've been a sysadmin for 20 years and I've never been a fan of the make
> 'n' break style of system administration.  There is no way I could
> manage a score of machines, many with subtly different hardware, if I
> had to build every package the old way.  As it is, I can spend a few
> hours monthly updating the OS and all installed software on all of our
> machines, with a simple "yum -y update"
> 
> In my opinion, package managers like apt-get and yum are some of the
> best things to happen to OS in a very long time.  Having installs
> tracked and managed by package managers keeps complicated OSs and their
> installed software up-to-date, eases system administration (especially
> as the server to sysadmin ratio increases), increases scalability,
> increases sysadmin efficiency, and creates standards for software
> manufacturers.
> 
> If as a conservative sysadmin you prefer to operate well-back from the
> bleeding edge anyway, the small trade-off in control is a small price to
> pay.
> 
> It is hardly the package manager's fault if a software manufacturer such
> as Best Practical and its user community fail to create a package for
> the latest software.  Compare that to software whose RPMs are kept
> relatively up-to-date.
> 
> Wes
> 
> On 11/2/2010 3:49 PM, Paul wrote:
>> On 11/02/2010 02:19 PM, Wes Modes wrote:
>>> Hello, I have been struggling with attempts to install RT3.8 via RPMs.
>>> 
>>> I know it is perfectly possible to install RT3.8 using the BP install
>>> scripts and docs, but I'd prefer to do it through yum for system
>>> sustainability, ease of updates and upgrades, etc.
>> ...
>>> If I can't resolve this, I will just forget about RT3.8 and stick with
>>> RT3.6 of which there is a well-behaved RPM already in the EPEL repo.
>>> 
>>> Wes
>>> 
>> I'm currently going through a RT move from freebsd to rhel5 (long story,
>> would rather stay with freebsd but don't have a choice here) and have
>> found all kinds of annoying difficulties with yum (or, rather, the
>> packages availabl

Re: [rt-users] Frustrating attempts to install RT3.8 from RPM

[Wes Modes]

That is nice to see that you made a well-crafted rpm that you can be
proud of.   I wonder what would happen if a later version of RT3 became
available via EPEL.  Would it nicely replace the files (maybe moving
stuff to rpmsave's)  or would all hell break loose?

What RT3 version is your centos rpm build?

When and where would your centos rpm be available to play with?

W.

On 11/3/2010 4:45 PM, Gary Greene wrote:
> The CentOS ones follow the RH way of directory layout, with the caveat that
> I chose to put the other modules that normally get pulled in via cpan in the
> perl5 site_lib hierarchy to assure that a rouge update from rpmforge or
> upstream CentOS would be able to be installed without odd file conflicts.
>
> The SuSE ones I did slightly differently as I think having the main RT stuff
> strewn around /usr a little odd. The CPAN stuff is in the perl5 site_lib
> hierarchy as before, but the main HTML/Mason templates/RT only specific
> modules/plugins stuff are in /srv/www/htdocs/rt. Configuration stuff is in
> /etc/rt and the plugin configuration directory is /etc/rt/local/...
>
> If I were to do over the CentOS ones, I'd likely do the same as I did with
> SuSE.
>
> On 3/11/10 4:36 PM, "Wes Modes"  wrote:
>
>> I presume that is CentOS5.  That would make me very happy as CentOS RPMs
>> should work for RHEL.
>>
>> One thing I adore about well-built packages is that things are placed in
>> the right location for the OS.  For instance, the RT3 rpms put all the
>> config files in /etc, all the perl modules in the perl modules dir, and
>> the various tools in /usr/bin and /usr/sbin.
>>
>> Is yours built that way, or does it keep to the Best Practical distro
>> locations?
>>
>> i guess this means that no one has a solution to the problem I observed
>> with the rpm bundle I did find, ya?
>>
>> Wes
>>
>>
>> On 11/3/2010 11:52 AM, Gary Greene wrote:
>>> Agreed. This is why I spent a week with cpan2rpm and built packages for both
>>> openSuSE (which we're transitioning to) and CentOS.
>>>
>>>
>>> On 3/11/10 11:21 AM, "Wes Modes"  wrote:
>>>
 Paul, sounds like you aren't a long term fan of Fedora, RHEL, or CentOS,
 so I'm guessing yum feels like an inconvenience to you, especially when
 it seems to be getting in the way of your desired install.

 I've been a sysadmin for 20 years and I've never been a fan of the make
 'n' break style of system administration.  There is no way I could
 manage a score of machines, many with subtly different hardware, if I
 had to build every package the old way.  As it is, I can spend a few
 hours monthly updating the OS and all installed software on all of our
 machines, with a simple "yum -y update"

 In my opinion, package managers like apt-get and yum are some of the
 best things to happen to OS in a very long time.  Having installs
 tracked and managed by package managers keeps complicated OSs and their
 installed software up-to-date, eases system administration (especially
 as the server to sysadmin ratio increases), increases scalability,
 increases sysadmin efficiency, and creates standards for software
 manufacturers. 

 If as a conservative sysadmin you prefer to operate well-back from the
 bleeding edge anyway, the small trade-off in control is a small price to
 pay.

 It is hardly the package manager's fault if a software manufacturer such
 as Best Practical and its user community fail to create a package for
 the latest software.  Compare that to software whose RPMs are kept
 relatively up-to-date.

 Wes

 On 11/2/2010 3:49 PM, Paul wrote:
> On 11/02/2010 02:19 PM, Wes Modes wrote:
>> Hello, I have been struggling with attempts to install RT3.8 via RPMs.
>>
>> I know it is perfectly possible to install RT3.8 using the BP install
>> scripts and docs, but I'd prefer to do it through yum for system
>> sustainability, ease of updates and upgrades, etc.
> ...
>> If I can't resolve this, I will just forget about RT3.8 and stick with
>> RT3.6 of which there is a well-behaved RPM already in the EPEL repo.
>>
>> Wes
>>
> I'm currently going through a RT move from freebsd to rhel5 (long story,
> would rather stay with freebsd but don't have a choice here) and have
> found all kinds of annoying difficulties with yum (or, rather, the
> packages available.) When I realized that I was trying to stick with yum
> for ease of upgrades when yum was preventing me from easily keeping up
> to date, life got a lot easier.
>
> In the end I just let cpan install what it could and used yum for the
> things that gave me trouble in cpan. Using RT's configure and make
> targets is a lot easier and much more maintainable than having to roll
> my own rpm just to do it the yum way.
>
> Being stuck with an old version of the software in the name of easy
> upgrades didn't mak

Re: [rt-users] Frustrating attempts to install RT3.8 from RPM

[Gary Greene]

The CentOS ones follow the RH way of directory layout, with the caveat that
I chose to put the other modules that normally get pulled in via cpan in the
perl5 site_lib hierarchy to assure that a rouge update from rpmforge or
upstream CentOS would be able to be installed without odd file conflicts.

The SuSE ones I did slightly differently as I think having the main RT stuff
strewn around /usr a little odd. The CPAN stuff is in the perl5 site_lib
hierarchy as before, but the main HTML/Mason templates/RT only specific
modules/plugins stuff are in /srv/www/htdocs/rt. Configuration stuff is in
/etc/rt and the plugin configuration directory is /etc/rt/local/...

If I were to do over the CentOS ones, I'd likely do the same as I did with
SuSE.

On 3/11/10 4:36 PM, "Wes Modes"  wrote:

> I presume that is CentOS5.  That would make me very happy as CentOS RPMs
> should work for RHEL.
> 
> One thing I adore about well-built packages is that things are placed in
> the right location for the OS.  For instance, the RT3 rpms put all the
> config files in /etc, all the perl modules in the perl modules dir, and
> the various tools in /usr/bin and /usr/sbin.
> 
> Is yours built that way, or does it keep to the Best Practical distro
> locations?
> 
> i guess this means that no one has a solution to the problem I observed
> with the rpm bundle I did find, ya?
> 
> Wes
> 
> 
> On 11/3/2010 11:52 AM, Gary Greene wrote:
>> Agreed. This is why I spent a week with cpan2rpm and built packages for both
>> openSuSE (which we're transitioning to) and CentOS.
>> 
>> 
>> On 3/11/10 11:21 AM, "Wes Modes"  wrote:
>> 
>>> Paul, sounds like you aren't a long term fan of Fedora, RHEL, or CentOS,
>>> so I'm guessing yum feels like an inconvenience to you, especially when
>>> it seems to be getting in the way of your desired install.
>>> 
>>> I've been a sysadmin for 20 years and I've never been a fan of the make
>>> 'n' break style of system administration.  There is no way I could
>>> manage a score of machines, many with subtly different hardware, if I
>>> had to build every package the old way.  As it is, I can spend a few
>>> hours monthly updating the OS and all installed software on all of our
>>> machines, with a simple "yum -y update"
>>> 
>>> In my opinion, package managers like apt-get and yum are some of the
>>> best things to happen to OS in a very long time.  Having installs
>>> tracked and managed by package managers keeps complicated OSs and their
>>> installed software up-to-date, eases system administration (especially
>>> as the server to sysadmin ratio increases), increases scalability,
>>> increases sysadmin efficiency, and creates standards for software
>>> manufacturers. 
>>> 
>>> If as a conservative sysadmin you prefer to operate well-back from the
>>> bleeding edge anyway, the small trade-off in control is a small price to
>>> pay.
>>> 
>>> It is hardly the package manager's fault if a software manufacturer such
>>> as Best Practical and its user community fail to create a package for
>>> the latest software.  Compare that to software whose RPMs are kept
>>> relatively up-to-date.
>>> 
>>> Wes
>>> 
>>> On 11/2/2010 3:49 PM, Paul wrote:
 On 11/02/2010 02:19 PM, Wes Modes wrote:
> Hello, I have been struggling with attempts to install RT3.8 via RPMs.
> 
> I know it is perfectly possible to install RT3.8 using the BP install
> scripts and docs, but I'd prefer to do it through yum for system
> sustainability, ease of updates and upgrades, etc.
 ...
> If I can't resolve this, I will just forget about RT3.8 and stick with
> RT3.6 of which there is a well-behaved RPM already in the EPEL repo.
> 
> Wes
> 
 I'm currently going through a RT move from freebsd to rhel5 (long story,
 would rather stay with freebsd but don't have a choice here) and have
 found all kinds of annoying difficulties with yum (or, rather, the
 packages available.) When I realized that I was trying to stick with yum
 for ease of upgrades when yum was preventing me from easily keeping up
 to date, life got a lot easier.
 
 In the end I just let cpan install what it could and used yum for the
 things that gave me trouble in cpan. Using RT's configure and make
 targets is a lot easier and much more maintainable than having to roll
 my own rpm just to do it the yum way.
 
 Being stuck with an old version of the software in the name of easy
 upgrades didn't make sense to me.
 
 Cheers,
 Paul

-- 
Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Cell:   (650) 704-6633
Office: (408) 240-1239

Re: [rt-users] Frustrating attempts to install RT3.8 from RPM

[Wes Modes]

I presume that is CentOS5.  That would make me very happy as CentOS RPMs
should work for RHEL.

One thing I adore about well-built packages is that things are placed in
the right location for the OS.  For instance, the RT3 rpms put all the
config files in /etc, all the perl modules in the perl modules dir, and
the various tools in /usr/bin and /usr/sbin.

Is yours built that way, or does it keep to the Best Practical distro
locations?

i guess this means that no one has a solution to the problem I observed
with the rpm bundle I did find, ya?

Wes


On 11/3/2010 11:52 AM, Gary Greene wrote:
> Agreed. This is why I spent a week with cpan2rpm and built packages for both
> openSuSE (which we're transitioning to) and CentOS.
>
>
> On 3/11/10 11:21 AM, "Wes Modes"  wrote:
>
>> Paul, sounds like you aren't a long term fan of Fedora, RHEL, or CentOS,
>> so I'm guessing yum feels like an inconvenience to you, especially when
>> it seems to be getting in the way of your desired install.
>>
>> I've been a sysadmin for 20 years and I've never been a fan of the make
>> 'n' break style of system administration.  There is no way I could
>> manage a score of machines, many with subtly different hardware, if I
>> had to build every package the old way.  As it is, I can spend a few
>> hours monthly updating the OS and all installed software on all of our
>> machines, with a simple "yum -y update"
>>
>> In my opinion, package managers like apt-get and yum are some of the
>> best things to happen to OS in a very long time.  Having installs
>> tracked and managed by package managers keeps complicated OSs and their
>> installed software up-to-date, eases system administration (especially
>> as the server to sysadmin ratio increases), increases scalability,
>> increases sysadmin efficiency, and creates standards for software
>> manufacturers. 
>>
>> If as a conservative sysadmin you prefer to operate well-back from the
>> bleeding edge anyway, the small trade-off in control is a small price to
>> pay.
>>
>> It is hardly the package manager's fault if a software manufacturer such
>> as Best Practical and its user community fail to create a package for
>> the latest software.  Compare that to software whose RPMs are kept
>> relatively up-to-date.
>>
>> Wes
>>
>> On 11/2/2010 3:49 PM, Paul wrote:
>>> On 11/02/2010 02:19 PM, Wes Modes wrote:
 Hello, I have been struggling with attempts to install RT3.8 via RPMs.

 I know it is perfectly possible to install RT3.8 using the BP install
 scripts and docs, but I'd prefer to do it through yum for system
 sustainability, ease of updates and upgrades, etc.
>>> ...
 If I can't resolve this, I will just forget about RT3.8 and stick with
 RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

 Wes

>>> I'm currently going through a RT move from freebsd to rhel5 (long story,
>>> would rather stay with freebsd but don't have a choice here) and have
>>> found all kinds of annoying difficulties with yum (or, rather, the
>>> packages available.) When I realized that I was trying to stick with yum
>>> for ease of upgrades when yum was preventing me from easily keeping up
>>> to date, life got a lot easier.
>>>
>>> In the end I just let cpan install what it could and used yum for the
>>> things that gave me trouble in cpan. Using RT's configure and make
>>> targets is a lot easier and much more maintainable than having to roll
>>> my own rpm just to do it the yum way.
>>>
>>> Being stuck with an old version of the software in the name of easy
>>> upgrades didn't make sense to me.
>>>
>>> Cheers,
>>> Paul

Re: [rt-users] Frustrating attempts to install RT3.8 from RPM

[Darin Perusich]

A few questions about your openSuSE packages. Are you using the
devel:languages:/perl repository for your perl dependencies? Would you
be willing to make your rpms available or at least the .spec? 

--
Darin Perusich
Email: darin.perus...@ctg.com
Office: 716-888-3690
Cell: 716-807-4589


> -Original Message-
> From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users-
> boun...@lists.bestpractical.com] On Behalf Of Gary Greene
> Sent: Wednesday, November 03, 2010 2:52 PM
> To: Wes Modes; rt-users@lists.bestpractical.com
> Subject: Re: [rt-users] Frustrating attempts to install RT3.8 from RPM
> 
> Agreed. This is why I spent a week with cpan2rpm and built packages
for
> both
> openSuSE (which we're transitioning to) and CentOS.
> 
> 
> On 3/11/10 11:21 AM, "Wes Modes"  wrote:
> 
> > Paul, sounds like you aren't a long term fan of Fedora, RHEL, or
> CentOS,
> > so I'm guessing yum feels like an inconvenience to you, especially
> when
> > it seems to be getting in the way of your desired install.
> >
> > I've been a sysadmin for 20 years and I've never been a fan of the
> make
> > 'n' break style of system administration.  There is no way I could
> > manage a score of machines, many with subtly different hardware, if
I
> > had to build every package the old way.  As it is, I can spend a few
> > hours monthly updating the OS and all installed software on all of
> our
> > machines, with a simple "yum -y update"
> >
> > In my opinion, package managers like apt-get and yum are some of the
> > best things to happen to OS in a very long time.  Having installs
> > tracked and managed by package managers keeps complicated OSs and
> their
> > installed software up-to-date, eases system administration
> (especially
> > as the server to sysadmin ratio increases), increases scalability,
> > increases sysadmin efficiency, and creates standards for software
> > manufacturers.
> >
> > If as a conservative sysadmin you prefer to operate well-back from
> the
> > bleeding edge anyway, the small trade-off in control is a small
price
> to
> > pay.
> >
> > It is hardly the package manager's fault if a software manufacturer
> such
> > as Best Practical and its user community fail to create a package
for
> > the latest software.  Compare that to software whose RPMs are kept
> > relatively up-to-date.
> >
> > Wes
> >
> > On 11/2/2010 3:49 PM, Paul wrote:
> >> On 11/02/2010 02:19 PM, Wes Modes wrote:
> >>> Hello, I have been struggling with attempts to install RT3.8 via
> RPMs.
> >>>
> >>> I know it is perfectly possible to install RT3.8 using the BP
> install
> >>> scripts and docs, but I'd prefer to do it through yum for system
> >>> sustainability, ease of updates and upgrades, etc.
> >> ...
> >>> If I can't resolve this, I will just forget about RT3.8 and stick
> with
> >>> RT3.6 of which there is a well-behaved RPM already in the EPEL
> repo.
> >>>
> >>> Wes
> >>>
> >> I'm currently going through a RT move from freebsd to rhel5 (long
> story,
> >> would rather stay with freebsd but don't have a choice here) and
> have
> >> found all kinds of annoying difficulties with yum (or, rather, the
> >> packages available.) When I realized that I was trying to stick
with
> yum
> >> for ease of upgrades when yum was preventing me from easily keeping
> up
> >> to date, life got a lot easier.
> >>
> >> In the end I just let cpan install what it could and used yum for
> the
> >> things that gave me trouble in cpan. Using RT's configure and make
> >> targets is a lot easier and much more maintainable than having to
> roll
> >> my own rpm just to do it the yum way.
> >>
> >> Being stuck with an old version of the software in the name of easy
> >> upgrades didn't make sense to me.
> >>
> >> Cheers,
> >> Paul
> 
> --
> Gary L. Greene, Jr.
> IT Operations
> Minerva Networks, Inc.
> Cell:   (650) 704-6633
> Office: (408) 240-1239
> 

The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you are not the intended recipient of this 
message, please contact the sender and delete this material from this computer.

Re: [rt-users] Frustrating attempts to install RT3.8 from RPM

[Gary Greene]

Agreed. This is why I spent a week with cpan2rpm and built packages for both
openSuSE (which we're transitioning to) and CentOS.


On 3/11/10 11:21 AM, "Wes Modes"  wrote:

> Paul, sounds like you aren't a long term fan of Fedora, RHEL, or CentOS,
> so I'm guessing yum feels like an inconvenience to you, especially when
> it seems to be getting in the way of your desired install.
> 
> I've been a sysadmin for 20 years and I've never been a fan of the make
> 'n' break style of system administration.  There is no way I could
> manage a score of machines, many with subtly different hardware, if I
> had to build every package the old way.  As it is, I can spend a few
> hours monthly updating the OS and all installed software on all of our
> machines, with a simple "yum -y update"
> 
> In my opinion, package managers like apt-get and yum are some of the
> best things to happen to OS in a very long time.  Having installs
> tracked and managed by package managers keeps complicated OSs and their
> installed software up-to-date, eases system administration (especially
> as the server to sysadmin ratio increases), increases scalability,
> increases sysadmin efficiency, and creates standards for software
> manufacturers. 
> 
> If as a conservative sysadmin you prefer to operate well-back from the
> bleeding edge anyway, the small trade-off in control is a small price to
> pay.
> 
> It is hardly the package manager's fault if a software manufacturer such
> as Best Practical and its user community fail to create a package for
> the latest software.  Compare that to software whose RPMs are kept
> relatively up-to-date.
> 
> Wes
> 
> On 11/2/2010 3:49 PM, Paul wrote:
>> On 11/02/2010 02:19 PM, Wes Modes wrote:
>>> Hello, I have been struggling with attempts to install RT3.8 via RPMs.
>>> 
>>> I know it is perfectly possible to install RT3.8 using the BP install
>>> scripts and docs, but I'd prefer to do it through yum for system
>>> sustainability, ease of updates and upgrades, etc.
>> ...
>>> If I can't resolve this, I will just forget about RT3.8 and stick with
>>> RT3.6 of which there is a well-behaved RPM already in the EPEL repo.
>>> 
>>> Wes
>>> 
>> I'm currently going through a RT move from freebsd to rhel5 (long story,
>> would rather stay with freebsd but don't have a choice here) and have
>> found all kinds of annoying difficulties with yum (or, rather, the
>> packages available.) When I realized that I was trying to stick with yum
>> for ease of upgrades when yum was preventing me from easily keeping up
>> to date, life got a lot easier.
>> 
>> In the end I just let cpan install what it could and used yum for the
>> things that gave me trouble in cpan. Using RT's configure and make
>> targets is a lot easier and much more maintainable than having to roll
>> my own rpm just to do it the yum way.
>> 
>> Being stuck with an old version of the software in the name of easy
>> upgrades didn't make sense to me.
>> 
>> Cheers,
>> Paul

-- 
Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Cell:   (650) 704-6633
Office: (408) 240-1239

Re: [rt-users] Frustrating attempts to install RT3.8 from RPM

[Wes Modes]

Paul, sounds like you aren't a long term fan of Fedora, RHEL, or CentOS,
so I'm guessing yum feels like an inconvenience to you, especially when
it seems to be getting in the way of your desired install.

I've been a sysadmin for 20 years and I've never been a fan of the make
'n' break style of system administration.  There is no way I could
manage a score of machines, many with subtly different hardware, if I
had to build every package the old way.  As it is, I can spend a few
hours monthly updating the OS and all installed software on all of our
machines, with a simple "yum -y update"

In my opinion, package managers like apt-get and yum are some of the
best things to happen to OS in a very long time.  Having installs
tracked and managed by package managers keeps complicated OSs and their
installed software up-to-date, eases system administration (especially
as the server to sysadmin ratio increases), increases scalability,
increases sysadmin efficiency, and creates standards for software
manufacturers. 

If as a conservative sysadmin you prefer to operate well-back from the
bleeding edge anyway, the small trade-off in control is a small price to
pay.

It is hardly the package manager's fault if a software manufacturer such
as Best Practical and its user community fail to create a package for
the latest software.  Compare that to software whose RPMs are kept
relatively up-to-date. 

Wes

On 11/2/2010 3:49 PM, Paul wrote:
> On 11/02/2010 02:19 PM, Wes Modes wrote:
>> Hello, I have been struggling with attempts to install RT3.8 via RPMs.  
>>
>> I know it is perfectly possible to install RT3.8 using the BP install
>> scripts and docs, but I'd prefer to do it through yum for system
>> sustainability, ease of updates and upgrades, etc.
> ...
>> If I can't resolve this, I will just forget about RT3.8 and stick with
>> RT3.6 of which there is a well-behaved RPM already in the EPEL repo.
>>
>> Wes
>>
> I'm currently going through a RT move from freebsd to rhel5 (long story,
> would rather stay with freebsd but don't have a choice here) and have
> found all kinds of annoying difficulties with yum (or, rather, the
> packages available.) When I realized that I was trying to stick with yum
> for ease of upgrades when yum was preventing me from easily keeping up
> to date, life got a lot easier.
>
> In the end I just let cpan install what it could and used yum for the
> things that gave me trouble in cpan. Using RT's configure and make
> targets is a lot easier and much more maintainable than having to roll
> my own rpm just to do it the yum way.
>
> Being stuck with an old version of the software in the name of easy
> upgrades didn't make sense to me.
>
> Cheers,
> Paul

Re: [rt-users] Frustrating attempts to install RT3.8 from RPM

[Paul]

On 11/02/2010 02:19 PM, Wes Modes wrote:
> Hello, I have been struggling with attempts to install RT3.8 via RPMs.  
> 
> I know it is perfectly possible to install RT3.8 using the BP install
> scripts and docs, but I'd prefer to do it through yum for system
> sustainability, ease of updates and upgrades, etc.
...
> 
> If I can't resolve this, I will just forget about RT3.8 and stick with
> RT3.6 of which there is a well-behaved RPM already in the EPEL repo.
> 
> Wes
> 

I'm currently going through a RT move from freebsd to rhel5 (long story,
would rather stay with freebsd but don't have a choice here) and have
found all kinds of annoying difficulties with yum (or, rather, the
packages available.) When I realized that I was trying to stick with yum
for ease of upgrades when yum was preventing me from easily keeping up
to date, life got a lot easier.

In the end I just let cpan install what it could and used yum for the
things that gave me trouble in cpan. Using RT's configure and make
targets is a lot easier and much more maintainable than having to roll
my own rpm just to do it the yum way.

Being stuck with an old version of the software in the name of easy
upgrades didn't make sense to me.

Cheers,
Paul

[rt-users] Frustrating attempts to install RT3.8 from RPM

[Wes Modes]

Hello, I have been struggling with attempts to install RT3.8 via RPMs.  

I know it is perfectly possible to install RT3.8 using the BP install
scripts and docs, but I'd prefer to do it through yum for system
sustainability, ease of updates and upgrades, etc.

These instructions show how to set up a local repo and install RT from a
bundle, but for version 3.6. 

*Installing RT 3.6.6 on Redhat Enterprise 5.x (using yum to install
from a bundle)*
http://wiki.bestpractical.com/view/Rhel5InstallGuide

(keep this link, because it is hard to find and all of the sometimes
contradictory RT docs look the same)

However there is a similar bundle for 3.8.7, so maybe that would work.

According to the install doc, we install a host of services first:

[r...@testbench1]# yum -y update

[r...@testbench1]# yum -y install httpd

[r...@testbench1]# yum -y install mysql mysql-server sendmail-cf

Start these services:

[r...@testbench1]# service mysqld start
Starting MySQL:[  OK  ]
[r...@testbench1]# service httpd start
Starting httpd:[  OK  ]
[r...@testbench1]# chkconfig httpd on
[r...@testbench1]# chkconfig mysqld on

The docs call for downloading this bundle: 

http://www.jwhite3.com/files/rt/rt-3.6.6-bundle.tar.gz

but we are going to be downloading the 3.8.7 bundle

[r...@testbench1]# cd
[r...@testbench1]# pwd
/root
[r...@testbench1]# mkdir rt3
[r...@testbench1]# cd rt3
[r...@testbench1]# wget http://www.jwhite3.com/files/rt/rt_3.8.7_bundle.zip
--2010-10-29 16:18:39--  http://www.jwhite3.com/files/rt/rt_3.8.7_bundle.zip
Resolving www.jwhite3.com ... 97.74.144.177
Connecting to www.jwhite3.com|97.74.144.177|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 38577186 (37M) [application/zip]
Saving to: `rt_3.8.7_bundle.zip'

100%[>] 38,577,186  4.87M/s   in 
7.8s

2010-10-29 16:18:47 (4.72 MB/s) - `rt_3.8.7_bundle.zip' saved 
[38577186/38577186]

Unpack:

[r...@testbench1]# unzip rt_3.8.7_bundle.zip  
Archive:  rt_3.8.7_bundle.zip
  inflating: install.sh  
  inflating: Modules.tar.gz  
  inflating: rt-3.8.7.tar.gz 
  inflating: rt.repo 
  inflating: rt_repo.tar.gz 

set up yum repo file:

[r...@testbench1]# ls
install.sh  rt_3.8.7_bundle.zip  rt.repo
Modules.tar.gz  rt-3.8.7.tar.gz  rt_repo.tar.gz

[r...@testbench1]# cp rt.repo  /etc/yum.repos.d/

[r...@testbench1]# vi /etc/yum.repos.d/rt.repo

[rt-387-local]
name=Request Tracker - $basearch
baseurl=file://opt/rt_repo/$basearch/
enabled=1
gpgcheck=0

[rt-387-noarch-local]
name=Request Tracker - noarch
baseurl=file://opt/rt_repo/noarch/
enabled=1
gpgcheck=0

Unpack the distro part and move it over to /opt where the yum file
expected it:

[r...@testbench1]# tar xfz rt_repo.tar.gz

[r...@testbench1]# mv rt_repo /opt
[r...@testbench1]# ls /opt/rt_repo/
i386  noarch  x86_64

Okay, let's see if that works:

[r...@testbench1]# yum clean all
Loaded plugins: rhnplugin, security
Cleaning up Everything

[r...@testbench1]# yum list rt3
Loaded plugins: rhnplugin, security
adobe-linux-i386   |  951 B 
00:00 
adobe-linux-i386/primary   |  12 kB 
00:00 
adobe-linux-i386
18/18
rhel-i386-server-5 | 1.4 kB 
00:00 
rhel-i386-server-5/primary | 3.0 MB 
00:00 
rhel-i386-server-5  
7696/7696
rhel-i386-server-vt-5  | 1.4 kB 
00:00 
rhel-i386-server-vt-5/primary  |  41 kB 
00:00 
rhel-i386-server-vt-5 
198/198
rhn-tools-rhel-i386-server-5   | 1.3 kB 
00:00 
rhn-tools-rhel-i386-server-5/primary   |  38 kB 
00:00 
rhn-tools-rhel-i386-server-5  
457/457
file://opt/rt_repo/i386/repodata/repomd.xml: 
 [Errno 5] OSError: [Errno 2] No 
such file or directory: '/rt_repo/i386/repodata/repomd.xml'
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: 
rt-387-local. Please verify its path and try again

No clue what this means.  I checked the yum locations.  I checked the
xml metadata.  Couldn't see where this bad path was coming from.

Any suggestions for resolving this?

If I can't resolve this, I will just forget about RT3.8 and stick with
RT3.6 of which there is a well-behaved RPM already in the EPEL repo.

Wes