Skip to main content

Posts

Showing posts from September, 2023

Foreman - Configure dhcp-proxy using the remote_isc plugin

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

AWX - upgrade awx using the operator

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

SSSD - sudo authentication fails with '4 (System error)'

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.

Ansible - copy and template to cifs shares with selinux enabled

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: