Re: [DNG] UEFI, software RAID1, LVM and encryption

[Gregory Nowak via Dng]

On Mon, Jul 25, 2022 at 08:54:00PM +0900, Olaf Meeuwissen via Dng wrote:
> OK but if / and /boot are encrypted, something has to be able to decrypt
> that before GRUB can read /boot/grub/grub.cfg.  It might be that GRUB is
> able to do that itself these days (haven't checked) but on my LibreBoot
> laptop it's the LibreBoot BIOS that does the decrypting, AFAIK.
> Hence, my comment.

I can confirm that grub2 in at least Beowulf and now Chimaera can deal
with decrypting the boot partition if you use LUKS for the encryption:



The archwiki has even more scenarios:



> I was thinking/hoping I could make an encrypted LV, without encrypting
> all PVs in the VG.  I use a fair number containers and VMs and don't see
> a need to encrypt those.  Actually, I don't see much need for putting
> these on RAID1 either :-/

You can in fact do what you describe. Make your LV, but instead of
creating a file system on it, format it as LUKS, unlock it, and create
your file system on /dev/mapper/unlocked_volume.

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Firefox unwilling to install extensions

[marc]

Hello list

I am running various versions of devuan (chimera, but also beowulf) in 
lxc containers, and the versions of firefox shipping with devuan 
refuse to install extensions on a permanent basis.

I can go to 

"add-ons and themes->manage your extensions->cog->debug add-ons->load temporary 
add-on" 

and get things like noscript to run, but sadly that doesn't last.
This is on firefox 91.11.0, and also some earlier versions.
The other install methods prompt me for an accept/install, and 
then just do nothing...

I am just holding it wrong and is there a magic setting which will
let me install addons permanently ? I did go to about:config, and after several
obnoxiously patronising warnings, set the "xpinstall.signatures.required" 
to "false". Alas, that did not seem to make a difference. 

I did disable all the telemetry (including the live blocklist
downloads, etc)... Maybe the logic baked into firefox only lets one 
install extensions if one consents to regular body cavity searches ? 

Or maybe there is logic to detect containers so that the all seeing
eye can require live humans with camera and microphone to present
themselves to the browser ? I have "lxc.cap.drop = sys_module mknod net_raw"
and an intermediate proxy set...

Suggestions are appreciated - my "apt-cache search" did not show
anything called iceweasel, nor palemoon, nor waterfox. Would it be possible
to include these in the devuan repository, or perhaps (a thankless
task, I believe) build a version of firefox with no user-hostile 
logic enabled. Though one imagines that would have the benefit
of halving the executable size.

I am not keen to install anything chrome related or derived - that
hands google yet more initiative for the offensive addition 
of ever more web mis-features. I think this used be called the
upgrade treadmill in the paid-for software era.

Though admittedly I am also beginning to suspect that google only 
keeps mozilla around as pet, to trot out when the regulators 
stir in their slumber and mumble something about anti-trust
or market distortion.

Is that as dire as I think ?  Should I start planning
a full escape into the gemini universe ? Or is there still
hope - is it still possible to assemble a browser+configuration 
which is featureful, ad-free and privacy respecting, to suit up in, 
to climb out the airlock and venture forth out into the corporate
wasteland that is the modern web to scavenge a last few bits of 
useful information, underneath the heaps of used dopamine 
syringes, ad-excrement and other web-addict paraphernalia ?

regards

marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] OpenVPN 2.5.1-3+devuan1 packaging vs best practices

[Ken Dibble]

This is the first time I have seen this with any package.

I have no idea whether it has happened with packages not installed on my 
systems.


It is my understanding that best practice is noexec on /tmp and that 
this is a Debian recommendation.


Here is the relevant line from /etc/fstab.

tmpfs   /tmp    tmpfs defaults,noatime,mode=1777,nosuid,noexec,nodev  0  0


Here is the error message.

sudo apt-get dist-upgrade

.

.

Preconfiguring packages ...
Can't exec "/tmp/openvpn.config.NDxHMl": Permission denied at 
/usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178.
open2: exec of /tmp/openvpn.config.NDxHMl configure 2.5.1-3+devuan1 
failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

.

.

The (apparent) recommendation from bug report 129289 in 2002 is to set

APT::ExtractTemplates::TempDir
in apt.conf to some directory which is mounted with exec

and
As of version 0.5.8, apt supports TMPDIR for determining where
apt-extracttemplates puts its temporary files. If you have a noexec
/tmp, use this or other documented means to make apt-extracttemplates
use a directory that does accept executables

