Proposal to Move Diaspora Pod to Noida datacentre

@saurabh , looks good to me. Since we have to also move to debian based hamara sugam, lets wait for its release (Feb?), what do you think? We also need to switch to full disk encryption.

Data center sounds more reliable. How would be the migration plan? Estimated downtime?

We have to inform users in advance.

@anisha

1. setup the new server with full disk encryption.
2. Sync uploaded files to new server (public directory)
3. Shutdown old instance
4. Resync files for recent changes
5. Backup the database
6. Copy database dump to new machine
7. Restore database
8. Bring up diaspora and test (use /etc/hosts).
9. If everything is fine switch dns to new server.

@praveenarimbrathod : February is fine for me. I guess we should wait then till Sugam is released.

@saurabh We need to look deeper into hardening a diaspora node and also an IDS

@vik any update on the hamara sugam plan?

Ambivalent. Whatever the people hands on think is right.

On side note and more of a long term thinking than immediate concern: I am somewhat paranoid about hosting my server in the same country as a government I piss off. Not to mention the government is currently obsessed with controlling content and particularly social media, but since we are already doing it, I wonder if we have/are exploring ways to eventually protect our data even in the event of the government physically accessing the server. I would also recommend not logging IPs of users by default. It can be turned on for testing and such or they can be recorded for a very short duration (so they get overwritten by the time anyone thinks to demand info on our users in the event of a problem)

@vidyut those who don't want to be under Indian jurisdiction can opt for a pod outside India, that is the beauty of decentralization. Hosting in India is important from a self reliance perspective, not having to depend on another country for your communications. But the fight for free speech in India is a long and hard one.

@vik @rajudvindane there was an article in Times of India few days back about diaspora and the author did not mention diasp.in hosted in India because we are not listed in podupti.me as our diaspora version is old. If she knew there was a pod in India,it would have had a bigger impact. But anyway we have to hurry up and complete the migration to hamara sugam.

http://timesofindia.indiatimes.com/tech/tech-news/The-Facebook-alternatives-you-didnt-know-about/articleshow/51274413.cms

@vidyut I don't think we log ips. As for protecting the data from physical access. We got to encrypt our disk. We are planning to do it when we move to Noida data centre.

@saurabh @vik @amardeepsingh @rajudvindane with so frequent down times, I think moving to new data centre has to be a priority. With Hamara Sugam getting delayed, I suggest we move to debian stretch directly and switch repos to Sugam when it is ready.

@isaagar volunteered to update diaspora in our current setup. He'll have to update ruby too.

We'll track progress of it here https://gitlab.com/piratemovin/diasp.in/issues/3

@saurabh I think we should migrate the vm as soon as possible. OS migration can be considered later. I think we can just copy the virtual disk. How soon can we do it?

@praveenarimbrathod @saurabh @isaagar we would schedule a time for the diasp.in migration

We discussed about it on our XMPP room (diasp.in@groups.poddery.com). It seems @amardeepsingh is busy for next 2-3 weeks and we can do the migration only when he is available.

The plan is to import the kvm qcow2 image (in Gurgaon) directly into openstack (in Noida).

@amardeepsingh assigned a new ip for diasp.in (182.74.5.230) on airtel connection (our current connection is tata) as a backup yesterday. We have configured the server with new ip, but we are not able to ping the server yet, possibly firewall needs adjustments. Amardeep is checking the issue.

Once we fix the issue with new ip address, we can add the second ip to dns and use the round robin method to fix the current reliability issue. If the reliability issue is fixed by this step, we can postpone the server migration until hamara sugam with debian is released.

We got removed from podupti.me again on 11th for the outdated version.

So there is work required before migration like testing the update path and taking full backup.

Just a thought. Instead of updating from the existing version can we restore data onto a fresh install of 0.6.0.0. If yes then as @praveenarimbrathod mentioned we can try on stretch and make it hamara by adding hamara repository when ready.

If @amardeepsingh can join us I think we can plan this better.

I suggest we update on the current hamara as we don't know when the debian based hamara is going to be released (we already got delayed a lot waiting for that initially). If at all we are going to move to debian first, we still have to move to 0.5.2.0 first and then do an upgrade as it is not a good idea to change too many things at once.

I think as @praveenarimbrathod said we should update to 0.6.0 on current hamara . Hamara sugam is still in pre-alpha stage so it will take time for stable release.
@praveenarimbrathod can you list out steps for upgrade process ??

Step 0. Complete backup (See https://www.loomio.org/d/gxrI4fjN/comment/1245316) so its less risky.
Step 1: Try update locally and fix package if necessary (See https://gitlab.com/piratemovin/diasp.in/wikis/HamaraSetup)
Step 3: Do the actual update (apt-get install diaspora-installer)

@isaagar can you tell us the deadline to move? Once we fix the actual date of migration, we should post an update from our account so users get a heads up.

The steps we need to take for migration,

1. Install debian stretch, with disk encryption. Just a way of protecting data if someone copies the disk.
2. Copy database. Setup new machine as a slave 2.
3. Install diaspora-installer package (TODO: I should add the latest version to my personal repo). rsync /usr/share/diaspora/public to new server.
4. Install prosody and copy its configuration.

When we are ready to switch, shutdown current machine, make new machine (slave 2) as master for slave 1, switch DNS to new machine.

Also we need volunteers to plan/execute the migration. Comment here if you'd like to help.

Before 13th april but we should migrate within two days for safer side.
I available for the migration task and will communicate on diasp.in xmpp channel.