I am new to tridion and trying to setup a new instance of tridion 2011. I was able to successfully publish all my requests to file system and broker db. Suddenly it stopped publishing and all requests are stuck in "Ready to transport" mode.
I have already gone through many related threads on this forum, but could not sort out the problem. I am using Widows server 2008, with Jre 1.6 (32 bit and 64 bit both installed). Any pointer to finding the issue will be appreciated.
First thing to check is if your transport service is running.
Second thing I would look at is the config files to make sure the transport service is looking in the same directory that the publisher is storing them. Then see if files are being dropped in the transactions folder on the CM machine.
In our environment this issue arose due to a change in the SSL ciphers supported on our Content Deployer server. We are using the SSHFTP transport protocol and for security reasons the RC-4 cipher suite that had been supported by the CD server was no longer supported. We logged a case with SDL support and they issued Hotfix CD_2011.1.2.2350 which adds support for the stronger ciphers.
Unfortunately, the logs gave absolutely no indication of the issue, even with TRACE level logging.
So if you face this issue and you're using SSHFTP and the other solutions don't work for you, maybe this will help.
Related
I am trying to connect to a remote sonarqube 6.2 server from Sonarlint 3.2 plugin in eclipse neon. I am able to connect to my local server http://localhost:9000.
But When I am trying to hit the remote sonar server I am getting below error:
Fail to request https://xxxxxxxxxxxxxx:xxxx/xxx/api/system/status
Please advise.
I ran into this problem myself using SonarLint 3.1 and SonarQube 6.7.
In IntelliJ I kept running into this error message
Failed to connect to the server. Please check the configuration.
Error: Fail to request https://<SONARQUBE>/api/system/status
However I could access that URL through my browser without any issues.
When you WireShark the requests coming from the browser and the IDE you can see that the cypher suite is quite different and that the IDE plugin gets a TLS handshake failure.
That lead me to discover that Java still ships with limited strength cryptographic functions. That’s either because of US export policy or because nobody has gotten around to fixing it. The internet isn’t quite sure.
Either way, you can download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
Once I installed those onto the IntelliJ JVM, I no longer got the underlying TLS handshake failure when trying to connect to SonarQube and the connection works.
since yesterday afternoon at 1.30pm, two separately written applications that access the SagePay payment gateway and the Reporting API Endpoint have both returned the following error:
The server committed a protocol violation. Section=ResponseStatusLine
This occurs in the code at the point of
System.Net.HttpWebRequest.GetResponse()
The payment application hasn't changed since 2009 and was written by an ex-member of staff and is ironically scheduled to be replaced in 3 weeks. The Reporting application was written at the end of last year and has worked since inception until yesterday.
I have spoken to SagePay and they advise that nothing has happened from their perspective and the only thing on my mind was the recent disabling of SSLv3 last month but at the time, the reporting tool was changed to use TLS and I have checked this today and it is indeed using TLS.
Is anyone able to shed any light on what could be causing this please?
Thank you.
OK - I have a fix for this :)
Having spoken to Sagepay, they no longer support Triple DES encryption, only AES. By default Windows 2003 won't use AES - hence the problem.
However, if you install the fix in this article: https://support.microsoft.com/kb/948963 it will enable AES and fix the problem.
BTW, it seems like the link to the hotfix in that article is broken, but this link works: http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe
It does require a reboot, and you will need to disable all protocols apart from TLS1.0 in order for this to work.
We have the same problem. One suggestion is to add the following to the web.config:
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
This at least avoids the protocol violation, but leads to the following error for me instead:
The underlying connection was closed: The connection was closed unexpectedly.
One other point which I would be interested in your comment on, is that we can only reproduce this error on Windows 2003 servers. On Windows 2008 it works OK. I have also reproduced this on my Windows 7 dev machine by forcing it to connect via SSL3.
I have disabled SSL3 in Schannel for both client and server applications, but I am wondering if it is continuing to connect via SSL3 for some reason, rather than using TLS. Any thoughts?
I have just spoken to someone at SagePay about this who says that this is an issue with the connection using SSLv3. We thought we had disabled this in November last year, but he said that when using Windows Server 2003, he’s heard that sometimes it looks like the SSLv3 is being disabled but that when it gets to the last step it doesn’t do it for some reason.
I'm looking into this now with our server hosts, but this could be something for you to look at too.
I am forced to use a visual-svn-server that is located in our windows domain. The problem is that it is super slow to use with windows client. Weird thing is that the same repository is very fast with linux client. The difference is like 3sec vs 90sec. I know somebody should fix the server, rather than me trying to fix the client, but i have no change of doing that.
So, to debug the problem I did some package capture with wireshark and it seems like windows, when doing 'svn up' (on up to date repository) does quite much ldap-negotiations before actually talking again with the actual svn-server. This takes time. Linux svn client when doing 'svn up' is not doing any ldap calls. The problem is not on my machine, but on all my colleagues windows clients too.
I tried forcing the svn client to 'basic' auth with configuration option http-auth-types (http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html), but it didnt help. I figured that would be basic, no ldap, http-basic-auth. I am able to confirm that the setting is included, since setting it to 'digest' says that authentication method is not available. But even that takes about 60s, so my guess is that its doing the ldap-wacko stuff before trying to do the authentication.
The subversion client i am using is 1.8 serie from tortoise svn official build. I did try also slicksvn client and it did have the same problem. The svn versions shows ra_serf is handling the https requests and my repository is visual-svn server located at https://my_server_intra_dns_name/
When opening the address with browser, its again fast as it should, so problem should not be with dns or similar.
I am linux guy, so i am bit lost with windows, but does anybody have an idea wtf is going on here?
---- edit ----
I had also linux as guest operating system on the windows host, and inside that linux doing svn up was about 3s, compare that to native windows 'svn.exe up' that took over minute !
If a Windows machine has a limited connectivity to the Internet, then you may notice the delay when running Subversion client command's against a remote repository over HTTPS.
Using a traffic analyzer you can notice, that the delay happens when Windows attempts to access ctldl.windowsupdate.com and gets a timeout. Windows attempts to access ctldl.windowsupdate.com to check Certificate Trust List (i.e. Certificate Revocation List). With limited Internet connectivity, Windows may be unable to access it thus resulting in these delays.
If it's not your case, then I suggest contacting VisualSVN's support team for investigation.
In my case it was due ot Windows proxy settings - that you set in IE (I use TortoiseSVN client, and Visual SVN Server was set to use basic authentication).
After I've set up IE proxy settings accordinlgy (automatic for me, but for you it might be something different) initial delay was gone.
It helped even though the svn server is on local LAN and I have checked with Wireshark if the traffic goes over proxy. In Tortoise I have proxy disabled. Why it helped with my issue - no idea.
The initial delay I had was 11-13 seconds. Now next to none.
And I am not using ssh client.
Go to http(s) location of your SVN server using your browsers: IE, Fireofx, whatever, and if the response is quick then it is very possible that is an svn client problem, or due to some similar settings (similar to your browser settings).
For instance IE was slow (IE was set up for local connection only previously), Firefox (with proper proxy settings) was OK - and SVN server IS local (sounds like some sort of network/firewall/routing issue to me, but proxy settings helped me).
I am writing a webdav server for embedded system. Everything goes normal until I tested it with windows client, the miniredir.
It became extremely slow when accessing the data with miniredir. I captured the network traffic and found that everytime I made a move, the miniredir tried to connect to the server via SMB first. (SYN package sent to 137,138,139,445) and the expolrer view would not show until the SMB request failed a few times, which takes more than 20s.
I also tried miniredir with Apache+mod_dav, same delay was observed (make sure the server machine disabled SMB service).
Is there anyone solved this problem? or if there's any work around solution for XP?
BTW: After a few days' debugging, now I believe MS Miniredir is not a qualified WebDAV client. A lot of bugs and shorting comings were reported, but MS didn't do much improvement. http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html
Significant delays can be encountered when accessing WebDAV resources if Internet Explorer is configured to auto-detect proxy servers. Try following these instructions for disabling proxy auto-detection and see if that helps.
After a few days' debugging, now I believe MS Miniredir is not a qualified WebDAV client.
I think this is an overstatement. The only documented issue in XP/SP3 is a by-default lack of support for basic auth, and there is a workaround for this. "When you hear hoofbeats, look for horses, not zebras."
I am at my wits' end on this one.
FYI, I work in infrastructure, not .net development, so I know very little about WCF and next to nothing about Visual Studio as an environment, but I don't think that's where the problem lies.
We have a WCF service running on a couple of IIS 7.5 servers on our internal network. This is exposed to the outside world via reverse proxy on Apache 2.2.15 on Fedora 11. The reverse proxy handles load balancing between the IIS servers, as well as SSL.
The WCF service is configured to use transport level security, and the IIS servers have self-signed SSL certificates. The reverse proxy does not authenticate the IIS servers, and the only reason we have SSL on the IIS servers in the first place is so the WSDL will present the correct location URL.
We thought we had it working perfectly, but there's one annoying and crucial exception: the WSDL can't be added as a service reference in Visual Studio on machines running Windows Vista or later. On an XP machine, it's fine, but anything later throws the following error:
There was an error downloading
'[URL]'. The operation has timed out
Metadata contains a reference that
cannot be resolved: '[URL]'. An error
occurred while making the HTTP request
to [URL]. This could be due to the
fact that the server certificate is
not configured properly with HTTP.SYS
in the HTTPS case. This could also be
caused by a mismatch of the security
binding between the client and the
server. The underlying connection was
closed: An unexpected error occurred
on a send. Received an unexpected EOF
or 0 bytes from the transport stream.
If the service is defined in the
current solution, try building the
solution and adding the service
reference again.
The WSDL is accessible through a browser, or through regular SOAP, on any machine and without any SSL complaints. It's just Visual Studio that has an issue.
Initial Googling revealed that it might be a problem with the cipher suite that VS used, suggesting that VS on Vista or later would by default attempt to use TLS1.0 in HTTPS connections, and if an intermediary device didn't support that protocol, it would just drop the request. This is definitely not the case, though. The reverse proxy explicitly prefers TLS1.0, and even when viewing the WSDL through a browser, it flags up as using TLS1.0 for the connection.
Having pointed the proxy at other functioning WCF services on different IIS servers, the same error occurs, leading me to assume it revolves around the reverse proxy configuration. The trouble is that it seems to be identically configured to another reverse proxy carrying out the same task elsewhere.
It's presumably some transport level issue around how VS establishes HTTPS connections on different operating systems, but I simply don't know enough about it to hazard a guess about what that might be. Anyone have any suggestions?
Well, that was embarrassing.
I'm sure there's some unwritten cosmic law that results in me finding the incredibly simple solution to a problem I've been grinding away at for days about ten minutes after posting it up on StackOverflow.
The ServerName directive in the virtual host config didn't match the URL. It did match the certificate (which has a Subject Alternative Name, so it didn't throw up any SSL warnings), but that wasn't the name I was accessing it with.
I'm assuming there's some extension of TLS1.0 that VS uses which enforces this, which isn't used by browsers or SOAP clients. This is probably useful information for anyone else trying this with a certificate that has Subject Alternative Names. It wouldn't have come up otherwise.