Hi Rob, On 3 Dec 2019, at 12:57, Rob Crittenden <[email protected]<mailto:[email protected]>> 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> 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. 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... Any advice that you guys recommend? Thanks, rob
_______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
