Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 12 22:46
    garrettjstevens edited #128
  • Aug 12 22:46
    garrettjstevens assigned #129
  • Aug 12 22:46
    garrettjstevens milestoned #129
  • Aug 12 22:46
    garrettjstevens opened #129
  • Aug 12 22:40
    garrettjstevens milestoned #128
  • Aug 12 22:40
    garrettjstevens assigned #128
  • Aug 12 22:40
    garrettjstevens opened #128
  • Aug 01 17:01
    garrettjstevens closed #118
  • Aug 01 17:00
    garrettjstevens closed #117
  • Aug 01 17:00
    garrettjstevens closed #124
  • Jul 28 03:57

    garrettjstevens on Issue124_UIContextMenuToCopyFeature

    (compare)

  • Jul 28 03:57
    garrettjstevens closed #126
  • Jul 28 03:57

    garrettjstevens on main

    Add context menu item to copy f… (compare)

  • Jul 28 03:57
    garrettjstevens edited #126
  • Jul 28 03:52
    garrettjstevens synchronize #126
  • Jul 28 03:52

    garrettjstevens on Issue124_UIContextMenuToCopyFeature

    Updates (compare)

  • Jul 28 03:49
    garrettjstevens ready_for_review #126
  • Jul 28 03:48
    garrettjstevens synchronize #126
  • Jul 28 03:48

    garrettjstevens on Issue124_UIContextMenuToCopyFeature

    ready for test even paramaters … passing parameters to dialog Add close button to ApolloDetai… and 2 more (compare)

  • Jul 28 03:38

    garrettjstevens on Issue118_CopyFeaturesAndAnnotations

    (compare)

