Re: [mv] Cybercash 3.2.0.6

["Webmaster" <webmaster@infothai.com>]

******    message to minivend-users from "Webmaster" <webmaster@infothai.com>     ******

I tried disabling the close of STDIN,STDOUT, and STDERR in Server.pm, 
but that did not solve the problem either. So, it would seem that there 
is some other resource that the child processes CCEncrypt and CCDecrypt 
want before they can run.

I've asked CyberCash support about this, but no reply has been made as yet.

Mike

On Sun, 04 Jun 2000 17:26:46 +0700, Webmaster wrote:

>******    message to minivend-users from "Webmaster" <webmaster@infothai.com>     ******
>
>No joy so far. Minivend wouldn't start, as follows:
>
>CyberCash module found (CyberCash 3).
>Unknown directive 'DebugFile'
>In line 61 of the configuration file 'minivend.cfg':
>DebugFile  /dev/null
>
>Can this be set in the Minivend source?
>
>Mike
>
>On Sat, 3 Jun 2000 23:27:39 -0400, Mike Heins wrote:
>
>>******    message to minivend-users from Mike Heins <mikeh@minivend.com>     ******
>>
>>Quoting Webmaster (webmaster@infothai.com):
>>> ******    message to minivend-users from "Webmaster" <webmaster@infothai.com>     ******
>>> 
>>> Hi,
>>> 
>>> I have encountered the Cybercash failure that was noted before in this list, 
>>> in which the latest Cybercash (v.3.2.0.6) will not encrypt when running with 
>>> Minivend 3.14-5.
>>> 
>>> Cybercash 3.2.0.6 introduced the use of the "open2' IPC call to communicate 
>>> with the encryption and decryption programs, which are invoked as separate 
>>> processes. It is clear from the earlier posts that the open2 versus temp files 
>>> change is the source of the problem, since on author reported that "degrading"
>>> to 3.2.0.4 solved the problem.
>>> 
>>> By instrumenting the Cybercash perl code, I found that the reported error 
>>> ("missing MAC") is exactly correct - there was null data returned from the 
>>> encryption process. I also found that if Minivend is started in -DEBUG mode, 
>>> then the everything works. The Cybercash integration tests also work.
>>> 
>>> Putting it all together, this means that the problem would seem to lie with 
>>> Minivend operating in the background and trying to use open2. Perhaps there is 
>>> a permission or resource difference between background and foreground/DEBUG 
>>> that is the problem?
>>> 
>>
>>The problem is that open2 apparently relies on STDERR the actual named
>>handle, without duping and re-creating as necessary if it doesn't exist.
>>
>>Minivend closes STDIN, STDOUT, and STDERR as any reasonable daemon process
>>should. It puts STDERR to a non-existent file handle if debug output is not
>>wanted. My understanding is that this is not a technical error, but I am certainly
>>willing to be corrected if more knowledge is brought to bear.
>>
>>They are not closed when in -DEBUG, so that would appear to
>>be the problem. 
>>
>>Try setting in minivend.cfg:
>>
>>	DebugFile  /dev/null
>>
>>and see if that solves it.
>>
>>-- 
>>Internet Robotics, 131 Willow Lane, Floor 2, Oxford, OH  45056
>>phone +1.513.523.7621 fax 7501 <mikeh@minivend.com>
>>
>>Light travels faster than sound. This is why some people appear bright
>>until you hear them speak. -- unknown
>>-
>>To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
>>email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
>>Archive of past messages: http://www.minivend.com/minivend/minivend-list
>>
>
>
>webmaster@infothai.com
>http://www.infothai.com
>
>
>-
>To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
>email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
>Archive of past messages: http://www.minivend.com/minivend/minivend-list
>


webmaster@infothai.com
http://www.infothai.com


-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list