On 12/11/2014 04:38 PM, Dmitri Pal wrote:
On 12/11/2014 08:08 AM, Martin Kosek wrote:
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.
[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?


With FreeIPA 4.1.1, client sudo integration should be automatically
so it should just work, including hostgroups. In your case, I would
start with


If that does not help, I bet SSSD devs will ask for logs.

I've done the troubleshooting steps:

[root@ipaclient21 log]# nisdomainname
[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
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
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
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.

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

Is it worth a howto? Seems like  a valuable piece of info...

It is, I added a task to my queue about generating howto with this and other updates I had to do to make FreeIPA demo run on OpenStack.

Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to