Bug 1006611

This issue is a bug in sudo, there is a bug filed 1000389. Dan, do you plan fixing this in Fedora 19 any time soon?

Hi,
I still think it is a duplicate of [1].

Can you send me output of following commands please?

$ nisdomainname
$ getent netgroup desktops
$ cat /etc/nsswitch.conf | grep netgroup

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1000389

[dean@desktop2 ~]$ nisdomainname
nisdomainname: Local domain name not set

[dean@desktop2 ~]$ getent netgroup desktops
desktops             

[dean@desktop2 ~]$ cat /etc/nsswitch.conf | grep netgroup
netgroup:   files sss

[dean@desktop2 ~]$

(In reply to Dean Hunter from comment #3)
> [dean@desktop2 ~]$ nisdomainname
> nisdomainname: Local domain name not set

You need to correctly set nisdomainname in order to use netgroups (hostgroups) with sudo.

(In reply to Dean Hunter from comment #3)
> [dean@desktop2 ~]$ getent netgroup desktops
> desktops

You can see here that the hostgroup is currently empty. (This proofs that it is a duplicate of 1000389.)

(In reply to Dean Hunter from comment #0)
>   ipa hostgroup-add            desktops       --desc "Desktops"
>   ipa automember-add           desktops       --type=hostgroup
>   ipa automember-add-condition desktops       --type=hostgroup \\
>                                               --key=fqdn \\
>                                               --inclusive-regex='\.hunter\.org$'

I'm not very familiar with automember, but I think it will not automatically include existing hosts in hostgroup, only newly added hosts. In other words, you need to manually include client machine in the hostgroup.

Martin, can you check the ipa commands please and tell if my suspicion is correct?

(In reply to Pavel Březina from comment #4)
> (In reply to Dean Hunter from comment #0)
> >   ipa hostgroup-add            desktops       --desc "Desktops"
> >   ipa automember-add           desktops       --type=hostgroup
> >   ipa automember-add-condition desktops       --type=hostgroup \\
> >                                               --key=fqdn \\
> >                                               --inclusive-regex='\.hunter\.org$'
> 
> I'm not very familiar with automember, but I think it will not automatically
> include existing hosts in hostgroup, only newly added hosts. In other words,
> you need to manually include client machine in the hostgroup.
> 
> Martin, can you check the ipa commands please and tell if my suspicion is
> correct?

This is correct. Automember rules only affects new LDAP entries (hosts). If you want to apply the rules also for existing entries, you would need to trigger a special task.

If you want to get more information about the automember tasks, see
https://fedorahosted.org/freeipa/ticket/3752 for RFE to improve add an API to add the automember task
https://fedorahosted.org/389/ticket/20#comment:10 for examples how to trigger the automember task by LDIF

How do I set nisdomainname?

# nisdomainname example.com

[dean@desktop2 ~]$ nisdomainname hunter.org

[dean@desktop2 ~]$ nisdomainname
hunter.org

[dean@desktop2 ~]$ getent netgroup desktops
desktops              (desktop2.hunter.org,-,hunter.org)

[dean@desktop2 ~]$ grep netgroup /etc/nsswitch.conf
netgroup:   files sss

The problem has been resolved.  

This rule now works as desired:

  ipa group-add                desktop-admins --desc "Desktop Administrators"
  ipa group-add-member         desktop-admins --users dean

  ipa hostgroup-add            desktops       --desc "Desktops"
  ipa automember-add           desktops       --type=hostgroup
  ipa automember-add-condition desktops       --type=hostgroup \\
                                              --key=fqdn \\
                                              --inclusive-regex='\.hunter\.org$'

  ipa sudorule-add             desktop-admins --desc "Desktop Administrators"
  ipa sudorule-mod             desktop-admins --cmdcat all
  ipa sudorule-add-host        desktop-admins --hostgroups desktops
  ipa sudorule-add-option      desktop-admins --sudooption '!authenticate'
  ipa sudorule-add-runasuser   desktop-admins --users root
  ipa sudorule-add-runasgroup  desktop-admins --groups root
  ipa sudorule-add-user        desktop-admins --groups desktop-admins

The requirement for nisdomainname to be set is really not documented very well.  I had seen discussions about sudo rules and host groups on the freeipa-users mailing list but did not understand the discussions until now.  I even asked the mailing list for the latest documentation, but I can not see that this requirement was in any of the references.  So for the next person I offer this script as my solution to configuring a client for IPA and sudo:

# Configure the sssd-sudo client for Fedora 18 or 19

  domainname=$(awk '/^ipa_domain/{print $3}' /etc/sssd/sssd.conf)
  nisdomainname $domainname

  if uname -r | grep fc18 &>/dev/null
  then
    yum --assumeyes install libsss_sudo
  fi

  sed --in-place \
    '/^services:/i sudoers:    files sss' \
    /etc/nsswitch.conf

  sed --in-place \
    '/^services/s/ssh/ssh, sudo/' \
    /etc/sssd/sssd.conf

  if uname -r | grep fc18 &>/dev/null
  then
    hostname=$(awk '/^ipa_hostname/{print $3}' /etc/sssd/sssd.conf)
    server=$(awk '/^ipa_server/{print $3}' /etc/sssd/sssd.conf)
    
    if [ "$server" = "_srv_," ]
    then
      server=$(awk '/^ipa_server/{print $4}' /etc/sssd/sssd.conf)
    fi

    cat >/tmp/sssd <<EOD
krb5_server = $server
ldap_sasl_authid = host/$hostname
ldap_sasl_mech = GSSAPI
ldap_sasl_realm = EXAMPLE.COM
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_uri = ldap://$server
sudo_provider = ldap
EOD

    sed -i '/^\[domain\/hunter.org\]/r /tmp/sssd' /etc/sssd/sssd.conf
  fi

  systemctl restart sssd.service

(In reply to Rob Crittenden from comment #7)
> # nisdomainname example.com

How do I set nisdomainname so that it persists across an operating system restart?

# echo "NISDOMAIN=xxx" >> /etc/sysconfig/network

...should do the trick.

Thank you.  That takes care of my problem, except for the documentation.

http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/example-configuring-sudo.html

Step 6, e, b.

Why do you pick one line, that is not sufficient, out of a page that is labeled as applying to Fedora 18 but uses an example from an earlier version of IPA that is not available for Fedora 18 and contains many instructions that no longer apply?

This example specifically configures a Fedora 2.2 client for sudo rules. The configuration file in step d is different, depending on the platform. 

How is someone new to IPA supposed to separate the wheat from the chaff?  Please update the documentation to something that more closely resembles the discoveries of this bug report.

I am sorry folks, but I still do not seem to have it right:

reboot

Login to Gnome on ipa2 as dean

Open a terminal

[dean@ipa2 ~]$ sudo -l
sudo: internal error, tried to erealloc3(0)

[dean@ipa2 ~]$ nisdomainname
nisdomainname: Local domain name not set

[dean@ipa2 ~]$ su -
Password: 

[root@ipa2 ~]# cat /etc/sysconfig/network
# Generated by anaconda
NETWORKING=yes
NISDOMAIN=hunter.org

[root@ipa2 ~]#

> 
> How is someone new to IPA supposed to separate the wheat from the chaff? 
> Please update the documentation to something that more closely resembles the
> discoveries of this bug report.

You are right, we have issues with documentation, but we are also quit thinly stretched supporting people in the community.

Are you willing to spend your cycles contributing to improvement of the upstream documentation? If you are interested we can talk more details offline. You have my email.

Please help, I do not know what I am doing wrong:

[root@ipa2 ~]# reboot
Write failed: Broken pipe

[dean@host ~]$ sudo ssh root@ipa2
Last login: Wed Sep 18 09:25:49 2013 from host.hunter.org

[root@ipa2 ~]# nisdomainname
nisdomainname: Local domain name not set

[root@ipa2 ~]# cat /etc/rc.d//rc.local
nisdomainname hunter.org

[root@ipa2 ~]#

Do you have rc-local.service enabled in systemd? It is their equivalent of rc.local processing in SysV.

What does

 systemctl status rc-local.service

say?

Thank you.  Your clue led me to a new series of Google queries and more arcane system administrator knowledge.

[dean@host ~]$ sudo ssh root@ipa2 reboot
Write failed: Broken pipe

[dean@host ~]$ sudo ssh -X root@ipa2
Last login: Wed Sep 18 12:21:48 2013 from host.hunter.org

[root@ipa2 ~]# nisdomainname
hunter.org

[root@ipa2 ~]# hostname --nis
hunter.org

[root@ipa2 ~]# ls -lZ /etc/rc.d/rc.local
-rwxr-xr-x. root root unconfined_u:object_r:initrc_exec_t:s0 /etc/rc.d/rc.local

[root@ipa2 ~]# cat /etc/rc.d/rc.local
#!/usr/bin/bash

nisdomainname hunter.org

[root@ipa2 ~]# systemctl status rc-local.service
rc-local.service - /etc/rc.d/rc.local Compatibility
   Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
   Active: active (exited) since Wed 2013-09-18 12:23:42 CDT; 1min 20s ago
  Process: 625 ExecStart=/etc/rc.d/rc.local start (code=exited, status=0/SUCCESS)

Sep 18 12:23:42 ipa2.hunter.org systemd[1]: Starting /etc/rc.d/rc.local Comp....
Sep 18 12:23:42 ipa2.hunter.org systemd[1]: Started /etc/rc.d/rc.local Compa....
[root@ipa2 ~]# 

Is the requirement for setting nisdomainname in /etc/rc.d/rc.local one of IPA's phased implementation steps?  I am concerned that several sources stated that  rc-local.service is something to be avoided in favor of a specifically designed service.

This is not really IPA-specific in Fedora as NIS services might be provided by other implementations too.

I think we need to introduce a separate service that would be enabled in compat plugin is enabled or if ypbind service is enabled. For IPA case it should be handled by ipa-client-install -- once we get sudo configuration support there.

Using rc-local.service is one of workarounds right now.

It would make sense to add this information to the IPA ticket regarding sudo integration.

Is there a ticket I can watch for adding sudo configuration to ipa-client-install?

FYI, Here is what I have now for sudo configuration:

#!/usr/bin/bash

  set -v

# Configure the sssd-sudo client for Fedora 18 or 19

  if uname -r | grep fc18
  then
    yum --assumeyes install libsss_sudo
  fi

  sed --in-place \
    '/^services:/a sudoers:    files sss' \
    /etc/nsswitch.conf

  sed --in-place \
    '/^services/s/ssh/ssh, sudo/' \
    /etc/sssd/sssd.conf

  if uname -r | grep fc18
  then
    hostname=$(awk '/^ipa_hostname/{print $3}' /etc/sssd/sssd.conf)
    server=$(awk '/^ipa_server/{print $3}' /etc/sssd/sssd.conf)
    
    if [ "$server" = "_srv_," ]
    then
      server=$(awk '/^ipa_server/{print $4}' /etc/sssd/sssd.conf)
    fi

    cat >/tmp/sssd <<EOD
krb5_server = $server
ldap_sasl_authid = host/$hostname
ldap_sasl_mech = GSSAPI
ldap_sasl_realm = HUNTER.ORG
ldap_sudo_search_base = ou=sudoers,dc=hunter,dc=org
ldap_uri = ldap://$server
sudo_provider = ldap
EOD

    sed -i '/^\[domain\/hunter.org\]/r /tmp/sssd' /etc/sssd/sssd.conf
  fi

  systemctl restart sssd.service

  domainname=$(awk '/^ipa_domain/{print $3}' /etc/sssd/sssd.conf)

  if [ -f /etc/rc.d/rc.local ]
  then
    cat >/etc/rc.d/rc.local <<EOD
nisdomainname $domainname
EOD
  else
    cat >/etc/rc.d/rc.local <<EOD
#!/usr/bin/bash

nisdomainname $domainname
EOD

    chmod 755 /etc/rc.d/rc.local
    restorecon -v /etc/rc.d/rc.local
  fi

Here is IPA ticket: https://fedorahosted.org/freeipa/ticket/3358
SSSD has a ticket for native IPA sudo support: https://fedorahosted.org/sssd/ticket/1108

Changing component to sudo.

sudo-1.8.11-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sudo-1.8.11-1.fc20

Package sudo-1.8.11-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sudo-1.8.11-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-11928/sudo-1.8.11-1.fc20
then log in and leave karma (feedback).

sudo-1.8.11p2-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sudo-1.8.11p2-1.fc20

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

sudo-1.8.12-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sudo-1.8.12-1.fc20

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

sudo-1.8.12-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.