Rea­son for the env pass­ing prob­lem in CUPS

Today I had the time to have a look at the prob­lem I have to pass the val­ue of the GD_LIB vari­able from CUPS to ghost­script: CUPS is set­ting this vari­able on its own and thus over­rid­ing my setting. 🙁

It seems CUPS is not check­ing if I have my own GS_LIB vari­able and adding its own path to the already set one. That is bad.

More prob­lems with CUPS (pass­ing env variables)

Sat­ur­day I had to print a post­script file. The file was gen­er­at­ed out of a tem­plate which I wrote myself by hand sev­er­al years ago. There I use a non-standard PS font which can not be changed. The font is not embed­ded, and I can print it via ghost­script by telling it the loca­tion where the font files are locat­ed (export GS_LIB=/path/to/dir1/path/to/dir2). Now that I switched to use CUPS as my printserv­er soft­ware, I had to teach it to set this for the call to gs (via foomat­ic). Unfor­tu­nate­ly I failed to get it work­ing via the CUPS config.

I added “SetEnv GS_LIB /path/to/dir1:/path/to/dir2” to cups.conf and restart­ed CUPS. This did not work. I added “PassEnv GS_LIB” to cups.conf, added an appro­pri­ate export of GS_LIB to /etc/rc.conf (just to make sure… I still had the SetEnv in cups.conf) and restart­ed CUPS. This did not work either.

As I just want­ed to print out some­thing and did not want to spend my time debug­ging this, I put a workaround into place: I moved gsc to gsc.bin and cre­at­ed a lit­tle shell script as gsc which sets the vari­able and starts gsc.bin.

At the next update of ghost­script this will break my print­ing (if I for­get that I have this workaround in place), so I should try to get some time to fix this. Maybe I can fix this by adding “env GS_LIB=…” to the call of gs in the ppd, but this seems more like anoth­er workaround to me, than a real fix.

The doc­u­men­ta­tion of CUPS is not very good (CUPS client setup)

Yes­ter­day evening I did set­up a CUPS serv­er at home. It was on my TODO list since years. Before I just went down­stairs and con­nect­ed the print­er via USB to the laptop/netbook for print­ing (to pick­up the print­out I have to go there any­way). It is not the first time that I set­up the serv­er side of CUPS, but it was the first time that I want­ed to use the CUPS com­mand line util­i­ties instead of the FreeBSD/Solaris printspool­er and the native lpr/lp commands.

First I just had a look at some man-pages of the CUPS util­i­ties, in the hope to find some com­mand to tell that any print­ing should be done via a remote CUPS serv­er. As I did not find any­thing, I went to the doc­u­men­ta­tion page of CUPS to search there. To me this is some sim­ple con­fig part if you want to print from more than one machine, so I had a look at the “Get­ting Start­ed” part. This was a total fail­ure. I found noth­ing relat­ed to my prob­lem. After that I went to the “Man Pages” part to search for a com­mand which I may have over­looked. Again, a total fail­ure. The FAQ also does not con­tain any use­ful infor­ma­tion when you search for “client” or “remote”. In the end I stum­bled over the client.conf entry in the Ref­er­ences part. After I found this it was easy (and fast, I just added a line in client.conf with “Server­Name <serv­er>” and every­thing worked as I want­ed it to work).

The set­up in Win­dows XP to use the CUPS serv­er is easy, just add a net­work print­er via http://<server>:631/printers/<printer> and use the cor­rect print­er dri­ver for your print­er mod­el. Do not for­get to make the application/object-stream in the mime* con­fig files and allow remote print­ing in the serv­er. No, I do not want to inte­grate it into Sam­ba, the num­ber of Win­dows sys­tems is very lim­it­ed (2 Win­dows against 2 Unix machines with 14 light­weight vir­tu­al Unix machines), so I do not need this.

Some more WP plugins

Addi­tion­al­ly to the WP plu­g­ins I already talked about, I installed some more since then:

  • aLinks: auto­mat­ic link gen­er­a­tion based upon rules/modules/keywords
  • All in one SEO Pack: Search Engine Opti­miza­tion, e.g. auto­mat­ic meta tag gen­er­a­tion and more
  • Glob­al Trans­la­tor: auto­mat­ic machine-translation of your posts into oth­er lan­guages (see the coun­try flags in the sidebar)
  • Google XML Sitemaps: auto­mat­i­cal­ly gen­er­ates a sitemap and announces the update (after a post) to sev­er­al searchengines
  • http:BL word­press plu­g­in: checks vis­i­tors against the Project Hon­ey Pot black­list (email har­vest­ing) and rejects access
  • InfoLink: adds a but­ton to look up marked text in the edi­tor and link the markup to the first result if desired
  • One-Time Pass­word: allows to use one-time pass­words (RFC 2289) for the WP login
  • Smartlink­er: anoth­er but­ton for the edi­tor regard­ing auto­mat­ic link­ing (gives oth­er auto­mat­ic links than the oth­er auto­mat­ic link­ing plugins)
  • Update Noti­fi­er: sends me a mail when there is a update for WP
  • WP-Print: print­er friend­ly page of the post­ing (see the link below the title of this post), I had to patch it to not print the links from the WP AJAX Edit Com­ments plugin
  • WP AJAX Edit Com­ments: pro­vides an AJAX edit inter­face for comments

Doxy­gen stuff updat­ed in 9‑current

I com­mit­ted my patch for tools/kerneldoc/subsys. Except for not gen­er­at­ing the PDF part, this is now the same con­fig which I use to gen­er­ate the online ver­sion. While writ­ing the com­mit log I noticed that I did more changes than I thought…

So any­one who wants to gen­er­ate the Doxy­gen docs of some FreeB­SD ker­nel sub­sys­tems on his own, can do it now. Adding more sub­sys­tems is easy, just make a copy of one the the exist­ing Doxyfile-* files – keep the same nam­ing scheme – and change the con­tents. Every­thing else is han­dled automatically.

I also added a link to the FreeB­SD wiki. It is not at a promi­nent place (near the end of the main page), but at least some­one can find the link to the my FreeBSD-doxygen page there.