Bug 963342 - "realmd join kickstart" test case not working
Summary: "realmd join kickstart" test case not working
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: realmd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stef Walter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-15 17:20 UTC by yelley
Modified: 2014-09-15 00:08 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-24 10:51:58 UTC
Type: Bug
Embargoed:


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

Description yelley 2013-05-15 17:20:36 UTC
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 15:42:18 UTC
(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 13:20:01 UTC
(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 14:02:36 UTC
Created attachment 750597 [details]
anaconda.log

Comment 4 yelley 2013-05-20 14:22:15 UTC
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 16:18:43 UTC
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 08:54:44 UTC
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 09:02:01 UTC
(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 15:42:59 UTC
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 10:51:58 UTC
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 14:27:20 UTC
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.