Make raw files read-only, implement a setup command

[standage]

In the spirit of making it harder for learners to bork their setup by accidentally deleting or overwriting the raw data, I propose that permissions for all "data files" on the pre-configured machine be set to read-only. I also propose that we implement some kind of for-instructors-only setup command (registered as a bash function such as dcsetup in the ~/.bashrc file) that will do a "factory reset" on the working directory in case things get problematic on one of the learner's VMs. Whether the raw data is copied or symlinked to the working directory is up for discussion. In either case, I suggest we shield the learners from the irrelevant details of how this particular contrived environment is set up.

[ErinBecker]

@standage - I must make sincere apologies here as I had completely forgotten that I was a maintainer (and the sole maintainer) on this repo. 😟

These are indeed excellent ideas. The first point I can take care of easily (setting data files to be read-only), but I'm not familiar with what would be required to do the second (a "factory reset button"). The way that we currently handle this problem is to provide extra instances for a workshop so that Instructors have a few backups that they can have learners use if something goes wrong. I'd be happy to get something like that set up, however, if you (or someone else) was able to collaborate on it. Please let me know if you're still interested. I know it's been a long time since you put in this issue.

[ErinBecker]

The raw data files are now read-only in the version of the AMI that is being prepared (see datacarpentry/genomics-r-intro#23 for related changes).

[standage]

No worries.

It's been a while since I taught this workshop, so the details are a bit fuzzy. Plus, it looks like things have changed. When I taught there was a hidden directory in the dcuser home dir with all of the gzip-compressed Fastq files. Now it looks like the instructions have the users download the files directly from the ENA.

My original suggestion was to automate the process of copying the data files from the hidden directory to the working directory, nuking any contents in the working directory beforehand (if necessary) to start with a clean slate. The script could just as easily automate the data download, although this is a completely different scenario and my original recommendation might not be relevant anymore.

[ErinBecker]

Looping in @taylorreiter here in case I get any of the details wrong - I also haven't taught the new version of the materials. We do still have all of the data files stored in a hidden directory, in case learners have trouble with the download. If I'm remembering correctly, @taylorreiter said they had to use the hidden data files in her last workshop due to internet connectivity issues.

[ErinBecker]

But also pinging myself again because I've just realized I had to start over with a different AMI setup and forgot to make the data files read only again. I'll put that back on my list!

[taylorreiter]

@standage I don't think your original suggestion applies to the new version of the lessons directly.

We can discuss whether automating the download is a good way to go. When I taught this lesson, I copied the links into the ether pad and had learners try and download that way. It worked for half of the group, but the other half had connectivity issues (t2.medium instance problem). For this half, I had them copy the files over from the hidden backup. We still need to address how these files are copied over if/when download fails (see #140 here), and that might be a place for automation. I'm hesitant to support nuking the working directory, unless it's just the download directory, in which case that would be a good idea!

[JasonJWilliamsNY]

The technology maintainer group should handle these requests. I am a maintainer and can help with organizing any and all cloud images and also the data. I think we need to agree on recommendations first on a policy and solution and them implement.