On 12/11/2014 01:57 PM, Chris Card wrote: >> On 12/11/2014 09:42 AM, Chris Card wrote: >>> >>>> On 12/10/2014 04:54 PM, Chris Card wrote: >>>>> >>>>> >>>>>> >>>>>>> On 12/10/2014 12:57 PM, Chris Card wrote: >>>>>> thanks Martin, >>>>>>>> I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a >>>>>>>> freeipa server and a freeipa client machine. >>>>>>>> I've set up a user with ssh keys, and can successfully ssh onto the >>>>>>>> client machine. >>>>>>>> I'm trying to setup sudo rules so that if the user is in a given user >>>>>>>> group, then the user can run "sudo su -" on the client to become root. >>>>>> <snip> >>>>>>>> [root@fedora21-freeipa log]# ipa hostgroup-show >>>>>>>> Host-group: cog >>>>>>>> Host-group: cog >>>>>>>> Member hosts: ipaclient21.testdomain21.com >>>>>>>> Member of Sudo rule: All >>>>>>>> [root@fedora21-freeipa log]# ipa sudorule-show All >>>>>>>> Rule name: All >>>>>>>> Enabled: TRUE >>>>>>>> Command category: all >>>>>>>> RunAs User category: all >>>>>>>> RunAs Group category: all >>>>>>>> User Groups: cog_rw >>>>>>>> Host Groups: cog >>>>>>>> Sudo Option: !authenticate >>>>>>>> >>>>>>>> but this setup doesn't work, i.e. even though the user is in the user >>>>>>>> group and the client machine is in the host group, sudo su - fails. Is >>>>>>>> this a bug, or have I missed something? >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> With FreeIPA 4.1.1, client sudo integration should be automatically >>>>>>> configured, >>>>>>> so it should just work, including hostgroups. In your case, I would >>>>>>> start with >>>>>>> investigating >>>>>>> >>>>>>> http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups >>>>>>> >>>>>>> If that does not help, I bet SSSD devs will ask for logs. >>>>>>> >>>>>> I've done the troubleshooting steps: >>>>>> >>>>>> [root@ipaclient21 log]# nisdomainname >>>>>> testdomain21.com >>>>>> [root@ipaclient21 log]# getent netgroup cog >>>>>> cog (ipaclient21.testdomain21.com,-,testdomain21.com) >>>>>> >>>>>> I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client >>>>>> machine, but I'm not sure if that's the right file (it didn't exist >>>>>> before). >>>>>> I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some >>>>>> stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error >>>>>> messages. >>>>> >>>>> I worked out how to set up debug for sudo. sudoers_debug is deprecated >>>>> now, but I created /etc/sssd.conf with a line >>>>> >>>>> Debug sudo /var/log/sudo_debug all@debug >>>>> >>>>> and I saw this in the debug output: >>>>> >>>>> Dec 10 15:42:57 sudo[10046] -> sudo_sss_check_host @ ./sssd.c:557 >>>>> Dec 10 15:42:57 sudo[10046] val[0]=+cog >>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches @ ./match_addr.c:189 >>>>> Dec 10 15:42:57 sudo[10046] -> addr_matches_if @ ./match_addr.c:61 >>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches_if @ ./match_addr.c:99 := >>>>> false >>>>> Dec 10 15:42:57 sudo[10046] <- addr_matches @ ./match_addr.c:199 := false >>>>> Dec 10 15:42:57 sudo[10046] -> netgr_matches @ ./match.c:899 >>>>> Dec 10 15:42:57 sudo[10046] <- netgr_matches @ ./match.c:918 := false >>>>> Dec 10 15:42:57 sudo[10046] -> hostname_matches @ ./match.c:758 >>>>> Dec 10 15:42:57 sudo[10046] <- hostname_matches @ ./match.c:769 := false >>>>> Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not >>>>> >>>>> The problem is that the hostname command on the client was returning a >>>>> short hostname, ipaclient21, instead of a FQDN, >>>>> ipaclient21.testdomain21.com and when I forced the hostname to be the >>>>> FQDN the sudo command worked. >>>>> >>>>> >>>>> The short hostname comes from the fact that the client machine is an >>>>> openstack instance, and that appears to be a feature of openstack >>>>> instances :( >>>> >>>> >>>> So on the OpenStack instance, even "hostname -f" does not show the FQDN? If >>>> this is the case, I am not sure what we could do, sudo somehow needs to >>>> learn >>>> the FQDN. >>>> >>> I can set up the instance so that hostname -f returns the FQDN, but the >>> only way I can get hostname to return the FQDN is if I explicitly run >>> "hostname <FQDN>"; unfortunately this doesn't survive a reboot. >> >> You should be able to just set the hostname to /etc/hostname (for older >> platforms, it may also be in /etc/sysconfig/network) and it should survive >> the >> reboot. I do not think that OpenStack really cares that much what hostname >> did >> you set up in the system after the VM is created. >> >> At least my OpenStack VM with the FreeIPA demo works this way. >> > I found that simply editing /etc/hostname and rebooting didn't work, because > cloud-init resets the hostname. But if I create the instance with a > cloud-init script to set the hostname to the FQDN, and then reboot the > instance after creation, /etc/hostname contains the FQDN and hostname returns > the FQDN. > > Chris
Ah, right. I just remembered I also need to set it up with cloud-init. This is the config I use for the FreeIPA demo: #cloud-config: FreeIPA cloud configuration hostname: ipa.demo1.freeipa.org fqdn: ipa.demo1.freeipa.org manage_etc_hosts: false -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project