Re: cupsys (was: Re: lprng as 'stantard' package)
Hello again.
I found PPR on freshmeat. It does about the same as CUPS, but
doesn't try to support non-PS printers itself (there are
interfaces to gs however). I think it could be made superior to
CUPS, since it is much more unixish (SysVish to be precise).
Henrique M Holschuh schrieb:
> I'm worried about cupsys' security. It has too much "nifty network
> awareness" (i.e.: browsing, serving files(!) and running cgi scripts(!!))
> for my tastes, Personally, I'll not trust it in a hostile network until I
> have a LOT of time to look at it closer.
Well, PPR serves files and runs cgis, since I had to create a
user pprwww for it, this seems to be done by a seperate process
with few privilegues. I think a nice web interface for
inspecting the queues is not necesserily a bad thing.
> Other stuff the DEBIAN packaging of cupsys and friends would need before
> going standard (IMHO, obviously):
>
> - To try to take advantage of magicfilter... or incorporate all that
> conversion support that magicfilter already has (at the very least DVI,
> compressed data and *roff). If CUPS has a fallback system for conversions,
> a wrapper script could be written I guess...
PPR has some magic/manual filtering facility, though no troff,
dvi etc filters currently.
> - To integrate CUPS with the distribution's font system (it really should
> share fonts AND font configuration with the gs-* packages) if that isn't
> done yet. I know I would be VERY ticked off if I found out that my
> postscript stuff wasn't printing correctly because cupsys' embebedded
> postscript rasterizer was not even trying to use the postscript fonts
> installed in the system. I assume others might not like it either :-)
Probably symlinking ppr/fonts to somewhere else works ... have
to try it out.
> - Package all that nifty ammount of printer PPDs at cups.sourceforge.net if
> their license allows it. Otherwise, consider packaging a installer and add
> URLs to cupsys' README.Debian
PPDs should be packaged seperately like fonts, in order not all
spooling systems which support them have to include them.
> - Package the GS PPD and related utils if the internal rasterizer can't be
> made to run GS to begin with. Without it, cupsys simply isn't useful for
> way too many people.
PPR has interfaces for gs. They are equal to the others, except
that error handling ends at gs -- PCL printers don't spit out PS
errors ...
> - Package the web-based administration separately (requiring the -docs
> package) if that proves necessary for system stability or reduces size in
> a meaningful way (better than 500kb savings IMHO).
Yes, kicking out/disabling web _administration_ is something
that would have to be done for PPR too. I think many would like
to check the status of the printers/queues web based, but the
admin stuff is really superfluous IMO.
I'll see how I stop the configure/install scripts that come with
ppr from chatting that much and get it FHS-compliant, then I'll
try to package it. I could happen to be already through the
NM-process when I'm finished with this beast! ;)
ciao, 2ri
--
It's not a bug, it's tradition!
Reply to: