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…
-
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.
-
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