[Freeipa-users] DNS configuration
Matthew Herzog
matthew.herzog at gmail.com
Mon Dec 8 19:27:00 UTC 2014
OK, I found the generated zoe file in /tmp and it looks sane.
Should I add those lines of config to our DNS servers?
On Mon, Dec 8, 2014 at 2:10 PM, Matthew Herzog <matthew.herzog at gmail.com>
wrote:
> Here are some errors I'm seeing on the client.
>
> tail -f sssd_lnx.e-bozo.com.log
> (Mon Dec 8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): dbus conn: 0x1e72ad0
> (Mon Dec 8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): Dispatching.
> (Mon Dec 8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_message_handler] (0x4000): Received SBUS method [ping]
> (Mon Dec 8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
> (Mon Dec 8 14:03:20 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
> (Mon Dec 8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): dbus conn: 0x1e72ad0
> (Mon Dec 8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): Dispatching.
> (Mon Dec 8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_message_handler] (0x4000): Received SBUS method [ping]
> (Mon Dec 8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
> (Mon Dec 8 14:03:30 2014) [sssd[be[lnx.e-bozo.com]]]
> [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping]
> (Mon Dec 8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): dbus conn: 0x1e72ad0
> (Mon Dec 8 14:03:40 2014) [sssd[be[lnx.e-bozo.com]]] [sbus_dispatch]
> (0x4000): Dispatching.
>
> [root at freeipa-poc-client02 sssd]# tail -f sssd_ssh.log
> (Sun Dec 7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
> sss_process_init() failed
> (Sun Dec 7 19:32:09 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
> connect to monitor services.
> (Sun Dec 7 19:32:09 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
> error setting up backend connector
> (Sun Dec 7 19:32:09 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
> sss_process_init() failed
> (Sun Dec 7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
> connect to monitor services.
> (Sun Dec 7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
> error setting up backend connector
> (Sun Dec 7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
> sss_process_init() failed
> (Sun Dec 7 19:32:16 2014) [sssd[ssh]] [sss_dp_init] (0x0010): Failed to
> connect to monitor services.
> (Sun Dec 7 19:32:16 2014) [sssd[ssh]] [sss_process_init] (0x0010): fatal
> error setting up backend connector
> (Sun Dec 7 19:32:16 2014) [sssd[ssh]] [ssh_process_init] (0x0010):
> sss_process_init() failed
>
>
> On Mon, Dec 8, 2014 at 11:48 AM, Matthew Herzog <matthew.herzog at gmail.com>
> wrote:
>
>> I have never seen my IPA servers produce a zone file nor has the install
>> script ever mentioned the creation of such. In fact, I just ran
>> ipa-server-install --uninstall && ipa-server-install and there was no
>> mention of a zone file.
>>
>> Where should I look in the file system to be sure? I see nothing in
>> /var/named. I'm using 3.3.3 IPA on Oracle Linux from Oracle's yum repo.
>> (Not my choice.)
>>
>> dsee7 is *not *running Kerberos. dsee7 is *not *configured with SRV
>> records. I guess I'll need to add SRV records for all my Linux hosts.
>>
>>
>>
>>
>>
>>
>> On Mon, Dec 8, 2014 at 10:41 AM, Petr Spacek <pspacek at redhat.com> wrote:
>>
>>> On 8.12.2014 14:44, Matthew Herzog wrote:
>>> > Petr said, "You can run ipa-server-install *without* --setup-dns
>>> option and
>>> > at the end of
>>> > installation it will produce DNS records which you have to manually
>>> add to
>>> > your existing DNS database."
>>> >
>>> > I can't see how this would be useful or which machines I would need to
>>> add
>>> > to our DNS.
>>> >
>>> > Perhaps I should have explained that we are not going to set up a new
>>> DNS
>>> > domain for the ipa-managed servers.
>>> Good.
>>>
>>> Now you should run ipa-server-install *without* --setup-dns, using
>>> lnx.e-bozo.com as you IPA domain. It will install full IPA server and
>>> spit out
>>> DNS zone file.
>>>
>>> Then you *have to* take this zone file and import it to your existing DNS
>>> infrastructure - that will give you fully functional IPA domain
>>> lnx.e-bozo.com.
>>>
>>> Caveat:
>>> Preceding text assumes that 'dsee7' is nor using either Kerberos nor DNS
>>> SRV
>>> records for LDAP service in domain lnx.e-bozo.com, i.e. clients
>>> connecting to
>>> DSEE7 should be (most likely) statically configured with DSEE7 server
>>> name.
>>>
>>> Petr^2 Spacek
>>>
>>> > We have an Oracle dsee7 server doing
>>> > LDAP for our Linux servers and accounts. We want to migrate to IPA so
>>> we
>>> > don't have to maintain a Linux/LDAP account for every user who needs
>>> access
>>> > to Linux servers. All of our users start with an account in AD and
>>> since
>>> > none of my predecessors knew about Winbind, they set up dsee7.
>>> >
>>> > So I'm thinking we'll need to import all our dsee7 accounts AND make it
>>> > possible for AD users to access the Linux systems without needing to
>>> create
>>> > them in IPA.
>>> >
>>> > On Mon, Dec 8, 2014 at 2:56 AM, Petr Spacek <pspacek at redhat.com>
>>> wrote:
>>> >
>>> >> On 8.12.2014 05:02, Dmitri Pal wrote:
>>> >>> On 12/07/2014 10:10 PM, Matthew Herzog wrote:
>>> >>>> So should the FreeIPA server be authoritative for the Kerb.
>>> realm/DNS
>>> >> domain
>>> >>>> or can it/should it be a slave DNS server instead? Or caching only?
>>> >>>
>>> >>> IPA DNS can't be a slave so you either delegate a whole zone to it or
>>> >> manage
>>> >>> IPA DNS domain via your own DNS server.
>>> >>
>>> >> Generally, "slave" is not allowed to do any changes so it is useless
>>> in
>>> >> your
>>> >> scenario.
>>> >>
>>> >> You can run ipa-server-install *without* --setup-dns option and at
>>> the end
>>> >> of
>>> >> installation it will produce DNS records which you have to manually
>>> add to
>>> >> your existing DNS database.
>>> >>
>>> >> Did you try that?
>>> >>
>>> >> Petr^2 Spacek
>>> >>
>>> >>>> On Sun, Dec 7, 2014 at 9:57 PM, Dmitri Pal <dpal at redhat.com
>>> >>>> <mailto:dpal at redhat.com>> wrote:
>>> >>>>
>>> >>>> On 12/07/2014 09:51 PM, Matthew Herzog wrote:
>>> >>>>> What must be done in or on the ipa server with regard to DNS,
>>> if
>>> >>>>> anything?
>>> >>>>>
>>> >>>>> Our DNS works. It works well. We have four Linux DNS servers
>>> and
>>> >>>>> two AD domain controllers that also do DNS.
>>> >>>>>
>>> >>>>> So if we already have DNS working well in our domain, why do we
>>> >>>>> want to manage DNS in IPA?
>>> >>>>
>>> >>>> Let us keep the discussion on the list.
>>> >>>> IPA when used with AD trust presents itself as a separate
>>> forest.
>>> >>>> AD thinks that it is working with another AD forest.
>>> >>>> For that to work we need to follow MSFT rules about relationship
>>> >>>> between Kerberos realm and DNS domain.
>>> >>>> AD assumes that for every trusted forest Kerberos realm = DNS
>>> >>>> domain. IPA makes it easy to do because it has integrated tools
>>> to
>>> >>>> manage IPA DNS domain.
>>> >>>> If you want to manage it yourself through your DNS you can do
>>> it,
>>> >>>> just more manual operations for you.
>>> >>>>
>>> >>>> HTH
>>> >>>>
>>> >>>> Thanks
>>> >>>> Dmitri
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>>> On Sun, Dec 7, 2014 at 9:44 PM, Dmitri Pal <dpal at redhat.com
>>> >>>>> <mailto:dpal at redhat.com>> wrote:
>>> >>>>>
>>> >>>>> On 12/07/2014 06:44 PM, Matthew Herzog wrote:
>>> >>>>>> Thanks guys. I'm sorry for my delay in responding.
>>> >>>>>>
>>> >>>>>> Firstly, I was under the impression (from reading the
>>> docs)
>>> >>>>>> that having named running on IPA server was critical.
>>> >>>>>
>>> >>>>> Properly configured DNS is critical.
>>> >>>>> How you accomplish it is up to you.
>>> >>>>> IPA allows you to have a DNS server that would simplify DNS
>>> >>>>> management but it can be done manually too. This is why DNS
>>> >>>>> is optional.
>>> >>>>>
>>> >>>>>
>>> >>>>>> Also, the first question the ipa-server-install script
>>> asks
>>> >>>>>> is, "Do you want to configure integrated DNS (BIND)? ."
>>> >>>>>> While it's true the default answer is no, it leads one to
>>> >>>>>> believe that DNS is central to IPA. Also the
>>> >>>>>> ipa-client-install script says,
>>> >>>>>>
>>> >>>>>> [root at freeipa-poc-client02 ~]# ipa-client-install
>>> >>>>>> DNS discovery failed to determine your DNS domain
>>> >>>>>> Provide the domain name of your IPA server (ex:
>>> example.com
>>> >>>>>> <http://example.com>):
>>> >>>>>>
>>> >>>>>> I can resolve -anything- from the machine using dig or
>>> >> whatever.
>>> >>>>>>
>>> >>>>>> Ultimately, the reason I started to be concerned about my
>>> >>>>>> IPA server's DNS config was because I was not able to
>>> >>>>>> authenticate AD accounts to a client machine. I saw a
>>> bunch
>>> >>>>>> of errors in the client's sssd logs which of course I
>>> can't
>>> >>>>>> find now.
>>> >>>>>>
>>> >>>>>> Perhaps it was these . . .
>>> >>>>>>
>>> >>>>>> (Thu Dec 4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>> Service nss replied to ping
>>> >>>>>> (Thu Dec 4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>> Service sudo replied to ping
>>> >>>>>> (Thu Dec 4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>> Service pam replied to ping
>>> >>>>>> (Thu Dec 4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>> Service ssh replied to ping
>>> >>>>>> (Thu Dec 4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>> Service pac replied to ping
>>> >>>>>> (Thu Dec 4 13:45:23 2014) [sssd] [ping_check] (0x0100):
>>> >>>>>> Service bo3.e-bozo.com <http://bo3.e-bozo.com> replied to
>>> >> ping
>>> >>>>>>
>>> >>>>>> I'm not allowed onto the AD domain controllers to examine
>>> >>>>>> log files or I'd be checking those first.
>>> >>>>>>
>>> >>>>>> So ultimately the goal is to authenticate AD users and
>>> users
>>> >>>>>> that exist in our ldap schema. We need to set up groups of
>>> >>>>>> users that can run sudo commands on specific groups of
>>> hosts.
>>> >>>>>
>>> >>>>> Did you setup trusts as explained on the following page?
>>> >>>>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
>>> >>>>>
>>> >>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Wed, Dec 3, 2014 at 3:46 AM, Petr Spacek
>>> >>>>>> <pspacek at redhat.com <mailto:pspacek at redhat.com>> wrote:
>>> >>>>>>
>>> >>>>>> On 3.12.2014 04:35, Dmitri Pal wrote:
>>> >>>>>> > On 12/02/2014 08:54 PM, Matthew Herzog wrote:
>>> >>>>>> >> Any other ideas? I just spun up a new VM and took
>>> the
>>> >>>>>> defaults on everything
>>> >>>>>> >> while running ipa-server-install (the defaults did
>>> >>>>>> make sense) and my new VM
>>> >>>>>> >> can't resolve -anything- in the domain in which it
>>> >>>>>> lives. The "old" VM
>>> >>>>>> >> (running the same versions of everything on the
>>> same
>>> >>>>>> OS) can't even resolve
>>> >>>>>> >> the clients I have registered with it!
>>> >>>>>> >>
>>> >>>>>> >> So I'm pretty frustrated and am wondering, what
>>> >>>>>> _exactly_ is the role of
>>> >>>>>> >> bind in the IPA server and how is it expected to
>>> know
>>> >>>>>> anything about the
>>> >>>>>> >> local DNS domain without becoming a bind slave
>>> server?
>>> >>>>>> >
>>> >>>>>> > I am not sure I am 100% with you but...
>>> >>>>>> > If you use the defaults and nothing else you get to
>>> >>>>>> the scenario when IPA has
>>> >>>>>> > its DNS but it is a self contained environment. It
>>> >>>>>> seems that this is what you
>>> >>>>>> > observe.
>>> >>>>>> > It is expected that you decide in advance what you
>>> >>>>>> want to do with DNS. There
>>> >>>>>> > are several options:
>>> >>>>>> > 1) You can delegate a zone to IPA to manage, then
>>> you
>>> >>>>>> need to connect your IPA
>>> >>>>>> > DNS to your existing DNS during install or after.
>>> >>>>>> > In this case the systems joined to IPA will be a
>>> part
>>> >>>>>> of IPA domain/zone and
>>> >>>>>> > would also be able to resolve other systems around
>>> >>>>>> > 2) Not use IPA DNS if you do not want to take
>>> >>>>>> advantage of it
>>> >>>>>> > 3) Have a self contained demo/lab environment that
>>> you
>>> >>>>>> currently observe.
>>> >>>>>> >
>>> >>>>>> > What is the intent?
>>> >>>>>>
>>> >>>>>> I agree with Dmitri, we need more information from
>>> you:
>>> >>>>>> - You said "my new VM can't resolve -anything- in the
>>> >>>>>> domain in which it
>>> >>>>>> lives." - Which domain do you mean?
>>> >>>>>>
>>> >>>>>> - Apparently you have configured FreeIPA to serve zone
>>> >>>>>> e-bozo.com <http://e-bozo.com>. Do you have
>>> >>>>>> this zone configured on some other DNS server at the
>>> >>>>>> same time?
>>> >>>>>>
>>> >>>>>> Please keep in mind that authoritative servers should
>>> >>>>>> share the database. You
>>> >>>>>> will get naming collisions if e-bozo.com
>>> >>>>>> <http://e-bozo.com> is served by FreeIPA DNS servers
>>> and
>>> >>>>>> some other servers at the same time. Maybe that is the
>>> >>>>>> problem you see right now.
>>> >>>>>>
>>> >>>>>> As Dmitri said, the architecturally correct solution
>>> is
>>> >>>>>> to decide if you want
>>> >>>>>> to use FreeIPA DNS or not. You have option to either
>>> >>>>>> remove non-FreeIPA DNS
>>> >>>>>> servers and import data to FreeIPA or to add
>>> >>>>>> FreeIPA-specific DNS records to
>>> >>>>>> existing DNS servers and do not configure FreeIPA to
>>> act
>>> >>>>>> as DNS server.
>>> >>>>>>
>>> >>>>>> Petr^2 Spacek
>>> >>>>>>
>>> >>>>>> >> Thanks.
>>> >>>>>> >>
>>> >>>>>> >> On Tue, Dec 2, 2014 at 11:58 AM, Petr Spacek
>>> >>>>>> <pspacek at redhat.com <mailto:pspacek at redhat.com>
>>> >>>>>> >> <mailto:pspacek at redhat.com
>>> >>>>>> <mailto:pspacek at redhat.com>>> wrote:
>>> >>>>>> >>
>>> >>>>>> >> On 2.12.2014 17:36, Martin Basti wrote:
>>> >>>>>> >> > On 02/12/14 17:28, Matthew Herzog wrote:
>>> >>>>>> >> >> I just realized that my IPA servers cannot
>>> >>>>>> resolve ANY servers
>>> >>>>>> >> in my domain.
>>> >>>>>> >> >> What do I need to do to fix this? Below is
>>> my
>>> >>>>>> named.conf.
>>> >>>>>> >> >>
>>> >>>>>> >> >>
>>> >>>>>> >> >> options {
>>> >>>>>> >> >> // turns on IPv6 for port 53, IPv4 is on by
>>> >>>>>> default for
>>> >>>>>> >> all ifaces
>>> >>>>>> >> >> listen-on-v6 {any;};
>>> >>>>>> >> >>
>>> >>>>>> >> >> // Put files that named is allowed to write
>>> >>>>>> in the
>>> >>>>>> >> data/ directory:
>>> >>>>>> >> >> directory "/var/named"; // the default
>>> >>>>>> >> >> dump-file "data/cache_dump.db";
>>> >>>>>> >> >> statistics-file "data/named_stats.txt";
>>> >>>>>> >> >> memstatistics-file
>>> "data/named_mem_stats.txt";
>>> >>>>>> >> >>
>>> >>>>>> >> >> forward first;
>>> >>>>>> >> >> forwarders {
>>> >>>>>> >> >> 10.100.8.41;
>>> >>>>>> >> >> 10.100.8.40;
>>> >>>>>> >> >> 10.100.4.13;
>>> >>>>>> >> >> 10.100.4.14;
>>> >>>>>> >> >> 10.100.4.19;
>>> >>>>>> >> >> 10.100.4.44;
>>> >>>>>> >> >> };
>>> >>>>>> >> >>
>>> >>>>>> >> >> // Any host is permitted to issue recursive
>>> >>>>>> queries
>>> >>>>>> >> >> allow-recursion { any; };
>>> >>>>>> >> >>
>>> >>>>>> >> >> tkey-gssapi-keytab "/etc/named.keytab";
>>> >>>>>> >> >> pid-file "/run/named/named.pid";
>>> >>>>>> >> >> };
>>> >>>>>> >> >>
>>> >>>>>> >> >> /* If you want to enable debugging, eg.
>>> using
>>> >>>>>> the 'rndc trace'
>>> >>>>>> >> command,
>>> >>>>>> >> >> * By default, SELinux policy does not allow
>>> >>>>>> named to modify
>>> >>>>>> >> the /var/named
>>> >>>>>> >> >> directory,
>>> >>>>>> >> >> * so put the default debug log file in
>>> data/ :
>>> >>>>>> >> >> */
>>> >>>>>> >> >> logging {
>>> >>>>>> >> >> channel default_debug {
>>> >>>>>> >> >> file "data/named.run";
>>> >>>>>> >> >> severity dynamic;
>>> >>>>>> >> >> print-time yes;
>>> >>>>>> >> >> };
>>> >>>>>> >> >> };
>>> >>>>>> >> >> };
>>> >>>>>> >> >>
>>> >>>>>> >> >> zone "." IN {
>>> >>>>>> >> >> type hint;
>>> >>>>>> >> >> file "named.ca <http://named.ca>
>>> >>>>>> <http://named.ca> <http://named.ca>";
>>> >>>>>> >> >> };
>>> >>>>>> >> >>
>>> >>>>>> >> >> include "/etc/named.rfc1912.zones";
>>> >>>>>> >> >>
>>> >>>>>> >> >> dynamic-db "ipa" {
>>> >>>>>> >> >> library "ldap.so";
>>> >>>>>> >> >> arg "uri
>>> >>>>>> >>
>>> ldapi://%2fvar%2frun%2fslapd-BO3-E-BOZO-COM.socket";
>>> >>>>>> >> >> arg "base cn=dns, dc=bo3,dc=e-bozo,dc=com";
>>> >>>>>> >> >> arg "fake_mname
>>> freeipa-poc01.bo3.e-bozo.com
>>> >>>>>> <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>>>>> >> <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>>>>> >> >> <http://freeipa-poc01.bo3.e-bozo.com>.";
>>> >>>>>> >> >> arg "auth_method sasl";
>>> >>>>>> >> >> arg "sasl_mech GSSAPI";
>>> >>>>>> >> >> arg "sasl_user
>>> >>>>>> DNS/freeipa-poc01.bo3.e-bozo.com
>>> >>>>>> <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>>>>> >> <http://freeipa-poc01.bo3.e-bozo.com>
>>> >>>>>> >> >> <http://freeipa-poc01.bo3.e-bozo.com>";
>>> >>>>>> >> >> arg "serial_autoincrement yes";
>>> >>>>>> >> >> };
>>> >>>>>> >> >>
>>> >>>>>> >> >>
>>> >>>>>> >> >>
>>> >>>>>> >> >>
>>> >>>>>> >> > Hello,
>>> >>>>>> >> >
>>> >>>>>> >> > which version ipa do you use? which platform?
>>> >>>>>> Which version
>>> >>>>>> >> bind-dyndb-ldap?
>>> >>>>>> >> >
>>> >>>>>> >> > Can you run these commands, and check if
>>> there
>>> >>>>>> any errors?
>>> >>>>>> >> > ipactl status
>>> >>>>>> >> > systemctl status named (respectively
>>> >>>>>> journalctl -u named)
>>> >>>>>> >>
>>> >>>>>> >> We also may want to see information listed on
>>> page
>>> >>>>>> >>
>>> >>>>>>
>>> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting
>>>
>>> --
>>> Petr^2 Spacek
>>>
>>
>>
>>
>> --
>> If life gives you melons, you may be dyslexic.
>>
>
>
>
> --
> If life gives you melons, you may be dyslexic.
>
--
If life gives you melons, you may be dyslexic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141208/9e2cca11/attachment.htm>
More information about the Freeipa-users
mailing list