[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