** Attachment added: "Proposed debdiff for a Gutsy SRU" http://launchpadlibrarian.net/11232402/cupsys-sru-req.debdiff
** Description changed: Binary package hint: cupsys - From CUPS 1.3.x, except at startup, network interfaces are not anymore - polled for changes (appearance and disappearance of a network interface, - and any IP address or mask change). + Problem: + From CUPS 1.3.x, except at startup, network interfaces are not anymore polled for changes (appearance and disappearance of a network interface, and any IP address or mask change). This means that in a CUPS configuration allowing local connection (sharing of local printer on local network), any connection from a local ip coming on an interface that appeared after CUPS startup (in my case a vpn one), is refused (403 error). And as a result, obviously, printer is not shared on the local network related to this interface. The user has to restart cupsd in order to make cups accept connection on these new network interfaces. Until recently this was difficult to see, because there was another problem affecting sharing in gutsy and hardy, that was necessitating a restart of cupsd (the late start of avahi, recently fixed in bug 173470 ). - I have tracked it down and in fact, the problem appeared with revision - 6123 (pre 1.3.0) in cups svn trunk, that was landing a multiplatform - management of poll (use of poll(), epoll(), or kqueue() depending of the - platform). Part of this checkout moved the Mac OS X specific call to - cupsdUpdateSystemMonitor in main.c to a select callback in sysman.c (we - don't care), but in the same time it removed (inadvertantly) in main.c - the set of NetIFUpdate to 1 every minute or so for all other OS (here, - we care ;-) ) + Fix: + I have tracked it down and in fact, the problem appeared with revision 6123 (pre 1.3.0) in cups svn trunk, that was landing a multiplatform management of poll (use of poll(), epoll(), or kqueue() depending of the platform). Part of this checkout moved the Mac OS X specific call to cupsdUpdateSystemMonitor in main.c to a select callback in sysman.c (we don't care), but in the same time it removed (inadvertantly) in main.c the set of NetIFUpdate to 1 every minute or so for all other OS (here, we care ;-) ) See: svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/main.c (look for NetIFUpdate) and more generally svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/ (to check that this checkout did not reintroduced the code removed anywhere in the scheduler else (except for Mac OS X) ) svn log -r 6123 http://svn.easysw.com/public/cups/trunk/ I have reported the problem upstream on Sunday : http://www.cups.org/str.php?L2631 with a patch : http://www.cups.org/strfiles/2631/interface-update_v2.patch + + + TEST CASE: + Edit /etc/cups/cupsd.conf in order to get a basic local sharing configuration : change "Listen localhost:631" to "Port 631" and "Browsing Off" to "Browsing On" + + Get your networking off to start it only after CUPS : + 1) sudo /etc/init.d/networking stop + 2) sudo /etc/init.d/cupsys restart + 3) sudo /etc/init.d/networking start + + After these restarts, any CUPS connection coming from the local network is refused if the bug is present + This can be checked from a remote box on the LAN by trying to access *more than 1 minute* after restart to http://<cupsserveripaddressonthelan>:631 , that leads to a 403 error if the bug is present. + + The 1 minute wait is needed because the check for new network interfaces + takes place once a minute. + + Note that CUPS correctly broadcast on the local network (test: avahi- + browse -k -t -v -r -a) whether or not this bug is present, but this is + useless if it is refusing connections.. ** Summary changed: - CUPS 1.3.x lists network interfaces only at startup (regression) + [Gutsy SRU Request] CUPS 1.3.x lists network interfaces only at startup (regression) -- [Gutsy SRU Request] CUPS 1.3.x lists network interfaces only at startup (regression) https://bugs.launchpad.net/bugs/177075 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
