Quick-List for Troubleshooting

Problems and Resolutions:

• Can't Send Email. It started taking about a minute to send. Recieving email is normal performance.
  After checking with 2 workstations, monitoring firewall with tcpdump, disableing GPG, and geting no-where, I sent mail to my work email then POP-d it down locally. After studying the header I found the SMTP server had changed. Shaw did not need to inform anyone, as they expect users to have their email set to "mail" and to be in the @home workgroup/domain. Because I am on a separate LAN, I must fully qualify the email servers (SMTP & POP). Once the new SMTP server address was put into me client settings, everything was back to normal.
  
  
  
• ls sort order is not case sensitive:
  Red Hat 7.1 uses a version of ls that no longer lists Upper case before lower case.
  Traditionally, the sort went 123...ABC...abc but the new version sorts 123...AaBbCc. If you don't like this new style, find a different dist or an older RH, and copy over /bin/ls.
  
  
  
• Setting the Correct Time Zone:
  Apparently different dist use different structures for this, it took a long time to find. But for RedHat....
  localtime should be a symbolic link to /usr/share/zoneinfo/Canada/Pacific (or whatever)
  ( other/older dists use: usr/lib/zoneinfo )
  ls -al /etc/localtime
  lrwxrwxrwx 1 root root 34 Jan 18 15:02 /etc/localtime -> /usr/share/zoneinfo/Canada/Pacific
  
  On my work system it appears to be a copy or a hardlink
  diff /etc/localtime /usr/share/zoneinfo/Canada/Pacific     (should return nothing)
  (that just confirms they are the same contents)
  
  Also it is suggested that the RTC be set to GMT for accuracy and let Linux deal with Time Zones (except dual boot, as most other os's want local time calculated for them).
  
  
  
• Track what files an install adds or alters:
  1. Before installing, run find /* > /tmp/filename1
  2. After installing, run find /* > /tmp/filename2
  3. to compare the files, run diff /tmp/filename1 /tmp/filename2 and maybe add > /tmp/filename3 to save to a file.
  
  
• Root can't access users HOME dir:
  The default conf for NFS mounts it to enable "root_squashing" which means root cannot access (maybe read only) the NFS drive. You can set it to either root_squash, no_root_squash or another option that changes everyone to a certain UID & GID like guest. (maybe all_squash?) Check the man on exports.
  
  I use nfs for most of my data plus my /home. I edited the /etc/exports file on the remote nfs host and on my local machine edited /etc/updatedb.conf to allow nfs entries into the locate database. This is on RH 7.1, I can't remember seeing this file before, it used to be just args.
  Note, be care ful with no_root_squash as if someone has root on one system, it gives them root on the nfs host, in the nfs exports.
  
  Also, the updatedb could run forever if you include all the nfs mnt's on a large network. I just do that at home.
  
  
  
• The Clock time is correct but Email is time stamped one hour ahead
  This happened on a machine at work and didn't make sence at first. Here is a bit of the email explaining it to the user:
  On Thursday 14 June 2001 07:02 pm, you wrote:
  > Pete -- this is strange. Both my outgoing message and the return to
  > me show the time as 1:22 pm! CvS
  > It looks like you may not be set for daylight savings time. The summertime setting should be -7 UCT (PDT). I suspect your clock is set to the correct display time, but set to -8 UCT (PST). The receiving station converts the time to local-time, which is 1 hr ahead.
  
  Here is a clip from the expanded email header
  (is this from your machine?):
  Date: Thu, 14 Jun 2001 18:02:33 -0800
  
  This shows that Learn is set to -0700 (PDT):
  by learn.etc.bc.ca (8.9.3/8.9.3) with SMTP id SAA25322
  for ; Thu, 14 Jun 2001 18:04:17 -0700 (PDT)
  
  I'm at home but an email from work to home shows -7 in all date fields.
  
  Let me know if that's it, and I'll confirm my workstation in the morning.
  Pete
  
  
  
• Force Auto-Detect of Hardware after you change hardware:
  This came up when kadzu (hardware detection utility) would no longer detect something after you put it back in.
  
  If you want to force kadzu (hardware auto-detect) to find something, you have to remove the file that references it and edit the control file.
  check the dir /etc/sysconfig
  
  to make it detect your mouse from scratch:
  1) open the file "hwconf" and remove the section called "mouse"
  2) delete the file called "mouse" from that dir.
  3) reboot
  
  
  
• DHCP keeps dropping IP Address. This is another email about a firewall issue I had:
  Well, I think I finally found my dropped ip address problem. I also discovered a cool command, pumpd, as in "pump -i eth0 --status" (it's in /sbin/)
  Anyway after lots of scutinizing logs and chain rules, (which apparently turnout to be incomplete in my hardcover book and not in my loose leaf), it looked like my dhcp lease could be set, but not renewed. Still unsure why that was. But I had only allowed my machine to talk to broadcasts of DHCP, however, that is how it starts, but then they speak directly.
  
  ===========================
  this is that I had:
  ============
  # allow DHCP conversations.bootps=67=dhcp_server, bootpc=68=dhcp_client
  # (book didn't have "no connect", added it 29-01-01)
  ipchains -A input -i $EXIF -p udp -s 0/0 bootps -d 255.255.255.255 bootpc\
  -j ACCEPT
  ipchains -A input -i $EXIF -p tcp ! -y -s 0/0 bootps -d 255.255.255.255 bootpc\
  -j ACCEPT
  ipchains -A output -i $EXIF -p udp -s 0/0 bootpc -d 255.255.255.255 bootps\
  -j ACCEPT
  ipchains -A output -i $EXIF -p tcp -s 0/0 bootpc -d 255.255.255.255 bootps\
  -j ACCEPT
  ============================
  this is what I added:
  ==============
  # book didn't have "any" destination,
  # just dest "broadcast", added -d 0/0 30-01-01
  # added this to try and find why lease not renewing.
  ipchains -A output -i $EXIF -p udp -s $EXIP bootpc -d 0/0 bootps\
  -j ACCEPT
  ipchains -A output -i $EXIF -p tcp -s $EXIP bootpc -d 0/0 bootps\
  -j ACCEPT
  ipchains -A input -i $EXIF -p udp -s 0/0 bootps -d $EXIP bootpc\
  -j ACCEPT
  ipchains -A input -i $EXIF -p tcp ! -y -s 0/0 bootps -d $EXIP bootpc\
  -j ACCEPT
  # end of DHCP client
  ==============================
  It does appear a little loose security wise, I could be attacked through port 68 I suppose. Maybe if I restrict the lease conversation to shaw's subnets??
  
  
  
• If ping times out, or has a very long delay before proceeding:
  Try ping -n xxx.xxx.xxx.xxx. Even when you ping an IP address, ping still does name resolution. If ping works fine with the -n option, then there is a problem related to DNS resolution.
  
  
  
• ping reports "Warning: time of day goes back, taking countermeasures.":
  I am not familiar with the new ping command under Red Hat 7.1, but I had to add a -U to ping (man page:"Print true user-to-user latency (the old behaviour)") to avoid having the above error line inserted in the results. The message is distracting, confusing and can mess up scripts.