[moneydance] Moneydance 2007 beta2

[Ronald D Thompson]

Bruce Marshall spoke thusly:<br>
> 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.
> _______________________________________________
>   
Ok, Will try that.
Ron