Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap
Hello,
On 22.10.2013 22:24, Brendan Kearney wrote:
my config uses bind and bind-dyndb-ldap to host zone data in ldap. i am
trying to achieve the equivalent directives and configuration of bind
+bind-dyndb-ldap that i have in straight bind.
Do you plan to use FreeIPA command line interface or not?
With FreeIPA, you can create equivalent records with this set of commands:
$ ipa dnszone-add bpk2.com
$ ipa dnsrecord-add bpk2.com _kerberos --txt-rec=...
etc.
Those commands allow you to create almost equivalent data in LDAP. This
doesn't work for you?
Please note that dnsrecord-add command contains zone name (as the first
argument), so the FQDN can be constructed from the first and second argument.
DNS zone is represented by LDAP object which contains all other named in the
zone:
idnsname=bkp2.com,cn=dns,dc=ipa,dc=test
Each name inside particular zone is represented by own LDAP object:
idnsname=_kerberos, idnsname=bkp2.com,cn=dns,dc=ipa,dc=test
As a result, FQDN can be constructed for each relative name in the zone simply
by concatenating second and first idnsname components.
Is it now clearer why bind-dyndb-ldap don't have equivalent of $ORIGIN?
attached is my forward zone (frozen before copying data, so that the jnl
entries were written out).
the desired outcome is to have zones configured so that unqualified
queries are looked up locally and return properly, if appropriate,
before being forwarded to any forwarders or via the hints to the roots
or whatever is configured to be done with a record that does not have a
locally authoritative entry.
AFAIK 'unqualified' names are purely client-side thing. I belive that all
names have to be expanded to FQDN *before* the query is sent to any DNS
server. (See search directive in /etc/resolv.conf.)
while zytrax does have good articles, the reference i provided is
directly out of the bind admin guide, and likely a more authoritative
voice on the subject.
I agree. Please note that both sources say the same information, just in other
words.
i have validated that when no $ORIGIN directive is set, a query using
the short name will fail when looked up locally, and will either be
forwarded or recursively searched for. the examples i provided go
against bind+bind-dyndb-ldap, and the short name query fails. doing the
same lookups against my straight bind instance, using the attached zone
file, gives authoritative responses for both short and FQDN queries.
I belive that your zone file will be perfectly functional if you remove origin
completely. You will have to replace name for SOA record.
$ diff -u bpk2.com.db.orig bpk2.com.db.noorigin
--- bpk2.com.db.orig2013-10-23 09:09:47.568113243 +0200
+++ bpk2.com.db.noorigin2013-10-23 09:10:09.347112464 +0200
@@ -1,6 +1,5 @@
-$ORIGIN .
$TTL 3600 ; 1 hour
-bpk2.com IN SOA server.bpk2.com. root.server.bpk2.com. (
+@ IN SOA server.bpk2.com. root.server.bpk2.com. (
21684 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
@@ -9,7 +8,6 @@
)
NS vpn.bpk2.com.
NS server.bpk2.com.
-$ORIGIN bpk2.com.
$TTL 600 ; 10 minutes
_kerberos TXT BPK2.COM
$TTL 5 ; 5 seconds
I assume that your zone definition in named.conf looks like:
zone bpk2.com. IN {
type master;
file bpk2.com.db;
};
As a result, default origin bpk2.com. is appended to all names in zone file
- and that is it.
Do not forget to bump serial and check server logs if the new zone file was
loaded correctly ...
Have a nice day!
--
Petr^2 Spacek
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Failure decoding Certificate Signing Request
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, October 22, 2013 7:13 PM
To: Thomson, Ryan; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request
Thomson, Ryan wrote:
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, October 22, 2013 10:46 AM
To: Thomson, Ryan; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Failure decoding Certificate Signing
Request
Thomson, Ryan wrote:
Hi Rob,
There is some duplication in the error strings (ticket
https://fedorahosted.org/freeipa/ticket/3988). Did you add a number
prefix to yours, I see a 3 -in the error. If so, by my calculation,
this works out to be an NSPRError. It would be helpful to know what
exception is being raised, which we don't do.
I did prefix numbers to the various error strings.
Either way, if you could enhance each occurrence of 'Failure
decoding Certificate Signing Request' in /usr/lib/python*/site-
packages/ipalib/plugins/cert.py to something like:
except NSPEError, nsprerr:
raise errors.CertificateOperationError(error=_('Failure
decoding Certificate Signing Request %s') % nsprerr)
You'll need to restart the httpd process afterwards. This should
give us the real reason for the failure.
Done. The error I get now is:
Server failed request, will retry: 4301 (RPC failed at server.
Certificate
operation cannot be completed: Failure decoding Certificate Signing
Request [Errno -8018] error (-8018) unknown).
Hmm, very strange indeed.
It should be using the NSS database initialized in mod_nss for
Apache, which should remain open and available for wsgi. It almost
seems like the database has been shut down.
Can you add a logging event to log the value of nss.nss_is_initialized()?
Have you done any configuration customization in Apache or mod_nss?
thanks
rob
The return value of nss.nss_is_initialized() is False when I resubmit the
(expired) certs through certmonger.
Ok, that is the core of the issue then. pkcs10.load_certificate() will
initialize
NSS If it isn't already and I'm guessing that is failing and is the source of
this
exception.
I did have a custom config for apache that configured a virtual host with
SSL. I have disabled that config and restarted httpd, resubmitted the certs to
certmonger but I still receive the same error. I will continue poking through
my apache / mod_nss config to see if anything stands out.
You're still using mod_nss though, right?
rob
I'm still using mod_nss.
I have discovered that I might be focusing on a symptom here rather than the
core problem. If I restart httpd and then certmonger, the first error returned
when certmonger tries to renew the certificates is not Failure decoding
Certificate Signing Request but rather:
Server failed request, will retry: 4301 (RPC failed at server. Certificate
operation cannot be completed: EXCEPTION (You did not provide a valid
certificate for this operation)).
for two certs, and:
Server failed request, will retry: 907 (RPC failed at server. cannot connect
to 'https://HOSTNAME.DOMAIN:443/ca/agent/ca/displayBySerial': [Errno -8053]
(SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use.).
for a third.
After some time, I resubmit and the error returned changes to Failure
decoding... for all three (expired) certs.
In the httpd error_log during that time, I see the following errors and
traceback:
[Sun Oct 06 21:13:14 2013] [error] /usr/lib64/python2.6/getpass.py:83:
GetPassWarning: Can not control echo on the terminal.
[Sun Oct 06 21:13:14 2013] [error] passwd = fallback_getpass(prompt, stream)
[Sun Oct 06 21:13:14 2013] [error] Warning: Password input may be echoed.
[Sun Oct 06 21:13:14 2013] [error] Enter password for internal:
[Sun Oct 06 21:13:14 2013] [error] exception in PK11 password callback
[Sun Oct 06 21:13:14 2013] [error] Traceback (most recent call last):
[Sun Oct 06 21:13:14 2013] [error] File
/usr/lib/python2.6/site-packages/ipapython/nsslib.py, line 229, in
password_callback
[Sun Oct 06 21:13:14 2013] [error] return getpass.getpass(Enter password
for %s: % slot.token_name);
[Sun Oct 06 21:13:14 2013] [error] File /usr/lib64/python2.6/getpass.py,
line 83, in unix_getpass
[Sun Oct 06 21:13:14 2013] [error] passwd = fallback_getpass(prompt, stream)
[Sun Oct 06 21:13:14 2013] [error] File /usr/lib64/python2.6/getpass.py,
line 118, in fallback_getpass
[Sun Oct 06 21:13:14 2013] [error] return _raw_input(prompt, stream)
[Sun Oct 06 21:13:14 2013] [error] File /usr/lib64/python2.6/getpass.py,
line 135, in _raw_input
[Sun Oct 06 21:13:14 2013] [error] raise EOFError
[Sun Oct 06 21:13:14 2013] [error] EOFError
It looks like perhaps there is a problem retrieving a password (for an NSS db?)
with getpass.
Thanks for your help so far, Rob. Much
Re: [Freeipa-users] No $ORIGIN directive in bind-dyndb-ldap
Do you plan to use FreeIPA command line interface or not?
With FreeIPA, you can create equivalent records with this set of commands:
$ ipa dnszone-add bpk2.com
$ ipa dnsrecord-add bpk2.com _kerberos --txt-rec=...
etc.
Those commands allow you to create almost equivalent data in LDAP. This
doesn't work for you?
Please note that dnsrecord-add command contains zone name (as the first
argument), so the FQDN can be constructed from the first and second argument.
i am using bind-dyndb-ldap without FreeIPA, or 389. It is on Fedora,
with OpenLDAP and a bunch of steps to get it working. i am using
phpLdapAdmin to administrate the ldap instance and have created the
needed configs in ldap, using the existing sample ldif as a guide.
DNS zone is represented by LDAP object which contains all other named in the
zone:
idnsname=bkp2.com,cn=dns,dc=ipa,dc=test
Each name inside particular zone is represented by own LDAP object:
idnsname=_kerberos, idnsname=bkp2.com,cn=dns,dc=ipa,dc=test
As a result, FQDN can be constructed for each relative name in the zone
simply
by concatenating second and first idnsname components.
Is it now clearer why bind-dyndb-ldap don't have equivalent of $ORIGIN?
no. you say that the FQDN can be constructed by stinging together 2 of
the values in the DN, but neither bind, nor the bind-dyndb-ldap
plug-in are doing that.
attached is my forward zone (frozen before copying data, so that the jnl
entries were written out).
the desired outcome is to have zones configured so that unqualified
queries are looked up locally and return properly, if appropriate,
before being forwarded to any forwarders or via the hints to the roots
or whatever is configured to be done with a record that does not have a
locally authoritative entry.
AFAIK 'unqualified' names are purely client-side thing. I belive that all
names have to be expanded to FQDN *before* the query is sent to any DNS
server. (See search directive in /etc/resolv.conf.)
and there are no conceivable scenarios where an unqualified query could
ever get to the bind server? regardless of opinions on how
frequent/infrequent it could happen, the fact is that this is an
entirely legitimate scenario that improperly fails with an error.
while zytrax does have good articles, the reference i provided is
directly out of the bind admin guide, and likely a more authoritative
voice on the subject.
I agree. Please note that both sources say the same information, just in
other
words.
i have validated that when no $ORIGIN directive is set, a query using
the short name will fail when looked up locally, and will either be
forwarded or recursively searched for. the examples i provided go
against bind+bind-dyndb-ldap, and the short name query fails. doing the
same lookups against my straight bind instance, using the attached zone
file, gives authoritative responses for both short and FQDN queries.
I belive that your zone file will be perfectly functional if you remove
origin
completely. You will have to replace name for SOA record.
it does not matter what will or will not work with my zones. what i am
trying to account for is lookups failing against bind when using the
bind-dyndb-ldap backend and a short name is specified. since the
$ORIGIN directive is written into RFC, why is it electively being
dropped, resulting in a broken implementation because of the lack of
compliance?
$ diff -u bpk2.com.db.orig bpk2.com.db.noorigin
--- bpk2.com.db.orig 2013-10-23 09:09:47.568113243 +0200
+++ bpk2.com.db.noorigin 2013-10-23 09:10:09.347112464 +0200
@@ -1,6 +1,5 @@
-$ORIGIN .
$TTL 3600 ; 1 hour
-bpk2.com IN SOA server.bpk2.com. root.server.bpk2.com. (
+@IN SOA server.bpk2.com. root.server.bpk2.com. (
21684 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
@@ -9,7 +8,6 @@
)
NS vpn.bpk2.com.
NS server.bpk2.com.
-$ORIGIN bpk2.com.
$TTL 600; 10 minutes
_kerberos TXT BPK2.COM
$TTL 5 ; 5 seconds
I assume that your zone definition in named.conf looks like:
zone bpk2.com. IN {
type master;
file bpk2.com.db;
};
As a result, default origin bpk2.com. is appended to all names in zone file
- and that is it.
Do not forget to bump serial and check server logs if the new zone file was
loaded correctly ...
Have a nice day!
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Failure decoding Certificate Signing Request
Thomson, Ryan wrote:
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, October 22, 2013 7:13 PM
To: Thomson, Ryan; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request
Thomson, Ryan wrote:
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, October 22, 2013 10:46 AM
To: Thomson, Ryan; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Failure decoding Certificate Signing
Request
Thomson, Ryan wrote:
Hi Rob,
There is some duplication in the error strings (ticket
https://fedorahosted.org/freeipa/ticket/3988). Did you add a number
prefix to yours, I see a 3 -in the error. If so, by my calculation,
this works out to be an NSPRError. It would be helpful to know what
exception is being raised, which we don't do.
I did prefix numbers to the various error strings.
Either way, if you could enhance each occurrence of 'Failure
decoding Certificate Signing Request' in /usr/lib/python*/site-
packages/ipalib/plugins/cert.py to something like:
except NSPEError, nsprerr:
raise errors.CertificateOperationError(error=_('Failure
decoding Certificate Signing Request %s') % nsprerr)
You'll need to restart the httpd process afterwards. This should
give us the real reason for the failure.
Done. The error I get now is:
Server failed request, will retry: 4301 (RPC failed at server.
Certificate
operation cannot be completed: Failure decoding Certificate Signing
Request [Errno -8018] error (-8018) unknown).
Hmm, very strange indeed.
It should be using the NSS database initialized in mod_nss for
Apache, which should remain open and available for wsgi. It almost
seems like the database has been shut down.
Can you add a logging event to log the value of nss.nss_is_initialized()?
Have you done any configuration customization in Apache or mod_nss?
thanks
rob
The return value of nss.nss_is_initialized() is False when I resubmit the
(expired) certs through certmonger.
Ok, that is the core of the issue then. pkcs10.load_certificate() will
initialize
NSS If it isn't already and I'm guessing that is failing and is the source of
this
exception.
I did have a custom config for apache that configured a virtual host with
SSL. I have disabled that config and restarted httpd, resubmitted the certs to
certmonger but I still receive the same error. I will continue poking through
my apache / mod_nss config to see if anything stands out.
You're still using mod_nss though, right?
rob
I'm still using mod_nss.
I have discovered that I might be focusing on a symptom here rather than the core
problem. If I restart httpd and then certmonger, the first error returned when certmonger
tries to renew the certificates is not Failure decoding Certificate Signing
Request but rather:
Server failed request, will retry: 4301 (RPC failed at server. Certificate
operation cannot be completed: EXCEPTION (You did not provide a valid certificate for
this operation)).
for two certs, and:
Server failed request, will retry: 907 (RPC failed at server. cannot connect to
'https://HOSTNAME.DOMAIN:443/ca/agent/ca/displayBySerial': [Errno -8053] (SEC_ERROR_BUSY)
NSS could not shutdown. Objects are still in use.).
for a third.
After some time, I resubmit and the error returned changes to Failure
decoding... for all three (expired) certs.
In the httpd error_log during that time, I see the following errors and
traceback:
[Sun Oct 06 21:13:14 2013] [error] /usr/lib64/python2.6/getpass.py:83:
GetPassWarning: Can not control echo on the terminal.
[Sun Oct 06 21:13:14 2013] [error] passwd = fallback_getpass(prompt, stream)
[Sun Oct 06 21:13:14 2013] [error] Warning: Password input may be echoed.
[Sun Oct 06 21:13:14 2013] [error] Enter password for internal:
[Sun Oct 06 21:13:14 2013] [error] exception in PK11 password callback
[Sun Oct 06 21:13:14 2013] [error] Traceback (most recent call last):
[Sun Oct 06 21:13:14 2013] [error] File
/usr/lib/python2.6/site-packages/ipapython/nsslib.py, line 229, in
password_callback
[Sun Oct 06 21:13:14 2013] [error] return getpass.getpass(Enter password for
%s: % slot.token_name);
[Sun Oct 06 21:13:14 2013] [error] File /usr/lib64/python2.6/getpass.py,
line 83, in unix_getpass
[Sun Oct 06 21:13:14 2013] [error] passwd = fallback_getpass(prompt, stream)
[Sun Oct 06 21:13:14 2013] [error] File /usr/lib64/python2.6/getpass.py,
line 118, in fallback_getpass
[Sun Oct 06 21:13:14 2013] [error] return _raw_input(prompt, stream)
[Sun Oct 06 21:13:14 2013] [error] File /usr/lib64/python2.6/getpass.py,
line 135, in _raw_input
[Sun Oct 06 21:13:14 2013] [error] raise EOFError
[Sun Oct 06 21:13:14 2013] [error] EOFError
It looks like perhaps there is a problem retrieving a password (for an NSS db?)
with getpass.
Thanks for your help so far, Rob. Much appreciated.
I think this still points to NSS not being initialized. The way we
