Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

11591 user ip #1742

Merged
merged 18 commits into from
Mar 14, 2014
Merged

11591 user ip #1742

merged 18 commits into from
Mar 14, 2014

Conversation

atarkowska
Copy link
Member

This PR allow to store IP address of the client creating omero session.

It should be tested from all our language bidings.

For example PYTHON:

import omero
from socket import gethostname, gethostbyname
ip = gethostbyname(gethostname()) 
print ip
c = omero.client(SERVER, PORT)
c.setIP(ip)
c.createSession(USERNAME, PASSWORD)
c.closeSession()

All integration tests should pass as defined here. The webclient does not yet make use of these changes.

@joshmoore
Copy link
Member

@aleksandra-tarkowska : this requires a purging the DB on gretzky. I'm marking excluded for the moment. If @pwalczysko is ok with deleting all the data on gretzky for Monday, than I can unexclude. Otherwise, we can discuss Monday AM. Thanks!

@jburel
Copy link
Member

jburel commented Nov 8, 2013

We will need to check with @imunro and @melissalinkert if there is still some on-going modulo work too.

@imunro
Copy link
Contributor

imunro commented Nov 8, 2013

If all this means that you want to clear Gretzky then feel free to go ahead & delete anything I've got on there.

@pwalczysko
Copy link
Member

Fine with clearing Gretzky. Please double check with @melissalinkert . If Purge Data option here http://hudson.openmicroscopy.org.uk/job/OMERO-merge-develop/configure is used, I suppose the auto_import script will kick in - this is how it was before and do not think it changed. Would prefer to leave it so = have always some data on Gretzky, but of course change it if this is necessary for this PR.

@mtbc
Copy link
Member

mtbc commented Nov 13, 2013

Keep excluded until at least November 20th (demo in Aberdeen).

@mtbc
Copy link
Member

mtbc commented Nov 24, 2013

Perhaps now include and test?

@@ -1866,6 +1866,7 @@
timeToIdle int8 not null,
timeToLive int8 not null,
userAgent varchar(255),
userIP varchar(255),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you expecting host names as well as IPs? If not, 15 digits would suffice. It would have to be a later SQL statement to shrink the column, since we don't support specifying string widths.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only expect IP. True will short it.

@mtbc
Copy link
Member

mtbc commented Jan 21, 2014

Perhaps now include and test?

@imunro
Copy link
Contributor

imunro commented Jan 21, 2014

I certainly have no objection (not sure why I'm cc'd actually)

@joshmoore
Copy link
Member

There are several things that will need to happen here before unexcluding:

  • Currently not mergeable (not sure where the conflict is)
  • There will need to be CI setup (new DBs, etc.)

Though we can proceed with those done, there should also be a general discussion of the target and requirements for this. What's the plan for other clients? Etc.

@mtbc
Copy link
Member

mtbc commented Jan 22, 2014

Aha, thanks. For my work on import logs, etc., obviously I'll also have to adjust the DB schema, so if that's to go into 5.0.0, hopefully at the end of this month, then my question would be if I should be expecting to rebase against this merged work first, or I'll probably just introduce more conflicts that further block this PR.

@@ -2071,6 +2071,11 @@ create unique index originalfile_repo_path_index on originalfile (repo, path, na
-- end ticket:2201
--


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change will need to also be added to the template files under components/dsl/resources/...

@jburel
Copy link
Member

jburel commented Jan 29, 2014

@aleksandra-tarkowska: insight already check the IP so it will be an easy addition if we go ahead.

@@ -2071,6 +2071,11 @@ create unique index originalfile_repo_path_index on originalfile (repo, path, na
-- end ticket:2201
--


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change will need to also make it into dsl/resources/**footer.vm

@joshmoore
Copy link
Member

Sorry, @aleksandra-tarkowska : but this is still listed as "We can’t automatically merge this pull request."

@atarkowska
Copy link
Member Author

@joshmoore is it better now?

@joshmoore
Copy link
Member

PR is mergeable and footer is updated. We'll still have to schedule a re-install on trout.

@atarkowska
Copy link
Member Author

@pwalczysko how do you feel about db re-install?

@pwalczysko
Copy link
Member

We are talking trout here (=develop). As discussed with @aleksandra-tarkowska ,

  1. happy to drop the DB and start from scratch, but not keeping the emptyi-ish DB for too long - re-population could be done by taking the old, upgraded, rich DB dump from Howe, upgrade it one more notch (as needed by this PR) and put it on the trout after the PR was tested. In this way, both the creation from scratch as well as upgrade would be tested, and I would have the rich-data DB ready.
  2. We have to have this done well before Thurdsday, because we will use trout in Nottingham demo/workshop (cc @will-moore )

@sbesson sbesson removed the exclude label Feb 7, 2014
@sbesson
Copy link
Member

sbesson commented Feb 7, 2014

Unexcluding.

@sbesson
Copy link
Member

sbesson commented Mar 13, 2014

@aleksandra-tarkowska: thanks. Last force push was due to the 5.0.0 sql scripts being moved rather than created. Restarted http://ci.openmicroscopy.org/view/Breaking/job/OMERO-5.1-breaking-trigger/ to test this change. Also created http://ci.openmicroscopy.org/view/Breaking/job/OMERO-5.1-breaking-upgrade/ to test the upgrade from a 5.0.0 DB for now.

@atarkowska
Copy link
Member Author

When that PR was opened there were next patch for 5.0DEV created following db schema instruction. We do not have anything mentioned in the doc how to create deal with first schema for new version

@sbesson sbesson removed the breaking label Mar 13, 2014
@sbesson
Copy link
Member

sbesson commented Mar 13, 2014

ALl breaking builds are green including http://ci.openmicroscopy.org/view/Breaking/job/OMERO-5.1-breaking-upgrade/12/. Altered the merge DB

[hudson@ome-c6100-3 ~]$ pg_dump -U omero -Fc -f ~/OMERO-5.1-merge-deploy-13032014-1943.db.dump OMERO-5.1-merge-deploy
[hudson@ome-c6100-3 ~]$ file ~/OMERO-5.1-merge-deploy-13032014-1943.db.dump 
/home/hudson/OMERO-5.1-merge-deploy-13032014-1943.db.dump: PostgreSQL custom database dump - v1.12-0
[hudson@ome-c6100-3 ~]$ psql -U omero OMERO-5.1-merge-deploy < /opt/hudson/workspace/OMERO-5.1-breaking-upgrade/VERSION/LAST_RELEASE/label/ome-c6100-3/OMERO.server/sql/psql/OMERO5.1DEV__0/OMERO5.0__0.sql
BEGIN
CREATE FUNCTION
 omero_assert_db_version 
-------------------------

(1 row)

DROP FUNCTION
INSERT 0 1
ALTER TABLE
UPDATE 1
                                 status                                 
------------------------------------------------------------------------
                                                                       +
                                                                       +
                                                                       +
 YOU HAVE SUCCESSFULLY UPGRADED YOUR DATABASE TO VERSION OMERO5.1DEV__0+
                                                                       +
                                                                       +

(1 row)

COMMIT
[hudson@ome-c6100-3 ~]$

breaking label removed for final inclusion in the daily merge build.

@sbesson
Copy link
Member

sbesson commented Mar 14, 2014

Thanks everyone for the thorough review.

sbesson added a commit that referenced this pull request Mar 14, 2014
@sbesson sbesson merged commit 9aeaa5a into ome:develop Mar 14, 2014
@atarkowska atarkowska deleted the 11591_user_IP branch March 14, 2014 10:51
@atarkowska
Copy link
Member Author

thank you ;-)

@sbesson
Copy link
Member

sbesson commented Mar 14, 2014

Ran the upgrade script on the latest DB

[hudson@ome-c6100-3 ~]$ pg_dump -U omero -Fc -f ~/OMERO-5.1-latest-deploy-14032014.db.dump OMERO-5.1-latest-deploy
[hudson@ome-c6100-3 ~]$ file ~/OMERO-5.1-latest-deploy-14032014.db.dump
/home/hudson/OMERO-5.1-latest-deploy-14032014.db.dump: PostgreSQL custom database dump - v1.12-0
[hudson@ome-c6100-3 ~]$ psql -U omero OMERO-5.1-latest-deploy < /opt/hudson/workspace/OMERO-5.1-breaking-upgrade/VERSION/LAST_RELEASE/label/ome-c6100-3/OMERO.server/sql/psql/OMERO5.1DEV__0/OMERO5.0__0.sql
BEGIN
CREATE FUNCTION
 omero_assert_db_version 
-------------------------

(1 row)

DROP FUNCTION
INSERT 0 1
ALTER TABLE
UPDATE 1
                                 status                                 
------------------------------------------------------------------------
                                                                       +
                                                                       +
                                                                       +
 YOU HAVE SUCCESSFULLY UPGRADED YOUR DATABASE TO VERSION OMERO5.1DEV__0+
                                                                       +
                                                                       +

(1 row)

COMMIT
[hudson@ome-c6100-3 ~]$

@atarkowska
Copy link
Member Author

--no-rebase

@atarkowska
Copy link
Member Author

It looks like server can get the IP address of the caller, but if the client is connected to the server via Glacier2, what is reported as the remote address is the Glacier2 endpoint that forwards the request, not the original endpoint of the client. See http://doc.zeroc.com/pages/viewpage.action?pageId=2523170

Ice.EndpointInfo einfo = current.con.getEndpoint().getInfo();
Ice.IPEndpointInfo ipeinfo = (Ice.IPEndpointInfo)einfo;

Ice.ConnectionInfo info = current.con.getInfo();
Ice.IPConnectionInfo ipinfo = (Ice.IPConnectionInfo)info;

@sbesson sbesson added this to the 5.1.0-m1 milestone Oct 14, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants