|
Hi Pawel,
On Nov 17, 2014, at 8:19 AM, Paweł Gesek <> wrote:
Aaron,
I've noticed that with the new web10g userlands the RPM will fail to build, since genplot10g is not mentioned in the spec file. I am assuming this means that the rpms being built for distribution will not contain the web10g binaries, since it passed on the
build system.
Correct, there is no dependency for the RPM on web10g-userland.
I am wondering whether this is ok for now, or should we include the web10g stuff in the RPM distribution. I think that both web100 and web10g binaries can be packaged together and the version used by the daemon can be controlled
by a configuration variable. Another option is to create a separate ndt-server-web10g RPM for web10g, since the web10g binaries do require the latest userlands as a dependency. What is your opinion on this?
Since no one is distributing RPMs for the web10g userland (AFAIK), I’d prefer to leave well enough alone for -rc1. If we did support it, i’d prefer splitting RPMs similar to how you noted, though, so that folks without web10g-userland RPMs could install just
the web100-dependent package, and vice versa. I’m not sure how the init script situation would work though.
Cheers,
Aaron
Regards,
Paweł
On 11/14/2014 08:53 PM, Aaron Brown wrote:
Hey Sebastian,
I think with my commit to the Issue162 branch, the RPM is now in reasonably good shape. One bit of oddity, and it’d be good if someone else could try building the RPM and testing. When we installed it here, the java applet would seem to switch randomly
between “working” and “failing”, and it wasn’t clear why it would do it. We’ve had two different folks see this same issue.
Cheers,
Aaron
On Nov 14, 2014, at 10:20 AM, Sebastian Kostuch <> wrote:
Hi Aaron,
I have made some changes to this page. Now buttons are moved on top of the site, also I have added proper info message there and when plugin is not loaded properly and user clicks start button then error message will be shown and test would not be started.
Also I have made plugin show only as a small bar. Please let me know if new version of this page looks ok for you :)
Regards
Sebastian
On 14.11.2014 13:44, Aaron Brown wrote:
Hey Sebastian,
The problem comes in with flash blockers, which are pretty common, especially among network engineers. I’ve attached a screenshot of what I see when I go to the page, and click “Use Flash”. It’s completely unclear to me that I need to hit anything other
than “Start Test”. However, if I click “Start Test”, it will bomb out in a bizarre fashion, because I haven’t clicked on the flash applet below the buttons to get around the flash blocker, and since I can’t scroll the page at all, I can’t even see that there
is something for me to click. I just have to blindly click in that box that’s below the blue page, and I’m given no guidance to do that. Beyond that, it’s rather jarring to have both appear in that page. If we could shrink the applet down so that it’s a very
small bar, and specifically note the “flash block” issue in the text somewhere (especially if they click “Start Test”, and it bombs out), that’d be vastly more intuitive.
If you want to try to see the issue for yourself, install a flash blocker in Chrome or FF, and then navigate to
http://desk179.internet2.edu:7123/ and select “Use Flash”.
Cheers,
Aaron
<Mail Attachment.png>
On Nov 14, 2014, at 6:23 AM, Sebastian Kostuch <> wrote:
Hi Aaron,
I'm not sure I understand you correctly. The purpose of this site is to provide the user JS UI and the ability to choose which client (java or flash) should be used as backend right? But this client itself is not supposed to be used directly here as the GUI
written in HTML + JS does the whole work. If we want to provide user these clients direct then we have separated pages for it (tcpbw100 and tcpbw100-java). So what about hiding these controls on the widget.html site so that only JS UI will be visible? Or am
I missing something and it should work different way?
Also for ensuring: by writing that it worked you mean JS UI or running flash client located on the bottom of the site?
Kind regards
Sebastian
On 13.11.2014 15:43, Aaron Brown wrote:
Hey Sebastian,
Ah ok. I’ve got Flash Block on the browsers so the applet did load, but because of how the page loads, wasn’t visible so I didn’t realize I needed to click on it first. Once I clicked on that, it worked. Given the prevelance of flash blockers, and the
odd nature of this HTML5 + Flash combo, is there a better way that we can better locate the actual Applet on the page itself so that, and put some text in, letting folks know they may need to click on the hidden flash applet first?
Cheers,
Aaron
On Nov 13, 2014, at 9:36 AM, Sebastian Kostuch <> wrote:
Hi Aaron,
as Pawel mentioned there is currently problem with calling applet functions from JS as from
java 7u45 update there are more security restrictions to applets. You can read more about it
here.
Basically now it is necessary to add Caller-Allowable-Codebase line to manifest file (which I have already commited) and jar file must be signed by a trusted CA.
When it comes to issues you have mentioned, is there also problem with calling start directly from applet or flash embedded on the same site where JS UI is? Are there any errors?
Kind regards
Sebastian
On 13.11.2014 15:20, Aaron Brown wrote:
Hey Pawel,
On Nov 13, 2014, at 9:11 AM, Paweł Gesek <> wrote:
Aaron,
I've taken a look and talked with Sebastian about this. The new page uses the applet by default if your browser supports java, however there is some sort of problem with the _javascript_-applet communication, making the gauges do nothing if you are using the
applet. Have you tried pressing the flash button below in order to switch the client to flash?
It doesn’t matter what I use, both bomb out, and don’t (as far as i can tell anyway) perform any tests.
One question regarding your changes, any reason to change nobase_ndt_DATA to ndt_DATA in HTML5-frontend/Makefile.am? Without the nobase modifier HTML5-frontend/images and HTML5-frontend/fonts get installed in /usr/ndt without the
fonts or images subdirectory, which leads to missing resources on the webpage.
The install had failed as is, and as part of my monkeying, i’d removed it, and then forgot about it when it didn’t fix the issue. It’s been restored in my latest commit.
Cheers,
Aaron
Regards,
Paweł
On 11/12/2014 05:04 PM, Aaron Brown wrote:
Hey Pawel,
I couldn’t get the RPM to build using mock, so I committed some changes so I could build the RPM. However, after installing the RPM, going to the web and hitting start, it doesn’t seem to do anything for me. Navigating to the flash client directly, however,
does seem to work.
Cheers,
Aaron
On Nov 12, 2014, at 8:53 AM, Paweł Gesek <> wrote:
I've added the flashpolicyd script with some small modifications to the NDT repository. It is started by the ndt daemon and can be disabled in the sysconfig file in the same way as the fakewww daemon.
I believe I am finished with the RPM work, the changes are on the branch "Issues162". Please review and let me know if I missed something or you feel something needs to be changed.
Regards,
Paweł
On 11/07/2014 04:14 PM, Paweł Gesek wrote:
Great, I'll look at packaging that script with NDT. I assume we should bundle it with the ndt-server rpm. I'm also thinking that we can handle this in a similar fashion we do with fakewww - the ndt daemon will handle starting and
stopping of that script. Is that okay?
It's possible I missed fakewww, I'll take a look and make sure its consistent with httpd. As for widget.html it allows switching between the applet and flash client.
Regards,
Paweł
On 11/07/2014 03:42 PM, Aaron Brown wrote:
That script looks reasonable. As long as it can be reasonably be packaged with NDT, I’d be fine with it.
Cheers,
Aaron
On Nov 7, 2014, at 8:15 AM, Jordan McCarthy <> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
For what it's worth, the M-Lab platform uses the second approach,
embodied in this file:
https://github.com/m-lab-tools/ndt-support/blob/master/flashpolicyd.py
If this code looks reasonable to you all, please feel free to use it!
Jordan
Jordan McCarthy
Open Technology Institute | New America Foundation
Public Key: 0xC08D8042 | 4A61 3D39 4125 127D 65EA DDC2 BFBD A2E9 C08D 8042
On 11/07/2014 04:46 AM, Paweł Gesek wrote:
Hello everyone,
I have been looking at updating the NDT RPM so that the flash
client there works out of the box(Issue162
<https://code.google.com/p/ndt/issues/detail?id=162>). I've
committed changes to the branch
Issue162(https://code.google.com/p/ndt/source/detail?r=1144), which
make the HTML5-frontend install with NDT and changed the index page
in the apache configuration to the new widget.html.
As far as running the Flash client out of the box goes, the NDT
server has to expose the crossdomain.xml file, which is required
for the Flash client to allow opening sockets to the server.
Unfortunately the socket policy does not go through HTTP, but a
simple proprietary protocol that uses the TCP port 843. I am
wondering for the best way to handle this in the NDT rpm. We can
possibly add a requirement for a package like
https://code.google.com/p/flashpolicyd/ and use that to serve the
file. We could also consider bundling some sort of a simple server
script(like this
https://github.com/xantus/mojo-websocket-examples/blob/master/script/flash-policy-server)
that would serve the policy file. Do you preferences on how to resolve this?
Regards, Paweł
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCgAGBQJUXMYFAAoJEL+9ounAjYBCzD4IAKkSGdqsimCHWyD0ZdQcdD7W
wXH7emXDbO7z2jSojcNSKGqQe6wLPWFsQPN5PPwQqYdTs8bigxaKb7wGNC3qNBD5
B2FJ1Ohle10Et2NW20m+TCoORSQiYjpGCI+UenhbiV5B57BBE3t8cRgpHtxOiHjc
c2zxelECxdHq5eZ7f1JvAxWqdhUJZNVbWr7uIVGggcwe/b5Vg0yq9cqzIaVEX/bL
t9PEeYdzmmNq8ctjfKzgNEjNQo3Sp9O29nFB70KR9YNXvf0bOupJ76msI+FbRWaV
iOhgbCzfyHuHcTxQuHfxtUm5mf03cJ0QDWP5qFgTJPQSFrPYB5h4uENuMcgxKRw=
=bfO0
-----END PGP SIGNATURE-----
|