As of 2018 Bug #887099, merged with sundry other bug reports of the same type
Control: reassign -1 debconf 1.5.61
Control: forcemerge 566247 -1

This appears to be a generic issue in debconf, so I'm reassigning it to
debconf and merging it with the existing bugs tracking the same issue.

There doesn't seem to be any activity after that.

Is there a best practice for the method of selecting and setting this 
directory?


Thanks,

Ken
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI, software RAID1, LVM and encryption

[o1bigtenor via Dng]

On Mon, Jul 25, 2022 at 6:24 AM Olaf Meeuwissen
 wrote:
>
> Hi o1bigtenor,
>
> o1bigtenor writes:
>
> > On Sat, Jul 23, 2022 at 10:19 PM Olaf Meeuwissen via Dng
> >  wrote:
> >>
> >> Hi list,
> >>
> >> I lost the single SSD on my mini PC and am in the process of rethinking
> >> its storage.  So far, I've got myself two brand new and identical PCIe
> >> NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
> >> enable UEFI to get access to the BIOS from the GRUB menu.
> >>
> >> I want my /home directory on a partition of its own, at a minimum, and
> >> encrypt it.  I don't see a need to encrypt much else as I am not after
> >> plausible deniability.  It's mostly to be able to return a broken disk
> >> for a replacement and still sleep in relative peace of mind ;-)
> >>
> >> I haven't quite made up my mind as to a need for other partitions.  I
> >> use containers and VMs quite a bit.  Perhaps these are better stored
> >> some place other than the partitions for / or (an encrypted) /home.
> >>
> >> With 64GB of RAM, I don't see much need for swap.  If needed, I could
> >> always add a swapfile instead of a partition.
> >>
> >> Given the above,
> >>
> >>  - what are your expert(?) opinions on partitioning for this?
> >
> > Well - - - expert - - - lol - - maybe in my mind but not really even
> > there - - -grin
> > but I've just done something like this!
> >
> >>  - how do I make (and keep) both disks bootable?
> >
> > I used the partitions
> > 1. small (4M) empty in between each partition
> > 2. ESP on each disk (partiion #1)
> > 3. see #1
> > 4. partition on each disk
> > rolled each partition into a raid 1 array.
> > 5. see #1
> > 6. see #4
> > 7. repeat until complete
>
> I don't really understand why you used the "small" unused partitions in
> between.  Some kind of buffer to prevent "out-of-range" writes?

I first used gpt to partition a uefi setup some over 10 years ago.
At that time there was a recommendation of (IIRC) 2 MB spaces between
the partitions. Seemed to work and I moved to 4 MB as that is the (again
IIRC) block size on the items. So I have an empty block between every
partition. Given that I don't use anything smaller than 1 TB losing even
20 blocks of space imo is minimal. (Again) IIRC the idea was that if one
needed to rescue the partition have the empty space on either side was
to make things go better - - - dunno as to the legitimacy of such but
until its thoroughly debunked for me - - - I'll likely continue. (I
run a raid-10
array for my main storage (/home is more short term although I need to
do some serious cleanup) as I was serious security and like the speed
compared to raid-6 anyway. If I had need for a lot more space (would be
a lot more $$$) I think I would go to raid-60 for my main storage anyway.
>
> >>  - can I put the ESP on RAID1?
> >
> > I couldn't find a practical way to do this.
> > Read of some who built their system on disc 1 and then
> > copied everything to disc 2 then did some kind of interesting and, for me
> > anyway, confusing manipulations and then they had a raid-1 array where
> > one array had everything.
>
> I came across
>
>   https://wiki.archlinux.org/title/EFI_system_partition#ESP_on_software_RAID1
>   https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/
>
> which indicate it is possible but not without taking some extra care.
>
> >>- if not, how do I keep the copies in sync?
> >
> > Using the copy and then manipulate to make raid1 then supposedly does
> > that but I didn't do that so - - - dunno.
> >
> >>  - do I need a separate partition for /boot?
> >
> > I gave it one.
>
> In other follow up, Antony Stone and I concluded that it would not be
> needed for my needs.  In that case, I prefer to go without and keep it
> simple.
>
> >>- if so, can it be put on RAID1?
> >
> > My stuff has a raid1 array for every partition except ESP.
>
> I think that's what I'll end up using too.

IMO its not elegant to need to use a raid partition for each of my
partitions. I would think I could specify raid-1 for my partitions and
there would be one raid device instead of my bulging portemanteau
of them! But - - - I think I'm a fringe thinker for raid use. The linux
raid list denizens have at least indicated such. They see little need
for more than raid-5. Maybe I've been a business owner too long and
really really hated the last time I had to redo a years worth of data
for my business (recordkeeping) but once is enough!

>
> >>  - if not, how do I keep the copies in sync?
> >>  - should I use LVM?
> >
> > Me - - - maybe I'm just deficient but I didn't want to deal with one more
> > possible point of failure so I did NOT use LVM. (I tend to not only like
> > but practice the K.I.S.S. principle.) Maybe I should have but don't see the
> > value in adding complexity.
>
> Hmm, if I were to practice KISS (and I usually do), I'd leave out the
> unused partitions and keep /boot as part of the partition mounted on /
> :-P
>
> The 

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Olaf Meeuwissen via Dng]

