seattletestbed / selexor Goto Github PK

Reported by llaw02 on 23 Apr 42749485 13:44 UTC
advertise_port in the configuration file should be removed. We don't use it anywhere in selexor, and in fact, it most likely gave incorrect names to vessels that are managed by nodemanagers that aren't operating on the advertise_port, since we are able to probe for these.

Reported by llaw02 on 12 Mar 43351025 17:05 UTC
When authenticating on the web interface, the authentication hangs indefinitely. The connection is still active however, as when you leave the page after initiating the authentication request, the timeout alert still pops up on the browser.

On the web server log, the server sets up the connection to the XMLRPC interface. However, not much else is shown otherwise.

...
2013-05-07 13:46:54,284 Connecting to the clearinghouse on behalf of leonwlaw
...

This issue shares some common ground with #11. We initiate the request to perform the connection to the XMLRPC server via a POST. However, the POST handler on the web server does not respond with a Content-Length header, causing the connection to hang.

Spammed post.

Reported by llaw02 on 2 Oct 42749487 14:06 UTC
The current implementation ignores NAT nodes. We need to include vessels on these nodes into the available vessel pool.

Reported by llaw02 on 21 Jul 43619434 17:43 UTC
Unacquirable vessels no longer break SeleXor requests. However, the lookup step can be slow since everytime we get an unacquirable vessel, we have to redo the request without bad vessel. We should cache these vessels so that we don't re-acquire a vessel that we have tried in a previous request that is un-acquirable.

Reported by llaw02 on 18 May 42759013 09:18 UTC
The current city file is not used to validate a user inputted city name. If we check the name first, we can give the user a more meaningful error message indicating that a bad name was set, rather than no vessels were in the invalid city.

Reported by llaw02 on 18 Sep 43624951 23:00 UTC
The log files grow very fast, and often don't give much meaningful information. Some consideration needs to be made in which log messages should be pruned.

Reported by llaw02 on 11 Jun 42924184 12:28 UTC
There is an issue if the same user is logged into selexor from 2 locations, and they have different requests that are sent to the server at the same time, selexor will try to honor both of them, and possibly fail.

A solution is to implement server enforced sessions, so that this problem is avoided entirely.

Reported by llaw02 on 31 Jul 43633748 17:24 UTC
Lookups with the Seattle nodestate transition key only returns a small set of nodes. The nodes in the set appear to be different between lookups. This can be replicated by performing an advertise lookup from selexor.poly.edu.

>>> import repyhelper
>>> repyhelper.translate_and_import('advertise.repy')
>>> repyhelper.translate_and_import('rsa.repy')
>>> k = rsa_file_to_publickey('../selexor/seattle_nodestatetransition.key')
>>> k
{'e': 22599311712094481841033180665237806588790054310631222126405381271924089573908627143292516781530652411806621379822579071415593657088637116149593337977245852950266439908269276789889378874571884748852746045643368058107460021117918657542413076791486130091963112612854591789518690856746757312472362332259277422867L, 'n': 12178066700672820207562107598028055819349361776558374610887354870455226150556699526375464863913750313427968362621410763996856543211502978012978982095721782038963923296750730921093699612004441897097001474531375768746287550135361393961995082362503104883364653410631228896653666456463100850609343988203007196015297634940347643303507210312220744678194150286966282701307645064974676316167089003178325518359863344277814551559197474590483044733574329925947570794508677779986459413166439000241765225023677767754555282196241915500996842713511830954353475439209109249856644278745081047029879999022462230957427158692886317487753201883260626152112524674984510719269715422340038620826684431748131325669940064404757120601727362881317222699393408097596981355810257955915922792648825991943804005848347665699744316223963851263851853483335699321871483966176480839293125413057603561724598227617736944260269994111610286827287926594015501020767105358832476708899657514473423153377514660641699383445065369199724043380072146246537039577390659243640710339329506620575034175016766639538091937167987100329247642670588246573895990251211721839517713790413170646177246216366029853604031421932123167115444834908424556992662935981166395451031277981021820123445253L}

>>> l = advertise_lookup(k, maxvals=2**32)
>>> len(l)
49
>>> l = advertise_lookup(k, maxvals=2**32)
>>> len(l)
48
>>>

The database log file:

root@selexor:/home/selexor/seattlelib# cat ../selexor/selexordatabase.log | grep nodes | tail -20
2013-08-18 20:44:31,008 Found 49 nodes
2013-08-18 20:55:03,512 Found 50 nodes
2013-08-18 21:06:10,702 Found 0 nodes
2013-08-18 21:16:14,847 Found 48 nodes
2013-08-18 21:27:11,986 Found 48 nodes
2013-08-18 21:37:46,303 Found 49 nodes
2013-08-18 21:48:35,253 Found 51 nodes
2013-08-18 21:59:26,421 Found 48 nodes
2013-08-18 22:10:13,610 Found 50 nodes
2013-08-18 22:21:12,827 Found 49 nodes
2013-08-18 22:31:45,125 Found 51 nodes
2013-08-18 22:42:50,249 Found 0 nodes
2013-08-18 22:52:51,389 Found 49 nodes
2013-08-18 23:03:30,581 Found 48 nodes
2013-08-18 23:13:59,767 Found 46 nodes
2013-08-18 23:24:42,530 Found 48 nodes
2013-08-18 23:35:32,136 Found 49 nodes
2013-08-18 23:45:57,264 Found 50 nodes
2013-08-18 23:56:24,404 Found 46 nodes
2013-08-19 00:07:07,764 Found 48 nodes

