I ran into this problem on a system with a large number of NFS mounts where 2 of 7 mounts worked properly. After doing a little digging there’s a very straight-forward work-around for this. Use the following to add a 30 second delay to the actual mount of your file-systems to give the network daemon time to populate the routing table:
action $"Sleeping for 30 secs: " sleep 30
[ ! -f /var/lock/subsys/portmap ] && service portmap start
and right before:
action $"Mounting NFS filesystems: " mount -a -t nfs,nfs4
All 7 mounts came up without issue following the next reboot. You will likely see the following error on the console during boot or in /var/log/messages:
Jan 22 07:16:02 localhost mount: mount: mount to NFS server '192.168.0.25' failed:
Jan 22 07:16:02 localhost mount: System Error: No route to host.
I purchased a P6T with 6GB of RAM a while back when I decided I wanted to upgrade to 12GB of RAM. Here’s an interesting tidbit about the P6T, your RAM timings have to be the same or you’re going to have stability problems. The stability problems will problems will present themselves as issues like this or this. After returning the motherboard several times, I finally spoke to a third level engineer who politely explained to me why the motherboard would randomly detect 10GB or 8GB of RAM. He explained that the issue was caused by 3 sticks of my memory having timings of CL8 and the other three with timings of CL9. I did not believe it until I purchased 12GB of CL8 matching memory and have since had no stability problems and the motherboard detects all 12GB of memory.
On a side note I do not think it is necessary that someone (Much like myself) return a motherboard three times (One time the replacement motherboard came with 2 faulty PCI slots) before they get to a technician that can explain the situation. Needless to say, I can neither recommend nor will I purchase Asus products in the future (Mostly because of poor support practices).
This is somewhat simple to resolve if you’re signing your certificates with a Microsoft CA however it’s not so simple using openssl.
In order to generate a certificate with OpenSSL you have to use extended keys as documented here:
I will post a follow up with specifics on signing the CR with OpenSSL soon.
Seems like it took forever for me to find this.
If you’re trying to set per-user umasks for your sftp server (Using either internal-sftp or sftp-server) there is a Base 8 to octal conversion bug in OpenSSH version 5.6p1 and earlier.