On 3 Dec 2019, at 13:19, Rob Crittenden <rcrit...@redhat.com<mailto:rcrit...@redhat.com>> wrote:
Vinícius Ferrão via FreeIPA-users wrote: Hi Rob, On 3 Dec 2019, at 12:57, Rob Crittenden <rcrit...@redhat.com<mailto:rcrit...@redhat.com> <mailto:rcrit...@redhat.com>> wrote: Vinícius Ferrão via FreeIPA-users wrote: Hello, this is probably to the developers. I’m deploying FreeIPA clients in automated fashion and hit an issue on some ancillary softwares, like ipa-client-automount. After a successful manual join of a FreeIPA client, this command specifically fails, saying that the machine isn’t joined to FreeIPA: "IPA client is not configured on this system”. But if we try to run ipa-client-install, even if I didn’t used it at first time, it says it’s already joined: "IPA client is already configured on this system”. So it’s probably some issue on the checking routines of those softwares. Digging further I was able to nail it down to a specific directory that ipa-client-automount checks during execution: /var/lib/ipa/sysrestore/ This directory is empty when the machine is joined manually. But the verification method used by ipa-client-automount is to look at this directory and get the contents, or the size, of it. I ran the command with strace and there’s a getdents() function called just before the error, so it returns -1 if the directory does not exists and throw up the error. I’ve created the directory. Now getdents() return 0, but it still fails. Touched a random file inside the directory, so getdents() can return something higher than 0. And it worked. Isa-client-automount worked as expected. So, I’m not a Python guy, I tried to read the code for ipa-client-automount and it was beyond my knowledge. The thing is: * Is it a bug? * The check is flawed? * There’s a way to fix this, or any workaround that I’m missing? * Should I make ipa-client-automount manually too? * Should I open some bug fix request? ipa-client-automount has assumptions on a properly configured client which is provided by ipa-client-install hence the enforcement. I’ve followed this guide: https://access.redhat.com/articles/2622831 with some modifications, I even commented on this page since some steps are missing. Basically I was able to recreate manually all the files changed by ipa-client-install. The workaround is what you found, add a file to /var/lib/ipa/sysrestore/. Supporting manual installations is not something we'd likely do. I thought it was supported, since there’s an IdM article on redhat.com<http://redhat.com> <http://redhat.com> ipa-client-automount running against a manual configuration is not supported or tested. I suppose the question is: why are you manually configuring the system instead of using ipa-client-install? Well, that’s a long story :) But to be honest, I’m developing an HPC product and FreeIPA (or Red Hat IdM) is the central authentication platform for the product. We have some additional tools, and one of them is the thing that we call the provisioner. It’s almost like Foreman but it supports stateless machines. Machines that boots on the server, get an initramfs and runs from RAM without local disks. The initramfs is packaged from an image. So that’s why I’m manually configuring the hosts. Because they don’t have states on the nodes. I can run ipa-client-install everytime a node boot, but it’s prone to failure since I need to run —force-join and some things might get messy. For instance, the SSH host keys changing at every reboot will break Hostbased Authentication in the product, and there’s another annoyances that happens when always rejoining during boot. I think we'd need more info on this. I'm not sure how SSH host keys are related to HBAC but you can use --no-dns-sshfp to not create DNS SSH records, for example. Sorry, this is always a source of confusion. It’s not HBAC from FreeIPA/IdM. I was referring to SSH Hostbased Authentication, so the host can authenticate with another host. It’s a common thing on HPC systems, so the users don’t need SSH Public Keys to authenticate without password on the nodes nor I need shared storage to hold the keys on every machine. I opened an issue some weeks ago about sssd not supporting this for what I’m looking for: https://pagure.io/SSSD/sssd/issue/4106 That’s why I’m joining manually. The files are already burned in on the image. And the next thing to do is touch a file on /var/lib/ipa/sysrestore inside the image, since this appears to be expected and not a bug... As described, it's a workaround. You are doing manual things, this is one more manual thing if you want to run ipa-client-automount. Any advice that you guys recommend? rob Thanks again Rob. I think this summarise everything. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org<mailto:freeipa-users-le...@lists.fedorahosted.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