Antony Stone writes:

> On Sunday 24 July 2022 at 11:58:01, Olaf Meeuwissen wrote:
>
>> Hi Antony,
>>
>> Thanks for the feedback.  I've been researching a bit myself in the mean
>> time as well but still value additional input from the list.
>
> I completely agree - asking people with experience, and with whom you can have
> a bit of a dialogue, is always a bit more encouranging than finding informatin
> of random ageas from random people on the Internet :)

Exactly!

>> > The only part of this you need to remember to do manually is grub-install
>> > /dev/thing2 if there's ever a new version of grub itself.
>>
>> I vaguely recall reading that you could enter a list of space separated
>> devices to install GRUB to in the installer.
>
> True, you can do this in the installer, but if grub gets updated later on, my
> experience is that it only updates the boot loader on the primary disk.

I'll make a note of that.

>> > Er, what's ESP?
>>
>> It's not Extra-Sensory Perception in this context :-P
>> It's the EFI System Partition and is what gets mounted on /boot/efi/.
>
> Ah, right, I seriously doubt you can put that on Raid, because it's not being
> read by Linux - it's being read by the UEFI/Bios ystsem itself in the machine,
> in order to find the boot loader (as far as I understand this process).

Turns out you can but it needs some special tinkering.  See

  https://wiki.archlinux.org/title/EFI_system_partition#ESP_on_software_RAID1
  https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/

Of course, you might get lucky and have a BIOS that understands RAID1 ...

> However, I also think it's something that you would simply install on both
> disksk and then leave it thre - either disk can then get the machien going.
>
>> > >- if not, how do I keep the copies in sync?
>
> As far as *that* one goes, I don't think you need to - I don't think this ever
> gets updated.

Then what would be the point of mounting it on /boot/efi?
It looks like efibootmgr can be used to tweak a couple of things, so if
you do, you'd want that reflected to the copy as well.

>> > >  - do I need a separate partition for /boot?
>> >
>> > You do not need one, but you can have one.
>>
>> Then I'd rather do without.  I asked because on a few of my systems it
>> *is* a separate partition.
>
> Yes, it used to be necessary before Linux could find /boot in LVM on Raid, for
> example.  You could put that separate /boot on Raid, but the LVM bit in the
> middle confused Grub before 2.00, as I recall.

So it won't be an issue on chimaera and beyond.

>> Thinking about that, I believe these were installed to use a "fully"
>> encrypted system, i.e. the partition mounted on / encrypted as well.  In
>> that case it makes sense because most BIOSs probably do not handle that.
>
> It's not the Bios that's doing anything at this stage - it's Grub.
>
> Bios looks at the boot sector on the disk, discovers Grub, and hands control
> over to it.  Grub then needs to know where / how to find /boot, because that
> contains /boot/grub/grub.cfg, which has all the details of everything want to
> be able to start up.

