[moneydance] Moneydance 2007 beta2

Bruce Marshall bmarsh at bmarsh.com
Tue Jan 9 20:45:02 EST 2007


On Tuesday 09 January 2007 20:33, Ronald D Thompson wrote:
> Fuzzy Fox spoke thusly:<br>
>
> > 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?
>
> Made the file
>
> /etc/cups/client.conf, and add this line:
>
>     ServerName /var/run/cups/cups.sock
>

Not sure you are going to get it to work without reverting to a 1.4.xx  
version of Java.    I can't get it to print with the distribution (with MD) 
java.


More information about the moneydance-info mailing list