Friday Oct 09, 2009

Preparing for OpenSolaris @ home

Since the "nevada" builds of Solaris next are due to end soon and for some time the upgrade of my home server has involved more than a little bit of TLC to get it to work I will be moving to an OpenSolaris build just as soon as I can.

However before I can do this I need to make sure I have all thesoftware to provide home service. This is really a note to myself to I don't forget anything.

  • Exim Mail Transfer Agent (MTA). Since I am using certain encryption routines, virus detection and spamassassin I was unable to use the standard MTA, sendmail, when the system was originaly built and have been using exim, from blastwave. I hope to build and use exim without getting all the cruft that comes from the Blastwave packaged. So far this looks like it will be simple as OpenSolaris now has OpenSSL.

  • An imapd. Currently I have a blastwave version but again I intend to build this from scratch again the addition of OpenSSL and libcrypto should make this easy.

  • Clamav. To protect any Windows systems and to generally not pass on viri to others clamav has been scanning all incoming email. Again I will build this from scratch as I already do.

  • Spamassassin. Again I already build this for nevada so building it for OpenSolaris will be easy.

  • Ddclient. Having dynamic DNS allows me to login remotely and read email.

  • Squeezecenter. This is a big issue and in the past has proved hard to get built thanks to all the perl dependacies. It is for that reason I will continue to run it in a zone so that I don't have to trash the main system. Clearly with all my digital music loaded into the squeezecentre software this has to work.

I'm going to see if I can jump through the legal hoops that will allow me to contribute the builds to the contrib repository via Source Juicer. However as this is my spare time I don't know whether the legal reviews will be funded.

Due to the way OpenSolaris is delivered I also need to be more careful about what I install. rather than being able to choose everything. First I need my list from my laptop. Then in addtion to that I'll need

  • Samba - pkg:/SUNWsmba

  • cups - pkg:/SUNWcups

  • OpenSSL - pkg:/SUNWopenssl

Oh and I'll need the Sun Ray server software.

Friday Apr 10, 2009

Native solaris printing working

The solution to my HP printer not working on Solaris is to use CUPS. Since I have a full install and solaris now has the packages installed all I had to do was switch the service over:

$ pfexec /usr/sbin/print-service -s cups

then configure the printer using http://localhosts:631 in the same way as I did with ubunto. Now I don't need the virtual machine running which is a bonus. I think cups may be a better fit for me at home since I don't have a nameservice running so the benefits of the lp system are very limited.

The bug is 6826086: printer drivers from package SUNWhpijs are not update with HPLIP

Sunday Feb 08, 2009

New Home printer VirtualBox & Ubuntu to the rescue

I've got a new printer for home, an HP OfficeJet J6410, but the bad news is on Solaris the hpijs server for ghostscript fails and while I have made some progress debugging this it will clearly take some time to get to the root cause. As part of the debugging I ran up a Ubuntu linux in VirtualBox to see if the problem was a generic ghostscript/CUPS problem.

Since Ubuntu had no problem printing for the short term I have given the Ubuntu system a virtual network interface so that I can configure the Sun Ray server to print via the Ubuntu print-server, which if I use the cups-lpd server, will do the formatting for the remote hosts. The remote hosts therefore just have to send PostScript to the print-server and only it needs to be able run the hpijs server.

I'm running the VirtualBox headless and gdm turned off, infact everything except CUPS, xinetd and sshd turned off. I've not written an SMF service to start the VirtualBox yet in the hope that this is infact a very short lived situation as the Solaris print service will be up and running soon. Anyway I now have working printing on Solaris

Now back to what I know about ghostscript and the hpijs service. If you know more (which would not be hard) then let me know.

The problem is that ghostscript called from foomatic-gswrapper fails with a range check error:

: pearson FSS 51 $; truss -faeo /tmp/tr.$$ /usr/lib/lp/bin/foomatic-gswrapper>
truss -faeo /tmp/tr.$$  /usr/lib/lp/bin/foomatic-gswrapper  -D -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ijs -sIjsServer=hpijs -dIjsUseOutputFD -sOutputFile=-
foomatic-gswrapper: gs '-D' '-dBATCH' '-dPARANOIDSAFER' '-dQUIET' '-dNOPAUSE' '-sDEVICE=ijs' '-sIjsServer=hpijs' '-dIjsUseOutputFD' '-sOutputFile=/dev/fd/3' 3>&1 1>&2
unable to set Quality=0, ColorMode=2, MediaType=0, err=4
following will be used Quality=0, ColorMode=2, MediaType=0
unable to set paper size=17, err=4
Unrecoverable error: rangecheck in setscreen
Operand stack:
    -0.0  0  --nostringval--
: pearson FSS 52 $; 

The errors, unable to set Quality and unable to set paper size appear to home from the hpijp server that returns NO_PRINTER_SELECTED (4) if these routines are called prior to the printer context is set up.

Quite how and why the printer context is not getting set up is the question. I've now rebuilt both ghostscript and the hpijs service from source and worked out how to get foomatic to use the new ones and I still have the issue but at least I should now be able to do diagnosis in my own time while the printer is usable by everyone on the local network.

Building ghostscript was simple:

$ ./configure –prefix=/opt/cjgsw

Then make and make install.

Building hpijs was less simple and I am not entirely sure I have it built correctly in fact I stronly suspect it is not built correctly. At least I have my binaries behaving the same way as the Solaris binaries, ie the failure mode is the same. My configure line was:

 $ ./configure LIBS=”-lsocket -lnsl” --prefix=/opt/cjgsw --disable-pp-build --ena
ble-static –disable-shared

All the –enable-static and –disable-shared are required or the linker gets upset during the build I think the next stop would be an update to gcc....


This is the old blog of Chris Gerhard. It has mostly moved to


« April 2014