noauto option ignored in /etc/fstab?

[Josef Wolf]

On Tue, Dec 12, 2017 at 01:36:13AM +0100, Xen wrote:
> Josef Wolf schreef op 11-12-2017 23:29:
> 
> The answer to that question lies in the fact that some people also encrypt
> remote systems.

Which, as we've seen, makes only sense if you can trust the operator (and
whoever else might have access to the hardware)

> >1. downloads the server-install-cd
> >2. adds a menu entry to use my preseed file
> >3. deletes some packages which I don't feel like needing
> >4. installs a late-command, which will install a systemd service that is
> >   executed when the freshly installed system is booted for the first
> >time.
> 
> Oh I thought you would have added the stuff (new packages etc) in the
> installer itself.

Tried that, but discarded that idea again. Found it hard getting those checksums
and signatures right. Packages on the CD will be outdated pretty fast anyway.

Since I always update/upgrade during the postinstall, it's just one additional
line in the postinstall-script to install the prerequisites for the
configuration system.

The configuration system will take care of the packages which are needed on
specific hosts. And this will take place not at cd-creation-time but at
INSTALL time and during the whole life-time of the host.

The configuration system runs "svn update" on a regular basis. This way, I
need only to commit changes to the svn repository. All the systems will pull
those changes and re-configure themselves.

Once this is in place, maintaining lots of systems starts getting pretty easy.

The only problem is to keep track with fast-moving changes. I've still not
adopted to systemd :-//

Oh, modern distros tend to prefer GUI for system configuration. That's a PITA,
too :-///

> But I guess you want the latest versions immediately.

Yes, that's also a reason.

> >5. this "postinstall" script starts a screen session on tty6 and starts
> >four
> >   initial windows:
> >   - window 0: top
> >   - window 1: watch 'hostname -f; echo; route -n; echo; ifconfig'
> >   - window 2: watch 'ps fax | grep -v grep | grep -B 5 -A 24 postinstall'
> >   - window 3: runs the real postinstall script.
> 
> That's neat.
> 
> What if you wouldn't have network?

Then I check why there's no network.

Really, nowadays you (almost) always have network available.

And if there'd be a serious problem with the network, then I'd get a beer and
the install will be deferred to the next day. But I never had THIS problem yet.

> >The postinstall script:
> >1. makes sure network is available
> >2. removes cdrom from apt.conf
> 
> This thing seems to be bugged...the CD. You have to add it back to the index
> each time if you want to use it :-/.

Why would I want it to be used? Network is (almost) always available and
faster than CD. Even more: if I log in from remote and want to install
something, I don't want apt to ask me to insert the CD.

> >If I can eliminate a risk without any effort, I go for it.
> 
> It's not without cost.

So, what's the cost?

> I hide the boot partition because I want the adversary to have as little
> information as possible.
> 
> The adversary knows it's a Linux system but does not even know the kernel
> version or the distribution.
> 
> This just reduces the room for asking questions. Someone who is faced with a
> blank wall cannot inquire into that wall, or less so.

This point has its merits.

> For instance your boot system probably displays the name of the partition
> that you are about to unlock, including the LUKS name.

Oh, it shows about three or four of them. I always keep some unused boot/root
partitions on my disks. This way I can easily reinstall the system without
wiping the current (working) one. This way I can always fall back to the
previous system should the reinstalled system have serious flaws.

> The Grub boot prompt is nondescript, ugly (unfortunately) and more like
> TrueCrypt.
> 
> There is no clue about partition layout (because there is only one) and
> after I'm done patching LUKS (one day, ever :p) there won't even be a
> partition table.
> 
> It will be a Grub bootsector, a LUKS header, some room... and then encrypted
> space.
> 
> Or even differently, LUKS headers are not encrypted, TrueCrypt's are.
> 
> TrueCrypt encrypts the partition table.
> 
> Linux doesn't even need no partition table.

No dual boot?

> But anyway I want the adversary to see the least amount of interesting
> possible.

So you're not going to enter the next level of paranoia: deniable encryption
(SCNR ;-)

> >If there'd be a noticeable effort, I'd step back and think whether it's
> >actually worth to do.
> 
> Sure but that's only true because you rarely reboot your machines or power
> them off.

This LOOKS to you as if I would have additional effort because you skip the
verification step. Would you verify your (vulnerable) grub, you'd have at
least the same cost.

So you're comparing apples with oranges.

> I'm on dmraid and my root partition is cached too :p.
> 
> So I have a RAID 0 HDD system cached by SSD :p.
> 
> Using embedded LVM :p.

????

> (I mean one partition contains 2 logical volumes that are actually physical
> volumes for another volume group, and the SSD does the same, so...
> 
> Both the HDD (raid) and the SSD have a volume group called "coll".
> 
> The part that's on the HDDs contains msata-pv and raid-pv and the part
> that's on the SSD contains msata-pv-cache and raid-pv-cache. msata-pv and
> msata-pv-cache combine to form in this case a cached root.
> 
> And raid-pv and raid-pv-cache do the same for something else.
> 
> So I have a cached logical volume spawned from physical volumes that are
> logical volumes that are part on raid 0 dmraid and part on SSD.
> 
> Now isn't that hilarious. And it all works :p.

I've tried to switch to LVM several times. Every time, I defer this because of
a lot of additional complexity.

> _Some results may have been removed under data protection law in Europe._

???

-- 
Josef Wolf
jw at raven.inka.de