Bug 7284 - netscape-JAVA and LDAP
Summary: netscape-JAVA and LDAP
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: netscape   
(Show other bugs)
Version: 6.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-11-24 12:45 UTC by Oliver Paukstadt
Modified: 2014-03-17 02:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-12-20 22:02:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Oliver Paukstadt 1999-11-24 12:45:13 UTC
We installed RH6.1 with full-LDAP-Support, so we have only the functional
accounts needed by the system in /etc/passwd.

Starting a Website containing JAVA generates a bus-error on netscape 4.6
and 4.7 if the user is complete LDAP.

If the users account-data is added too /etc/passwd, netscape-JAVA works.

Comment 1 Bill Nottingham 1999-12-01 19:26:59 UTC
What does your /etc/nsswitch.conf look like?

Comment 2 Oliver Paukstadt 1999-12-01 20:09:59 UTC
We only have the user and group-information stored in LDAP and all the other
commands which need uid/gid-information seem to work (in contrast to RH5.2 as
base-system and multiple pam/ldap-patches added).

cat /etc/nsswitch.conf | grep -v "^#" | grep -v '^$'
passwd:         files ldap
group:          files ldap
hosts:          dns
services:   files
networks:   files
protocols:  files
rpc:        files
ethers:     files
netmasks:   files
bootparams: files
publickey:  files
automount:  files
aliases:    files
sendmailvars:   files
netgroup:   files

Comment 3 Bill Nottingham 1999-12-01 20:13:59 UTC
If you strace and/or ltrace netscape, what in particular is it
doing before it dies?

(This is trying to see if there's a configuration workaround. If
the problem is in netscape/jdk, there's not much we can do.)

If you install the blackdown or IBM jdk and just try and run
something, does it have the same problems?

Comment 4 Oliver Paukstadt 1999-12-06 17:56:59 UTC
I tried jdk_1.1.7-v3-glibc-x86.tar.gz and it worked.

I did some straces and found strange behaviour.....
You can access the comeplete traces via
http://linux.fh-heilbronn.de/RH/nstrace0[1-4]
I did an strace of the netscape-call and got these last lines (nstrace01):

uname({sys="Linux", node="becks.stud.fh-heilbronn.de", ...}) = 0
rt_sigprocmask(SIG_BLOCK, [ALRM], [RT_0], 8) = 0
socket(PF_UNIX, SOCK_STREAM, 0)         = 28
connect(28, {sun_family=AF_UNIX, sun_path="/var/run/.nscd_socket"}, 110) = -1
ECONNREFUSED (Connection refused)
close(28)                               = 0
--- SIGSEGV (Segmentation fault) ---
getpid()                                = 2018
kill(2018, SIGBUS)                      = 0
--- SIGBUS (Bus error) ---
+++ killed by SIGBUS +++

Some lines above, where those errors:
open("/home/pstadt/.netscape/java/download/Welcome.class", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/lib/netscape/java/download/Welcome.class", O_RDONLY) = -1 ENOENT (No
such file or directory)

I made the missing directory and did another strace (nstrace02), but it always
died.

Then I started netscape remote on another box which has the same
package-configuration and it ran!!!! (nstrace03)
I did the redirection vice versa an it did, too!

After all, I did another strace (nstrace04) with nearly a clean environemnt, but
it died again.

Comment 5 Oliver Paukstadt 1999-12-06 18:13:59 UTC
When netscape is started with redirected X, the line after the connect to
/var/run/.nscd_socket looks like this:

connect(4, {sun_family=AF_UNIX, sun_path="/var/run/.nscd_socket"}, 110) = -1
ECONNREFUSED (Connection refused)
close(4)                                = 0
open("/etc/nsswitch.conf", O_RDONLY)    = 4

The nsswitch.conf exists on both systems, and it is worldreadable....

Comment 6 Bill Nottingham 1999-12-06 23:05:59 UTC
What's the output of chkfontpath --list on the working
and non-working cases?

Comment 7 Oliver Paukstadt 1999-12-07 15:37:59 UTC
chkfontpath is always (on all clients) the same: (logins via X, ssh, telnet)

[pstadt@becks pstadt]$ /usr/sbin/chkfontpath
Current directories in font path:
1: /usr/X11R6/lib/X11/fonts/misc:unscaled
2: /usr/X11R6/lib/X11/fonts/75dpi:unscaled
3: /usr/X11R6/lib/X11/fonts/100dpi:unscaled
4: /usr/X11R6/lib/X11/fonts/misc
5: /usr/X11R6/lib/X11/fonts/Type1
6: /usr/X11R6/lib/X11/fonts/Speedo
7: /usr/X11R6/lib/X11/fonts/100dpi
8: /usr/X11R6/lib/X11/fonts/75dpi
9: /usr/share/fonts/ISO8859-2/misc
10: /usr/share/fonts/ISO8859-2/100dpi
11: /usr/share/fonts/ISO8859-2/75dpi
12: /usr/share/fonts/ISO8859-2/Type1
13: /usr/share/fonts/ISO8859-7/misc
14: /usr/share/fonts/ISO8859-7/100dpi
15: /usr/share/fonts/ISO8859-7/75dpi
16: /usr/share/fonts/ISO8859-7/Type1
17: /usr/share/fonts/ISO8859-9/100dpi
18: /usr/share/fonts/ISO8859-9/misc
19: /usr/share/fonts/ISO8859-9/75dpi
20: /usr/X11R6/lib/X11/fonts/cyrillic
21: /usr/share/fonts/default/Type1

Comment 8 Oliver Paukstadt 1999-12-07 15:51:59 UTC
hm, maybe it is something like a "timeout"-problem?

On our "old" RH5.2-based Clients we got "Signal 13"-Errors for ssh in 9 of 10
tries after installing the ldap-Usermanagement. That was the main reason to
upgrade to the "Full-LDAP-featured RH6.1" ;-))

Ok, how are our chances to get rid of this problem??? How are the RH connections
to NS?? What about using a external jdk with netscape??

We now installed a work-around with a nightly generated passwd, but that is !:?#

Comment 9 Bill Nottingham 1999-12-20 22:02:59 UTC
Out of curiousity, are you running nscd?

We've tried this here, and can't reproduce it.

Comment 10 Bill Nottingham 2000-06-10 23:39:18 UTC
I'm going to close this, as I was never able to reproduce it.


Note You need to log in before you can comment on or make changes to this bug.