My Early Arch Config - Looking for feedback

This is the best way I can come up with to install AURs from the live installer…

# Configure nobody for makepkg
printf  '%s %s\n'                                     \
        '%nobody ALL=(ALL)'                           \
        'NOPASSWD:/usr/bin/makepkg, /usr/bin/pacman'  >\
        '/mnt/etc/sudoers.d/nobody'

chown --recursive \
      'nobody'    \
      '/mnt/root' #arch-chroot always uses /root for home despite -u, so we lend it to nobody

# Install yay
printf  '%s\n'                                                        \
        '#!/usr/bin/env bash'                                         \
        'set -euxo pipefail'                                          \
        'for aur_pkg in "${@}"; do'                                   \
        '  git clone "https://aur.archlinux.org/${aur_pkg}.git"  \'   \
        '            "/tmp/${aur_pkg}"'                               \
        '  cd "/tmp/${aur_pkg}"'                                      \
        '  makepkg --noconfirm --syncdeps --needed --clean --install' \
        '  rm --force --recursive "/tmp/${aur_pkg}"'                  \
        'done'                                                        >\
        '/mnt/var/tmp/install_aur.sh'

chmod '+x'                          \
      '/mnt/var/tmp/install_aur.sh'

arch-chroot -u  'nobody'                          \
            '/mnt'                                \
            /var/tmp/install_aur.sh  yay brave-bin

rm '/mnt/var/tmp/install_aur.sh'

# Reset nobody privileges
chown --recursive 'root' '/mnt/root'

rm  '/mnt/etc/sudoers.d/nobody'

Trying to get selinux working on this thing, I’m starting to understand why all you maniacs want threadrippers for your linux workstations… Need to put more cores into this VM.

1 Like

Nah, just overclock it and be happy with 87c load temps

1 Like

Getting closer :grimacing:

:frowning:

cvtsudoers/test5: OK
cvtsudoers/test6: OK
cvtsudoers/test7: OK
cvtsudoers/test8: OK
cvtsudoers/test9: OK
cvtsudoers: 35/35 tests passed; 0/35 tests failed
make[1]: *** [Makefile:458: check] Error 3
make[1]: Leaving directory '/home/z6f9c9717/selinux/sudo-selinux/src/sudo-1.9.3p1/plugins/sudoers'
make: *** [Makefile:114: check] Error 2
==> ERROR: A failure occurred in check().
    Aborting... 
1 Like
==> Validating source files with sha512sums...
    IPMIView_2.17.0_build.200505_bundleJRE_Linux_x64.tar.gz ... FAILED
    ipmiview.desktop ... Passed
    ipmiview.png ... Passed
==> ERROR: One or more files did not pass the validity check!

:-1:

It’s funny, the AUR reminds me a lot of Hombrew. Just more difficult to use per obligatory Arch gatekeeping/barrier-to-entry.

By default, systemd creates a tmpfs for /tmp if nothing is set in fstab (see tmp.mount). Alternatively, I can set /tmp to be encrypted dynamically on each boot which is how I have configured swap. Arch wiki describes this here:

temporary crypt volumes for /tmp … considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised.

I have plenty of ram and disk space, so neither should impact the decision. Wondering what people do, prefer or wish they did…

What should I do with /tmp?

  • tmpfs
  • crypt

0 voters

1st revision of the install script incoming. I was able to get SELinux functional (albeit in permissive mode), and devised a way to install AURs via chroot from the live installer.

Still need to:

  1. Try dracut
  2. Configure smartd
  3. Configure postfix for email alerts
  4. Configure clamav
  5. Firewall?
  6. Configure auditd
  7. Enforce XDG paths where possible
  8. DE stuff
  9. SELinux policy/context changes

smartd, postfix, clamav and auditd should be easy because I’ve scripted config for them on other systems before. dracut might take some time, and of course DE will definitely take some time. SELinux policy will be a long haul. Idk if I’ll ever get it into enforcing mode, esp using an alt WM like Awesome.

Updated Gist:

1 Like

