> -=-=-=- > Name : cups Relocations: (not > relocateable) Version : 1.1.19 Vendor: > MandrakeSoft Release : 10mdk Build Date: Thu > 18 Sep 2003 04:24:28 AM CEST Install Date: (not installed) > Build Host: no.mandrakesoft.com Group : System/Servers > Source RPM: (none) > Size : 3791412 License: GPL > Signature : (none) > Packager : Till Kamppeter <[EMAIL PROTECTED]> > URL : http://www.cups.org > Summary : Common Unix Printing System - Server package > Description :
> -=-=-=- > Till Kamppeter <[EMAIL PROTECTED]> 1.1.19-10mdk > > - Fixed bug 5615 by means of the following two changes: > o Make the CUPS daemon not sending broadcast packages with the host > name > "localhost". In this case the IP address of the appropriate > interface is used (patch 22). > o Do not insert "ServerName" directives in /etc/cups/cupsd.conf any > more > during the startup of CUPS (with the /usr/sbin/correctcupsconfig > script). > Hmm, it seems cups admits defeat to drakconnect ... IMHO, drakconnect's job is to ensure: 1)The hostname is never set to localhost if there is any networking device attached to the machine in question 2)Reverse lookups will always work. In the case of DHCP, drakconnect should ensure that the hostname is sent as DHCP_HOSTNAME (in which case we hope the DHCP administrator has working DDNS), and doesn't touch tmdns.conf. In the case of no DHCP, tmdns.conf is not touched (and we hope the other machines have working tmdns). Really, this patch to cups should not be necessary, and there are similar problems with having the hostname as localhost (samba will register 'localhost' in WINS, announce itself by broadcast as 'localhost', will attempt to join domains as 'localhost' and many similar bad things), and I refuse to patch samba just because drakconnect stuffs up. At present, the only way a user will get a working config is by running drakconnect in expert (or using all the advanced buttons) to set it to send the hostname in the dhcp request and set the hostname to be the same as the zeroconf name (which really doesn't need to be set). Sorry, but I'm fed up with having to rerun configuration tools becuase their defaults suck, and I am not prepared to support samba for issues caused by of drakconnect (ie if someone asks on the samba lists, I will point them to bug reports for drakconnect which have been flatly ignored). This is a very important aspect, which is not difficult to fix, but no-one has been willing to discuss the failings of drakconnect ... even when the problems with the current approach have been highlighted before. This solution should not have been necessary. Regards, Buchan ***************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *****************************************************************
