Installation on Cobalt RaQ XTR

I have been trying to get an installation going on a Cobalt RaQ XTR
with quite a few problems. Among them some FAQs which I would have
noticed if I read through the documentation. [ Why is CPAN making me
upgrade to 5.6.1? – of course a note on how to downgrade back if you
just were saying yes to everything on a monday morning, would be nice
too.]

The machines are designed for ISPs who do web hosting and I’m trying
to get it up using the http://rt.domain.com where rt is running on
virtual server.

Should I create an rt virtual user first? Basically, using a server
appliance adds a lot of possiblities but in this case is forcing me
into older versions of database software and perl than I’d like. I
don’t believe mod_perl or FastCGI is possible, but I’m not sure. So if
anyone has dealt with these devices I’d appreciate heaing back.

Josh Kuperman
josh@saratoga.lib.ny.us

I can’t say anything about how to downgrade back to a previous Perl version.
But to avoid this problem, decline to update perl, and update the CPAN
module itself. Newer versions do not attempt to shove a perl upgrade down
your throat.

If you can, I would recommend using the latest perl with mason–especially
if you are currently using 5.6.0.

Some people (especially linux users) are reporting success using Mason with
the latest mod_perl and perl 5.6.1 compiled as a DSO. You could try this
config.

Another option, if you have a support contract, is to harass Sun about your
problems with the RAQ. They should really make current software support
available for server appliance users.

Good luck.

-Mark-----Original Message-----
From: josh [mailto:josh@saratoga.lib.ny.us]
Sent: Tuesday, May 21, 2002 8:46 AM
To: rt-users
Subject: [rt-users] Installation on Cobalt RaQ XTR

I have been trying to get an installation going on a Cobalt RaQ XTR
with quite a few problems. Among them some FAQs which I would have
noticed if I read through the documentation. [ Why is CPAN making me
upgrade to 5.6.1? – of course a note on how to downgrade back if you
just were saying yes to everything on a monday morning, would be nice
too.]

The machines are designed for ISPs who do web hosting and I’m trying
to get it up using the http://rt.domain.com where rt is running on
virtual server.

Should I create an rt virtual user first? Basically, using a server
appliance adds a lot of possiblities but in this case is forcing me
into older versions of database software and perl than I’d like. I
don’t believe mod_perl or FastCGI is possible, but I’m not sure. So if
anyone has dealt with these devices I’d appreciate heaing back.

Josh Kuperman
josh@saratoga.lib.ny.us

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

DO NOT UPGRADE PERL!!!

Nothing will work!!! It is VERRY VERRRY VERRRY bad on a cobalt!!!

If u send me a list of the problems you are having, I regularly configure &
install rt on cobalts - I may be able to help.

AndrewOn 22/5/02 7:36 AM, “Swayne, Mark A” mark.a.swayne@xo.com wrote:

I can’t say anything about how to downgrade back to a previous Perl version.
But to avoid this problem, decline to update perl, and update the CPAN
module itself. Newer versions do not attempt to shove a perl upgrade down
your throat.

If you can, I would recommend using the latest perl with mason–especially
if you are currently using 5.6.0.

Some people (especially linux users) are reporting success using Mason with
the latest mod_perl and perl 5.6.1 compiled as a DSO. You could try this
config.

Another option, if you have a support contract, is to harass Sun about your
problems with the RAQ. They should really make current software support
available for server appliance users.

Good luck.

-Mark
-----Original Message-----
From: josh [mailto:josh@saratoga.lib.ny.us]
Sent: Tuesday, May 21, 2002 8:46 AM
To: rt-users
Subject: [rt-users] Installation on Cobalt RaQ XTR

I have been trying to get an installation going on a Cobalt RaQ XTR
with quite a few problems. Among them some FAQs which I would have
noticed if I read through the documentation. [ Why is CPAN making me
upgrade to 5.6.1? – of course a note on how to downgrade back if you
just were saying yes to everything on a monday morning, would be nice
too.]

The machines are designed for ISPs who do web hosting and I’m trying
to get it up using the http://rt.domain.com where rt is running on
virtual server.

Should I create an rt virtual user first? Basically, using a server
appliance adds a lot of possiblities but in this case is forcing me
into older versions of database software and perl than I’d like. I
don’t believe mod_perl or FastCGI is possible, but I’m not sure. So if
anyone has dealt with these devices I’d appreciate heaing back.

Andrew Yager
Real World Technology Solutions
Real People, Real SolUtions ™
ph: (02) 9945 2567 fax: (02) 9945 2566
mob: 0405 15 2568

Also, a point to remember: regardless of platform, if you are upgrading a
version of CPAN prior to 1.5x, ALWAYS UPGRADE MANUALLY.

If you’ve never used CPAN, go to
http://search.cpan.org/search?mode=module&query=CPAN
download the tarball and install and configure it.

If your version of CPAN is already configured but is older than (say) 1.52,
either install the tarball (as above) or have CPAN grab it for you via:

perl -MCPAN -e 'get "CPAN";'

and install it manually.

If you’re curious, I can explain why CPAN appears to go berserk sometimes,
attempting to ‘helpfully’ upgrade core perl when installing otherwise
innocuous modules (like CPAN…) The solution is to manually upgrade CPAN
beyond version 1.48. I believe this problem plagues perl versions earlier
than 5.6.1 or 5.7.x. though realistically, with packaged software you often
have little idea what version your idiot vendor has stuck you with. The
current version of CPAN is 1.61 and I haven’t had any trouble with it.

Back to the subject of Cobalts - how angry do they get if you install a
second, less broken perl alongside (rather than in place of) the vendor’s
distribution? You’d need to change the prefix and the library directory at a
minimum.

– Bob
P.S: On a completely unrelated note, if you need help convincing Sun’s stock
perl on Solaris to use gcc instead of Sun’s ‘compiler advertisement’
(/usr/ccs/bin/cc) so you can install additional modules, use CPAN, etc., drop
me a line. It’s pretty easy but involves a little deft maneuvering with a
coat hanger (metaphorically speaking). I’ve done it on many Solaris boxes
ranging from v5.5.1 to v8.On Wednesday 22 May 2002 20:48, Andrew Yager wrote:

DO NOT UPGRADE PERL!!!

Nothing will work!!! It is VERRY VERRRY VERRRY bad on a cobalt!!!

If u send me a list of the problems you are having, I regularly configure &
install rt on cobalts - I may be able to help.

Andrew

On 22/5/02 7:36 AM, “Swayne, Mark A” mark.a.swayne@xo.com wrote:

I can’t say anything about how to downgrade back to a previous Perl
version. But to avoid this problem, decline to update perl, and update
the CPAN module itself. Newer versions do not attempt to shove a perl
upgrade down your throat.

If you can, I would recommend using the latest perl with
mason–especially if you are currently using 5.6.0.

Some people (especially linux users) are reporting success using Mason
with the latest mod_perl and perl 5.6.1 compiled as a DSO. You could try
this config.

Another option, if you have a support contract, is to harass Sun about
your problems with the RAQ. They should really make current software
support available for server appliance users.

Good luck.

-Mark
-----Original Message-----
From: josh [mailto:josh@saratoga.lib.ny.us]
Sent: Tuesday, May 21, 2002 8:46 AM
To: rt-users
Subject: [rt-users] Installation on Cobalt RaQ XTR

I have been trying to get an installation going on a Cobalt RaQ XTR
with quite a few problems. Among them some FAQs which I would have
noticed if I read through the documentation. [ Why is CPAN making me
upgrade to 5.6.1? – of course a note on how to downgrade back if you
just were saying yes to everything on a monday morning, would be nice
too.]

The machines are designed for ISPs who do web hosting and I’m trying
to get it up using the http://rt.domain.com where rt is running on
virtual server.

Should I create an rt virtual user first? Basically, using a server
appliance adds a lot of possiblities but in this case is forcing me
into older versions of database software and perl than I’d like. I
don’t believe mod_perl or FastCGI is possible, but I’m not sure. So if
anyone has dealt with these devices I’d appreciate heaing back.


Andrew Yager
Real World Technology Solutions
Real People, Real SolUtions ™
ph: (02) 9945 2567 fax: (02) 9945 2566
mob: 0405 15 2568
http://www.rwts.com.au/



rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

As a minor aside, RT 2.0.14’s testdeps script will make sure that CPAN.pm
is of a new enough vintage to not have this perl change beat you up anymore.
(And it will fix it if it finds that it’s too old)

-jOn Wed, May 22, 2002 at 10:04:04PM -0500, Bob Apthorpe wrote:

Also, a point to remember: regardless of platform, if you are upgrading a
version of CPAN prior to 1.5x, ALWAYS UPGRADE MANUALLY.

If you’ve never used CPAN, go to
http://search.cpan.org/search?mode=module&query=CPAN
download the tarball and install and configure it.

If your version of CPAN is already configured but is older than (say) 1.52,
either install the tarball (as above) or have CPAN grab it for you via:

perl -MCPAN -e 'get "CPAN";'

and install it manually.

If you’re curious, I can explain why CPAN appears to go berserk sometimes,
attempting to ‘helpfully’ upgrade core perl when installing otherwise
innocuous modules (like CPAN…) The solution is to manually upgrade CPAN
beyond version 1.48. I believe this problem plagues perl versions earlier
than 5.6.1 or 5.7.x. though realistically, with packaged software you often
have little idea what version your idiot vendor has stuck you with. The
current version of CPAN is 1.61 and I haven’t had any trouble with it.

Back to the subject of Cobalts - how angry do they get if you install a
second, less broken perl alongside (rather than in place of) the vendor’s
distribution? You’d need to change the prefix and the library directory at a
minimum.

– Bob
P.S: On a completely unrelated note, if you need help convincing Sun’s stock
perl on Solaris to use gcc instead of Sun’s ‘compiler advertisement’
(/usr/ccs/bin/cc) so you can install additional modules, use CPAN, etc., drop
me a line. It’s pretty easy but involves a little deft maneuvering with a
coat hanger (metaphorically speaking). I’ve done it on many Solaris boxes
ranging from v5.5.1 to v8.

On Wednesday 22 May 2002 20:48, Andrew Yager wrote:

DO NOT UPGRADE PERL!!!

Nothing will work!!! It is VERRY VERRRY VERRRY bad on a cobalt!!!

If u send me a list of the problems you are having, I regularly configure &
install rt on cobalts - I may be able to help.

Andrew

On 22/5/02 7:36 AM, “Swayne, Mark A” mark.a.swayne@xo.com wrote:

I can’t say anything about how to downgrade back to a previous Perl
version. But to avoid this problem, decline to update perl, and update
the CPAN module itself. Newer versions do not attempt to shove a perl
upgrade down your throat.

If you can, I would recommend using the latest perl with
mason–especially if you are currently using 5.6.0.

Some people (especially linux users) are reporting success using Mason
with the latest mod_perl and perl 5.6.1 compiled as a DSO. You could try
this config.

Another option, if you have a support contract, is to harass Sun about
your problems with the RAQ. They should really make current software
support available for server appliance users.

Good luck.

-Mark
-----Original Message-----
From: josh [mailto:josh@saratoga.lib.ny.us]
Sent: Tuesday, May 21, 2002 8:46 AM
To: rt-users
Subject: [rt-users] Installation on Cobalt RaQ XTR

I have been trying to get an installation going on a Cobalt RaQ XTR
with quite a few problems. Among them some FAQs which I would have
noticed if I read through the documentation. [ Why is CPAN making me
upgrade to 5.6.1? – of course a note on how to downgrade back if you
just were saying yes to everything on a monday morning, would be nice
too.]

The machines are designed for ISPs who do web hosting and I’m trying
to get it up using the http://rt.domain.com where rt is running on
virtual server.

Should I create an rt virtual user first? Basically, using a server
appliance adds a lot of possiblities but in this case is forcing me
into older versions of database software and perl than I’d like. I
don’t believe mod_perl or FastCGI is possible, but I’m not sure. So if
anyone has dealt with these devices I’d appreciate heaing back.


Andrew Yager
Real World Technology Solutions
Real People, Real SolUtions ™
ph: (02) 9945 2567 fax: (02) 9945 2566
mob: 0405 15 2568
http://www.rwts.com.au/



rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

You could probably, and quite happily install a second version of Perl (of a
later vintage).

Just make sure that you leave the original Perl intact.

However, it is possible to get everything working without upgrading Perl.

As far as the Cpan debate - I’m using 1.5.something and I still have it want
to upgrade me to version 5.6.1 of perl… Which is fine except it’s a real
no-no on a cobalt, and I can’t seem to get a Makefile for perl on OS X
(nothing ever appears after the configure script runs, and it seems as
though it should work for me…)

