Review your favorite Linux distribution.
Go Back > Blogs > Rod3775
User Name


Rate this Entry

Building a CUPS server for a network with Slackware

Posted 05-06-2017 at 11:05 AM by Rod3775

Heterogenous Networks with Heterogeneous Printers

This blog describes the process of building a modest home network involving multiple printers and computers with different operating systems, using consumer-level equipment.

The priority objective was to be able to print on all printers from all computers.
A secondary objective was to concentrate the maintainable software in one place, so that if new printers or computers were added, only the new equipment needed to be set up, and printer-specific software did not have to be maintained on every computer across upgrades.

The target system consisted of the following computers:

A MacBook running OS X (who knows what version) with 2 NICs
An iPhone running iOS with (at least) one wireless NIC
A Windows laptop running Windows 8(?) with one wireless NIC
A Slackware laptop running Slackware-14.2 with one wired and one wireless NIC
A retired Window XP desktop repurposed to run Slackware 14.2, with one wired NIC

and the following printers:

An Epson inkjet printer with a USB port, standard wireless, and an AirPrint access point.
An HP inkjet printer with a USB port, an Ethernet port, standard wireless, and an AirPrint access point.
A Brother laser printer with a USB port, an Ethernet port, and standard wireless.
A Canon inkjet printer with a USB port.

Both printers and computers were located at various places around the building. The existing local area network (LAN) was supplied by a NETGEAR wireless router that also supported 4 wired Ethernet ports and DHCP. It did not support local DNS, but passed DNS requests through to its WAN connection for external name service. As with most consumer-grade wireless routers, it supported global unicast, LAN-level broadcast, and no multicast on its network. Fortuitously, its DHCP did support static IP allocations, although without local name service, these allocations had to be carried around on paper! Let us call this network "MyNetwork"

All sources were on MyNetwork in order to obtain external Internet service, which worked fine.
The Slackware desktop was directly connected to the Canon printer and had a wired connection to the router.

The other computers were wireless only, and so were all the other printers.

The Slackware desktop ran CUPS with 4 print queues and could print to any printer either directly or thru unicast on MyNetwork.

The iPhone could print to the HP and the Epson inkjet printers using their AirPrint access points. One presumes the iPhone has a second NIC so it could be on the Internet and use VOIP calling, but who knows? It cannot print to the Brother or the Canon.

The MacBook could print on all 4 printers using unicast on My Network. It connected directly to the three wireless printers and as a CUPS client to the CUPS server on the Slackware desktop. However, three different CUPS drivers were required on the MacBook. The connection to the CUPS server used "Generic-PDF_Printer" and the IPP protocol for the Canon. The other printers could have been accessed the same way, but the MacBook setup predated the Slackware desktop.

The Slackware laptop can print on all 4 printers through the Slackware desktop CUPS server, using its wireless connection to MyNetwork. It does not even need to run CUPS, although it could.

The fundamental complication in this setup is the iPhone. iPhones require the BonJour multicast protocol for service discovery, and most wireless routers do not support multicast. Multicast destination addresses look just like external Internet addresses, and go out to the WAN, where they are dropped.

The hardware part of the solution to all this was to add a wireless NIC (USB connected) to the Slackware desktop. So the local wireless environment would now contain 4 networks - MyNetwork, the HP access point network, the Epson access point network, and the CUPS server network (referred to as MyBonJour).

The software part required a bunch of new software, all running on the Slackware desktop (which was not used for anything else anyway). Sbopkg was used to get most of them. Here's the list:

