Hello i have a bit of a problem using websockify.
I made executable for windows, then i start my websockify in cmd:
c:\web\websockify.exe 192.168.1.70:5901 192.168.1.70:5900
WARNING: no 'resource' module, daemonizing is slower or disabled
WebSocket server settings:
Listen on 192.168.1.70:5901
Flash security policy server
No SSL/TLS support (no cert file)
proxying from 192.168.1.70:5901 to 192.168.1.70:5900
so far all good. In the background VNC server is running on the same
computer at port 5900. The thing is i need to use websockify to be
able to use novnc on the other computer in local network.
I have latest novnc installed on latest XAMPP server (apache 2.2).
When i start vnc.html it asks for server, port, password. I typed
them in and press connect. I get an error on the websockify side:
WARNING: no 'resource' module, daemonizing is slower or disabled
Usage:
websockify.exe [options] [source_addr:]source_port target_addr:target_port
websockify.exe [options] [source_addr:]source_port -- WRAP_COMMAND_LINE
websockify.exe: error: no such option: --multiprocessing-fork
I can't connect using noVNC. I searched for internet to find solution
but did not find it.
Can someone help me get this apps together runnig?
or is there some more windows friendly solution with some other app that
does what websockify does?
br
Did you follow this guide? https://github.com/kanaka/websockify/wiki/Compiling-Websockify-as-Windows-Executable
Websockify uses the python multiprocessing module. This module is problematic on Windows, especially with older versions of python. You might try python 3.2 or greater and see if you have more success although no guarantees. Websockify is developed and tested on Linux only.
There used to be a pre-built version of Websockify for Windows that at least worked without multiprocessing (one client at a time), however, github dropped support for downloads so this build is no longer available.
Disclaimer: I made websockify.
Related
Correct me if I am wrong, a server side library runs on a server, and a client side library runs on the user's computer.
However, how do I know if a library runs on server or client? Is there a rule of thumb?
For example, why are node.js libraries server side libraries if you install it on your local machine and run it on your local machine?
If the library is executed somewhere locally but outside of a browser, is it still considered a client side library?
I would recommend you read these two articles. They should give you some clarity on Node.js functionality and server and client side scripting.
Server VS Client
https://skillcrush.com/2012/07/30/client-side-vs-server-side/
Intro to Node.js
https://www.google.com/amp/s/opensourceforu.com/2016/01/an-introduction-to-node-js-the-server-side-javascript/amp/
I have a C++ Windows application, developed using Visual studio 2017 on windows 10 system. This application uses cpprestsdk to post request to REST Server. My application works perfectly fine on windows 10 machine with properly posting request over ssl to rest server. I did not create any local certificate to make my application work on windows 10.
However same application when ported on windows 7 (64 bit), is not able to POST request with SSL protocol to rest server.
Same request works without SSL, (http://HOST/API works)
but (https://host/api fails)
by giving following error.
winhttpsendrequest 12029 a connection with the server could not be established.
From same windows 7, PostMan can successfully post https request.
No clue of what could be wrong with the implementation.
Can any one share what could be the reason of failing the POST request on windows 7?
I'm a bit late with the answer but I hope that it might help others who face the same problem ...
I think that your server insists on using tls version higher than 1.0 which is a default on Windows 7. Unfortunately cpprestsdk cannot be configured to use a specific tls version. On Windows cpprestsdk uses WinHTTP which exposes two handles but only one of them can be used to configure tls (I do not remember handle names at the moment). Unfortunately the native handle that cpprestsdk has access to cannot be used to configure tls.
The only workaround is to configure Windows 7 (and indirectly WinHTTP) to use a specific tls version as default. Instructions on how to do that can be found here: https://support.microsoft.com/en-ca/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi.
After successfully running subversion for years on a Windows 2008 server, I recently moved to Windows 8.1, mainly because the machine does also serve videos to my home network (works fine) and because Windows 8 provides better energy saving on my platform than Windows 2008 server did. So far, so good.
Then I tried to re-install Subversion. I intend to use the built-in server application svnserve.exe. I downloaded the latest windows package, installed it (success), and configured a service (svnserve --service ...) which I can successfully start using the Windows Service Management Console. Port 80 is already taken by a different application, so I let subversion pick 3690, which is fine for me. I used netstat to confirm that svnserve.exe is bound to port TCP:3690, which is listed OK. Just to clear one potential roadblock I also disabled the Windows firewall.
Then I created a sample repository named "test" using svnadmin locally, success as well, a subversion file structure appeared on the harddisk.
Problems arise when I try to access the repository using my local browser (Firefox), an attempt to connect to URLs
http://127.0.0.1:3690[/svn|/svn/test]
all three give me the same cryptical response:
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )
Somehow I have expected a subversion GUI instead.
Connecting from a remote machine via browser reveals the same useless line of text.
Connecting from a remote machine using my usual Tortoise client gives the message:
Unable to connect to a repository at URL 'http://xxx.xxx.xxx.xxx:3690/svn/test
Error running context: The server unexpectedly closed the connection
I tried to add the --log-file option to svnserve, and indeed a log file appears once I start the service, but it is empty and it remains empty.
Trying to use svnserve -X instead of running it as a service reveals the exact same behavior.
Seems I am stuck. Anyone who has an idea what I can do to get that thing working?
Just to help out another beginner running into the same problem ... I finally found the problem: I simply used the wrong client, svnserve does not support web browsers. Using the Tortoise client, and providing the correct prefix (svn:127.0.0.1/...) was all I had to do.
The long version:
If one wants to work with the simple, reliable, fast, but plain-text and proprietary protocol based) svnserve service, he needs to use a proprietary client, like Tortoise, and the svn: prefix instead of http/https:, and no port, like
svn://mysvnserver/testrepo
If needed, one may even reconfigure svnservice to use authentication and encryption later. svnserve isn't supporting web browsers, if one tries to access svnserve using a web browser like I did he gehts the internals of the svn protocol dumped to the screen.
If one wants to use his web browser, http/https protocol, and niceties, like a user friendly browser based interface and some remote administration capabilities, he must not use svnserve, but install a web server service (like apache) and configure if for use with subversion.
So in the end my problem had nothing to do with Windows 8. It just has slipped from my mind that years ago I went the apache path, while now I decided that the built-in svnserve service was good enough for my needs.
Armin.
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'm using the AJAX Test Server in Rational Application Developer. I'm posting a form to another host for authentication. That host takes a URL to redirect to after authentication. However, it insists on using HTTPS whenever it sends the 302 response. The low hanging fruit would be to just use HTTPS locally.
Looking at the launch configuration, the AJAX Test Server appears to be a custom Apache HttpCore server. I haven't spotted anything in the configuration guide.
Is there a way to access this test server via HTTPS?
This is for demo and local development purposes; not production.
Speaking from working with WAS (WebSphere Application Server) in RAD, I'm pretty sure the answer would be yes. The server (at least with WAS) has both secure and "unsecure" ports.
What I have noticed is that when the server is built with the install (at least with the newer versions of the products 7.5+), the ports used are different per install. This is to help with not conflicting with other applications that may use those ports.
So https is probably fine. You just may have to use it over port 302 or some other port.
If there is no admin console for viewing your ports, you could always try the Window | Preferences option under your menu items. Sometimes IBM hides server config stuff in there.