But I’ve found that just control-c ing the perl install seems to work, and
then, if things refuse to install, install them manually. There was one
module for RT 2.1.13 that apparently required perl 5.6.1, but I modified the
source for one of the scripts to let it accept 5.0.1, and now RT is running
very nicely on the server.

AndrewOn 23/5/02 1:07 PM, “Jesse Vincent” jesse@bestpractical.com wrote:

As a minor aside, RT 2.0.14’s testdeps script will make sure that CPAN.pm
is of a new enough vintage to not have this perl change beat you up anymore.
(And it will fix it if it finds that it’s too old)

-j

On Wed, May 22, 2002 at 10:04:04PM -0500, Bob Apthorpe wrote:

Also, a point to remember: regardless of platform, if you are upgrading a
version of CPAN prior to 1.5x, ALWAYS UPGRADE MANUALLY.

If you’ve never used CPAN, go to
http://search.cpan.org/search?mode=module&query=CPAN
download the tarball and install and configure it.

If your version of CPAN is already configured but is older than (say) 1.52,
either install the tarball (as above) or have CPAN grab it for you via:

perl -MCPAN -e 'get "CPAN";'

and install it manually.

If you’re curious, I can explain why CPAN appears to go berserk sometimes,
attempting to ‘helpfully’ upgrade core perl when installing otherwise
innocuous modules (like CPAN…) The solution is to manually upgrade CPAN
beyond version 1.48. I believe this problem plagues perl versions earlier
than 5.6.1 or 5.7.x. though realistically, with packaged software you often
have little idea what version your idiot vendor has stuck you with. The
current version of CPAN is 1.61 and I haven’t had any trouble with it.

Back to the subject of Cobalts - how angry do they get if you install a
second, less broken perl alongside (rather than in place of) the vendor’s
distribution? You’d need to change the prefix and the library directory at a
minimum.

– Bob
P.S: On a completely unrelated note, if you need help convincing Sun’s stock
perl on Solaris to use gcc instead of Sun’s ‘compiler advertisement’
(/usr/ccs/bin/cc) so you can install additional modules, use CPAN, etc., drop
me a line. It’s pretty easy but involves a little deft maneuvering with a
coat hanger (metaphorically speaking). I’ve done it on many Solaris boxes
ranging from v5.5.1 to v8.

On Wednesday 22 May 2002 20:48, Andrew Yager wrote:

DO NOT UPGRADE PERL!!!

Nothing will work!!! It is VERRY VERRRY VERRRY bad on a cobalt!!!

If u send me a list of the problems you are having, I regularly configure &
install rt on cobalts - I may be able to help.

Andrew

On 22/5/02 7:36 AM, “Swayne, Mark A” mark.a.swayne@xo.com wrote:

I can’t say anything about how to downgrade back to a previous Perl
version. But to avoid this problem, decline to update perl, and update
the CPAN module itself. Newer versions do not attempt to shove a perl
upgrade down your throat.

If you can, I would recommend using the latest perl with
mason–especially if you are currently using 5.6.0.

Some people (especially linux users) are reporting success using Mason
with the latest mod_perl and perl 5.6.1 compiled as a DSO. You could try
this config.

Another option, if you have a support contract, is to harass Sun about
your problems with the RAQ. They should really make current software
support available for server appliance users.

Good luck.

-Mark
-----Original Message-----
From: josh [mailto:josh@saratoga.lib.ny.us]
Sent: Tuesday, May 21, 2002 8:46 AM
To: rt-users
Subject: [rt-users] Installation on Cobalt RaQ XTR

I have been trying to get an installation going on a Cobalt RaQ XTR
with quite a few problems. Among them some FAQs which I would have
noticed if I read through the documentation. [ Why is CPAN making me
upgrade to 5.6.1? – of course a note on how to downgrade back if you
just were saying yes to everything on a monday morning, would be nice
too.]

The machines are designed for ISPs who do web hosting and I’m trying
to get it up using the http://rt.domain.com where rt is running on
virtual server.

Should I create an rt virtual user first? Basically, using a server
appliance adds a lot of possiblities but in this case is forcing me
into older versions of database software and perl than I’d like. I
don’t believe mod_perl or FastCGI is possible, but I’m not sure. So if
anyone has dealt with these devices I’d appreciate heaing back.


Andrew Yager
Real World Technology Solutions
Real People, Real SolUtions ™
ph: (02) 9945 2567 fax: (02) 9945 2566
mob: 0405 15 2568
http://www.rwts.com.au/



rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Andrew Yager
Real World Technology Solutions
Real People, Real SolUtions ™
ph: (02) 9945 2567 fax: (02) 9945 2566
mob: 0405 15 2568

As far as the Cpan debate - I’m using 1.5.something and I still have it
want to upgrade me to version 5.6.1 of perl… Which is fine except it’s a
real no-no on a cobalt, and I can’t seem to get a Makefile for perl on OS X
(nothing ever appears after the configure script runs, and it seems as
though it should work for me…)

Hmm. I thought 1.58 or 1.59 was safe (maybe as far back as 1.52); I know 1.48
was unsafe. The trick is manually installing all the modules that have been
folded into the current core perl distribution that were not distributed with
your version of perl before upgrading CPAN and setting it to ask (not follow)
prerequisites. The problem is that it’s not a simple matter to tell what’s
new in core perl since your perl was installed so it’s not safe to use
older versions of CPAN because you never know which modules will trigger
CPAN’s “differently-helpful” behavior.

My old notes on configuring perl at Excite are at
http://www.cynistar.net/~apthorpe/xcit/doclets/configuring_cpan.html. Some of
the notes are site-specific (directories, local CPAN mirror, nasty comments
about ncftp, etc.) Note that CPAN’s original behavior does make a bit of
sense, just not in an environment with a shred of configuration management.
There are some really cool things you can do with CPAN::Site, a private
repository, and a local mirror of the public repository but that discussion
is way, way off-topic.

Can’t help with OS/X though…

– Bob

DO NOT UPGRADE PERL!!!

Nothing will work!!! It is VERRY VERRRY VERRRY bad on a cobalt!!!

This is quite true. Oh, and so everyone nows the version of Perl that
comes with them is current enough according to the install
notes. Cobalts are (at least my RaQ XTR is ) Intel processor machines
(some older ones were MIPS) that are using RedHat with a customized
driven by an apache server, a postgresql database, and a lot of perl
scripts. If you see a similarity to say, ‘rt’, you’ll realize where
the trouble is because I would, ideally like to use the same apache
server, database server, and perl for rt.

As it is an appliance it seems to rightly appeal to people who just
want something they can mount in a rack, and not have to mess
with. While I’d like that too, I was expecting to have to customize
more anyhow since I’m adapting it to serve my business, which is a
public library, not an ISP.

If u send me a list of the problems you are having, I regularly configure &
install rt on cobalts - I may be able to help.

Well most of it seems related to the Perl. The two things that are
still confusing are which database to use. There is a MySQL package,
which I installed and looks like it would work, though Postgres is
also installed and I would like to user that eventually. The MySQL is
only one release too old according to the doc.

The biggest problem for me is figuring out how to create the users and
locate the web site. These are web appliances so if I create an RT
user through the web interface, I’d wind up with a ~rt web site - that
I don’t want. I’d like to create a support.mydomain.org web site as a
home for the rt system. The Cobalts, designed for web hosting, can
create multipble web site almost by accident. Virtual domains are
easily supported, but there is a maze of symlinks. Do I try to get RT
to install in place of the site for the domain.

Andrew

I can’t say anything about how to downgrade back to a previous Perl version.
But to avoid this problem, decline to update perl, and update the CPAN
module itself. Newer versions do not attempt to shove a perl upgrade down
your throat.

This is really a FAQ. The instructions to install a new CPAN module to
avoid the problem were in the Installation Guide that I downloaded,
more toward back than I would’ve liked. I think everyone should note,
that at least earlier in this week, the CPAN upgrade does not wipe out
the old version. After upgrading there were three perl binaries in
/usr/bin/; perl, perl5.6.1, and perl5.00503. The ‘perl’ was an exact
copy of perl5.6.1. I simply copied perl5.00503 to perl. [ Keeping old
and new versions with either a copy or a symlink to the system default
name used to be a very common way of upgrading programs at unix
sites. When I was working at a university you had to keep all the old
versions of everything for professors who needed to keep using the old
versions for classes while converting to the new version.]

If you can, I would recommend using the latest perl with mason–especially
if you are currently using 5.6.0.

Some people (especially linux users) are reporting success using Mason with
the latest mod_perl and perl 5.6.1 compiled as a DSO. You could try this
config.

