Opened 9 years ago

Closed 7 years ago

#2301 closed task (fixed)

migrate bridgedb to tor server

Reported by: phobos Owned by: aagbsn
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords:
Cc: kaner, ln5 Actual Points:
Parent ID: #5481 Points:
Reviewer: Sponsor:

Description

Currently bridgedb runs on byblos. The byblos owner asks us to move it to a tor server.

Child Tickets

Change History (16)

comment:1 Changed 9 years ago by phobos

This needs coordination, I believe, between at least three different people. We should identify those three people and send an email to start the coordination, date selection, and final migration date.

comment:2 Changed 8 years ago by karsten

Milestone: BridgeDB Upgrades Phase 1
Parent ID: #4380

Assigning as a child ticket to the project ticket that replaces the "BridgeDB Upgrades Phase 1" milestone.

comment:3 Changed 8 years ago by phobos

What if we just setup a new server and pointed people at it? And then left the current server as a backup?

comment:4 Changed 8 years ago by karsten

AFAIK, the new server wouldn't assign bridges to the same pools. This would be really confusing once we try to make use of the sanitized bridge pool assignments.

Let's do a clean migration from one server to the other.

comment:5 Changed 8 years ago by aagbsn

Status: newneeds_information

ponticum.tpo is the new VM. Is the existing (bridges.tpo) configuration/security documented anywhere?

comment:6 in reply to:  4 Changed 8 years ago by arma

Replying to karsten:

AFAIK, the new server wouldn't assign bridges to the same pools. This would be really confusing once we try to make use of the sanitized bridge pool assignments.

Let's do a clean migration from one server to the other.

By clean do you mean that we should copy over all the databases as-is, or do you mean that we should discard all the "working databases" and do a clean install?

I think you want the former, but that sure seems less clean to me. :)

comment:7 Changed 8 years ago by karsten

I meant copying over all the databases and making the migration as transparent for users and researchers as possible. There, now we can fight over the meaning of "transparent." ;)

comment:8 in reply to:  5 Changed 8 years ago by arma

Replying to aagbsn:

ponticum.tpo is the new VM. Is the existing (bridges.tpo) configuration/security documented anywhere?

Sounds like setting up the new one is the perfect time to document how to do it. ;) We should work to simplify the set-up, and work to isolate the parts that need to stay secret (like keys) so the rest can be documented in public.

Here's a starting list of items to investigate:

  • You'll want the apache conf stanza for redirecting http://bridges.torproject.org/ to the https version, and for proxypassing the https version to the bridgedb service. I emailed it to you.
  • You'll want to get an ssl cert for bridges.torproject.org. I think right now it uses a wildcard cert, but maybe that's a less wise idea for its new home. I bet Andrew will have an opinion here.
  • You'll want some smtp forwarding lines from your postfix-or-whatever-that-knows-how-to-do-optimistic-tls to the bridgedb smtp port. I'm not sure what the current lines are. Also, somewhere in the process something needs to check the dkim signature on incoming mail -- that used to be a separate dkim proxy, but maybe bridgedb has a dkim python module now.
  • You'll want the bridgedb.conf file. I just sent it to you.
  • You'll want various secrets, databases, etc if you want Karsten's "clean" transition plan.
  • You'll want a way of getting the bulk-exitlist file. Right now moria1 generates it twice an hour (at the :20 and :50) and makes it available via http. Then bridgedb sucks it down via a cron (at the :00 and :30) and hups bridgedb. Eventually you'll want to switch to pulling down the bulkexitlist as exported by torbel, but that doesn't exist yet.
  • At :07 and :37, Tonga tars up the bridge descriptors and bridge networkstatus and ssh'es it to bridgedb, which has a special authorized_keys line that makes it run bin/store-bridge-tarball, which makes a backup copy of the tarball and then untars it into bridgedb's working directory. It looks like the script doesn't hup bridgedb, but I think that's a bug.
  • bridges rsyncs its bridge-directories (backup) directory to metrics.tp.o on an hourly basis. The bridge tarball directory gets big really fast.
  • Once a day we send email to the people who are configured to get the 'unallocated' bridges. I think those emails might be broken currently -- or maybe kaner just took me off the cc list. More likely byblos has some config or iptables rule that is preventing them from going out.
  • When things are set up, make sure all the places that expect to cron an ssh somewhere have done the ssh manually at least once, to store the expected fingerprint in the right place.

comment:9 Changed 8 years ago by arma

Cc: kaner added

comment:10 Changed 8 years ago by kaner

Please let me know if I should move the scripts & cronjobs and set them up on the new host. I already offered this on IRC, but it might have gone lost.

comment:11 Changed 8 years ago by arma

Type: defecttask

kaner, can you clarify what the current situation is with dkim? Is there a dkimproxy running on gettor.tp.o that bridges@… uses?

If aagbsn is up for it, I think having him set everything up, and document it all as an outsider to the process, will force us to actually write everything up.

comment:12 Changed 8 years ago by arma

Owner: changed from phobos to aagbsn
Status: needs_informationassigned

comment:13 Changed 8 years ago by arma

Cc: ln5 added

comment:14 Changed 8 years ago by arma

I think something has moved forward here but nobody's updated the ticket? Or am I wrong?

comment:15 Changed 8 years ago by karsten

Parent ID: #4380#5481

Making this a child ticket of #5481 where it's already listed as required substep.

comment:16 Changed 7 years ago by aagbsn

Resolution: fixed
Status: assignedclosed

bridges.tpo is now on ponticum.tpo

Note: See TracTickets for help on using tickets.