> 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 -- 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