@rice.edu:evan@brazos.rice.edu (Evan Wetstone) (04/26/89)
If you are running Sun's nameserver kit (available via anonymous ftp from uunet.uu.net in the file sun-fixes/ddn.tar.Z), you may find that you have a problem with syslogging. The problem is described quite well by Steven Miller of the University of Maryland: -----------Begin included message----------- >From: steve@grinch.umiacs.umd.edu (Steven D. Miller) >Subject: Re: sendmail 5.59 and syslogging You're not seeing any logging because of incompatibilities between old-style and new-style struct hostents. The syslog libc routines were compiled expecting gethostbyname() to return a hostent like: struct hostent { ... char *h_addr; ... } However, you're using the new gethostbyname(), which returns: struct hostent { ... char **h_addr_list; ... } Thus, when syslog goes to grab the IP address of loghost (or whatever), it gets instead some random pointer value, which it treats as an IP address. The UDP syslog packet gets sent to never-never land. (I suppose it's a lucky thing that pointers generally make poor IP addresses, or some people would be seeing lots of strange syslogs on their machines!) If you can recompile the libc syslog routines against your BIND libraries, you'll be OK. If not, I'm not really sure what to suggest. Perhaps Sun Technical Support could cough up a recompiled syslog; all they'd have to do is change the #include of netdb.h to include the new netdb.h with the new structure declaration, and all would be well. This problem also arises when building the new sendmail on older Ultrix systems. I know that the new structure declaration is used on the 2.4 and 3.0 field test stuff we're running on a few machines, and it may have been used under Ultrix 2.2, but I have nothing running 2.2 or earlier and can't check this out. The hostent problem often occurs in reverse, too. When building BIND (and the occasional other thing), if you somehow get back an old-style hostent but are expecting a new-style one, you'll dereference an IP address. Can you say, "instant core dump?" -Steve -----------End of included message----------- I experienced this problem while trying to bring up sendmail 5.61. I proceeded to call it in to Sun to see if they had a fix. You will note that one possible fix is given in the above letter. Another option would be simply to recompile the syslog.c routines with the new netdb.h, and include them along with the new gethostbyxxxx() routines in libresolv.a. This was about four weeks ago. I have been calling my software support person about 3 times a week now, and the answer I am getting now is that the engineer is working on it, but it's been given a low priority. Personally, I don't consider it to be a low priority. First, if I want any of my code to do name resolution, it can't do any system logging. If I want it to log, it can't do name resolution. To me, this is not a low priority problem. Second, the nameserver kit was released by Sun. It's their code. I would think that fixing a bug in some of their own code would have at least a mid-level priority. Third, after four weeks, I really don't consider it to be low priority. What more do they want? We've given them the problem, sent them code which duplicated it, and given them a relatively simple fix for it. Why has it taken a month? Would anyone out there from Sun care to comment on this? Perhaps explain why fixing this bug is considered to be a low priority? As an added incentive, the sooner I get this problem fixed, the sooner I can install the new sendmail on rice.edu, which may help reduce some of the problems we have while trying to deliver Sun-Spots....8-) Thanks, Evan Wetstone (evan@rice.edu) Networking and Planning Rice University, PO Box 1892, Houston TX, 77251-1892, (713) 527-6059