Skip to main content

Posts

Showing posts from September, 2021

Foreman - Automatic group membership using the 'External' auth provider

Foreman can utilize User Groups and Mappings to automatically assign permissions to users based on their external group membership. I'll be using the 'External' authentication source as well as FreeIPA as my external provider. In order for this to work, the foreman server will have to have ipa authentication enabled as well as be enrolled in the ipa-domain. First, create the required groups in FreeIPA: [archy@ipa02 ~]$ ipa group-add foreman-admins Add the required users to the group you've just created: [archy@ipa02 ~]$ ipa group-add-member foreman-admins --users 'archy' The freeipa side of this setup is done with that. Next, ensure the foreman's /etc/sssd/sssd.conf contains the following sections for the [ifp] section otherwise you might get 'User not in ACL\n' errors in your http error log: [ifp] allowed_uids = apache, root user_attributes=+email, +firstname, +lastname If you had to change the configuration, make sure to restart sssd

Kubernetes - DNS Lookups timeout on nodes where a coredns pod is running on

I've encountered this very strange problem that DNS resolution from pods would only work if no coredns pod was running on it. I'm using the dnsPolicy 'clusterFirst' for pretty much everything and 'Default' on my coredns deployments. Here are some debugging commands worth mentioning: [archy@kube-master01 ~]$ kubectl -n kube-system logs -f deployments/coredns [archy@kube-master01 ~]$ kubectl -n kube-system describe -f deployments/coredns In the end, it boiled down to 'br_netfilter' not being loaded properly. To fix that, create the directory '/etc/modules-load.d' which is a dependency for systemd-modules-load.service [archy@kube-master01 ~]$ sudo mkdir -m '0755' /etc/modules-load.d Now create a file with the name of the module in /etc/modules-load.d [archy@kube-master01 ~]$ echo 'br_netfilter' | sudo tee /etc/modules-load.d/br_netfilter.conf Last, ensure the systemd-load-modules.service is started and enabled to load mod

Ansible - Using 'selectattr()' to use one specific item from a list

Sometimes one specific item in a list needs special treatment or should be used in a different way. In ansible, one method would be to use the 'selectattr()' filter which basically works like a if statement in python looking for a specific attribute value. Here's a code snippet using selectattr to download one specific artifact from a list of artifacts - name: download newest specific artifact loop: "{{ application_artifacts | selectattr('artifact', 'match', application1) | list }}" maven_artifact: group_id: "{{ item.group }}" artifact_id: "{{ item.artifact }}" classifier: "{{ item.classifier }}" extensions: "{{ item.extensions }}" version. "{{ item.version }}" repository_url: "{{ item.repourl }}" dest: /tmp/ validate_certs: false tags: - deploy_artifacts - deploy_application The advantage here would be

OpenSSH - Ignore user's .ssh/authorized_keys and pull them from FreeIPA instead

This will likely only be interesting to you if you have your users stored centrally using some form of centralized identity management such as OpenLDAP, 389ds, or FreeIPA which again uses 389ds in the background. I'll configure SSHD to ignore each user's .ssh/authorized_keys file with the only exception being root. SSH-Keys for users will be stored in FreeIPA which can be managed using the 'freeipa.ansible_freeipa' modules and git for example. First, make sure your host is enrolled in FreeIPA [root@host ~]# ipa-client-install --mkhomedir --enable-dns-updates Now that your client is enrolled, let's try querying a user that exists in the ldap tree [root@host ~]# $ executor uid=10007(executor) gid=10007(executor) groups=10007(executor),10011(ansible-users) The ipa-client will automatically configure the 'AuthorizedKeysCommand' and 'AuthorizedKeysCommandUser' options which you could change to some self-written helper script if absolutely require