Walt Disney said it best:
We keep moving forward, opening new doors, and doing new things, because we’re curious and curiosity keeps leading us down new paths.
The world of technology is all about change. We tear down the old things that get in our way and we build new technology that takes us to new heights. Tearing down these old things can often be difficult and that forces us to make difficult choices.
After a recent OpenStack-Ansible (OSA) deployment on CentOS, I found that keepalived was not starting properly at boot time:
Keepalived_vrrp: Cant find interface br-mgmt for vrrp_instance internal !!! Keepalived_vrrp: Truncating auth_pass to 8 characters Keepalived_vrrp: VRRP is trying to assign ip address 172.29.236.11/32 to unknown br-mgmt interface !!! go out and fix your conf !!! Keepalived_vrrp: Cant find interface br-mgmt for vrrp_instance external !!! Keepalived_vrrp: Truncating auth_pass to 8 characters Keepalived_vrrp: VRRP is trying to assign ip address 192.
The latest release of the Red Hat Enterprise Linux Security Technical Implementation Guide (STIG) was published last week. This release is Version 1, Release 3, and it contains four main changes:
V-77819 - Multifactor authentication is required for graphical logins V-77821 - Datagram Congestion Control Protocol (DCCP) kernel module must be disabled V-77823 - Single user mode must require user authentication V-77825 - Address space layout randomization (ASLR) must be enabled Deep dive Let’s break down this list to understand what each one means.
I’ve been working through some patches to OpenStack-Ansible lately to optimize how we configure yum repositories in our deployments. During that work, I ran into some issues where pgp.mit.edu was returning 500 errors for some requests to retrieve GPG keys.
Ansible was returning this error:
curl: (22) The requested URL returned error: 502 Proxy Error error: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x61E8806C
: import read failed(2) How does the rpm command know which keyserver to use? Let’s use the –showrc argument to show how it is configured:
I merged some initial Debian support into the openstack-ansible-security role and ran into an issue enabling AppArmor. The apparmor service failed to start and I found this output in the system journal:
kernel: AppArmor: AppArmor disabled by boot time parameter Digging in That was unexpected. I was using the Debian jessie cloud image and it uses extlinux as the bootloader. The file didn’t reference AppArmor at all:
cat /boot/extlinux/extlinux.conf default linux timeout 1 label linux kernel boot/vmlinuz-3.