On Fri, 2011-09-23 at 13:17 -0400, Adam Young wrote:
> On 09/23/2011 11:52 AM, Rob Crittenden wrote:
> > Adam Young wrote:
> >> On 09/23/2011 02:02 AM, Martin Kosek wrote:
> >>> On Thu, 2011-09-22 at 22:05 -0400, Adam Young wrote:
> On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
> >> OPE
On 09/23/2011 11:52 AM, Rob Crittenden wrote:
Adam Young wrote:
On 09/23/2011 02:02 AM, Martin Kosek wrote:
On Thu, 2011-09-22 at 22:05 -0400, Adam Young wrote:
On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
OPEN QUESTION: should we implement these new commands also for
discrete
DNS records
Adam Young wrote:
On 09/23/2011 02:02 AM, Martin Kosek wrote:
On Thu, 2011-09-22 at 22:05 -0400, Adam Young wrote:
On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
OPEN QUESTION: should we implement these new commands also for
discrete
DNS records types to be consistent? I mean for example A,
On Fri, 2011-09-23 at 10:46 -0400, Adam Young wrote:
> On 09/23/2011 02:02 AM, Martin Kosek wrote:
> > On Thu, 2011-09-22 at 22:05 -0400, Adam Young wrote:
> >> On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
> OPEN QUESTION: should we implement these new commands also for discrete
> DNS
On 09/23/2011 02:02 AM, Martin Kosek wrote:
On Thu, 2011-09-22 at 22:05 -0400, Adam Young wrote:
On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
OPEN QUESTION: should we implement these new commands also for discrete
DNS records types to be consistent? I mean for example A, , CNAME,
PTR, .
On 09/23/2011 02:02 AM, Martin Kosek wrote:
On Thu, 2011-09-22 at 22:05 -0400, Adam Young wrote:
On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
OPEN QUESTION: should we implement these new commands also for discrete
DNS records types to be consistent? I mean for example A, , CNAME,
PTR, .
On Thu, Sep 22, 2011 at 09:59:01PM -0400, Dmitri Pal wrote:
> On 09/22/2011 03:37 AM, Jakub Hrozek wrote:
> > On Thu, Sep 22, 2011 at 08:25:01AM +0200, Jan Cholasta wrote:
> >> On 21.9.2011 23:55, Dmitri Pal wrote:
> >>> On 09/21/2011 10:27 AM, Adam Young wrote:
> On 09/20/2011 11:11 AM, Marti
On Thu, 2011-09-22 at 22:05 -0400, Adam Young wrote:
> On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
> >> OPEN QUESTION: should we implement these new commands also for discrete
> >> DNS records types to be consistent? I mean for example A, , CNAME,
> >> PTR, ... They would look like
> >>
>
On Thu, 2011-09-22 at 19:31 -0500, Endi Sukma Dewata wrote:
> On 9/22/2011 7:24 AM, Martin Kosek wrote:
> >> 2) Some DNS records may be pretty large. MX record data is small, but
> >> for example CERT records have an entire certificate stored in it.
> >> Wouldn't there be a problem if we place the
On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
On 9/22/2011 7:24 AM, Martin Kosek wrote:
2) Some DNS records may be pretty large. MX record data is small, but
for example CERT records have an entire certificate stored in it.
Wouldn't there be a problem if we place the large DNS record in URL?
On 09/22/2011 03:37 AM, Jakub Hrozek wrote:
> On Thu, Sep 22, 2011 at 08:25:01AM +0200, Jan Cholasta wrote:
>> On 21.9.2011 23:55, Dmitri Pal wrote:
>>> On 09/21/2011 10:27 AM, Adam Young wrote:
On 09/20/2011 11:11 AM, Martin Kosek wrote:
> On Tue, 2011-09-20 at 10:02 -0400, Adam Young wro
On 9/22/2011 7:24 AM, Martin Kosek wrote:
2) Some DNS records may be pretty large. MX record data is small, but
for example CERT records have an entire certificate stored in it.
Wouldn't there be a problem if we place the large DNS record in URL?
This is how the DNS record list page could be re
Martin Kosek wrote:
On Wed, 2011-09-21 at 11:22 +0200, Martin Kosek wrote:
On Tue, 2011-09-20 at 11:22 -0500, Endi Sukma Dewata wrote:
On 9/20/2011 6:15 AM, Martin Kosek wrote:
ACK. Proposal looks like it will work fairly easily with the UI.
We'll have to make some chagnes due to the Add doin
On Wed, 2011-09-21 at 11:22 +0200, Martin Kosek wrote:
> On Tue, 2011-09-20 at 11:22 -0500, Endi Sukma Dewata wrote:
> > On 9/20/2011 6:15 AM, Martin Kosek wrote:
> > >>> ACK. Proposal looks like it will work fairly easily with the UI.
> > >>> We'll have to make some chagnes due to the Add doing s
On Thu, Sep 22, 2011 at 08:25:01AM +0200, Jan Cholasta wrote:
> On 21.9.2011 23:55, Dmitri Pal wrote:
> >On 09/21/2011 10:27 AM, Adam Young wrote:
> >>On 09/20/2011 11:11 AM, Martin Kosek wrote:
> >>>On Tue, 2011-09-20 at 10:02 -0400, Adam Young wrote:
> This discussion got me thinking, always
On 21.9.2011 23:55, Dmitri Pal wrote:
On 09/21/2011 10:27 AM, Adam Young wrote:
On 09/20/2011 11:11 AM, Martin Kosek wrote:
On Tue, 2011-09-20 at 10:02 -0400, Adam Young wrote:
This discussion got me thinking, always a dangerous proposal:
We are currently exposing record add with the lie tha
Can we use augeas for this?
Augeas lenses use this kind of the validation and there is python
binding so may be we should use augeas as an inspiration or ask for an
augeas Javascript solution?
We might be able to learn something from Augeas, but the current Param
aspect of the Python architec
On 09/21/2011 10:27 AM, Adam Young wrote:
> On 09/20/2011 11:11 AM, Martin Kosek wrote:
>> On Tue, 2011-09-20 at 10:02 -0400, Adam Young wrote:
>>> This discussion got me thinking, always a dangerous proposal:
>>>
>>> We are currently exposing record add with the lie that when you add a
>>> recor
On 09/21/2011 08:44 AM, Martin Kosek wrote:
On Wed, 2011-09-21 at 08:06 -0700, yi zhang wrote:
On 09/21/2011 01:58 AM, Adam Tkac wrote:
On 09/16/2011 02:25 PM, Martin Kosek wrote:
On Fri, 2011-09-16 at 08:12 -0400, Simo Sorce wrote:
Whatever you do do not split this operation into a DEL+ADD,
On Wed, 2011-09-21 at 08:06 -0700, yi zhang wrote:
> On 09/21/2011 01:58 AM, Adam Tkac wrote:
> > On 09/16/2011 02:25 PM, Martin Kosek wrote:
> >> On Fri, 2011-09-16 at 08:12 -0400, Simo Sorce wrote:
> >>> Whatever you do do not split this operation into a DEL+ADD, we want an
> >>> atomic modify op
On 09/21/2011 01:58 AM, Adam Tkac wrote:
On 09/16/2011 02:25 PM, Martin Kosek wrote:
On Fri, 2011-09-16 at 08:12 -0400, Simo Sorce wrote:
Whatever you do do not split this operation into a DEL+ADD, we want an
atomic modify operation in any case. as you do not want to have a race
where named may
On 09/20/2011 11:11 AM, Martin Kosek wrote:
On Tue, 2011-09-20 at 10:02 -0400, Adam Young wrote:
This discussion got me thinking, always a dangerous proposal:
We are currently exposing record add with the lie that when you add a
record, it has a type. THe reality is that a record is just thi
On Tue, 2011-09-20 at 11:22 -0500, Endi Sukma Dewata wrote:
> On 9/20/2011 6:15 AM, Martin Kosek wrote:
> >>> ACK. Proposal looks like it will work fairly easily with the UI.
> >>> We'll have to make some chagnes due to the Add doing something
> >>> different based on the type, but that is the cas
On Wed, 2011-09-21 at 10:58 +0200, Adam Tkac wrote:
> On 09/16/2011 02:25 PM, Martin Kosek wrote:
> > On Fri, 2011-09-16 at 08:12 -0400, Simo Sorce wrote:
> >> Whatever you do do not split this operation into a DEL+ADD, we want an
> >> atomic modify operation in any case. as you do not want to have
On 09/16/2011 02:25 PM, Martin Kosek wrote:
> On Fri, 2011-09-16 at 08:12 -0400, Simo Sorce wrote:
>> Whatever you do do not split this operation into a DEL+ADD, we want an
>> atomic modify operation in any case. as you do not want to have a race
>> where named may query the MX records and find the
On 9/20/2011 6:15 AM, Martin Kosek wrote:
ACK. Proposal looks like it will work fairly easily with the UI.
We'll have to make some chagnes due to the Add doing something
different based on the type, but that is the case anyway.
Yes, I was thinking how can we integrate this new API to WebUI. AF
On Tue, 2011-09-20 at 10:02 -0400, Adam Young wrote:
> This discussion got me thinking, always a dangerous proposal:
>
> We are currently exposing record add with the lie that when you add a
> record, it has a type. THe reality is that a record is just this big
> collection of multi value att
This discussion got me thinking, always a dangerous proposal:
We are currently exposing record add with the lie that when you add a
record, it has a type. THe reality is that a record is just this big
collection of multi value attributes, and each of those is the "type"
of the record.
On Fri, 2011-09-16 at 09:42 +0200, Martin Kosek wrote:
> On Thu, 2011-09-15 at 15:28 -0400, Adam Young wrote:
> > On 09/14/2011 12:18 PM, Martin Kosek wrote:
> > > Attached in the txt file. If you have any comments or suggestions to
> > > this proposal, please let me know.
> > >
> > > https://fed
On Fri, 2011-09-16 at 08:12 -0400, Simo Sorce wrote:
> On Fri, 2011-09-16 at 14:04 +0200, Martin Kosek wrote:
...
> > How would that work? We are designing -add -show -mod commands for
> > mutlivalued LDAP attribute values, we should have some reference what
> > value we are modifying. Or did you m
On Fri, 2011-09-16 at 14:04 +0200, Martin Kosek wrote:
> On Fri, 2011-09-16 at 07:58 -0400, Simo Sorce wrote:
> > On Fri, 2011-09-16 at 09:42 +0200, Martin Kosek wrote:
> > > On Thu, 2011-09-15 at 15:28 -0400, Adam Young wrote:
> > > > On 09/14/2011 12:18 PM, Martin Kosek wrote:
> > > > > Attached
On Fri, 2011-09-16 at 07:58 -0400, Simo Sorce wrote:
> On Fri, 2011-09-16 at 09:42 +0200, Martin Kosek wrote:
> > On Thu, 2011-09-15 at 15:28 -0400, Adam Young wrote:
> > > On 09/14/2011 12:18 PM, Martin Kosek wrote:
> > > > Attached in the txt file. If you have any comments or suggestions to
> >
On Fri, 2011-09-16 at 09:42 +0200, Martin Kosek wrote:
> On Thu, 2011-09-15 at 15:28 -0400, Adam Young wrote:
> > On 09/14/2011 12:18 PM, Martin Kosek wrote:
> > > Attached in the txt file. If you have any comments or suggestions to
> > > this proposal, please let me know.
> > >
> > > https://fed
On 09/16/2011 09:51 AM, Martin Kosek wrote:
On Thu, 2011-09-15 at 10:26 +0200, Adam Tkac wrote:
Your proposal seems fine for me. However I would recommend not to expose
routines for managing DNSSEC related records because DNSSEC is currently
not supported in the bind-dyndb-ldap. This doesn't me
On Thu, 2011-09-15 at 10:26 +0200, Adam Tkac wrote:
> On 09/14/2011 06:18 PM, Martin Kosek wrote:
> > Attached in the txt file. If you have any comments or suggestions to
> > this proposal, please let me know.
> >
> > https://fedorahosted.org/freeipa/ticket/1766
>
> Your proposal seems fine for me
On Thu, 2011-09-15 at 15:28 -0400, Adam Young wrote:
> On 09/14/2011 12:18 PM, Martin Kosek wrote:
> > Attached in the txt file. If you have any comments or suggestions to
> > this proposal, please let me know.
> >
> > https://fedorahosted.org/freeipa/ticket/1766
> >
> >
> > ___
On 09/14/2011 12:18 PM, Martin Kosek wrote:
Attached in the txt file. If you have any comments or suggestions to
this proposal, please let me know.
https://fedorahosted.org/freeipa/ticket/1766
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
h
On 09/14/2011 06:18 PM, Martin Kosek wrote:
Attached in the txt file. If you have any comments or suggestions to
this proposal, please let me know.
https://fedorahosted.org/freeipa/ticket/1766
Your proposal seems fine for me. However I would recommend not to expose
routines for managing DNSSE
Attached in the txt file. If you have any comments or suggestions to
this proposal, please let me know.
https://fedorahosted.org/freeipa/ticket/1766
https://fedorahosted.org/freeipa/ticket/1766
This is a proposal for API for per-DNS-type interface in FreeIPA.
There are many structured DNS RR typ
39 matches
Mail list logo