Playing around with some DEs in Arch just to get a feel for them. My earlier Plasma install (the distro, not just the DE) was such a disaster, I don’t think I’ll try it again on Arch, but I do really like some things about it, so I tried it out. It does look nice…

Also tried out Budgie which I used for 2 years on Solus. I think I’ve grown out of it though.

Probably going to continue with Awesome. Might try to run it on top of gnome if I feel like I’m missing some gui config and other DE luxuries.

Over a year ago, it was announced that Arch would replace mkinitcpio with dracut, but based on my experience with it today, progress on that has been slow. I followed the instructions, but it would hang on boot. I inspected the initramfs and it did have my luks key, cryptab, etc, so I’m not quite sure what the problem was.

Additionally, dracut-hooks is still only in the AUR which to me means that it isn’t anywhere close to being an official replacement for mkinitcpio yet. It’s also extremely noisy when it runs. Feels very unpolished.

So I am going to stick with mkinitcpio. From my attempt at getting dracut to work, I think it will be pretty easy to migrate once the kinks are worked out.


I have these done. clamav took a bit because I had to write unit files for scheduled scans. So nice that RHEL does that for you. I was a little surprised not to find anything in the AUR for that.

2 Likes

And it’s ready to try on some hardware. I have switched to AppArmor because Selinux policy is not production-ready. I actually would have done this from the start, but when I initially looked at the Arch wiki page for App Armor, I saw the section on compiling the kernel and didn’t see that you can just install it normally with a couple kernel parameters… Anyway, I left both options in the script, you can select them by setting a variable at the top.

1 Like

I uncommented the drive-zeroing section for the bare metal test. Taking a long time…

#hailsatan

why zero the drives?

If they’re trimmed SSDs, you’re literally doing nothing but wearing it out.

1 Like

It could very well be some silly arch wiki thing like putting swap on a separate drive from root to avoid data corruption (what?). Let me try and find it.


https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Preparing_the_disk

Preparing the block devices

As explained in dm-crypt/Drive preparation, the devices are wiped with random data utilizing /dev/zero and a crypt device with a random key. Alternatively, you could use dd with /dev/random or /dev/urandom , though it will be much slower.

# cryptsetup open --type plain /dev/md/root container --key-file /dev/random # dd if=/dev/zero of=/dev/mapper/container bs=1M status=progress
# cryptsetup close container

So yeah, maybe that’s just for hard drives? I literally copied/pasted it and didn’t question.

One thing I ran into is that cryptsetup close container sees the device as busy for a few seconds after dd exits, so I put it in a brute force loop:

while ! cryptsetup close 'container'; do; done

TIL, you can:

StandardOutput=journal+console

In a unit file. I was trying to use tty for the first-boot scripts which didn’t work, but console does.

1 Like

@SgtAwesomesauce can I ask a favor? Are you able to install aide from the aur? I’m having pgp issues, but I want to double check that it’s not just me before I hassle the maintainer (again).

Tried multiple keyservers and -vvv on gpg --recv, it just says Server indicated a failure

Can’t imagine why pgp failed to attain ubiquitous adoption…

Sure, what’s your issue, specifically?

via yay but confirmed with gpg

:: PGP keys need importing:
 -> 2BBBD30FAAB29B3253BCFBA6F6947DAB68E7B931, required by: aide
==> Import? [Y/n] y
:: Importing keys with gpg...
gpg: keyserver receive failed: Server indicated a failure
problem importing keys

I broke out my installer into modular config. It’s still very hard coded, but should be easier to adapt this way. Or maybe more importantly, easier to reference.

Haven’t tested yet so it’s likely that something is broken. Still working on the desktop part, so once that’s ready, I’ll run through the whole installation again. It’s just pretty time consuming and I wanted to go ahead and get the structure into the repo first.


Speaking of desktop, I have abandoned awesome in favor of dwm. Once I found dwm-flexipatch, I was able to move much quicker through customizing dwm than awesome, so the choice was clear.

That said, it still takes considerable time to work through customizing dwm and it has turned into my holiday project (been on the forum much less than usual as a result recently).