|
Ok, thanks for clearing that up Aaron.
As for the init script, if we would decide to split the rpms, I
believe we would either have to have the RPMs conflict, or create
a separate base rpm(ndt-server-base) which would contain scripts,
html, fakewww, the daemon, etc. Then have two ndt-server rpms for
just the binaries, depending on the base package. The daemon would
detect which version is installed and it could be manually
configured if both were present. That would probably be the
simplest route(aside from having them conflict), but as you say,
there is no web10g rpm so thats for the future.
Regards,
Paweł
On 11/17/2014 03:22 PM, Aaron Brown wrote:
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-----
|