OK but if / and /boot are encrypted, something has to be able to decrypt
that before GRUB can read /boot/grub/grub.cfg.  It might be that GRUB is
able to do that itself these days (haven't checked) but on my LibreBoot
laptop it's the LibreBoot BIOS that does the decrypting, AFAIK.
Hence, my comment.

> But, the Grub loader in the boot sector is small and simple, and also needs to
> be able to find an encryption key if it's going to be able to decipher /boot 
> in
> an encrypted file system.

FTR, I enter the key via the keyboard.

>> If I only want/need an encrypted /home then I should be okay with /boot
>> on the partition that's mounted on /.
>
> Precisely.
>
>> > >  - does randomizing the partition for /home make sense if on LVM and may
>> > >get resized sometime in the future?
>> >
>> > What do you mean by randomizing?
>>
>> Writing random data to the partition before using it.  This is supposed
>> to make it harder to decrypt for prying eyes.
>
> Ah, right.
>
>> After I sent my mail, I thought I could randomize the whole disk (or
>> that part that's used as an LVM PV) but that might take a while ...
>
> Well, let's just think about that - if you write random data to a device and
> then use it as a PV for a VG, anyone who can get into the LVM system can see
> the VG and whatever LVs it contains, and therefore just ignores the random
> data.

True, but my concern was with the case where I'd resize the LV after
initial creation.  Suppose the LV was randomized upon initial creation
and then I extend it by a couple of GB.  Those extra GB would then not
be randomized, IIUC, and I'm not sure how one would go about randomizing
them after the fact.  Hence, making sure everything that could possibly
end up being part of an encrypted LV is randomized beforehand would
solve that (at the expense of randomizing too much).

> Unless you can 

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Olaf Meeuwissen via Dng]

Hi Didier,

Didier Kryn writes:

> Le 24/07/2022 à 05:18, Olaf Meeuwissen via Dng a écrit:
>> Hi list,
>>
>> I lost the single SSD on my mini PC and am in the process of rethinking
>> its storage.  So far, I've got myself two brand new and identical PCIe
>> NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
>> enable UEFI to get access to the BIOS from the GRUB menu.
>>
>> I want my /home directory on a partition of its own, at a minimum, and
>> encrypt it.  I don't see a need to encrypt much else as I am not after
>> plausible deniability.  It's mostly to be able to return a broken disk
>> for a replacement and still sleep in relative peace of mind;-)
>>
>> I haven't quite made up my mind as to a need for other partitions.  I
>> use containers and VMs quite a bit.  Perhaps these are better stored
>> some place other than the partitions for / or (an encrypted) /home.
>>
>> With 64GB of RAM, I don't see much need for swap.  If needed, I could
>> always add a swapfile instead of a partition.
>
>   Apart from the containers, which I haven't any experience of, and
> given your pretty reasonable description of your needs, my take would be
> to reserve the whole of your RAID1 for /home and add a small ssd for all
> the OS, in one single partition. Of course, no swap.

Hmm, if I were to add a small ssd, I'd either have to use up the one
SATA SSD port I have or revert to using an SSD on one of the USB ports.

I think I'm better off carving out a 30GB or so partition for the OS on
the RAID1.  The 30GB value comes from a chimaera install using guided
partitioning for the entire disk with encrypted LVM and a separate
/home.  I've found a 30GB partition for the OS to be plenty roomy for my
needs but it will happily hold a mostly default Xfce4 GUI.  Even adding
fcitx-mocz and Japanese fonts, a must for me, leaves room to spare.

>   If you happen to loose the OS disk, which is very unlikely: not a
> big harm, install Devuan on a fresh one. Your home is safe, although the
> only protection against your own mistakes is, of course, backup. KISS!

Putting both OS and /home on RAID1 would keep both safe.  Backups don't
only protect against one's own mistakes, they also protect against very
bad disk failures ... as I recently found out the hard way :-(

# I didn't quite expect my SSD to go bad on me after six months and a
# bad.  Actually, I can still see some of the file system but as soon
# as I get an I/O error, the device disappears.
# Reading the initrd triggers one ... duh!

My new setup will definitely run rsync backups on (ana)cron to a NAS on
the home LAN.
--
Olaf Meeuwissen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI, software RAID1, LVM and encryption

[Didier Kryn]

Le 24/07/2022 à 05:18, Olaf Meeuwissen via Dng a écrit :

Hi list,

I lost the single SSD on my mini PC and am in the process of rethinking
its storage.  So far, I've got myself two brand new and identical PCIe
NVMe SSDs (256GB) for use in a software RAID1 setup.  I think I need to
enable UEFI to get access to the BIOS from the GRUB menu.

I want my /home directory on a partition of its own, at a minimum, and
encrypt it.  I don't see a need to encrypt much else as I am not after
plausible deniability.  It's mostly to be able to return a broken disk
for a replacement and still sleep in relative peace of mind;-)

I haven't quite made up my mind as to a need for other partitions.  I
use containers and VMs quite a bit.  Perhaps these are better stored
some place other than the partitions for / or (an encrypted) /home.

With 64GB of RAM, I don't see much need for swap.  If needed, I could
always add a swapfile instead of a partition.


    Apart from the containers, which I haven't any experience of, and 
given your pretty reasonable description of your needs, my take would be 
to reserve the whole of your RAID1 for /home and add a small ssd for all 
the OS, in one single partition. Of course, no swap.


    If you happen to loose the OS disk, which is very unlikely: not a 
big harm, install Devuan on a fresh one. Your home is safe, although the 
only protection against your own mistakes is, of course, backup. KISS!


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng