Tag: Improvements

I’m not entirely clear what’s being audited in the Manjaro Linux boxes I’ve recently set up, nor what the difference between res=success and res=failed might mean for the x11vnc unit:

[   98.632347] audit: type=1131 audit(1594859418.419:110): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=x11vnc comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   98.632348] audit: audit_lost=46 audit_rate_limit=0 audit_backlog_limit=64
[   98.632349] audit: kauditd hold queue overflow
[   98.649743] audit: type=1130 audit(1594859418.433:111): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=x11vnc comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
[   98.649745] audit: audit_lost=47 audit_rate_limit=0 audit_backlog_limit=64
[   98.649746] audit: kauditd hold queue overflow
[  100.515527] audit: type=1101 audit(1594859420.299:112): pid=843 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="ed" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'

That’s the better part of two seconds in the life of the box and, later on, the pace picks up. Casual searching suggests nobody else knows what’s going on, either, apart from the fact than that it obviously has something to do with systemd and, thus, is just the way things are these days.

Add audit=off to the default kernel command-line parameters by editing /etc/default/grub thusly:

GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=whatever udev.log_priority=3 audit=off"

Then update the bootloader:

sudo grub-mkconfig -o /boot/grub/grub.cfg 

Whereupon dmesg becomes all quiet and (mostly) meaningful to this civilian.

All our data files spin around on a nearly full 1 TB drive in a “file server”, a grandiosely overqualified and dirt-cheap off-lease Dell Optiplex desktop sitting in the basement. It’s been running headless and unattended for the last half-dozen years and is badly in need of replacement, so I must copy all its files to a newer, even more overqualified, and equally cheap off-lease Optiplex.

Copying the files from the /mnt/music collection on the existing server to the identically named directory on the new server proceeds thusly:

sudo mount -o ro fileserver.local:/mnt/music /mnt/nfs
sudo rsync -ahu --progress --log-file=/tmp/music.log \
 --exclude="/lost+found" \
 --exclude=".Trash*" \
 --exclude=".dtrash*" \
 --delete \
 /mnt/nfs/ /mnt/music

Mount the existing collection (from the old server) in read-only mode to avoid heartache subsequent to confusion. It could happen.

The first time through, add a -n option for a dry run, then inspect the log file for surprises.

The various --exclude options avoid copying trashed-but-not-yet-deleted files from the various trash directories maintained by various file handlers. In the process of sorting this out, I learned the DigiKam photo manager creates a .dtrash directory holding deleted files for each of its Album listings, appearing down near the bottom of the top-level album wherein you’ve quasi-deleted photos via “Move to Trash”.

The --delete option removes files on the destination (new disk) if they’re not on the source (old disk). I started this migration earlier this year, before the world fell apart, and have moved / consolidated / renamed various directories & files in the interim, so deleting the previous copies from their old locations makes the destination match the source.

So far, so good …