|
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.
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?
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-----
|
