Renamed attached file: 'Screenshot from 2015-11-16 11:44:49.png' to 'Screenshot from 2015-11-16 11_44_49.png' because it contained invalid character(s).

Hi Enrique,

I can confirm that problem comes only from FILAB Piraeus Node.
I deployed the IDM-Keyrock on our VPS and we have no problem with
connections,signup and timeouts from any terminal
On FILAB the Keyrock can not be works well.

I will request to open an issue about performance on Piraeus Node.

Thanks at all,

Zacharias,
BeeZon IoT Solutions,

On Mon, Nov 23, 2015 at 12:33 PM, Enrique Garcia Navalon <

Renamed attached file: 'Screenshot from 2015-11-16 11:44:49.png' to 'Screenshot from 2015-11-16 11_44_49.png' because it contained invalid character(s).

Hi Zahos,

I think the connection issue has definitely something to do with the node
and is infrastructure. The fact that the error depends on the time frame
really supports this. You should contact the Piraeus node administrators to
fix it.

About the SSL warning, don't worry too much about it. First of all, that
trace is during the installation of the libraries, not the actual functing
of Horizon. Furthermore, it's a very common warning to appear but has never
been an actual issue. If you want to make sure it's not affecting the
component, check this link
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning

I'll take a look at the signup error. Seems like there is a path where the
view doesn't return a response object, but I don't know why yet. Could you
open a issue here https://github.com/ging/fiware-idm/issues so we can track
it more easily? Email is not the best tool for this

Best regards,
Enrique

Renamed attached file: 'Screenshot from 2015-11-16 11:44:49.png' to 'Screenshot from 2015-11-16 11_44_49.png' because it contained invalid character(s).

Hi Enique,

Also,
We are faced problem to register a new user (the attachment codes the huge
error stack response page) at
http://185.23.171.114:8000/sign_up/

Thanks,

Renamed attached file: 'Screenshot from 2015-11-16 11:44:49.png' to 'Screenshot from 2015-11-16 11_44_49.png' because it contained invalid character(s).

Hi again, Enrique

We repeat the same tests yesterday during the 19:30 to 01:00 (Athens time)
with the same results.

Also I installed and deployed another instance of Keyrock in the
185.23.171.56:8000 with same results.

I have attached the log from horizon. It seems to loose the connections.

Another very interesting experiment we made was today morning.* In Morning
hours all instances works perfectly with all browsers!*
(Is it possible the PiraeusN node to have expremely load afternoon hours
and loose packets?)

Also during the installation of keyrock in 185.23.171.56 I had a warning
like

*pip install virtualenvwrapperCollecting
virtualenvwrapper/usr/local/lib/python2.7/dist-packages/pip/vendor/requests/packages/urllib3/util/ssl.py:90:
InsecurePlatformWarning: A true SSLContext object is not available. This
prevents urllib3 from configuring SSL appropriately and may cause certain
SSL connections to fail. For more information,
see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
<https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning>.
InsecurePlatformWarning Downloading
virtualenvwrapper-4.7.1-py2.py3-none-any.whlCollecting virtualenv (from
virtualenvwrapper) Downloading virtualenv-13.1.2-py2.py3-none-any.whl
(1.7MB) 100% |████████████████████████████████| 1.7MB 298kB/sCollecting
virtualenv-clone (from virtualenvwrapper) Downloading
virtualenv-clone-0.2.6.tar.gzCollecting stevedore (from virtualenvwrapper)
Downloading stevedore-1.9.0-py2.py3-none-any.whlCollecting pbr>=1.6 (from
stevedore->virtualenvwrapper) Downloading pbr-1.8.1-py2.py3-none-any.whl
(89kB) 100% |████████████████████████████████| 90kB 4.8MB/sRequirement
already satisfied (use --upgrade to upgrade): argparse in
/usr/lib/python2.7 (from stevedore->virtualenvwrapper)Collecting six>=1.9.0
(from stevedore->virtualenvwrapper) Downloading
six-1.10.0-py2.py3-none-any.whlBuilding wheels for collected packages:
virtualenv-clone Running setup.py bdist_wheel for virtualenv-clone Stored
in directory:
/root/.cache/pip/wheels/0b/86/b4/295afae21c0d76d0465dc41b2457424aa5b6c7a049c14df1e9Successfully
built virtualenv-cloneInstalling collected packages: virtualenv,
virtualenv-clone, pbr, six, stevedore, virtualenvwrapper Found existing
installation: six 1.5.2 DEPRECATION: Uninstalling a distutils installed
project (six) has been deprecated and will be removed in a future version.
This is due to the fact that uninstalling a distutils project will only
partially uninstall the project. Uninstalling six-1.5.2:
Successfully uninstalled six-1.5.2Successfully installed pbr-1.8.1
six-1.10.0 stevedore-1.9.0 virtualenv-13.1.2 virtualenv-clone-0.2.6
virtualenvwrapper-4.7.1*

I don't know if this warning affects the application.All other components
has been successfully.
Also I rebuild the database into the 185.23.171.114 and loaded with the
test data as described in manual.

The rar file as attachment contains the IDM horizon log from 185.23.171.56
and the test file which shows the test clients and the results

Best Regards,

On Wed, Nov 18, 2015 at 12:33 PM, Enrique Garcia Navalon <

Renamed attached file: 'Screenshot from 2015-11-16 11:44:49.png' to 'Screenshot from 2015-11-16 11_44_49.png' because it contained invalid character(s).

Very interesting.
I have never experienced a problem like this, but I always work with my
local instance or the fiwarelab one.

I don't think there is anything wrong with your installation, at least that
I can think of. To pinpoint the problem I'd need more specific details on
what browsers (an what versions) on which operating systems works.

Btw, are your browsers up to date?

Another interesting question is if the fiwarelab instance works correctly
with the browsers that don't load correctly the web. Although I have a gut
feeling that is not a browser related issue...

To check database access log into your machine and check MySQL and Keystone
logs.

I'm going to do some testing on FIWARE-Lab images to see what else could be
going on...

Thanks for your feedback.

BR,

Enrique

Renamed attached file: 'Screenshot from 2015-11-16 11:44:49.png' to 'Screenshot from 2015-11-16 11_44_49.png' because it contained invalid character(s).

Hi all,

I would like to mention that the problem exist.
We made many tests from different web browsers, different ips. As result,
in some cases the Horizon works perfectly but there are other where we
have the same problem.
As a example, from my laptop pc works perfectly with firefox but not with
Chrome!

About your suggestions,

*Check that Keystone is not blocking the web (database access taking too
long)*
How we can check the database performance?Is there any tool? Any info?

Check your Horizon settings
We have the settings.py as defined into github. We have no changes in the
settings file.Except the change into the horizon_idm.conf line 13 as you
suggested.

Check the Horizon logs to see where it is spending the most time
Where is my default path of logs? We follow the installation guide.

Check that static files are compressed and Apache correctly configured
????

make sure the machine is performing well in general
The machine is a VM with ubuntu14.04 from FILAB node PiraeusN. It seems
that it works with no problem. (Over 60% free space, consume 9.2% cpu)
If the machine has any problem or if there are network problems I thing the
most appropriate group is the Piraeus N node administrators

Also I would like to ask if you had before the same problem with the
Keyrock. It is possible to have something wrong in installation?

We will try to install another fresh copy of the keyrock to another VM from
FILAB and also another on promises to compare them.

Thanks,

On Mon, Nov 16, 2015 at 3:46 PM, Enrique Garcia Navalon <

Renamed attached file: 'Screenshot from 2015-11-16 11:44:49.png' to 'Screenshot from 2015-11-16 11_44_49.png' because it contained invalid character(s).

I don't know why is it going slow, you'll have to trace down the
bottleneck(s).

• Check that Keystone is not blocking the web (database access taking too
  long)
• Check your Horizon settings
• Check the Horizon logs to see where it is spending the most time
• Are you using Apache or the dev server? Check that static files are
  compressed and Apache correctly configured
• And make sure the machine is performing well in general

Best regards,
Enrique

Renamed attached file: 'Screenshot from 2015-11-16 11:44:49.png' to 'Screenshot from 2015-11-16 11_44_49.png' because it contained invalid character(s).

Thanks Enrique,

After 15 minutes I got the next image!!! Also I am trying to login with the
default admin user idm and the page is still loaded!!!
It seems that I can not download images and css! Also it is extremely
slower than the test we have done the previous days.

I don;t know if the problem is in the IDM or if there is a performance
issue in the FILAB and Piraeus Node.
Also I checked all the settings maybe firewall blocking and I have no any
issue.

[image: Inline image 1]

On Mon, Nov 16, 2015 at 12:48 PM, Enrique Garcia Navalon <

Renamed attached file: 'Screenshot from 2015-11-16 11:44:49.png' to 'Screenshot from 2015-11-16 11_44_49.png' because it contained invalid character(s).

Hi again,
I tried going to http://185.23.171.114:8000/ with my browser, and the page
renders correctly, although it takes a while to load. I'm not sure if I
understand the problem correctly, maybe its fixed now?

Best regards,
Enrique

[image: Screenshot from 2015-11-16 11:44:49.png]

Hi again,

We faced the same problem again.
At 21/10, with the help of Enrique we had solved the problem.
I am remind you that the problem was that in the IDM the keyrock backend
portion worked normally at 5000, but the UI portion (Horizon) at 8000 had
no response (timeout).
Now we have The same problem again (however we have included the solution
of Enrique).

We found nothing in logs about the problems in keyrock application.

Any suggestions,

The external IP is 185.23.171.114 (internal 10.60.5.110) at node PiraeusN

Best Regards,

Thanks Enrique,

It works,

Best Regards

On Wed, Oct 21, 2015 at 1:21 PM, Enrique Garcia Navalon <

Looks like the set_up_as_service task doesn't use that setting. We will fix
the bug, but in the mean time you can fix your installation editing the
file /etc/init/horizon_idm.conf and change line 13 :
from python manage.py runserver
to python manage.py runserver 0.0.0.0:8000

then restart the service and it should be fixed.

Best regards,
Enrique

Thanks Enrique,

Unfortunately we are not familiar with fabric application and we have
difficulties on setup the IDM
I am running as a service

After the command fab horizon.install
I am running the
fab horizon.set_up_as_service
and

service horizon_idm start
I think the application uses the *settings.py *which has the parameter
HORIZON_DEV_ADDRESS = '0.0.0.0:8000'

Best Regards,

On Wed, Oct 21, 2015 at 12:31 PM, Enrique Garcia Navalon <

Hi Zacharias,

Looks like a problem in the network configuration of your VMs or a
misconfiguration in Horizon or Keystone in where to listen.

• Check that those ports are accesible and all the VM network stuff. From
  your mail that seems to be OK.
• Check in which address is Horizon listening. It looks like you are
  listening to 'localhost' but that doesn't work if you want to respond calls
  from outside your VM, you have to listen to 0.0.0.0:8000. I imagine you are
  running the development server for Horizon, calling fab horizon.dev_server.
  Call it like fab horizon.dev_server:address='0.0.0.0:8000' and it should
  function correctly.

Best regards,
Enrique

Hi Enrique,

OK I gave up the installation with docker. I tried to install the IDM based
on instructions from docs web site.

I install them (IDM-Keyrock and IDM-Horizon) I think, without any mistake
and with default configuration.
The services run but the problem is that when I call it from my browser I
get error timeout. (http://185.23.171.114:8000/)

However the http://185.23.171.114:5000/ for Keyrock works perfectly.

I have also checked the ports from security group of VM and ports 5000 and
8000 are open.

Also I checked it from inside the VM with wget http://localhost:5000 and I
am getting response 200 (OK ) and it downloads the page index.html.
However from external call http://185.23.171.114:8000/ I am getting timeout.

Any suggestions,

Best Regards,

Zacharias Papachristos
Beezon IoT Solutions

On Mon, Oct 19, 2015 at 12:30 PM, Enrique Garcia Navalon <

Hi,

The docker image is experimental. Right now we are in process of discussing
how should we use docker for the IdM. It makes little sense just to have a
docker image, so we are probably going to implement a docker-compose file
to do all the work required to make an IdM work.
https://github.com/ging/fiware-idm/issues/21

I will recommend following the installation instructions for now before
using docker:

http://fiware-idm.readthedocs.org/en/latest/admin_guide.html#automated-installation-recommended

We can provide support for any issues you encounter following the supported
path.

Best regards,

Enrique

Hi,

my colleague Enrique will help you.

BR

Dear,

I’ve forwarded your request to the second level support.

Best,
Daniele

Since January 1st, old domains won't be supported and messages sent to any domain different to @lists.fiware.org will be lost.
Please, send your messages using the new domain (Fiware-lab-help@lists.fiware.org) instead of the old one.
_______________________________________________
Fiware-lab-help mailing list
Fiware-lab-help@lists.fiware.org
https://lists.fiware.org/listinfo/fiware-lab-help