Outro -a.k.a- Where can I find $Stuff!?

Ok guys, $Stuff is now distributed around different servers, domains, services, people… Here are some links for external users to find the resources:

SEMS web page

The wordpress site has been serialised to static web content and is now available through sems.bio.informatik.uni-rostock.de. All sems.uni-rostock.de/.* links should send proper HTTP redirects, so your browser will automatically guide you to the new location.

Trac

Everything trac-related is now available through GitHub. There are plenty of repositories at github.com/SemsProject, the trac-wikis and tickets are converted to GitHub pages at semsproject.github.io/.
The webserver should be configured to properly redirect individual projects, wikis, tickets etc… Thus, bookmarks and scripts should be working fine.

Compilation Products

During SEMS’ life time we created quite some binaries. People and pipelines are relying on their availability. However, they also needed to move and are now available here:

Again, webservers are configured to redirect people and pipelines automagically!

Maven

We continue developing our tools and we will provide them through Maven. As described above, our Maven repository has moved to mvn.bio.informatik.uni-rostock.de.
But even better: we’re now distributing our tools through Maven central! No need to integrate a third party repository anymore :)
However, we switched the group id. It is now de.uni-rostock.sbi – so update your POMs. But don’t worry, you don’t need to update all the package names, the classes are still packaged as de.unirostock.sems.*. Find our artifacts published under de.uni-rostock.sbi at Maven Central.
Maven central will only contain new artifacts. The repository at mvn.bio.informatik.uni-rostock.de will still deliver previous artifacts, and mirror Maven central for the new artifacts. Thus, feel free to keep our third party repository integrated in your workflows.

Tools

Online tools, demos and prototypes have moved as well:

By the way, did you recognize that we also deployed proper SSL certificates for all services? :)

Cool, but how…

..did I just do it? Maybe it’s interesting for one or the other, or maybe you need to archive/migrate your $stuff as well? Therefore a quick overview on how I’m handling different things.

WordPress

This website used to be a WordPress instance. It has been serialised to static HTML pages using HTTrack and a bit manual fine-tuning – see also Archiving a Website.

Services that can handle HTTP redirects

Services that just handle default HTTP traffic now reply with a permanent redirect (HTTP/1.1 301 Moved Permanently). That’s realised using tiny Nginx vhosts. For example, bin.sems.uni-rostock.de can now be found at https://bin.bio.informatik.uni-rostock.de/, and the following definition makes sure people are forwarded to the proper location:

1
2
3
4
5
server {
        server_name bin.sems.uni-rostock.de;
        listen 80 ;
        rewrite ^/(.*)$ https://bin.bio.informatik.uni-rostock.de/$1 permanent;
}

Thus, a request on http://bin.sems.uni-rostock.de/CombineArchiveWeb/CombineArchiveWeb-0.4.9.war will be forwarded to https://bin.bio.informatik.uni-rostock.de/CombineArchiveWeb/CombineArchiveWeb-0.4.9.war. Try it yourself:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
usr@srv $ curl -LI http://bin.sems.uni-rostock.de/CombineArchiveWeb/CombineArchiveWeb-0.4.9.war
HTTP/1.1 301 Moved Permanently
Server: nginx/1.13.8
Date: Wed, 24 Jan 2018 12:40:44 GMT
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Location: https://bin.bio.informatik.uni-rostock.de/CombineArchiveWeb/CombineArchiveWeb-0.4.9.war

HTTP/2 200
server: nginx/1.13.8
date: Wed, 24 Jan 2018 12:40:44 GMT
content-length: 47174359
last-modified: Thu, 08 Oct 2015 16:01:12 GMT
etag: "2cfd2d7-52199f8defcec"
accept-ranges: bytes
strict-transport-security: max-age=31536000
Services that can’t handle 301

The above is probably the preferred approach, as people/browsers/search-engines won’t recognize anything and the old URLs will smoothly disappear (they won’t be copied anymore etc).
However, not every tool/pipeline is able to work with 301 redirects… For example, the BiVeS web application accepts POST requests. Tools that send a POST to bives.sems.uni-rostock.de may also receive a 301 that BiVeS moved to bives.bio.informatik.uni-rostock.de, and they may look at the new URL if you’re lucky, but they (most certainly) won’t resent the POST data to the new location. Thus, all tools that integrate BiVeS will not work anymore… :(
Thus, I’m not responding with a 301, but the request will just be proxied to the new location. For example, the Nginx configuration for BiVeS looks like this:

1
2
3
4
5
6
7
8
server {
        server_name bives.sems.uni-rostock.de;
        listen 80 ;
        location / {
                proxy_pass https://bives.bio.informatik.uni-rostock.de;
        }

}

This, however, is a bit sub-optimal as users won’t realised that BiVeS has moved…
That means I need to make sure this URL stays up and running!

Source code and wikis and tickets and stuff

Our git and trac stuff was migrated to GitHub (https://github.com/SemsProject/) and GitHub Pages (https://semsproject.github.io/). That has been made possible by Martin Peters, who developed a https://github.com/FreakyBytes/TracMigrator.

Monitoring

I’m a big fan of monitoring. Thus I started the migration with monitoring of web content using check_links. For example, I wrote a check to see if the page behind https://sems.bio.informatik.uni-rostock.de/projects/bives/ still contains the phrase highlighted reaction network. So a went around the many different sites and tools to define almost 100 different checks. This way, my monitoring solution would notify me as soon as a page/tool is not properly migrated and I can be sure that the HTTP redirects for all the URLs forward to the correct final locations (also with proper content negotiation for COMODI etc).
These checks are now properly integrated in my monitoring infrastructure, so that I can continuously be sure that links (in papers for example) stay valid.

Help from the whale

In the process of migration I encapsulated almost everything in Docker containers. This way it’s easier to handle the (legacy) content and a future migration will hopefully be much quicker.

But where is…?

Did we forget something? Is some tool not working properly anymore?
If you experience any problems please drop me an email.