Reported by llaw02 on 18 Apr 43357409 21:17 UTC
When loading the web page for selexor on Chrome, it may take a >10 seconds before the user sees something on the screen.

There are two underlying issues:

This has been identified as a chrome issue:

https://code.google.com/p/chromium/issues/detail?id=195550#c11

Modern browsers perform pre-connections to web servers when they anticipate that multiple files are going to be requested from the web server. Since the selexor was initially single threaded, it can only handle one connection at a time. The extra preconnections don't actually send any data over initially, so after the first connection is served, if they somehow become the active connection that is being handled, selexor blocks until it times out, effectively being a race condition.

The length of the message was not sent over from selexor to the client. Web browsers expect the length of a response when performing a request. This causes them to wait until a timeout to occur.

Spammed post.

Reported by llaw02 on 31 Dec 43351072 21:57 UTC
This would allow browsers to automatically log in for a user. Its intent is to prevent users from having to type in their API key frequently if they use selexor frequently, and can jump directly to interacting with selexor rather than copy/pasting their API key every single time.

Possible solutions:

• Store session state on the hash after the URL. Use javascript to extract credentials and authenticate
  • Advantages
  • Users can save their logins merely by adding a bookmark to the current page after logging in
  • URL Hashes are not sent to the server, people eavesdropping on the connection would not be able to pick it up when the request is initiated. Also, SSL support prevents eavesdropping from occuring, period.
  • Disadvantages
  • API keys are visible within the bookmark if another person opens the user's bookmark manager, or is looking over their shoulder. This doesn't seem that bad, however. Users can easily re-generate a new API key if they deem necessary.

Reported by llaw02 on 28 Feb 43940689 18:34 UTC
The rule parser library currently use string concatenation to build SQL queries. (See: one of the many examples)

This is prone to SQL injection. The most prominent attack path is the rule "from a specific location", which is directly accessible from the Selexor interface.

We should use prepared statements to protect against this.

Spammed post.

Reported by llaw02 on 5 Sep 43386128 08:49 UTC
With the current acquisition method, we may attempt to acquire extra vessels from the Clearinghouse. However, this is not supported by the Clearinghouse, and ends up triggering an InvalidRequestError.

Spammed post.

Reported by llaw02 on 4 Nov 43412073 00:05 UTC
The vesselports table is absurdly large. Looking into the database shows that there are multiple entries for each port on each vessel.

Reported by llaw02 on 13 Aug 43351060 22:09 UTC
Acquiring vessels through selexor limits users to their specified clearinghouse port. There is no current way to get vessels regardless of what ports they have, i.e. if users wish to run code on more vessels than there are available with a certain port, they can never acquire that many vessels.

Spammed post.

Reported by llaw02 on 13 Jan 43628259 15:30 UTC
The UI plugins that we use are antiquated and non-standard. We should consider switching to using jQuery UI as a replacement, as they are industry standard.

Another incentive to switch over is to make links in tooltips clickable. They are not supported by jQuery UI's tooltips natively, but this thread provides some insights on how to implement it.

http://stackoverflow.com/questions/13286514/jquery-ui-tooltip-set-timeout-and-set-hover-events-freeze-tooltip-on-mouseover/15014759#15014759

Reported by llaw02 on 7 Jun 43412109 05:57 UTC
The log files keep growing to no limit. Log rotation needs to be set up so that the server does not run out of disk space.

Reported by llaw02 on 20 Jan 43011152 10:46 UTC
When the database is probing, the web interface is very slow to load, even on a local system.

A possible solution is to separate the database probing and web service into separate processes, and use sockets to communicate between the processes when lookups are needed. The current implementation has everything as one process.

Reported by llaw02 on 9 Jun 42760238 21:34 UTC
When the user logs in via the web UI, they should be able to see their previously acquired vessels in one group. This way, they can release them if they want to.

Reported by llaw02 on 7 May 42749519 03:55 UTC
The current implementation backs up the database state upon normal shutdown (ctrl+C). Therefore, if the server shuts down for any other reason, then the current data cannot be recovered in a later restart. This might be an issue for persistent vessel parameters that we may support in the future (e.g. latency?)

Reported by llaw02 on 4 Nov 43945104 04:56 UTC
Test ticket to test ticket creation slowness.

Reported by Gaetano on 5 Nov 43378477 21:40 UTC
We should add a monitoring script for Selexor. This script should probably be locating on Betabox or Blackbox.

Reported by llaw02 on 23 Jul 43944951 15:02 UTC
The user will provide a set of geographical coordinates and a maximum distance, and SeleXor will return a set of vessels that are within that distance from the coordinates.

This will be mostly used in part to find vessels that are along some routing path. Therefore, we should treat the world as a cylinder when performing these calculations. (i.e. east-west wrapping only, poles do not converge into a single point to avoid paths going across the poles because we aren't going to have have any nodes there...)