Bug 963342 - "realmd join kickstart" test case not working
"realmd join kickstart" test case not working
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: realmd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stef Walter
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-15 13:20 EDT by yelley
Modified: 2014-09-14 20:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-24 06:51:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda.log (11.89 KB, text/plain)
2013-05-20 10:02 EDT, yelley
no flags Details

  None (edit)
Description yelley 2013-05-15 13:20:36 EDT
Description of problem:
When running through the "realmd join kickstart" test case, I am able to boot, install, and reboot the VM. However, "realm list" has no output, indicating that the machine is not joined.

When trying to join manually using "realm join -U Administrator foo.com", it complains that it is unable to resolve foo.com, which makes sense since the /etc/resolv.conf file is not pointing at my AD server. It's not clear to me where I should have specified the IP address of my AD server.

After modifying /etc/resolv.conf to point to my AD server, the "realm join" then complains that PackageKit is not installed. After manually installing Package Kit, the "realm join" command is able to download the other required packages and succesfully join the realm.

Note that I was previously seeing network connectivity issues, in which the VM was unable to install files from http://dl.fedoraproject.org. This was when I had run "systemctl stop firewalld" on my host machine (in order to disable the firewall completely). However, I am finding that disabling firewalld on my host machine results in all outbound traffic from my VMs being blocked (including ping, http, etc). Restarting the firewall, and executing "firewall-cmd --add-service=http" fixed that problem, in that ping and http were now no longer being blocked. It is possible that I need to add additional services to the firewall but I'm not sure which ones.

