dist

Hi, I get the error without any warnings when running "cm lrep". Running "replicate" on the command line produces the very same error. ... and the GUI client did show the error in all cases where I expected it to show it ... Best, Dirk

Hi, I am certain that we are using the "correct" hostname on command line and within the client. On both machines no customization of the Plastic Setup whatsoever was done. Still, the sync view does not work. Also, in case of a hostname mismatch the client would spawn warning dialogs. This does not happen. We are running: 5.0.44.608 - Segovia Best, Dirk

Hello everybody, I am still stuck on this topic and would be happy about some attention. The problem: - do a plain install of plastic client and server on two windows machines - run plastic server on both machines in UPWorkingMode - create identical plastic user on both machines - punch the necessary holes into the firewalls of both machines - create a repository on both machines - in order to install the default ssl certificates on both machines into the user cert store run: > cm lrep ssl://<self>:8088 > cm lrep ssl://<other>:8088 - set up a sync view using ssl communication between both machines I end up with: Error: The authentication or decryption has failed. Anybody out there that can vote on? 1) works for me 2) I have the same problem Any voter gets a big mental hug All the best, Dirk

Hi, <side note: I will move posting #11 because it seems unrelated to this thread> both channels enabled on all machines yes. I checked the files on each machine and also run a "> cm lrep ssl://xxxx:8088" successfully when logged into the machine. Best, Dirk The client/remoting.conf looks like this in all cases: <configuration> <system.runtime.remoting> <application> <channels> <channel type="Codice.Channels.PlasticTcpChannel, plastictcpchannel" name="normal"> <clientProviders> <provider type="Codice.Channels.ClientSinkProvider, plastictcpchannel" /> <formatter ref="binary" /> </clientProviders> </channel> <channel type="Codice.Channels.PlasticSecuredTcpChannel, plastictcpchannel" > <clientProviders> <provider type="Codice.Channels.ClientSinkProvider, plastictcpchannel" /> <formatter ref="binary" /> </clientProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration>

<moved by author because it causes confusion>

Hello, thank you for the information. I followed the path described in the document but: I used openssl to generate the PKCS#12 pfx-file I did not install certificates manually but triggered Plastic into doing the installation via "> cm lrep ..." Then I ended up with the error stated above. As far as I can tell from the remoting.conf coming with Plastic5 the PKCS#12 pfx is the way to go. Right? Best, Dirk

Hi Carlos, thanks for the helpful reply. I logged into all the machines as the proper user and did a > cm lrep ... to trigger installation of the certificate. Then verified certificate installation using certmgr.msc. The error persists. Any ideas? Best, Dirk

Let machines run on Windows in UPWorking mode using the default certificate shipped with Plastic as well as shipped 'remoting.conf'. Use identical users and groups on both machines. Open port 8087 and 8088 on both machines via inbound rule. serverAact as remote on LAN repository 'repA' serverBlocal machine on LAN repository 'repB' Then I observe the following on the command line: > cm replicate /main@repA@ssl://serverA:8088 rebB@ssl://serverB:8088 Error: The authentication or decryption has failed.: serverA:8088 > cm replicate /main@repA@ssl://serverA:8088 rebB@serverB:8087 Error: The authentication or decryption has failed.: serverA:8088 > cm replicate /main@repA@serverA:8087 rebB@serverB:ssl://8088 ...here we go... > cm replicate /main@repA@serverA:8087 rebB@serverB:8087 ...here we go... This is, things work unless I talk to the remote on the SSL channel. I am new to Plastic. Anybody here that can help me making sense of this observation? Best, Dirk

Hi everybody, I run into just the problem gusdpr encountered. Any news on this? Anybody with an idea where we go wrong? Best, Dirk