Loading ...
Sorry, an error occurred while loading the content.

CUPS printing to LPD Unslung 6.10-beta? Or should I change firmware?

Expand Messages
  • starnamer
    One on my intended uses for getting a Slug was to move a IPP print service off a really old Ubuntu box (circa 1999). CUPS on Ubuntu is configured to print to
    Message 1 of 7 , Aug 7, 2009
    • 0 Attachment
      One on my intended uses for getting a Slug was to move a IPP print service off a really old Ubuntu box (circa 1999).

      CUPS on Ubuntu is configured to print to an HP Deskjet on an LPD printserver and port 631 is open on my firewall to allow internet access to the Ubuntu CUPS service so I can print from other locations. The main remote location I use is behind a firewall and HTTP proxy so I have to use IPP rather than just opening up the LPD port.

      [Me]->[HTTP_Proxy]->[Firewall]->[Internet]->[Firewall]->]IPP_Server]->[LPD_Server]->[Printer]

      The setup I've tried was to install CUPS and CUPS-DOC on Unslung 6.10 beta and add a printer pointing at the LPD printserver. Unfortunately, I get "unsupported format: text/plain" when trying to print from the command line and "unsupported format: application/postscript" when trying to print a test page from CUPS.

      Reading a post here [http://tech.groups.yahoo.com/group/nslu2-linux/message/22992%5d implies that the problem is that the slug "doesn't have the oomph" to run the renderer and that the CUPS implementation just doesn't try to do local conversion. Since a quick check indicates that the mime type and conv files are there and the filter executale exist, it's not immediately obvious why it doesn't work, but it's been a few years since I tried to look closely at how CUPS works.

      So the questions are - is this correct? Or is there some way to get CUPS (1.3.11) to run properly on Unslung? If there is a way to enable this functionality, would it kill the slug?

      Alternatively, does this functionality exist in another firmware version for the slug? I'm pretty certain that Debian-NSLU2 would support it, but this seems like overkill.

      At the moment, I'm only using the slug as a file, NTP and DAAP server and am toying with the idea of a web server.

      Thanks

      Derek.
    • Mike Westerhof (mwester)
      ... In my opinion and experience, no, there is no *practical* way to get the entire CUPS suite of software and supporting tools to run on the NSLU2. From an
      Message 2 of 7 , Aug 8, 2009
      • 0 Attachment
        starnamer wrote:
        > One on my intended uses for getting a Slug was to move a IPP print service off a really old Ubuntu box (circa 1999).
        >
        > CUPS on Ubuntu is configured to print to an HP Deskjet on an LPD printserver and port 631 is open on my firewall to allow internet access to the Ubuntu CUPS service so I can print from other locations. The main remote location I use is behind a firewall and HTTP proxy so I have to use IPP rather than just opening up the LPD port.
        >
        > [Me]->[HTTP_Proxy]->[Firewall]->[Internet]->[Firewall]->]IPP_Server]->[LPD_Server]->[Printer]
        >
        > The setup I've tried was to install CUPS and CUPS-DOC on Unslung 6.10 beta and add a printer pointing at the LPD printserver. Unfortunately, I get "unsupported format: text/plain" when trying to print from the command line and "unsupported format: application/postscript" when trying to print a test page from CUPS.
        >
        > Reading a post here [http://tech.groups.yahoo.com/group/nslu2-linux/message/22992%5d implies that the problem is that the slug "doesn't have the oomph" to run the renderer and that the CUPS implementation just doesn't try to do local conversion. Since a quick check indicates that the mime type and conv files are there and the filter executale exist, it's not immediately obvious why it doesn't work, but it's been a few years since I tried to look closely at how CUPS works.
        >
        > So the questions are - is this correct? Or is there some way to get CUPS (1.3.11) to run properly on Unslung? If there is a way to enable this functionality, would it kill the slug?

        In my opinion and experience, no, there is no *practical* way to get the
        entire CUPS suite of software and supporting tools to run on the NSLU2.
        From an "impractical" point-of-view, with enough swap space, and
        careful tailoring, and selection of small documents to print, along with
        great patience (and the disabling of the OOM Killer), you might actually
        get something to work.

        (And now it's time for the inevitable comment from someone, that goes
        something like: "But I had CUPS 1.0 working wonderfully back in 1955, on
        my 5 MHz 8-bit Studebaker running Linux 0.1 with only 640KB of RAM! The
        NSLU2 is far more powerful than that!!" :-D Regardless, I'll stick with
        my statement: the NSLU2 cannot meet modern expectations for complex
        document conversion and rendering, no matter what you do.)

        > Alternatively, does this functionality exist in another firmware version for the slug? I'm pretty certain that Debian-NSLU2 would support it, but this seems like overkill.

        Well, no. Optware is optware on both SlugOS and Unslung. And the issue
        is the memory on the device primarily, and its CPU speed secondarily.

        > At the moment, I'm only using the slug as a file, NTP and DAAP server and am toying with the idea of a web server.

        You might consider a different approach, though. The NSLU2 does a dandy
        job running just the part of CUPs that spools the print job and drives
        the printer. I've got that running handling an HP Laser printer, works
        great. The trick is to make the other devices in the network (Windows
        and Linux machines) run the renderer locally. This is relatively easy
        to configure, and even Windows cooperates if you have it drive the
        printer as an IPP device.

        > Thanks
        >
        > Derek.

        Mike (mwester)
      • starnamer
        ... Thanks Mike. Interesting, the the date you reference (possibly a typo :)) I was born in 1955 so, yes, I did used to run an early version of CUPS on
        Message 3 of 7 , Aug 9, 2009
        • 0 Attachment
          --- In nslu2-linux@yahoogroups.com, "Mike Westerhof (mwester)" <mwester@...> wrote:
          > In my opinion and experience, no, there is no *practical* way to get the
          > entire CUPS suite of software and supporting tools to run on the NSLU2.
          > From an "impractical" point-of-view, with enough swap space, and
          > careful tailoring, and selection of small documents to print, along with
          > great patience (and the disabling of the OOM Killer), you might actually
          > get something to work.
          >
          > (And now it's time for the inevitable comment from someone, that goes
          > something like: "But I had CUPS 1.0 working wonderfully back in 1955, on
          > my 5 MHz 8-bit Studebaker running Linux 0.1 with only 640KB of RAM! The
          > NSLU2 is far more powerful than that!!" :-D Regardless, I'll stick with
          > my statement: the NSLU2 cannot meet modern expectations for complex
          > document conversion and rendering, no matter what you do.)
          >
          > > Alternatively, does this functionality exist in another firmware version for the slug? I'm pretty certain that Debian-NSLU2 would support it, but this seems like overkill.
          >
          > Well, no. Optware is optware on both SlugOS and Unslung. And the issue
          > is the memory on the device primarily, and its CPU speed secondarily.
          >
          > > At the moment, I'm only using the slug as a file, NTP and DAAP server and am toying with the idea of a web server.
          >
          > You might consider a different approach, though. The NSLU2 does a dandy
          > job running just the part of CUPs that spools the print job and drives
          > the printer. I've got that running handling an HP Laser printer, works
          > great. The trick is to make the other devices in the network (Windows
          > and Linux machines) run the renderer locally. This is relatively easy
          > to configure, and even Windows cooperates if you have it drive the
          > printer as an IPP device.
          >
          > > Thanks
          > >
          > > Derek.
          >
          > Mike (mwester)
          >

          Thanks Mike.

          Interesting, the the date you reference (possibly a typo :)) I was born in 1955 so, yes, I did used to run an early version of CUPS on something far less powerful than the NSLU2.

          Regarding your suggestion, the point is that I don't want to leave another PC running when I'm away and want to print something for reference back home. There's also the situation where I'm sat next to the printer using a PC which is VPN'd into a remote site, and blocked from accessing the local subnet by policies set at the remote site, so, effectively, the local PC isn't available!

          So with all the caveats, it is possible to get at least a subset of CUPS running?

          Obviously, it would need a reasonable amount of spool space and probably a large swap area, but since old PC's used to be able to manage to do this so it should be possibly. Does the functionality exist and has been disabled or would I need to get hold of the sources and build a custom version of CUPS? The latter might be better as I could then remove completely anything I didn't want rather than just disable or not use it, however, this would obviously be more work!

          You also didn't comment as to whether Debian could do it? Or does this count as an Optware variant in this case?

          Thanks agan for the reply.

          Derek.
        • starnamer
          ... BTW, the point is that the printserver is an LPD device, which can t be routed through HTTP proxies, so I need a Linux or other box to drive it. If I have
          Message 4 of 7 , Aug 9, 2009
          • 0 Attachment
            --- In nslu2-linux@yahoogroups.com, "Mike Westerhof (mwester)" <mwester@...> wrote:
            > You might consider a different approach, though. The NSLU2 does a dandy
            > job running just the part of CUPs that spools the print job and drives
            > the printer. I've got that running handling an HP Laser printer, works
            > great. The trick is to make the other devices in the network (Windows
            > and Linux machines) run the renderer locally. This is relatively easy
            > to configure, and even Windows cooperates if you have it drive the
            > printer as an IPP device.

            BTW, the point is that the printserver is an LPD device, which can't be routed through HTTP proxies, so I need a Linux or other box to drive it. If I have to leave a Linux PC running to route from IPP to LPD then there's no advantage to routing it through the NSLU2! Or am I missing something here?

            Derek.
          • starnamer
            ... I m quite prepared to reduce my expectations! :)
            Message 5 of 7 , Aug 9, 2009
            • 0 Attachment
              --- In nslu2-linux@yahoogroups.com, "Mike Westerhof (mwester)" <mwester@...> wrote:
              > (And now it's time for the inevitable comment from someone, that goes
              > something like: "But I had CUPS 1.0 working wonderfully back in 1955, on
              > my 5 MHz 8-bit Studebaker running Linux 0.1 with only 640KB of RAM! The
              > NSLU2 is far more powerful than that!!" :-D Regardless, I'll stick with
              > my statement: the NSLU2 cannot meet modern expectations for complex
              > document conversion and rendering, no matter what you do.)

              I'm quite prepared to reduce my expectations! :)
            • Mike Westerhof (mwester)
              ... So you need IPP. No problem, works great. ... Of course - I mentioned that in the original email you referenced: just run the print driver (Windows) or
              Message 6 of 7 , Aug 9, 2009
              • 0 Attachment
                starnamer wrote:

                > Regarding your suggestion, the point is that I don't want to leave another PC running when I'm away and want to print something for reference back home. There's also the situation where I'm sat next to the printer using a PC which is VPN'd into a remote site, and blocked from accessing the local subnet by policies set at the remote site, so, effectively, the local PC isn't available!

                So you need IPP. No problem, works great.

                > So with all the caveats, it is possible to get at least a subset of CUPS running?

                Of course - I mentioned that in the original email you referenced: just
                run the print driver (Windows) or renderer/converter (Linux) locally,
                and use CUPS on the NSLU2 to pass the HP PCL (or whatever your native
                printer speaks) from the IPP port to the printer.

                > Obviously, it would need a reasonable amount of spool space and probably a large swap area, but since old PC's used to be able to manage to do this so it should be possibly. Does the functionality exist and has been disabled or would I need to get hold of the sources and build a custom version of CUPS? The latter might be better as I could then remove completely anything I didn't want rather than just disable or not use it, however, this would obviously be more work!

                Of course this works -- see my earlier emails! This is basic CUPS
                functionality. I chose to use a 20GByte hard drive for spool space, but
                given the price of flash drives anymore you could easily do this with a
                flash drive.

                > You also didn't comment as to whether Debian could do it? Or does this count as an Optware variant in this case?

                The issue is the NSLU2 hardware. So, no, Debian would have exactly the
                same issues SlugOS would have. Unslung differs only in that it has an
                older kernel, so it may be slightly different in exactly where and how
                it would fail. But the issue is the hardware -- you do not have enough
                CPU and memory to run the postscript->PCL conversion (or whatever
                converter you would need for your printer) on the device, in any
                practical way.

                > Thanks agan for the reply.

                Mike (mwester)
              • starnamer
                Thanks Mike. It works as expected! I was thrown by the fact that after initially installing CUPS, I got Unsupported format errors from both trying to use the
                Message 7 of 7 , Aug 9, 2009
                • 0 Attachment
                  Thanks Mike. It works as expected!

                  I was thrown by the fact that after initially installing CUPS, I got 'Unsupported format' errors from both trying to use the command 'lpr' (text/plain) and trying to print a test page (application/postscript).

                  This led me to this the renderer wouldn't run. I tried simply setting up to print remotely (changing firewall setting) and, after solving the "using invalid Host: field" problem (the external hostname needs to be in the/etc/hosts file), it worked fine.

                  I then tried the 'lpr' command and printing a test page and these work too, although, as expected, printing postscript causes paging. However, it seems the NSLU2 will use a local renderer without dying. Perhaps it would be worse for more complex print.

                  Anyway, thanks for your advice.

                  Derek.
                Your message has been successfully submitted and would be delivered to recipients shortly.