Version-Release number of selected component (if applicable):
realmd-0.13.91-1.fc19.x86_64 (not the latest version!!)
Comment 1 Stef Walter 2013-05-17 11:42:18 EDT
(In reply to comment #0)
> Description of problem:
> When running through the "realmd join kickstart" test case, I am able to
> boot, install, and reboot the VM. However, "realm list" has no output,
> indicating that the machine is not joined.

It sounds like the machine could not be joined. 

Vratislav, is there an appropriate place this is logged. If not, should we log it appropriately?

> When trying to join manually using "realm join -U Administrator foo.com", it
> complains that it is unable to resolve foo.com, which makes sense since the
> /etc/resolv.conf file is not pointing at my AD server. It's not clear to me
> where I should have specified the IP address of my AD server.

Indeed. I think you can add appropriate entries to your host machine's /etc/resolv.conf. Please see 'man dnsmasq'
> 
> After modifying /etc/resolv.conf to point to my AD server, the "realm join"
> then complains that PackageKit is not installed. After manually installing
> Package Kit, the "realm join" command is able to download the other required
> packages and succesfully join the realm.

The kickstart realmd integration doesn't need PackageKit as anaconda does the install of the necessary packages. Once the network is working.

> Note that I was previously seeing network connectivity issues, in which the
> VM was unable to install files from http://dl.fedoraproject.org. This was
> when I had run "systemctl stop firewalld" on my host machine (in order to
> disable the firewall completely). However, I am finding that disabling
> firewalld on my host machine results in all outbound traffic from my VMs
> being blocked (including ping, http, etc). Restarting the firewall, and
> executing "firewall-cmd --add-service=http" fixed that problem, in that ping
> and http were now no longer being blocked. It is possible that I need to add
> additional services to the firewall but I'm not sure which ones.

I often run 'iptables -F'

> Version-Release number of selected component (if applicable):
> realmd-0.13.91-1.fc19.x86_64 (not the latest version!!)

Please wait for the next anaconda release in anaconda to test with the actual Fedora 19 images.

With the exception of the possible lack of logging, this doesn't sound like a bug.
Comment 2 Vratislav Podzimek 2013-05-20 09:20:01 EDT
(In reply to Stef Walter from comment #1)
> (In reply to comment #0)
> > Description of problem:
> > When running through the "realmd join kickstart" test case, I am able to
> > boot, install, and reboot the VM. However, "realm list" has no output,
> > indicating that the machine is not joined.
> 
> It sounds like the machine could not be joined. 
> 
> Vratislav, is there an appropriate place this is logged. If not, should we
> log it appropriately?
The stderr outputs from calling 'realmd' should all be in the /var/log/anaconda/anaconda.log

Yassir, could you please attach the log?
Comment 3 yelley 2013-05-20 10:02:36 EDT
Created attachment 750597 [details]
anaconda.log
Comment 4 yelley 2013-05-20 10:22:15 EDT
I have attached anaconda.log. I think the relevant excerpt is:

16:21:07,100 INFO anaconda: Discovering realm to join
16:21:07,637 INFO anaconda: Realm discover stderr:
 * Searching for kerberos SRV records for domain: _kerberos._udp.foo.com
 * Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.foo.com
 * Couldn't find kerberos DNS records for: foo.com
realm: No such realm found: foo.com
16:21:07,640 INFO anaconda: Realm discovered: 
16:21:07,640 INFO anaconda: Realm  needs packages realmd

I think the problem is that I did not know of any way to pre-populate the /etc/resolv.conf file to point to the DNS name server on the AD server. Stef mentioned that dnsmasq could be used for this purpose. I'm trying to figure out how to do it. If one of you knows, please let me know.
Comment 5 yelley 2013-05-20 12:18:43 EDT
I just wanted to document my (failed) attempt of trying to solve this problem using dnsmasq. This is what I did:

1) I added the following to /etc/dnsmasq.conf: "address=/foo.com/10.16.189.20"
2) I also had to remove the default "--conf-file=" option for this to work

The reason I thought this might work is because my existing anaconda vm was suddenly able to resolve foo.com when I manually restarted /sbin/dnsmasq (without even having to restart the anaconda vm). The anaconda vm has 192.168.122.1 in its /etc/resolv.conf (which points to dnsmasq, which has 10.16.189.20 as nameserver for foo.com). 

With this in hand, I created a new anaconda2 vm from scratch, hoping that it would automatically be initialized so that it could resolve foo.com (and find the appropriate DNS records). Unfortunately, I am still seeing the same problem with the anaconda2 vm as I was seeing with the original anaconda vm (i.e. "realm list" has no output, PackageKit not installed). The /var/log/anaconda/anaconda.log is identical.

The only difference is that it is able to resolve foo.com after installation (but apparently not during installation??). Curiously, although I am able to manually resolve foo.com ("host foo.com"), the reverse DNS check and SRV checks don't work.
$ host 10.16.189.20
20.189.16.10.in-addr.arpa domain name pointer dhcp-189-20.bos.redhat.com.
[this should say: "... domain name pointer adserver"]

$ host -t SRV _kerberos._udp.foo.com
_kerberos._udp.foo.com has no SRV record

I think merely including the "address" line  in dnsmasq.conf is not adequate. I think we need to somehow modify /etc/resolv.conf itself. Perhaps there is another directive in dnsmasq.conf that can be used. Not sure. I wonder how the testers that were successful with this test case solved this problem (if they were using vms).
Comment 6 Vratislav Podzimek 2013-05-21 04:54:44 EDT
Comment on attachment 750597 [details]
anaconda.log

Hint: set "text/plain" as MIME Type for the .log files. Bugzilla is not good in guessing the type right.
Comment 7 Vratislav Podzimek 2013-05-21 05:02:01 EDT
(In reply to yelley from comment #4)
> I have attached anaconda.log. I think the relevant excerpt is:
> 
> 16:21:07,100 INFO anaconda: Discovering realm to join
> 16:21:07,637 INFO anaconda: Realm discover stderr:
>  * Searching for kerberos SRV records for domain: _kerberos._udp.foo.com
>  * Searching for MSDCS SRV records on domain:
> _kerberos._tcp.dc._msdcs.foo.com
>  * Couldn't find kerberos DNS records for: foo.com
> realm: No such realm found: foo.com
> 16:21:07,640 INFO anaconda: Realm discovered: 
> 16:21:07,640 INFO anaconda: Realm  needs packages realmd
> 
> I think the problem is that I did not know of any way to pre-populate the
> /etc/resolv.conf file to point to the DNS name server on the AD server. Stef
> mentioned that dnsmasq could be used for this purpose. I'm trying to figure
> out how to do it. If one of you knows, please let me know.
Can you use the '--nameserver' option for the 'network' kickstart command? Or do you want to use the nameservers provided by the DHCP and just add one particular entry for the 'foo.com'? For the former case please see the example kickstart I've created [1], for the latter case you can use the '%pre' kickstart section [2] to do that.

[1] http://vpodzime.fedorapeople.org/realm_support_testing/realm_test_ks.cfg
[2] http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_4._Pre-installation_Script
Comment 8 yelley 2013-05-21 11:42:59 EDT
Success!

Using your first option, I added the following line to ks.cfg:
"network --bootproto=static --ip=192.168.122.165 --netmask=255.255.255.0 --gateway=192.168.122.1 --nameserver=10.16.189.20 --hostname=anaconda1"

With this in place, I was able to work through the test case successfully (with the caveat that I had to start sssd manually - a known issue). The realm join had worked, the packages were installed, klist/kinit work fine (although I had to install krb5-workstation for that). Yay!
Comment 9 Stef Walter 2013-05-24 06:51:58 EDT
Cool. Yassir, could you update the test case to add a comment about putting your --nameserver in the case where the domain is not resolveable by the DHCP name server?
Comment 10 yelley 2013-05-24 10:27:20 EDT
I have updated the test case by adding a bullet point to the troubleshooting section.

Note You need to log in before you can comment on or make changes to this bug.