Another option, if you have a support contract, is to harass Sun about your
problems with the RAQ. They should really make current software support
available for server appliance users.

Support? I am the support. Which is to say, yes Sun should keep it
more current, but I believe it is current enough anyhow.

-Mark


Andrew Yager

Josh Kuperman
josh@saratoga.lib.ny.us

As an aside [to start], if you ever do come across a spare cobalt, do
upgrade perl on it. It’s interesting to watch the machine systematically
fail to start up anything remotely human :-)… First with apache… But
it’s all down hill from there. Don’t do it on a production server as the
only way to recover (according to Sun - and we know because we paid a large
sum of money to find this out) is with a full system recovery.

If u send me a list of the problems you are having, I regularly configure &
install rt on cobalts - I may be able to help.

Well most of it seems related to the Perl. The two things that are
still confusing are which database to use. There is a MySQL package,
which I installed and looks like it would work, though Postgres is
also installed and I would like to user that eventually. The MySQL is
only one release too old according to the doc.

If you want to use MySQL (which, incidently there is nothing wrong with)
grab a copy of it from Package master

http://www.pkgmaster.com/ - this is the new URL for the old unsupported
distribution of sun packages. There is a late MySQL up there for you to
grab. This should help with that… I’ve never set it up on Postgres so I
can’t quite help with that…

The biggest problem for me is figuring out how to create the users and
locate the web site. These are web appliances so if I create an RT
user through the web interface, I’d wind up with a ~rt web site - that
I don’t want. I’d like to create a support.mydomain.org web site as a
home for the rt system. The Cobalts, designed for web hosting, can
create multipble web site almost by accident. Virtual domains are
easily supported, but there is a maze of symlinks. Do I try to get RT
to install in place of the site for the domain.

A couple of options…

  1. Create a user over the command line using useradd (can’t remember if it’s
    in the redhat distribution cobalt uses) or modifying the appropriate system
    file (/etc/passwd) to add a user.
    The down side of this is that backups fail and restores don’t work for the
    entire server because of this. It’s bizzare - but a pain. The same is not
    true of the e-mail aliases you set up and the web domains you set up.

  2. Create a user using the web interface on some site that you have (dosen’t
    even have to really exist - for example you may create a new site called
    mynothingsite.somewhere.com ) called rt. It doesn’t need to have anything.
    This will allow backups/restores to still function. The user doesn’t really
    have to do anything.

If you want, you can actually remove the user’s web folder
(/home/sites/sitename/users/rt/web)

Usernames are global - so an rt user on one site exists everywhere.
This should allow the rt user to work. Take your pick which method to use -
but I strongly suggest that you use the web interface to make the user.

Step 1 completed, you need to move to step 2.

You should be able to get the packages to install from testdeps/fixdeps…
This requires a few long hours of fiddling, but I always seem to get it. One
day I’ll actually document it and put up a how-to somewhere. In past the
Msql/MySQL package has been the hardest, but it seems to have gotten better
(perhaps I just go smarter???) If you have the latest version of MySQL
available from pkgmaster you should be fine.

Step 3 is install - this is straight forward. I recommend you install to
/usr/local/rt2/

Step 4 - modify httpd config.

Open your httpd.conf file (/etc/httpd/conf/httpd.conf ) using your favourite
text editor and edit as per instructions. There is no great tricks to
this… Just stick the appropriate lines for you. If you are setting rt up
as a virtual site (which I believe you are…) just add it in the virtual
sites area down the bottom. This site will not show up on the web interface
for the cobalt, but will still work.

You will need to enable rt-mailgate to be used by smrsh (if you get stuck
type man smrsh).

To make your mail aliases work (this was the hardest bit as I didn’t notice
any documentation on this) - modify the aliases file (/etc/mail/aliases)
with some rt aliases (eg support-queue: /usr/local/rt2/bin/rt-mailgate …)
and then modify the virtusertable to include users that point to this alias

There is a point in this file where it says add your changes below here -
that is the best place to stick these users.

I’m not sure if the cobalt processes the virtusertable file when you issue
the newaliases command, so the easiest thing is to open the web interface,
and modify a user (add another alias or something to their e-mail address).
This will cause this file to be processed, and everything will be dandy.
[hopefully]

Hopefull this will help you a bit, and perhaps even some other poor
struggling cobalt users out there as well.

Yours,
Andrew

Andrew

I can’t say anything about how to downgrade back to a previous Perl version.
But to avoid this problem, decline to update perl, and update the CPAN
module itself. Newer versions do not attempt to shove a perl upgrade down
your throat.

This is really a FAQ. The instructions to install a new CPAN module to
avoid the problem were in the Installation Guide that I downloaded,
more toward back than I would’ve liked. I think everyone should note,
that at least earlier in this week, the CPAN upgrade does not wipe out
the old version. After upgrading there were three perl binaries in
/usr/bin/; perl, perl5.6.1, and perl5.00503. The ‘perl’ was an exact
copy of perl5.6.1. I simply copied perl5.00503 to perl. [ Keeping old
and new versions with either a copy or a symlink to the system default
name used to be a very common way of upgrading programs at unix
sites. When I was working at a university you had to keep all the old
versions of everything for professors who needed to keep using the old
versions for classes while converting to the new version.]

If you can, I would recommend using the latest perl with mason–especially
if you are currently using 5.6.0.

Some people (especially linux users) are reporting success using Mason with
the latest mod_perl and perl 5.6.1 compiled as a DSO. You could try this
config.

Another option, if you have a support contract, is to harass Sun about your
problems with the RAQ. They should really make current software support
available for server appliance users.

Support? I am the support. Which is to say, yes Sun should keep it
more current, but I believe it is current enough anyhow.

-Mark


Andrew Yager

Andrew Yager
Real World Technology Solutions
Real People, Real SolUtions ™
ph: (02) 9945 2567 fax: (02) 9945 2566
mob: 0405 15 2568

Sounds like a good reason not to use a Cobalt.

Just spent a few minutes searching the knowledge base, and the only hint of
catastrophe was in this article:

Question
How do I determine which version of perl is insatlled?
Answer
SUN COBALT PRODUCTS ARE SERVER APPLIANCES AND ARE DESIGNED TO PROVIDE
SERVICES SUCH AS WEB HOSTING, E-MAIL, AND FILE SHARING, WHICH ARE ACCESSED
VIA A WEB-BASED USER INTERFACE. DIRECT ACCESS OR MODIFICATION OF THE
UNDERLYING SOFTWARE OR HARDWARE OF THE SUN COBALT PRODUCT IS NOT SUPPORTED
BY SUN COBALT AND WILL VOID YOUR PRODUCT WARRANTY. THE INFORMATION BELOW IS
PROVIDED “AS IS,” FOR INFORMATIONAL PURPOSES ONLY. SUN COBALT WILL NOT BE
LIABLE FOR ANY LOSSES OR DAMAGES SUFFERED AS A RESULT OF YOUR USE OF THIS
INFORMATION. PHONE AND WEB-BASED SUPPORT WILL NOT BE AVAILABLE FOR SYSTEM
ISSUES ARISING OUT OF THE USE OF THIS INFORMATION.
Log into the server using a telnet application, and enter the following at
the command line:

[admin admin]$ perl -v

http://cobalt-knowledge.sun.com/cgi-bin/kbase.cfg/php/enduser/std_adp.php?p_
sid=TQALIRfg&p_lva=&p_refno=010608-002524&p_created=992013163&p_sp=cF9ncmlkc
29ydD0mcF9yb3dfY250PTMyJnBfc2VhcmNoX3RleHQ9cGVybCZwX3NlYXJjaF90eXBlPTMmcF9wc
m9kX2x2bDE9fmFueX4mcF9wcm9kX2x2bDI9fmFueX4mcF9jYXRfbHZsMT1_YW55fiZwX2NhdF9sd
mwyPX5hbnl_JnBfc29ydF9ieT1kZmx0JnBfcGFnZT0x&p_li=

Nice of them to give fair warning. I’ll think I’ll stick with real RedHat
systems.-----Original Message-----
From: Andrew Yager [mailto:andrew@rwts.com.au]
Sent: Thursday, May 23, 2002 6:16 AM
To: rt-users
Subject: Re: [rt-users] Installation on Cobalt RaQ XTR

As an aside [to start], if you ever do come across a spare cobalt, do
upgrade perl on it. It’s interesting to watch the machine systematically
fail to start up anything remotely human :-)… First with apache… But
it’s all down hill from there. Don’t do it on a production server as the
only way to recover (according to Sun - and we know because we paid a large
sum of money to find this out) is with a full system recovery.

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm