Home / user-7923

Alex's questions

Martin Hope
Alex
Asked: 2010-09-18 08:07:59 +0800 CST
  • 0

To illustrate what I'm trying to do:

https://www.google.com uses a cert issued by Thawte SGC CA (which in turn is issued by one of the Verisign CAs). It looks like Internet Explorer comes with that issuer cert preinstalled, but Firefox (I'm using 3.5.1) does not. Nevertheless, the browser doesn't complain that the site cert is untrusted, because the Thawte cert gets installed right then and there. So far so good.

I have a server (using Apache) where I'd like to accomplish the same thing. It also uses a cert from the same CA, and I've got it sending the complete chain of trust during the SSL handshake (using the httpd.conf SSLCertificateChainFile directive). But if the intermediate cert isn't already previously imported into Firefox' Authorities keystore, it'll complain that the site cert isn't trusted.

In short, then, my question is: what do I need to do to get the Thawte cert to auto-install, so that the browser will accept the site cert without prompting?

firefox ssl-certificate
Martin Hope
Alex
Asked: 2010-01-30 11:48:47 +0800 CST
  • 3

On a box recently upgraded from SLES 9.3 to 10.2, I'm seeing the following issue:

Prior to the upgrade, an NFS mount (defined via yast, i.e., it appeared in /etc/fstab) worked correctly. Following the upgrade, however, it is failing. A network trace shows that it is making the initial connection to the NFS server over TCP (for the portmapper RPC), but then it switches to UDP for the subsequent MOUNT call; since the NFS server doesn't allow UDP (with good reason, due to the possible issues with data corruption, as in nfs(5)), the connection will not go through.

Adding the TCP option (whether in fstab, or at the command line, etc.) has no effect.

In the course of troubleshooting this, I've found that /var/adm/messages is reporting the following as occurring during boot:

Failed services in runlevel 3: network

(I should note that despite this error message, apparently at least some network services are started, since the box is accessible via SSH.)

My questions, then:

  1. What should I be looking at to determine the cause of the service startup failure?
  2. Would this indeed be likely to cause the problem with NFS described above?
  3. If the answer to (2) is no, then any suggestions on what to look for?

Editing to add some information relating to the answers below.

It turns out that the network service is failing on bootup because one of the interfaces (there are two on this box) uses DHCP, and that's not available yet at this time. So I've disabled it for now, stopped/restarted the network service and the NFS client services, but still get the same results.

There's no firewall on the client side. Also, iptables -L on the client side shows that everything is accepted; and there are no entries in /etc/hosts.allow or /etc/hosts.deny.

On the NFS server side, nothing has changed. The remote nfsserver is indeed advertising that it allows both TCP and UDP for all of the NFS services (though there is an iptables rule blocking UDP).

/etc/fstab entry is pretty basic - what you'd get from setting it up in yast:

x.x.x.x:/volume      /localdir   nfs     defaults 0 0

rpcinfo -p for the client box shows only portmapper v2 running, advertising both TCP and UDP. For the server, it shows all of the usual services:

   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp   4047  status
    100024    1   tcp   4047  status
    100011    1   udp   4049  rquotad
    100021    1   udp   4045  nlockmgr
    100021    3   udp   4045  nlockmgr
    100021    4   udp   4045  nlockmgr
    100021    1   tcp   4045  nlockmgr
    100021    3   tcp   4045  nlockmgr
    100021    4   tcp   4045  nlockmgr
    100005    1   udp   4046  mountd
    100005    1   tcp   4046  mountd
    100005    2   udp   4046  mountd
    100005    2   tcp   4046  mountd
    100005    3   udp   4046  mountd
    100005    3   tcp   4046  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs

The mount call, with the /etc/fstab entry above, is simply:

mount /localdir

although I've also tried it with various options such as tcp, v3, etc.

Both the /etc/fstab entry (hence the mount) and the rpcinfo -p call are using the IP address, so there are no DNS resolution issues involved.

nfs networking sles10