On Wed, Aug 9, 2017 at 5:27 PM, Fabrice Bacchella
<fabrice.bacche...@orange.fr> wrote:
>> Le 9 août 2017 à 16:03, Yedidyah Bar David <d...@redhat.com> a écrit :
>> On Wed, Aug 9, 2017 at 4:35 PM, Fabrice Bacchella
>> <fabrice.bacche...@orange.fr> wrote:
>>> oVirt own a private ssh keys that it can use to do remote installation on
>>> host, instead of using a password. But I didn't found at
>>> https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/rest_api_guide/
>>> how to find it's public key. Where can I found it ?
>> For the public key, see:
>> http://www.ovirt.org/develop/release-management/features/infra/pki/#services
>> Not sure if it's part of the API, or if it should be - adding Juan.
> I'm writing code to create automatically datacenter/cluster/host, without 
> storing the root password in scripts.

How do you provision your hosts? If using pxe or cloud-init or
something like that, you can arrange to add a public key to the
authorized keys during installation, and then you can use the matching
private key later on for management, with no relation to oVirt.

> Having a way to have the sdk automatically get it would be nice. Having a 
> known URL is good enough, but it it's not obvious to find it.

Doc patches/Blog posts/etc. are welcome :-)

> The resource is missing content-disposition, and the date is not optimal:
> $ curl -JORLkv 
> 'https://XXXX/ovirt-engine/services/pki-resource?format=OPENSSH-PUBKEY&resource=engine-certificate'
> < HTTP/1.1 200 OK
> < Date: Wed, 09 Aug 2017 14:22:49 GMT
> < Server: Apache
> < Set-Cookie: locale=en_US; path=/; HttpOnly; Max-Age=2147483647; 
> Expires=Mon, 27-Aug-2085 17:36:56 GMT
> < Content-Type: text/plain; charset=ISO-8859-1
> < Content-Length: 394
> $ls
> ...
> pki-resource\?format\=OPENSSH-PUBKEY\&resource\=engine-certificate
> See curl(1)
>        -J, --remote-header-name
>               (HTTP)  This  option tells the -O, --remote-name option to use 
> the server-specified Content-Disposition filename instead of extracting a
>               filename from the URL.
>               If the server specifies a file name and a file with that name 
> already exists in the current working directory it will not be overwritten
>               and an error will occur. If the server doesn't specify a file 
> name then this option has no effect.
>               There's  no  attempt  to  decode %-sequences (yet) in the 
> provided file name, so this option may provide you with rather unexpected file
>               names.
>               WARNING: Exercise judicious use of this option, especially on 
> Windows. A rogue server could send you the name of a  DLL  or  other  file
>               that could possibly be loaded automatically by Windows or some 
> third party software.

Users mailing list

Reply via email to