[Bastille-linux-discuss] Not finding Curses.pm

[James]

Good day,

OS: Red Hat 7.3
Using (in this order of installation):
perl-Curses-1.06-1.1.rh73.dag.i386.rpm
Bastille-2.1.7-1.0.noarch.rom
Bastille-Curses-module-1.2.0-1.lmdk.noarch.rpm

CPAN has no record of Bundle::Curses or Bundle::Tk.

Whether installing from RPMs or from source, I cannot run Bastille because it cannot find Curses.pm, which is located in /usr/lib/perl5/vendor_perl/5.6.1/i386-linux.

I'm administrating the server from an SSH bash shell (I'm in California, it's in Virginia), so using the X interface isn't available to me.

$bash> export $CORRECT_PERL_PATH=/usr/lib/perl5/vendor_perl/5.6.1/i386-linux

consistently returns "not a valid identifier", regardless of slashes or the depth of the path (trying from /usr all the way through the above). There is currently no data in the $CORRECT_PERL_PATH environment variable.

When launching the Bastille config stage with "bastille -c" I get (as you know):

ERROR: Could not load the 'Curses.pm' interface module.
This may be due to an invalid $DISPLAY setting,
or the module not being visible to Perl.

There is also no data in the $DISPLAY environmental variable.

FYI, I also tried this on Fedora Core 1, Red Hat 9.0 and Red Hat 7.2 with the exact same results: No problem installing but these same problems running.

Any help will be appreciated.

James Butler

[s***@criminaldefense.com]

Thanks very much to Paul Allen and Keith Buck for your responses.

Since PERL cannot find my Curses.pm in its current location, wouldn't it be more simple to place a link to the real file in a location where Bastille expects it to be? Of course, I cannot find this place, and have tried several, including /usr/lib/perl5/5.6.1 (which contains the other .PM files) and /usr/lib/perl5/ and /usr/lib on and on.

If my PERL installation is working fine in every other application, like web apps, why wouldn't Bastille perform similarly? There were no erros during installation of the perl-Curses RPM. There were erros during installation of perl-Tk, but I attribute them to the absence of an active X installation.

During the installation of the Bastille source, it clearly saw the embedded PERL subdirectories and accommodated them. As mentioned, PERL seems to be working fine, including activating the various installed modules during attempts using the CPAN method, where Net::FTP was utilized heavily, among other modules.

Are RH7.2, 7.3, 9.0 and FC1 considered to be fringe OSs? Certainly at least one of them is very close to a pretty default server installation. All are dedicated servers. Does someone recognize a host-provider-specific path structure in my messages? They seem consistent to me, although two are with VP* Hos***g and two are with Val***We*. RH7.x is consistent with RH7.x and v.9 is a lot like FC1.

I apologize for my Bastille-oriented troubleshooting; I'm not trying to give it a hard time. There's not much that has been aberrant with these servers, so I'm kinda forced to look at the new kid on the block a little bit more closely, and a little reluctant to fix what ain't broke.

I very much appreciate any comments, again, and yes, Mr. Allen and Mr. Buck, I will give reinstalling PERL a shot, should I need to. Happily. :) What the heck!

James

[Jay Beale]

Post by s***@criminaldefense.com
Thanks very much to Paul Allen and Keith Buck for your responses.
Since PERL cannot find my Curses.pm in its current location, wouldn't

it be more simple to place a link to the real file in a location where
Bastille expects it to be? Of course, I cannot find this place, and have
tried several, including /usr/lib/perl5/5.6.1 (which contains the other
.PM files) and /usr/lib/perl5/ and /usr/lib on and on.

You can figure out if perl itself is finding your Curses module like this:

$ perl
use Curses;

If you don't get a long error message, your Curses module is being
found. If you do, it'll look like this and tell you

Post by s***@criminaldefense.com
If my PERL installation is working fine in every other application,

like web apps, why wouldn't Bastille perform similarly? There were no
erros during installation of the perl-Curses RPM. There were erros
during installation of perl-Tk, but I attribute them to the absence of
an active X installation.

Well, your web apps almost definitely aren't using Curses, which is a
library for building terminal-based
interfaces. It's not a question necessarily of your perl installation
being hosed, but rather your perl installation
not finding the libraries it needs.

Could you run this command please:

$ rpm -ql perl-Curses

The output of these last two commands should be massively helpful for
diagnosing your problem.

Post by s***@criminaldefense.com
During the installation of the Bastille source, it clearly saw the

embedded PERL subdirectories and accommodated them. As mentioned, PERL
seems to be working fine, including activating the various installed
modules during attempts using the CPAN method, where Net::FTP was
utilized heavily, among other modules.

The CPAN installation method is generally the least-error prone, I'd agree.

Post by s***@criminaldefense.com
Are RH7.2, 7.3, 9.0 and FC1 considered to be fringe OSs? Certainly at

least one of them is very close to a pretty default server installation.
All are dedicated servers. Does someone recognize a
host-provider-specific path structure in my messages? They seem
consistent to me, although two are with VP* Hos***g and two are with
Val***We*. RH7.x is consistent with RH7.x and v.9 is a lot like FC1.

These are all covered O/S's that were the dominant O/S we covered at
some point.

Post by s***@criminaldefense.com
I apologize for my Bastille-oriented troubleshooting; I'm not trying

to give it a hard time. There's not much that has been aberrant with
these servers, so I'm kinda forced to look at the new kid on the block a
little bit more closely, and a little reluctant to fix what ain't broke.

Of course. Let's see what we can do to help you. :)

Post by s***@criminaldefense.com
I very much appreciate any comments, again, and yes, Mr. Allen and

Mr. Buck, I will give reinstalling PERL a shot, should I need to.
Happily. :) What the heck!

With those two helping, you're getting assistance from some of the very
best sources. I'll try to pitch in too.

- Jay

[s***@criminaldefense.com]

Dear Mr. Allen,

Here's my output (from the RH 9.0 system):

# perl -e 'use Curses'
Can't locate loadable object for module Curses in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at -e line 1
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

Here's another interesting bit:

# locate Curses.pm
/usr/lib/perl5/site_perl/Bastille_Curses.pm
/usr/lib/perl5/vendor_perl/5.6.1/i386-linux/Curses.pm
/usr/lib/Bastille/Bastille_Curses.pm

No wonder PERL 5.8.0 can't find it! :)

I'll check the other systems, but I installed the nearly the same RPMs on them, so my guess is there are similar version issues. I have located a v2.0 perl-Curses RPM as this discussion has progressed. It's a little curious why I would have both 5.6.1 and 5.8.0 in this installation ... maybe the Curses RPM assumed its own faux install path or something ... I'll figger it out.

I should probably make a couple of RPMs to better understand their relationship to the installation environment.

Onward to the Curses tarball (after some sleep)! Many thanks.
If I have something I think, in my innocence, is useful to say, I now feel comfortable saying it.

James Butler

[Jay Beale]

I'm not seeing Paul Allen's messages to you, so I appeared to repeat
some of this advice in the previous message.

I still would be massively helped by knowing what perl-Curses rpm you're
using.

Post by s***@criminaldefense.com
Dear Mr. Allen,
# perl -e 'use Curses'
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at -e line 1
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

OK -- so you've got perl 5.8.0, with the associated perl module search path.

Post by s***@criminaldefense.com
# locate Curses.pm
/usr/lib/perl5/site_perl/Bastille_Curses.pm
/usr/lib/perl5/vendor_perl/5.6.1/i386-linux/Curses.pm
/usr/lib/Bastille/Bastille_Curses.pm
No wonder PERL 5.8.0 can't find it! :)

Right. It looks like you've got an older perl-Curses rpm that puts the
Curses.pm file (the one that we're looking for here) outside of any of
the @INC directories.

You should use the perl-Curses rpm from this table:

http://www.bastille-linux.org/perl-rpm-chart.html

For RH9.0, it looks like we're recommending:

http://www.bastille-linux.org/perl-Curses-1.06-219.i586.rpm

Actually, rpmfind.net shows one specifically for RH9 in the DAG repository:

http://www.rpmfind.net//linux/RPM/dag/redhat/9/i386/perl-Curses-1.06-1.rh90.dag.i386.html

Try out the latter -- I'll update our table.

- Jay

Post by s***@criminaldefense.com
I'll check the other systems, but I installed the nearly the same RPMs on them, so my guess is there are similar version issues. I have located a v2.0 perl-Curses RPM as this discussion has progressed. It's a little curious why I would have both 5.6.1 and 5.8.0 in this installation ... maybe the Curses RPM assumed its own faux install path or something ... I'll figger it out.
I should probably make a couple of RPMs to better understand their relationship to the installation environment.
Onward to the Curses tarball (after some sleep)! Many thanks.
If I have something I think, in my innocence, is useful to say, I now feel comfortable saying it.
James Butler