Re: [Freeipa-devel] Data source-agnostic parameters

[Jan Cholasta]

Dne 6.8.2012 17:29, Simo Sorce napsal(a):

On Mon, 2012-08-06 at 16:27 +0200, Jan Cholasta wrote:

Dne 6.8.2012 16:10, Alexander Bokovoy napsal(a):

On Mon, 06 Aug 2012, Jan Cholasta wrote:

Dne 6.8.2012 15:20, Simo Sorce napsal(a):

On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:

Hi,

while thinking about , I
had an idea how to make loading data from files available for all
parameters:

I think we can use URI-like strings in parameter values that the CLI
would interpret and extract the wanted information from them
(similar to
what openssl does in the -pass command line option, see PASS PHRASE
ARGUMENTS in openssl(1)).

So, instead of adding a new parameter as a file-accepting
alternative to
any existing parameter (i.e. what is suggested in the ticket), the user
would be able to specify the file in a URI-like string:

(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub

vs.

(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

and the CLI would take care of reading the file and using its contents
as the parameter value.

This could be extended with additional URI(-like) schemes:

- data: - use  as the value (useful for escaping values
that look like URIs, but you don't want them to be treated as such)
- base64: - use the value of base64 decoded  (useful for
--delattr on ugly raw binary values)
- fd: - read value from file descriptor 
- env: - read value from environment variable 
- ask: - always prompt interactively for the value
- default: - use default value, never prompt interactively

Thoughts?


How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?

Simo.



You can escape them like this: --someparam data:actual://uri/string

As for backward compatibility, this change has the potential to break
things (user scripts which use the CLI, etc.), but AFAIK there is no
parameter in IPA which expects URI string values specifically, so the
impact would be miminal IMHO.


I don't think you need to invent anything here. RFC2397 is available for
long time and provides already effective way to represent any data in
URI.

http://tools.ietf.org/html/rfc2397



I have considered this, but given that these URL-like strings would be
mainly used directly by users on the command-line, I think that
"base64:" is more user friendly than "data:;base64,".


If you want to propose URIs then use standard URIs please.

Simo.



I don't - URIs are just one of the options we can use.

I think sticking with URIs might be limiting (no relative paths in file 
URIs, not everything can be represented by standard URI schemes, etc.), 
that's why I called the strings URI-*like* in the original email.


Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Data source-agnostic parameters

[Simo Sorce]

On Mon, 2012-08-06 at 16:27 +0200, Jan Cholasta wrote:
> Dne 6.8.2012 16:10, Alexander Bokovoy napsal(a):
> > On Mon, 06 Aug 2012, Jan Cholasta wrote:
> >> Dne 6.8.2012 15:20, Simo Sorce napsal(a):
> >>> On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:
>  Hi,
> 
>  while thinking about , I
>  had an idea how to make loading data from files available for all
>  parameters:
> 
>  I think we can use URI-like strings in parameter values that the CLI
>  would interpret and extract the wanted information from them
>  (similar to
>  what openssl does in the -pass command line option, see PASS PHRASE
>  ARGUMENTS in openssl(1)).
> 
>  So, instead of adding a new parameter as a file-accepting
>  alternative to
>  any existing parameter (i.e. what is suggested in the ticket), the user
>  would be able to specify the file in a URI-like string:
> 
>  (use new parameter --sshpubkeyfile)
>  $ ipa user-mod --sshpubkey="ssh-rsa  ..."
>  $ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub
> 
>  vs.
> 
>  (use file URI-like string)
>  $ ipa user-mod --sshpubkey="ssh-rsa  ..."
>  $ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub
> 
>  and the CLI would take care of reading the file and using its contents
>  as the parameter value.
> 
>  This could be extended with additional URI(-like) schemes:
> 
> - data: - use  as the value (useful for escaping values
>  that look like URIs, but you don't want them to be treated as such)
> - base64: - use the value of base64 decoded  (useful for
>  --delattr on ugly raw binary values)
> - fd: - read value from file descriptor 
> - env: - read value from environment variable 
> - ask: - always prompt interactively for the value
> - default: - use default value, never prompt interactively
> 
>  Thoughts?
> >>>
> >>> How do you handle values that are actually URI strings, how do you tell
> >>> the command to not interpret them ?
> >>>
> >>> Simo.
> >>>
> >>
> >> You can escape them like this: --someparam data:actual://uri/string
> >>
> >> As for backward compatibility, this change has the potential to break
> >> things (user scripts which use the CLI, etc.), but AFAIK there is no
> >> parameter in IPA which expects URI string values specifically, so the
> >> impact would be miminal IMHO.
> >
> > I don't think you need to invent anything here. RFC2397 is available for
> > long time and provides already effective way to represent any data in
> > URI.
> >
> > http://tools.ietf.org/html/rfc2397
> >
> 
> I have considered this, but given that these URL-like strings would be 
> mainly used directly by users on the command-line, I think that 
> "base64:" is more user friendly than "data:;base64,".

If you want to propose URIs then use standard URIs please.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Data source-agnostic parameters

[Jan Cholasta]

Dne 6.8.2012 16:27, John Dennis napsal(a):

On 08/06/2012 10:10 AM, Alexander Bokovoy wrote:

On Mon, 06 Aug 2012, Jan Cholasta wrote:

Dne 6.8.2012 15:20, Simo Sorce napsal(a):

On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:

Hi,

while thinking about , I
had an idea how to make loading data from files available for all
parameters:

I think we can use URI-like strings in parameter values that the CLI
would interpret and extract the wanted information from them
(similar to
what openssl does in the -pass command line option, see PASS PHRASE
ARGUMENTS in openssl(1)).

So, instead of adding a new parameter as a file-accepting
alternative to
any existing parameter (i.e. what is suggested in the ticket), the
user
would be able to specify the file in a URI-like string:

(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub

vs.

(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

and the CLI would take care of reading the file and using its contents
as the parameter value.

This could be extended with additional URI(-like) schemes:

- data: - use  as the value (useful for escaping
values
that look like URIs, but you don't want them to be treated as such)
- base64: - use the value of base64 decoded 
(useful for
--delattr on ugly raw binary values)
- fd: - read value from file descriptor 
- env: - read value from environment variable 
- ask: - always prompt interactively for the value
- default: - use default value, never prompt interactively

Thoughts?


How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?

Simo.



You can escape them like this: --someparam data:actual://uri/string

As for backward compatibility, this change has the potential to break
things (user scripts which use the CLI, etc.), but AFAIK there is no
parameter in IPA which expects URI string values specifically, so the
impact would be miminal IMHO.


I don't think you need to invent anything here. RFC2397 is available for
long time and provides already effective way to represent any data in
URI.

http://tools.ietf.org/html/rfc2397


I think it would be much better to follow RFC's including the one
Alexander cited above.

Rather than

$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

shouldn't it be:

$ ipa user-mod --sshpubkey=file:///.ssh/id_rsa.pub



Not necesarrily, RFC 3986 allows the former format (but AFAIK there is 
no RFC which allows relative file names in the URIs).




I'm not sure we need or want to pass file descriptors and I wonder about
the security implications of reading from environment variables. So I'm
not sure about supporting the fd and env input.


Sure, these are just ideas, not something absolutely necessary.



I don't think we need 'default' either, if the parameter does not begin
with URI syntax then it's processes just as before.

I can see a value in 'ask', but I'd rather see this expressed as a URI
scheme.



Both "default" and "ask" are scheme names in my proposal (the URIs using 
these schemes don't have anything after the colon, but the colon must be 
present).


The only use of "default:" is when a parameter has a default value and 
the always_ask flag set, but you don't actually want the CLI to prompt 
for it.


Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Data source-agnostic parameters

[John Dennis]

On 08/06/2012 10:27 AM, Jan Cholasta wrote:

Dne 6.8.2012 16:10, Alexander Bokovoy napsal(a):

On Mon, 06 Aug 2012, Jan Cholasta wrote:

Dne 6.8.2012 15:20, Simo Sorce napsal(a):

On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:

Hi,

while thinking about , I
had an idea how to make loading data from files available for all
parameters:

I think we can use URI-like strings in parameter values that the CLI
would interpret and extract the wanted information from them
(similar to
what openssl does in the -pass command line option, see PASS PHRASE
ARGUMENTS in openssl(1)).

So, instead of adding a new parameter as a file-accepting
alternative to
any existing parameter (i.e. what is suggested in the ticket), the user
would be able to specify the file in a URI-like string:

(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub

vs.

(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

and the CLI would take care of reading the file and using its contents
as the parameter value.

This could be extended with additional URI(-like) schemes:

- data: - use  as the value (useful for escaping values
that look like URIs, but you don't want them to be treated as such)
- base64: - use the value of base64 decoded  (useful for
--delattr on ugly raw binary values)
- fd: - read value from file descriptor 
- env: - read value from environment variable 
- ask: - always prompt interactively for the value
- default: - use default value, never prompt interactively

Thoughts?


How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?

Simo.



You can escape them like this: --someparam data:actual://uri/string

As for backward compatibility, this change has the potential to break
things (user scripts which use the CLI, etc.), but AFAIK there is no
parameter in IPA which expects URI string values specifically, so the
impact would be miminal IMHO.


I don't think you need to invent anything here. RFC2397 is available for
long time and provides already effective way to represent any data in
URI.

http://tools.ietf.org/html/rfc2397



I have considered this, but given that these URL-like strings would be
mainly used directly by users on the command-line, I think that
"base64:" is more user friendly than "data:;base64,".


Hmm... user friendly to me means not having to remember odd proprietary 
exceptions. It's easier to remember what's a standard because in theory 
it will always be the same no matter what piece of software is I'm using.



--
John Dennis 

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Data source-agnostic parameters

[John Dennis]

On 08/06/2012 10:10 AM, Alexander Bokovoy wrote:

On Mon, 06 Aug 2012, Jan Cholasta wrote:

Dne 6.8.2012 15:20, Simo Sorce napsal(a):

On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:

Hi,

while thinking about , I
had an idea how to make loading data from files available for all
parameters:

I think we can use URI-like strings in parameter values that the CLI
would interpret and extract the wanted information from them (similar to
what openssl does in the -pass command line option, see PASS PHRASE
ARGUMENTS in openssl(1)).

So, instead of adding a new parameter as a file-accepting alternative to
any existing parameter (i.e. what is suggested in the ticket), the user
would be able to specify the file in a URI-like string:

(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub

vs.

(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

and the CLI would take care of reading the file and using its contents
as the parameter value.

This could be extended with additional URI(-like) schemes:

- data: - use  as the value (useful for escaping values
that look like URIs, but you don't want them to be treated as such)
- base64: - use the value of base64 decoded  (useful for
--delattr on ugly raw binary values)
- fd: - read value from file descriptor 
- env: - read value from environment variable 
- ask: - always prompt interactively for the value
- default: - use default value, never prompt interactively

Thoughts?


How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?

Simo.



You can escape them like this: --someparam data:actual://uri/string

As for backward compatibility, this change has the potential to break
things (user scripts which use the CLI, etc.), but AFAIK there is no
parameter in IPA which expects URI string values specifically, so the
impact would be miminal IMHO.


I don't think you need to invent anything here. RFC2397 is available for
long time and provides already effective way to represent any data in
URI.

http://tools.ietf.org/html/rfc2397


I think it would be much better to follow RFC's including the one 
Alexander cited above.


Rather than

$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

shouldn't it be:

$ ipa user-mod --sshpubkey=file:///.ssh/id_rsa.pub


I'm not sure we need or want to pass file descriptors and I wonder about 
the security implications of reading from environment variables. So I'm 
not sure about supporting the fd and env input.


I don't think we need 'default' either, if the parameter does not begin 
with URI syntax then it's processes just as before.


I can see a value in 'ask', but I'd rather see this expressed as a URI 
scheme.


--
John Dennis 

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Data source-agnostic parameters

[Jan Cholasta]

Dne 6.8.2012 16:10, Alexander Bokovoy napsal(a):

On Mon, 06 Aug 2012, Jan Cholasta wrote:

Dne 6.8.2012 15:20, Simo Sorce napsal(a):

On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:

Hi,

while thinking about , I
had an idea how to make loading data from files available for all
parameters:

I think we can use URI-like strings in parameter values that the CLI
would interpret and extract the wanted information from them
(similar to
what openssl does in the -pass command line option, see PASS PHRASE
ARGUMENTS in openssl(1)).

So, instead of adding a new parameter as a file-accepting
alternative to
any existing parameter (i.e. what is suggested in the ticket), the user
would be able to specify the file in a URI-like string:

(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub

vs.

(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

and the CLI would take care of reading the file and using its contents
as the parameter value.

This could be extended with additional URI(-like) schemes:

   - data: - use  as the value (useful for escaping values
that look like URIs, but you don't want them to be treated as such)
   - base64: - use the value of base64 decoded  (useful for
--delattr on ugly raw binary values)
   - fd: - read value from file descriptor 
   - env: - read value from environment variable 
   - ask: - always prompt interactively for the value
   - default: - use default value, never prompt interactively

Thoughts?


How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?

Simo.



You can escape them like this: --someparam data:actual://uri/string

As for backward compatibility, this change has the potential to break
things (user scripts which use the CLI, etc.), but AFAIK there is no
parameter in IPA which expects URI string values specifically, so the
impact would be miminal IMHO.


I don't think you need to invent anything here. RFC2397 is available for
long time and provides already effective way to represent any data in
URI.

http://tools.ietf.org/html/rfc2397



I have considered this, but given that these URL-like strings would be 
mainly used directly by users on the command-line, I think that 
"base64:" is more user friendly than "data:;base64,".


Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Data source-agnostic parameters

[Alexander Bokovoy]

On Mon, 06 Aug 2012, Jan Cholasta wrote:

Dne 6.8.2012 15:20, Simo Sorce napsal(a):

On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:

Hi,

while thinking about , I
had an idea how to make loading data from files available for all
parameters:

I think we can use URI-like strings in parameter values that the CLI
would interpret and extract the wanted information from them (similar to
what openssl does in the -pass command line option, see PASS PHRASE
ARGUMENTS in openssl(1)).

So, instead of adding a new parameter as a file-accepting alternative to
any existing parameter (i.e. what is suggested in the ticket), the user
would be able to specify the file in a URI-like string:

(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub

vs.

(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

and the CLI would take care of reading the file and using its contents
as the parameter value.

This could be extended with additional URI(-like) schemes:

   - data: - use  as the value (useful for escaping values
that look like URIs, but you don't want them to be treated as such)
   - base64: - use the value of base64 decoded  (useful for
--delattr on ugly raw binary values)
   - fd: - read value from file descriptor 
   - env: - read value from environment variable 
   - ask: - always prompt interactively for the value
   - default: - use default value, never prompt interactively

Thoughts?


How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?

Simo.



You can escape them like this: --someparam data:actual://uri/string

As for backward compatibility, this change has the potential to break 
things (user scripts which use the CLI, etc.), but AFAIK there is no 
parameter in IPA which expects URI string values specifically, so the 
impact would be miminal IMHO.


I don't think you need to invent anything here. RFC2397 is available for
long time and provides already effective way to represent any data in
URI.

http://tools.ietf.org/html/rfc2397


--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Data source-agnostic parameters

[Jan Cholasta]

Dne 6.8.2012 15:20, Simo Sorce napsal(a):

On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:

Hi,

while thinking about , I
had an idea how to make loading data from files available for all
parameters:

I think we can use URI-like strings in parameter values that the CLI
would interpret and extract the wanted information from them (similar to
what openssl does in the -pass command line option, see PASS PHRASE
ARGUMENTS in openssl(1)).

So, instead of adding a new parameter as a file-accepting alternative to
any existing parameter (i.e. what is suggested in the ticket), the user
would be able to specify the file in a URI-like string:

(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub

vs.

(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

and the CLI would take care of reading the file and using its contents
as the parameter value.

This could be extended with additional URI(-like) schemes:

- data: - use  as the value (useful for escaping values
that look like URIs, but you don't want them to be treated as such)
- base64: - use the value of base64 decoded  (useful for
--delattr on ugly raw binary values)
- fd: - read value from file descriptor 
- env: - read value from environment variable 
- ask: - always prompt interactively for the value
- default: - use default value, never prompt interactively

Thoughts?


How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?

Simo.



You can escape them like this: --someparam data:actual://uri/string

As for backward compatibility, this change has the potential to break 
things (user scripts which use the CLI, etc.), but AFAIK there is no 
parameter in IPA which expects URI string values specifically, so the 
impact would be miminal IMHO.


Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Data source-agnostic parameters

[Simo Sorce]

On Mon, 2012-08-06 at 10:55 +0200, Jan Cholasta wrote:
> Hi,
> 
> while thinking about , I 
> had an idea how to make loading data from files available for all 
> parameters:
> 
> I think we can use URI-like strings in parameter values that the CLI 
> would interpret and extract the wanted information from them (similar to 
> what openssl does in the -pass command line option, see PASS PHRASE 
> ARGUMENTS in openssl(1)).
> 
> So, instead of adding a new parameter as a file-accepting alternative to 
> any existing parameter (i.e. what is suggested in the ticket), the user 
> would be able to specify the file in a URI-like string:
> 
> (use new parameter --sshpubkeyfile)
> $ ipa user-mod --sshpubkey="ssh-rsa  ..."
> $ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub
> 
> vs.
> 
> (use file URI-like string)
> $ ipa user-mod --sshpubkey="ssh-rsa  ..."
> $ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub
> 
> and the CLI would take care of reading the file and using its contents 
> as the parameter value.
> 
> This could be extended with additional URI(-like) schemes:
> 
>- data: - use  as the value (useful for escaping values 
> that look like URIs, but you don't want them to be treated as such)
>- base64: - use the value of base64 decoded  (useful for 
> --delattr on ugly raw binary values)
>- fd: - read value from file descriptor 
>- env: - read value from environment variable 
>- ask: - always prompt interactively for the value
>- default: - use default value, never prompt interactively
> 
> Thoughts?

How do you handle values that are actually URI strings, how do you tell
the command to not interpret them ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] Data source-agnostic parameters

[Jan Cholasta]

Hi,

while thinking about , I 
had an idea how to make loading data from files available for all 
parameters:


I think we can use URI-like strings in parameter values that the CLI 
would interpret and extract the wanted information from them (similar to 
what openssl does in the -pass command line option, see PASS PHRASE 
ARGUMENTS in openssl(1)).


So, instead of adding a new parameter as a file-accepting alternative to 
any existing parameter (i.e. what is suggested in the ticket), the user 
would be able to specify the file in a URI-like string:


(use new parameter --sshpubkeyfile)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkeyfile=.ssh/id_rsa.pub

vs.

(use file URI-like string)
$ ipa user-mod --sshpubkey="ssh-rsa  ..."
$ ipa user-mod --sshpubkey=file:.ssh/id_rsa.pub

and the CLI would take care of reading the file and using its contents 
as the parameter value.


This could be extended with additional URI(-like) schemes:

  - data: - use  as the value (useful for escaping values 
that look like URIs, but you don't want them to be treated as such)
  - base64: - use the value of base64 decoded  (useful for 
--delattr on ugly raw binary values)

  - fd: - read value from file descriptor 
  - env: - read value from environment variable 
  - ask: - always prompt interactively for the value
  - default: - use default value, never prompt interactively

Thoughts?

Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel