[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: