The man pages for getent(1) and getpwent(3) don’t help me understand what could be going on. sssd(8) shows me that sssd can cache local users, which actually goes against what I want! The nss section of sssd.conf(5) doesn’t help, but maybe I didn’t take enough time to read it. I’m a little stuck.

Devuan, as a fork of debian that uses sysvinit (or another– your choice), still uses debian-based utilities. I come from the Fedora/Red Hat/CentOS rpm-based family of distributions, and I struggle with the dpkg-based package management on occasion.

I really dislike how the software upgrades will sometimes pause in the middle, to display the changelog. If I wanted a changelog, I’d go read it! When I issue a command to update packages, I want to walk away, and come back, and it be done, not get stuck at 20% because openssh changed some defaults and wants to tell me. It emails me anyway! I find the defaults of apt-get to be not sane.

Here is how to configure apt-get to run without pausing to display duplicate information or ask you questions.

The story

The disk space for /var/log/audit/audit.log tends to get filled up. The audit daemon has an ability to rotate its own logs. See the man page for auditd.conf.

max_log_file = 100
max_log_file_action = rotate

That’s swell and all, until you realize that auditd cannot compress its rotated logs. On a small /var/log/audit mount point, you’ll fill it up with uncompressed logs.

/dev/mapper/os-var_log_audit 2490M 2136M 355M 86% /var/log/audit

So on a RHEL7 system with logrotate, you can adjust logrotate to handle the audit.log file. Now, logrotate is a finicky application. It has caused me many hours of grief in the past.
You would want to set auditd.conf a certain way:

After a few days, I learned that my logs were getting filled up so fast, the weekly rotation wasn’t good enough. So I had to place it in my cron.hourly.
And then I learned that it wasn’t running every hour. I spent a few days investigating, and eventually learned that some systems use a specific status file for logrotate. I remember in the past logrotate needs an execution with a -f flag to force the rotation the first time and add a new file to the status file. So if a new file was never force-rotated, it won’t be added to the status file.
My manual logrotate -f command was indeed adding my audit.log log file to the status file, but to the wrong one!
Some of my systems use -s /var/lib/logrotate/logrotate.status but the default is /var/lib/logrotate.status.
So I had to reflect that in my ansible playbook. Actually, I had to write some logic to find the one used by the cronjob and then use that status file.

So I got the correct logrotate status file set up in the ansible playbook. I spent the next week figuring out that logrotate simply couldn’t rotate the file when called from cron. I piped the utility to tee, and also included the -v flag on logrotate. I saw a permission denied.
With the permission issue, I had no choices left by selinux. I had to use the audit.log file to determine that the audit.log file is not readable by logrotate when called by cron.
I finally set captured all the actions performed by logrotate by setting the selinux process context to be permissive:

semanage permissive -a logrotate_t

I let it run, and then had to collect all the actions it performed, and saw what had happened.

Now, I wrote a master ansible playbook that performs this whole operation, from loading the .te file and compiling it and installing it, to setting logrotate to watch the audit file, and telling auditd to ignore rotating it.Note: It is outside the scope of this task to ensure that the selinux tools are in place on each server. My environment already ensures package libselinux-python is present on each system, which should bring in all the dependencies of this ansible playbook.

I can never remember how the set-gid and sticky bits work on directories, so I finally spent some time to re-read man (but had to resort to info) about chmod. This is my cheat sheet.

set-gid

Setgid (octal permission 2000) makes new files in the directory owned by the group that owns the directory. This is very useful for teams.

How to set

chmod g+s thisdir
chmod 2770 thisdir

How to clear

chmod g-s thisdir
chmod 00770 thisdir

sticky bit, or restricted deletion

Sticky bit (octal permission 1000) on a directory prevents Bob from deleting a file owned by Alice. Even if the directory is owned by one of Bob’s groups and is writable, Bob cannot delete the Alice’s files. This is particulary helpful for the /tmp directory. Check it out:

$ ls -lad /tmp
drwxrwxrwt. 4 root root 120 Jan 23 09:40 /tmp

How to set sticky bit

chmod a+t thisdir
chmod 1770 thisdir

How to clear

chmod a-t thisdir
chmod 00770 thisdir

According to info coreutils chapter 27.4, “Directories and the Set-User-ID and Set-Group-ID Bits,” gnu chmod needs a 5-digit octal to clear this bit.
Basically, if it’s worth setting set-gid, you should throw in sticky bit.

There is a weakness in the repo file delivered by the copr, where it uses the $releasever instead of a static number 23 used by the repo. Davidva compiled the package without a specific fedora version number tied to it, so it will install on any version of Fedora, as long as you can get to the rpm package.
There is also a weakness with a particular library. It’s in the wrong directory, so it cannot be found. You might find an error when trying to compile a project: