noauto option ignored in /etc/fstab?
jw at raven.inka.de
Tue Dec 12 13:14:09 UTC 2017
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
> 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
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,
> 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
> > 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
> 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
> 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
So you're not going to enter the next level of paranoia: deniable encryption
> >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._
jw at raven.inka.de
More information about the ubuntu-users