Hi again
after further investigation I have noticed that the problem on linux
is related with bug in these versions of java (based on discussion here).
When I installed older version as suggested there (7u67) I was
finally able to successfully run applet. Again, running it multiple
times resulted in working ok all the time so I wasn't able to
reproduce bug.
What is current status of releasing NDT? Are there any things left
that should be done before we can do it?
Regards
Sebastian
On 21.11.2014 17:36, Sebastian Kostuch
wrote:
Hi Aaron
I have tried to reproduce bug with java applet working randomly
(on widget.html site). What I have noticed is that on linux
systems (tried on Ubuntu 14.04 and Fedora 20) I wasn't able to
successfully run test using applet and got warning that plugin was
not loaded properly and when I removed catching JS exception from
script.js file then it was "
Liveconnect call for Applet ID [id] is not allowed in this JVM
instance" which is java security issue (unless I have added site
hosting it to exceptions list). It's odd that using windows and
same security settings I didn't have such error (java version
8u25, on linux I have tried with the same version and 7u72 also).
However it resulted in working all the time on windows and not
working all the time on linux, wasn't able to reproduce it the way
you have mentioned. It would be helpfull to know what exactly
versions of java they were using and what system/browser.
Regards
Sebastian
On 17.11.2014 21:12, Aaron Brown
wrote:
Hey Pawel,
On Nov 17, 2014, at 10:51 AM, Paweł Gesek <>
wrote:
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.
That’s more the division I was thinking of:
ndt-server-common (init scripts, fakewww, flashpolicyd,
etc.), ndt-server-web100 (web100srv), ndt-server-web10g
(web10gsrv). Allow both -web100 and -web10g RPMs to be
installed, and have the existing “ndt-server” RPM become a
meta-package that grabs ndt-server-web100 and
ndt-server-common. Another option would be to have
“ndt-server” have web100srv, and have it depend on
ndt-server-common. Upgrades would then work as expected.
Cheers,
Aaron
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-----
|