hostapd-2.6 (sbopkg)
libdaemon-0.14 (sbopkg)
avahi-0.6.31 (sbopkg)
nss-mdns-0.10 (sbopkg)
cups-2.2.3 (slackpkg, but recompiled - see below)
cups-filters-1.9.0 (slackware-stable) or cups-filters-1.13.4 (slackware-current) (slackpkg, but recompiled -but see below)
gstoraster-1.20 (, but see below)
rc.dhcpd (
airprint-generate (
AirPrint article (linux-magazine/Online/Features/AirPrint (good howto information)

To get the Slackware access point running, configure hostapd.conf using the example in /etc/hostapd (the complete .conf file and the man page are terminally obscure and intimidating). Configure the wireless NIC in /etc/rc.d/rc.inet1.conf to a new network IP(suggested 192.168.x.1,where x>1), netmask( and USE_DHCP="no". Modify the rc.dhcpd script to start dhcpd on your new wireless NIC (only). At this point, running /etc/rc.d/rc.hostapd and /etc/rc.d/dhcpd should give you a new wireless network visible from another wireless machine. Do what you need to about encryption and passphrases on both ends. You should be able to ping on the new network and if you run tcpdump/wireshark on the Slackware desktop, you should see the ICMP packets.

Libdaemon, Avahi, and nss-mdns can be compiled and installed with sbopkg -i. Nothing special.

CUPS is more problematic. The standard slackpkg does not support mDNS, required for printer discovery. The source for the slackware-current version is on Download all the files (only about 6 or so) and edit the SlackBuild to --enable (rather than --disable Avahi and mdns). Then run the SlackBuild and "installpkg" the result.

This installation tries to do all the rendering on the CUPS server, so data from remote clients is sent as PDF/PS and converted in many cases by the CUPS filter "gstoraster". However, the current Slackware versions of gstoraster are 'C' executables and contain a bug which prevents gstoraster from correctly detecting the file type. I posted a patch on about this, and cups-filters can be rebuilt from source (again at Slackware-stable and slackware-current use different versions of cups-filters, and the -current version won't compile on slackware-stable, so get the right version. The patch works on both. Alternatively, pick up gstoraster-1.20 from and copy it into /usr/lib[64]/cups/filter. It's a Perl script, works fine, and doesn't have the bug.

Presuming that the printers have all been added to CUPS by manually typing in their connections:
ipp://192.168.[0|1].y (on MyNetwork)
and correctly print test pages from the CUPS server itself, set up /etc/cups/cupsd.conf
for remote printing and AirPrint printer discovery. If your CUPS server is MyServer (hostname)
and the domain used for MyNetwork is MyDomain, add "ServerAlias MyServer.local MyServer.MyDomain" to cupsd.conf. Add "Port 631" if it's not already there.

At this point, remote sources with access to MyNetwork should be able to print to
ipp:/192.168.[0|1].z/printers/CUPS_queue_name (on MyNetwork,
where z is the last digit of MyServer's IP address)
using THEIR local CUPS server, whose queues define these connections with the PPD file "Generic-PDF_Printer-PDF.ppd"

When the print queues on the CUPS server were created, the file /etc/cups/printers.conf was created by CUPS. The Python script "airprint-generate" will read this data and create a set of Avahi service files describing them for service discovery. They go in /etc/avahi/services and are the basis of what Avahi (Apple's BonJour) tells remote clients about printers (and other things).

So now, when a remote computer connects to the CUPS server and does its equivalent of "Add New Printer", ITS local Avahi equivalent will have discovered the availability of these printers through a multicast interchange with the CUPS server's Avahi, which is multicasting ("advertising") this info. The annoying part is that the wireless router does not pass multicast, so the information is only available through the server's access point. If the remote computer only has one wireless NIC, it can connect to the MyBonJour network and print, but will have no other outside access. This is why the printers have two NICs to support AirPrint, and the MacBook has two also. Its why the other actual computers don't use AirPrint and explicitly refer to either the CUPS server IP or the printer IP on MyNetwork. Its also why it's a good thing the router allows fixed IP addresses, even though it won't tell anyone about them!

Avahi and mDNS use the ".local" domain, which is why cupsd.conf uses ServerAlias. But the host names that Avahi multicasts are in the ".local" domain and when a remote client uses that domain to try to print, CUPS becomes confused. The file /etc/nsswitch.conf describes a series of sources for name resolution. The line in question is `hosts:' and should contain "hosts: files dns". Avahi would like you to put "mdns" in between
"files" and "dns" but don't do it. Instead, add a line in the server's /etc/hosts of the form
" MyServer.local"

This makes the order of search

/etc/hosts # gets localhost and MyServer.local
dns # gets everything else

This file is used by much of the system. There are numerous ways to resolve names,
some historical and some bypassing NSS. All of them seem to locally cache answers, and may therefore return inconsistent results. So putting mdns in there is not without risk. Especially if Avahi is not running all the time. The only way to flush the caches (which are in memory) is to reboot!

The article mentioned above describes needed mime changes for airprint - not repeated here.

And last, rc.M needs to be modified on the CUPS server. It starts CUPS, but not hostapd, DHCP and Avahi.
So make rc.avahidaemon. rc.dhcpd and rc.hostapd executable, and start them in the order

Good luck!
Posted in Uncategorized
Views 1306 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 07:00 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration