Archy's Blog

I have run my foreman-server up until recently without the dhcp-capsule feature enabled but I decided to change that to have proper integration so here's a quick how-to: First, generate the omapi_key and get the hash: [root@dhcp ~]# dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 512 -n HOST omapi_key [root@dhcp ~]# grep -iE '^Key' Komapi_key*.private | cut -d ' ' -f 2- Now, prepare the dhcp-server config by appending these options: [root@dhcp ~]# vim /etc/dhcp/dhcpd.conf omapi-port 7911; key omapi_key { algorithm HMAC-MD5; secret "hash-from-command-gathered-earlier"; }; omapi-key omapi_key; Change the permissions for the dhcp folder and config file: [root@dhcp ~]# chmod o+rx /etc/dhcp/ [root@dhcp ~]# chmod o+r /etc/dhcp/dhcpd.conf According to Red Hat's Documentation, the bindmounts are necessary: [root@dhcp ~]# vim /etc/fstab /var/lib/dhcpd /exports/var/lib/dhcpd none bind,auto 0 0 /etc/dhcp /exports/etc/dhcp ...

Upgrading AWX is made very simple when using the operator since it just requires changing the version of the deployment. I'll be using a awx-deployment in okd-4.13 using the awx operator installed using these yaml files: $ cat 0-awx-namespace.yml --- apiVersion: v1 kind: Namespace metadata: name: awx ... $ cat 1-awx-operatorgroup.yml --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: awx-operatorgroup namespace: awx spec: upgradeStrategy: Default targetNamespaces: - awx ... $ cat 2-awx-subscription.yml --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: awx-operator namespace: awx spec: channel: alpha installPlanApproval: Automatic name: awx-operator source: community-operators sourceNamespace: openshift-marketplace startingCSV: awx-operator.v2.5.3 ... $ cat 4-awx-deployment.yml --- apiVersion: awx.ansib...

There is this strange error where sssd allows logins using gssapi but does not permit sudo and instead writes the dreaded '4 (System error)' to /var/log/secure: Sep 7 10:48:30 server sudo[676183]: pam_sss(sudo:auth): authentication failure; logname=archy uid=103600028 euid=0 tty=/dev/pts/0 ruser=archy rhost= user=archy Sep 7 10:48:30 server sudo[676183]: pam_sss(sudo:auth): received for user archy: 4 (System error) In my case, it was old kerberos tickets that were not deleted. So The fix should be really simple: [archy@server ~]$ kdestroy -A [archy@server ~]$ kinit Troubleshooting steps that might be of interest might be the date / time, hbac rules and the sssd-cache. [root@server ~]# sudo sssctl cache-expire -E [root@server ~]# sudo systemctl restart sssd.service Feel free to comment and / or suggest a topic.

With current ansible versions, the following modules will result in a error if the destination is on a cifs share using systems that have selinux enabled ansible.builtin.copy ansible.builtin.template The error in question: invalid selinux context: [Errno 95] Operation not supported A possible workaround could be to first create the file using 'ansible.builtin.file' with 'state=touch' which would allow the file to be changed later on. Example: - name: ensure empty files are present with:_items: "{{ files_to_copy + files_to_template }}" ansible.builtin.file: path: "{{ item['dest'] }}" state: touch Depending on the structure of your playbooks, this task could go into the 'pre_tasks' section of your playbook, example for a full playbook: --- - name: test hosts: test user: root gather_facts: false collections: - ansible.posix - community.general vars: src_dir:...