NetTalk Central
NetTalk Web Server => Web Server - Ask For Help => Topic started by: jking on March 11, 2012, 07:39:55 PM
-
Bruce,
I have compiled the multi-site host app and the site1 app. I have two issues.
1. When I first log in I see the screen in clip1.png. It seems there are missing icons on the site buttons at the top.
2. Also, I find I cannot open the site1 home page or the site2 static pages. Site1 is on port 8003 and site2 is on port 8080. Both these ports are open on the firewall. See servers.png for a screen shot of the servers list.
I have your Developing Web Applications book, and the chapter dealing with the multi-site host details a full pathname variable set up in the dictionary. When looking at the dictionary for the example app, I don't see the use of a global variable. Instead, I see the use of webservers{prop:name} in the process link embed of the WebHandler. Are both these techniques valid or should I be using one or the other?
I have checked the prototypes of the WebServer and WebHandler procedures and they both have the name attribute entered. Dynamic DLL support is also checked. I'm using C8.8778 ABC and NT 6.25. Any thoughts why I can't get to the two sites?
Thanks,
Jeff
[attachment deleted by admin]
-
<< 1. When I first log in I see the screen in clip1.png. It seems there are missing icons on the site buttons at the top.
indeed - it's looking for the favicons of those two sites, and they don't exist (at least not in the example.)
>> Also, I find I cannot open the site1 home page or the site2 static pages. Site1 is on port 8003 and site2 is on port 8080. Both these ports are open on the firewall. See servers.png for a screen shot of the servers list.
the whole point of the Multi-Site host is that they allow your dll's to share a _ip and port_ address - using the hostname alone as the differentiator. If the sites were indeed on different ports, they would have no need of the host. So, in your case, _all_ the sites are on the same port as the host. (in this case :88).
>> I have your Developing Web Applications book, and the chapter dealing with the multi-site host details a full pathname variable set up in the dictionary. When looking at the dictionary for the example app, I don't see the use of a global variable. Instead, I see the use of webservers{prop:name} in the process link embed of the WebHandler. Are both these techniques valid or should I be using one or the other?
both approaches, and indeed any other approach for setting the name, are valid. I prefer setting the name explicitly in the ProcessLink method - which is, as I recall, what the example does. Note that p_web.site.apppath in this context contains the path to the _dll_ not the host exe, which can be useful.
cheers
Bruce
-
Bruce,
I'm still confused. If site1 is on 127.0.0.1:88 and site 2 is on localhost:88, how would I open the server management web site, which is also on 127.0.0.1:88?
Thanks,
Jeff
-
by using an address, that points to the same machine, but is neither of those.
for example, my machine is 192.168.2.11 so if I was running on my machine I'd do it with
http://192.168.2.11:88
The example is somewhat contrived because I don't have a bunch of dns settings set up as one would in the real world. So, if I installed this on my server I'd have www.capesoft.com:88 and www.faswin.com:88 and so on.
cheers
Bruce
-
Bruce,
Ah! Now I see. I have it working now, all except the static pages from site2. Not a big deal so I'm going to move this to our main server and test two live dll apps. Thanks for all your help.
Jeff
-
Bruce,
I'm still testing on my development machine, trying to run the host app on port 443. Can the multi-site host run on port 443? I ask because I get the error shown in clip3.png. The settings tab is set as seen in clip1.png and the general tab of the NT object is seen in clip2.png.
I presume that the host app must be on port 443 as do all the other apps I wish to run over 443.
I checked my firewall and both inbound and outbound rulles allow 443.
I created my own self-signed wildcard certificate by using *.breasthealthcrisp.org. Perhaps this is the issue and I need to move this to the server for that domain. What do you think?
Thanks,
Jeff
[attachment deleted by admin]
-
not sure it will work locally without certificates.
-
I think the 3rd pic is the most instructive.
it's saying it did connect, but the browse has opted not to display the page, presumably because it's a self-signed certificate.
try another browser, or add your site to the right IE zone or something.
cheers
Bruce
-
Bruce,
Something does not seem right. I have the host.exe out on my server. I load the host and it defaults to port 88. From the browser on the server I can get to the website manager using
http://192.168.24.160:88.
Next, I change the Listen on Port to 8888, click save, and try http://192.168.24.160:8888. It does not work. However, http://192.168.24.160:88 continues to work even though I have set the Listen to Port to 8888. Is this expected behavior? It would seem the Listen on Port is not being set to the new port. The settings.xml file does show the newly set port at 8888.
Thanks,
Jeff
-
when changing the port you need to restart the server. I haven't added the code to the host yet to do that "on the fly".
cheers
Bruce
-
Bruce,
That does not seem to work either. Always defaults to 88.
Thanks,
Jeff
-
did you click the "save" button on that tab after changing the setting?
cheers
Bruce
-
Bruce,
Yes, I did click the save button. As I mentioned earlier, the settings.XML file does contain the new port, but when I re- start the Server, it defaults back to 88.
Jeff
-
Bruce,
In the Weserver procedure, Init embed, code is setting the sg:ListenOnPort variable to 88. I changed this to my port and now I'm making some progress. I presume things such as this should be coming from the settings.xml tag but it does not appear this is working yet. I'll code for this and see howw far I get.
Thanks,
Jeff
-
Bruce,
I have had limited success with the host and site1. However, I cannot get one of my actual sites to work. It always sets to Inactive. If I uncheck inactive in the server manager, the actual host.exe app on the server seems to reset and then hangs.
I have attached an image of the sever manager screen, see servers.png. The host and my app have been compiled with C8.8778 and NT 6.25. I set the name explicitly in the process link method.
I have the clarion dll's in the host folder as well as the certificate folder. I do not have clarion dll's or a certificate folder in the dll app folder...is this necessary anyway? In addition my dll app folder is not directly under the host folder. I beleive this is allowable as well...is this right?
Any other things I should look at? I'm at a loss here.
Thanks,
Jeff
[attachment deleted by admin]
-
Bruce,
More info, the error tab on the host app shows "DLL Caused GPF- automatically made inactive". This app runs fine as an exe. What could be the problem with this dll?
Thanks,
Jeff
-
Bruce,
Another question...in the instructions for compiling my app as a dll, you mention adding (string p-String) to the parameters list of the WebHandler procedure. There is no parameters entry field on the properties screen, like there is on the Webserver procedure. In looking at the code, the parameter list contains (String, p_ReqString) and this cannot be changed. Is this an important detail?
Thanks,
Jeff
-
>> What could be the problem with this dll?
One of the tabs on the Host window covers the most likely reasons for a GPF in the DLL. 3 things as I recall.
As long as the Prototype of the WebHandler procedure is
(String p_String),Name('WebHandler')
you're ok onn that front.
cheers
Bruce
-
Bruce,
The three items are:
1. Webserver prototype has name attribute...mine does.
2. WebHandler prototype has name attribute...mine does
3. NetWeb version of DLL and host app do not match...I presume this means botht he host and dll must use the same version of NetTalk. Mine does.
So I'm at a loss as to what to do next.
Thanks,
Jeff
-
Bruce,
I found the problem with my first app. I had not placed the app folder directly under the host folder. Now that I moved it, the host app recognizes my app dll and it runs fine using SSL on a non-standard port with my wildcard certificate.
So with a bit of confidence, I tried a second NT app that has secwin installed. I'm not having much luck with this app. I think the problem lies with the secwin files: SecWinOperators, SecWinOperatorsUserGroups and dssw5. When I set the name attribute for these three files in the ProcessLink embed I get errors about unknown identifier...please see attached image. Anything you can suggest here?
Thanks,
Jeff
[attachment deleted by admin]
-
unknown identifier.
Means that the compiler doesn't know the name.
Which means the table is not being included in your app.
Have you go the secwin extension added to this app? If you look in the app.clw file do you see the table declaration with that name?
specifically you're looking for the name
Secwin_OperatorsUserGroups
Maybe you misspelled it?
cheers
Bruce
-
Bruce,
I re-imported the secwin tables to my dictionary and re-imported the secwin procedures in my app. Now the errors are gone. However, I cannot include the dssw5.tps security file in the process link embed, since it is not defined in the dictionary. Is this necessary and thus the cause of my problem?
The host still deactivates this app. I have attached a zip file containing the app and dct. If you have some time could you take a look? I don't know what else to do.
Thanks,
Jeff
[attachment deleted by admin]
-
I'll take a look Jeff.
How many of your DLL's are going to be using Secwin? I'm not sure to what degree the Secwin stuff is "safe" across multiple DLL's running under multi-host. That's something that might take some considering.
cheers
Bruce
-
Bruce,
Thanks for taking the time to look at this. As for other dll's using secwin, ideally I would like to be able to create many NT apps using secwin. Currently I have two without secwin and two with secwin. These NT apps will handle multiple research projects with patient data so security and access levels is important. Secwin makes it easy to add what I need.
The key issue now is that at our satellite office, we have servers that will host these apps, but we have limited IP addresses. So using the wildcard certificate and multi-host will be a big help. Hopefully the multi-host will enable me to manage a mixture of secwin and non-secwin apps. Please let me know if this becomes a big project as we can help offset some of the cost if needed.
Thanks,
Jeff
-
Bruce,
Just a follow up....have you had a chance to look at the app I attached in the last post? It still gets deactivated by the host.
I did have success with another very similar app that has secwin installed. The only difference is this new app uses the in memory secwin files whereas the problem app uses all tps files. I converted the problem app to use the in memory secwin files but this did not help. Still searching for a solution.
Thanks,
Jeff
-
Hi Jeff,
the solution does not appear to be trivial. we're looking into it, but I'm out the office all of next week, so it'll likely be some time before we get there.
Incidentally, since you're running your apps on a non-standard port anyway, why are you needing to run under the multi-host? why not just run each on a different port?
cheers
Bruce
-
Bruce,
" likely be some time before we get there..."
thanks, I'll try to be patient!<G>.
"why not just run each on a different port..."
I do currently run my 4 NT apps on different ports now. However, two of our research collegues are at institutions that require the use of port 443 and do not allow any use of non-standard ports. So assuming I can get the multi-host app to run my NT/SecWin dll apps, I will move all of them to port 443 so we don't have any similar issues in the future.
Thanks,
Jeff