Scott Cain
@scottcain
At the moment, the Dockerfile in the apollo repo, develop branch is failing to build. It looks to me like it is a grails problem, as the first indication of a problem is this line Error Resolve error obtaining dependencies: Could not transfer artifact org.odftoolkit:odfdom-java:jar:0.8.5 from/to repo_grails_org_grails_core (http://repo.grails.org/grails/core): Permanent Redirect (308) (Use --stacktrace to see the full trace) with a simple build (docker build .) but to be honest, I’m not that experienced with apollo builds. Any ideas?
Garrett Stevens
@garrettjstevens
It built just fine 10 days ago, when the last change to develop branch was made, so I'm guessing something changed with the grails website.
Looks like they may have changed the structure of their website and something in the installation tools can't follow the redirect.
Scott Cain
@scottcain
Oh, well that’s a pain. As an aside, one of the things I’d like to do (once I get all the other things off my to do list ) is make a base image for apollo that has all the prereqs installed, so that silly things like this wouldn’t prevent building an apollo container.
Garrett Stevens
@garrettjstevens
That would be nice.
Scott Cain
@scottcain
Oh, heck, and that’s not even that easy a thing for us to fix, since the docker file depends on sdkman, which I know nothing about.
Nathan Dunn
@nathandunn
Gradle and groovy also depend on it so I’m pretty sure it’ll get fixed
Scott Cain
@scottcain
OK, still working on getting the Apollo container to build. I switched to pulling from the develop branch for Apollo, and it felt like it was working, because the build ran longer, but it ended up dying at the same place as above, trying to get odfdom-java. I thought the problem was a failure to gracefully redirect (since there is a 308 error thrown), and that may still be the most current problem, but when I go in a browser to http://repo.grails.org/grails/core and get redirected to https://repo.grails.org/artifactory/core/, I see that there is no listing for odfdom-java there, so even if the redirect were successful, I don’t think the build would complete successfully. So, I’m left wondering if we can/should try to get odfdom-java from somewhere else, or I am misinterpreting what’s going on? @garrettjstevens @nathandunn
(or can we pitch odfdom for the AGR build of apollo? No clue)
Nathan Dunn
@nathandunn
@garrettjstevens I would push to dev and see if its fixed there
its in maven central, so it should be getting picked up: https://mvnrepository.com/artifact/org.odftoolkit/odfdom-java
Garrett Stevens
@garrettjstevens
@scottcain looks like it's a problem with grails: grails/grails-core#11825. I realized it wasn't just docker, I couldn't build Apollo locally, either. Hopefully I'll have a fix in develop soon: GMOD/Apollo#2624.
Scott Cain
@scottcain
I figured it was something like that (ie, updating a repo url) but I didn’t know where to do it.
Garrett Stevens
@garrettjstevens
Just merged. Should be able to try again now.
Scott Cain
@scottcain
Yep, worked on my local apollo docker file; now I’ll try with the AGR container. Thanks!
Nathan Dunn
@nathandunn
Sorry, just put this on the twitters. Building a genome browser from neo4j: https://twitter.com/precogincog/status/1405612735077908481 . Not sure if the title is misleading, but its still kind of interesting.
childers
@childers
Hey all, is there any thought on adding two factor auth for apollo?
Robert Buels
@rbuels
Not the current one, no. Next gen one that we are currently working on might support external authn that could provide that
childers
@childers
@rbuels Cool. Thanks for the update
Nathan Dunn
@nathandunn
childers
@childers
@nathandunn Thanks! I'll check that out.
Does Apollo support java 17? I know the docs say 8+ but that is a pretty big jump
Curtis Ross
@cross12tamu
Hello, is there an easy way to prune/delete organisms (as an admin?)
Helena Rasche
@hexylena:matrix.org
[m]
If you've got a list of of organism common names or so, use arrow
https://github.com/galaxy-genome-annotation/python-apollo you can pretty quickly write a loop in bash to call the delete organism function
Curtis Ross
@cross12tamu
Thanks
Scott Cain
@scottcain
When I’m running the apollo container that we use at AGR, I see several sql errors when running the launch script and then the message Not using chado!. Given that the container isn’t working (tomcat is returning 500 errors), is this likely the problem, and what should I do.
(and of course, our devops guy says to me again: “ you should really create a base container that has a chado database already in it”. yeah, yeah, I know.)
2 replies
Nathan Dunn
@nathandunn
@scottcain the base docker container of Apollo has docker in it
so, just need to merge that in
probably a few other places as well
Helena Rasche
@hexylena:matrix.org
[m]

Oh yeah no worries, didn't know if you knew, and yeah new moving parts is always more work, totally get it.

Hour and a half to rebuild

Oof yeah that's a mood.

Scott Cain
@scottcain
It was something stupid (isn’t it always): I changed a set of urls and forgot to tell apollo
Scott Cain
@scottcain
Hi Apollo peeps! Has there been any thought to log4j and Apollo? I see that the version of grails I’m using is too old to be affected by the vulnerability (yay(?)). Are there other components that perhaps use a newer version of log4j?
Garrett Stevens
@garrettjstevens
I think we're safe (from that at least), see a bit of discussion here: GMOD/Apollo#2640
Scott Cain
@scottcain
Sounds good. Thanks!
Curtis Ross
@cross12tamu

I did not see the issue before, thanks for the post.

"Upper IT" at aTm is very involved right now, and some of it is about 1.X. However, I just got out of a meeting and I'll know over the next few days about how much they want to treat it as an actual problem. I'll keep y'all posted on what is found out.

childers
@childers
There are 2 other critical security issues with the log4j version in apollo2. It might be too old for the current crisis, but it is still vulnerable to other exploits
Helena
@hexylena:matrix.org
[m]
Yeah, the latest one applies under non standard configuration with something related to JMS toggled. I added it to that GitHub issue, but probably not affecting most folks
childers
@childers
Once we've seen that there are many critical and high issues, we can't ignore it. I am really unqualified in terms of Java development, but am tryin to slog through updating components. Is there anyone on the JBrowse/Apollo dev team or other developers that are interested in coming together to help update test these updates?
Nathan Dunn
@nathandunn
@childers it is using 1.2.17 . . . not sure all of the risks, but here: https://logging.apache.org/log4j/2.x/security.html . . mostly log4j 1 isn't affected for most of these.
Helena
@hexylena:matrix.org
[m]
No, not suggesting ignoring it, just that the exploit not applying to most users means it's a lot lower of a priority. The list Colin posted was definitely full of things to address, but for a lot we shouldn't discard that the exploits simply don't work for many instances, that should factor in the "panic patching" calculation a bit.
childers
@childers
@hexylena:matrix.org Apologies for my language there, I didn't think that the list of errors was being ignored, it's good to see that there is interest to bring the dependencies up to date. I am concerned because I read the earlier statements as dismissive of the critical and high vulnerabilities. Just because the log4j is not impacted by this critical vulnerability, there is another critical vulnerability that affects the version that is being used.
Helena
@hexylena:matrix.org
[m]
Oh no worries, apologies for coming across dismissive, I can see that interpretation for sure. I wish I had bandwidth to work on any of these myself
I think I personally am stuck with defense in depth and locking it down as much as possible, not sure what else we can do, it's such a long list
And worse it looks like less than half have a fix available which is not great
Helena
@hexylena:matrix.org
[m]
I can't remember if we posted it or not, but for other large Apollo users, we built this to work around slow loading of large large organism lists. For hundreds of organisms it can take load times from 10 minutes to 30 seconds. https://github.com/galaxy-genome-annotation/apolpi/
Curtis Ross
@cross12tamu
^ can confirm :)