Feature #8861

Be able to launch Tails Installer from the command line

Added by sajolida 2015-02-04 22:18:46 . Updated 2018-09-10 14:43:51 .

Status:
Rejected
Priority:
Low
Assignee:
Category:
Installation
Target version:
Start date:
2015-02-04
Due date:
% Done:

50%

Feature Branch:
kurono/feature/9005-Improve-tails-installer
Type of work:
Code
Blueprint:

https://tails.boum.org/blueprint/bootstrapping/installer#simplify

Starter:
Affected tool:
Installer
Deliverable for:

Description

In our redesign of the bootstrapping workflow for Tails, we would like to propose a path only in command line for people in Debian. With this in mind, it would be helpful to be able to start it from the command line. The original software took our code from already knew how to do that, so that shouldn’t be too hard.

As a bonus point, using it with the command line option to install, should also propose the user to upgrade instead if the destination device has a Tails already installed, see Feature #8860.

Subtasks

Related issues

Related to Tails - Feature #5929: Consider creating a persistence by default for plausible deniability Confirmed 2016-08-20
Related to Tails - Feature #10312: Assistant: Write "Debian & Ubuntu command line" scenario Resolved 2015-09-30
Related to Tails - Bug #10538: Do not install tails-installer to $PATH Resolved 2015-11-12
Related to Tails - Feature #15292: Distribute a USB image Resolved 2016-04-14 2019-01-29
Related to Tails - Feature #7499: Extend the upgrader to allow full (self) upgrade Confirmed 2014-07-06

History

#1 Updated by intrigeri 2015-03-01 21:52:34

#2 Updated by intrigeri 2015-03-03 18:14:53

#3 Updated by sajolida 2015-03-05 15:08:12

This would also be helpful to be able to automate the installation of Tails USB sticks. Imagine you’re getting ready for a conference and want to install 50 sticks semi-automatically.

#4 Updated by intrigeri 2015-03-05 17:07:12

> Imagine you’re getting ready for a conference and want to install 50 sticks semi-automatically.

I’ve no idea what’s the benefit compared to:

  1. create an original stick with Tails Installer
  2. cat/dd it to a disk image on my hard drive
  3. loop through cat/dd to duplicate the original stick to the 49 other ones

(I really don’t mean to argue about it, so don’t waste your time answering unless you find it important to enlighten me — as long as you take my point into account next time you think about it, I’m happy :)

#5 Updated by sajolida 2015-03-09 19:54:33

  • related to Feature #7630: Encryption plausible deniability added

#6 Updated by sajolida 2015-03-09 19:55:35

You’re right. Still, dd won’t be enough once we have plausible deniability for the persistent volume (Feature #7630) which would require having unique persistent volumes by default.

#7 Updated by BitingBird 2015-04-10 16:55:09

  • related to Feature #5929: Consider creating a persistence by default for plausible deniability added

#8 Updated by BitingBird 2015-04-10 16:55:14

  • related to deleted (Feature #7630: Encryption plausible deniability)

#9 Updated by Anonymous 2015-08-19 08:31:57

currently this does not work, the -f option (which says which device to install to is not taken into account).

A working command line to create a Tails device and partition it would be:

liveusb-creator -u -P -x -m -f /dev/sdb -c tails.iso

#10 Updated by intrigeri 2015-08-25 00:46:48

> currently this does not work, the -f option (which says which device to install to is not taken into account).

And more generally: lots of the installer’s logic lives in gui.py, which is not used when using it on the command-line. I see two options:

  • tracer bullet approach: copy’n’paste stuff from gui.py to liveusb-creator (main function, if opts.console block) until basic functionality works from the command-line;
  • good design approach: refactor by extracting logic from gui.py into a new controller class, that delegates all interactions with the user to a UI (view) object, that itself could be the GUI one or the console one.

I think that going for the tracer bullet approach first would help with the refactoring. And we’ll see how much code duplication it introduces, and in turn, whether it’s good enough to ship it as-is, or whether the refactoring is a blocker.

#11 Updated by sajolida 2015-10-14 04:29:28

  • related to Feature #10312: Assistant: Write "Debian & Ubuntu command line" scenario added

#12 Updated by Anonymous 2015-11-12 02:19:15

  • related to Bug #10538: Do not install tails-installer to $PATH added

#13 Updated by intrigeri 2015-11-12 02:54:11

  • related to deleted (Bug #10538: Do not install tails-installer to $PATH)

#14 Updated by intrigeri 2015-11-12 02:54:56

  • related to Bug #10538: Do not install tails-installer to $PATH added

#15 Updated by sajolida 2016-05-10 08:57:56

  • Blueprint set to https://tails.boum.org/blueprint/bootstrapping/installer#simplify

#16 Updated by kurono 2016-05-18 15:40:01

  • Assignee set to kurono
  • Target version set to Tails_2.5
  • QA Check set to Ready for QA
  • Feature Branch set to kurono/feature/9005-Improve-tails-installer

#17 Updated by intrigeri 2016-08-02 09:31:54

  • Target version changed from Tails_2.5 to Tails_2.6

#18 Updated by anonym 2016-09-20 16:53:45

  • Target version changed from Tails_2.6 to Tails_2.7

#19 Updated by BitingBird 2016-10-16 04:48:32

  • Status changed from Confirmed to In Progress
  • Target version changed from Tails_2.7 to Tails_2.9.1
  • % Done changed from 0 to 50

Assigning to next major release (but assignee should probably be changed)

#20 Updated by anonym 2016-12-14 20:11:19

  • Target version changed from Tails_2.9.1 to Tails 2.10

#21 Updated by anonym 2017-01-24 20:48:46

  • Target version changed from Tails 2.10 to Tails_2.11

#22 Updated by anonym 2017-03-09 14:00:28

  • Target version changed from Tails_2.11 to Tails_2.12

#23 Updated by sajolida 2017-03-18 11:12:50

  • Priority changed from Normal to Low

I’m sorry I didn’t make this clear from the start but this is a goodie for command line folks so it’s definitely low priority (and should maybe even be removed from Feature #9005).

kurono: I’m also seeing just now that you reassigned this to you and marked as “Ready for QA” 10 months ago (Feature #8861#note-16). Maybe that’s a mistake and you want someone else to test that. You can assign it to me if you want and tell me which command line should work now.

#24 Updated by kurono 2017-03-18 13:01:31

  • QA Check changed from Ready for QA to Dev Needed

Ah sorry I have changed it to Ready for QA by mistake.

#25 Updated by intrigeri 2017-04-20 06:48:15

  • Target version deleted (Tails_2.12)

(This has been postponed to $nextrelease for almost a year => dropping target version; feel free to set one back if it helps you organize your work :)

#26 Updated by anonym 2017-09-25 16:39:39

If we ever decide to do this (I’m very skeptical it’s worth the time investment) you’ll likely want to revert commits:

  • f071b0f41272196712facbe1a5052ec39d7608ad
  • 1111fa4cc0e4ec018b8ded72f126404b4777b3d2

#27 Updated by anonym 2017-09-25 17:42:58

Follow-ups from Feature #8860#note-40:

This feels wrong:

+        if self.opts.unprivileged == None:
+            self.opts.unprivileged = True
+        if self.opts.noverify == None:
+            self.opts.noverify = True

given we have:

parser.add_option('-n', '--noverify', dest='noverify', action='store_true',
help='Skip checksum verification')
[…]
parser.add_option('-u', '--unprivileged', dest='unprivileged',
action='store_true', help='Allow not being root')

With this change we’re now setting different defaults for the GUI than for the CLI, with no (obvious) way to override them when using the GUI at runtime. I bet that our code hasn’t supported not passing -n -u for a while anyway, so I think we should entirely drop these options and default to unprivileged + noverify in all cases. While we’re at it, instead of fixing the previously buggy --no-xo option, we could drop it.

#28 Updated by kurono 2018-07-18 16:47:25

  • Status changed from In Progress to Confirmed
  • Assignee deleted (kurono)

#29 Updated by sajolida 2018-08-19 10:06:11

#30 Updated by sajolida 2018-08-19 10:08:39

This is low prio already and I think should be competely rejected once we’ll distribute USB images (Feature #15292).

#31 Updated by intrigeri 2018-08-19 10:34:08

> This is low prio already and I think should be competely rejected once we’ll distribute USB images (Feature #15292).

Agreed!

#32 Updated by intrigeri 2018-08-20 10:06:12

  • related to Feature #7499: Extend the upgrader to allow full (self) upgrade added

#33 Updated by sajolida 2018-09-10 14:43:51

  • Status changed from Confirmed to Rejected
  • QA Check deleted (Dev Needed)

We now have a contract for Feature #15292, so I’m rejecting this.