|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| AWK one liners | VIM Tips | Shell Tips and Tricks | Perl Tips | Humor |
Etc |
docs.sun.com System Administration Guide Naming and Directory Services (DNS, NIS, and LDAP) Changes Do Not Take Effect or Are Erratic
Symptom You add or delete machines or servers but your changes are not recognized or do not take effect. Or in some instances the changes are recognized and at other times they are not yet in effect.
Probable cause The most likely cause is that you forgot to increment the SOA serial number on the master server after you made your change. Since there is no new SOA number, your slave servers do not update their data to match that of the master so they are working with the old, unchanged data files.
Another possible cause is that the SOA serial number in one or more of the master data files was set to a value lower than the corresponding serial number on your slave servers. This could happen, for example, if you deleted a file on the master and then recreated it from scratch using an input file of some sort.
A third possible cause is that you forgot to send a HUP signal to the master server after making changes to the primary's data files.
Diagnosis and solution First, check the SOA serial numbers in the data file that you changed and the corresponding file on the slave server.
- If the SOA serial number in the master file is equal to, or less than, the serial number in the slave file, increase the serial number on the primary's file so that it is greater than the number in the slave file. For example, if the SOA number in both files is 37, change the number in the primary's file to 38. The next time the slave checks with the primary, it will load the new data. (There are utilities that can force a master to immediately transfer data to the secondaries, if you have one of these utilities you can update the slave without waiting for it to check the primary.)
- Review the syslog output for the most recent named nnnn restarted or named nnn reloading nameserver entry. If the timestamp for that entry is before the time you finished making changes to the file, either reboot the server or force it to read the new data as explained in Forcing in.named to Reload DNS Data.
[syslog-ng] Resolving Hostnames for Syslog Source IPs
Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Wed Jun 1 22:52:47 CEST 2005
- Previous message: [syslog-ng] Resolving Hostnames for Syslog Source IPs
- Next message: [syslog-ng] Assessing reliability - did we get all messages?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, 01 Jun 2005 09:33:58 PDT, Jarrod Manzer said: > I had this same problem. I resolved it by logging by IP and then doing > reverse DNS lookups with a script and creating symbolic links to those > IP based directories. The end result was people who like to use IP or > DNS were happy. Gotta make sure your reverse is set up properly though. > > But I never did find out why syslog-ng couldn't resolve the same names > that the host command on the same box could. The most common cause for things like this is semi-borked DNS that *appears* to work, but in fact is subtly misconfigured. A few things to check: 1) Take the IP address, and look up the PTR, which should give you a hostname (this is where most 'host' commands stop). Then actually check that hostname in the DNS, and make sure the IP is listed in an A record (some resolvers do this additional sanity checking). 2) You may have a "lame delegation". Look at the SOA and NS entries for your DNS zones, both PTR and A, and double-check that all machines listed in NS are in fact serving up correct data for the zones (a quick double-check is if all the DNS servers show the correct zone serial number in the SOA). It often happens that if there are multiple NS records, a daemon will "lock in" on asking one NS first, and if it returns an authoritative NXDOMAIN because it's a lame delegation, the daemon won't ask other NS. However, when you use the 'host' command, it may check some *other* NS entry first and magically appear to work. 3) Double-check /etc/resolv.conf to make sure it points 'nameserver' entries at DNS servers that pass the sanity checks in (1) and (2).... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.balabit.hu/pipermail/syslog-ng/attachments/20050601/10f65ff6/attachment-0001.pgp
- Previous message: [syslog-ng] Resolving Hostnames for Syslog Source IPs
- Next message: [syslog-ng] Assessing reliability - did we get all messages?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the syslog-ng mailing list