[moneydance] Moneydance 2007 beta2

[Fuzzy Fox]

Patrick Wagstrom <patrick at wagstrom.net> wrote:
>
> > I tried, At a command line prompt, try "env CUPS_SERVER=localhost
> > moneydance"  but it says "no such file or directory"

> You shouldn't need the "env" command.  Try running:
> 
> "CUPS_SERVER=localhost Moneydance"

I used "env" as my example command because it work in any shell, not
just a sh/bash/zsh shell.  It's better to give an example that works for
everyone, than an example that can give spurious, unrelated errors.

Of course, I failed in that myself, by assuming that Moneydance on Linux
still works by launching the command "moneydance".  You sort of glossed
over that your command launches "Moneydance" instead, where that capital
M might indeed be what makes it work.  Rather than the use of "env",
which should make no difference.


Doug B <md at hatterhill.com> wrote:
>
> Not printers...  You may not have the file.  Note above in what Fuzzy
> Fox posted:  ...you can *create/update* an /etc/cups/client.conf
> file...
> 
> I have one, but it's all comments.  It isn't needed in most cases.  I
> didn't edit the file on my box...  I was just reposting what Fuzzy Fox
> had to say.  All I did was comment out the "Listen
> /var/run/cups/cups.sock" line in my /etc/cups/client.conf and
> restarted cups.

This shows that there is still more to the problem than has been pointed
out so far.  I think I can summarize it like this:


CUPS consists of two parts, a client and a server.  When you talk about
"restarting CUPS" you are restarting the server.  There is no "client"
process that needs to be restarted.  The "client" program is the program
that is trying to print (such as "lpr", or "gimp" or "Moneydance").

The file /etc/cups/client.conf is the client configuration file.  On
some systems it does not exist, and when it does not, that means any
client program that wants to print will use default settings.  The file
is read whenever the program tries to print.  This means that there is
no need to restart anything when changing the file; the changes should
be noticed immediately next time you try to print something.

The file /etc/cups/cupsd.conf is the server configuration file.  If you
change it, you need to restart CUPS in order for your changes to be
noticed, because the file is only read once, when the CUPS server
process starts up.

Now, the problem:  CUPS has two methods for the client to contact the
server:  Via unix domain socket, or via IP socket.  Some clients use one
method by default, and some use the other.  Some servers are able to
accept either method.  Some accept only one method.  So you can declare
a "fix" for the problem by just telling someone to change their client,
or change their server.  You have to look at both in order to really
know what will fix the problem.

IP sockets are less secure than domain sockets.  A domain socket can
only be used by a process running on the same machine.  An IP socket can
be used by anyone on the internet.  So, if your system is configured to
use IP sockets for printing, and you don't have decent firewalling in
place, it could be possible for someone out in China to connect to your
printer and mess with it.  This is considered bad, so many Linux
distributions turn off IP sockets, because it's very rare for people to
want to print over the network.  Usually they are printing to a printer
that is connected to the same machine.  This is a safe default.

What this means is:  1. It's more likely that the default behavior for
the CUPS client is to attempt to print via unix domain socket, and 2.
It's more likely that the server is only listening for domain socket
connections, and has not been told to listen for IP sockets at all.

Now, normally this would work just fine, because whoever packaged the
distribution made sure that the client and server behaviors match up. 
But then along comes Java.  Java has its own way of doing things. 
Different versions of Java do things differently.  It's a mess!  So,
while your entire system might be correctly configured to use domain
sockets for printing, Java might ignore all that, and try to print
directly to an IP socket.  Or it might try to print to a domain socket,
but it's using the wrong path.  These sorts of problems are hard to
debug, because of the variables involved.

However, from reading the results from this list, it would seem that
Java DOES seem to respect the CUPS_SERVER environment variable.  It
might even be reading the /etc/cups/client.conf file.  But, if that file
is missing, or nothing but comments, Java might still be following some
built-in default behavior which is not the same as other printing
programs on the rest of the system.  As such, it seems that Java's
behavior can be influenced, which is good, but influencing Java's
behavior might not be enough!  You might have to change the CUPS
server's behavior as well, so that it will listen for connections in the
manner that Java is going to attempt to use.

Unfortunately, the only Linux system I currently have access to, does
not have a printer, so this is not something I can test and report back
results for.  Would anyone out there be willing to test some options?

I think the best course would be to somehow cajole Java into using the
same print method as the rest of the system, which is likely to be
domain sockets.

On my Ubuntu system, CUPS server ports are configured in the file
/etc/cups/cups.d/ports.conf, which has these lines:

    Listen localhost:631
    Listen /var/run/cups/cups.sock

So, my particular CUPS server is listening on both methods.

However, my system has no /etc/cups/cups.client file, so it is following
some mystery default behavior.  What I'd like to do is to create the
file /etc/cups/client.conf, and add this line:

    ServerName /var/run/cups/cups.sock

This would tell any printing client (hopefully including Java) that it
should use the domain socket to print.  However, without a printer, I
can't really test that.  Does anyone want to try this and see if it
works?

It is rather sad that every Linux distribution probably has a different
default behavior for CUPS, and has configuration files in slightly
different places, and puts the domain sockets in different locations, so
that there is no "One True Way" to solve this problem once and for all,
for all Moneydance users.

But, maybe we can at least build up enough information to fill a Wiki.
Who knows?

-- 
 Fuzzy Fox <fox at foxtaur.com>
  "Why a man would want a wife is a big mystery to some people.
   Why a man would want two wives is a bigamystery."