Paul Sokolovsky <[email protected]> writes:

> Hello,
>
> On Tue, 27 Nov 2012 20:15:55 +0100
> Danilo Šegan <[email protected]> wrote:
>
>> Heya Andy,
>> 
>> У уто, 27. 11 2012. у 12:24 -0600, Andy Doan пише:
>> 
>> > yes, we have ways of transferring a file from target->host in our 
>> > dispatcher. We could use that so that our private key only has to
>> > live on our actual server(s).
>> 
>> Cool.
>> 
>> > > Since we'd like to switch to API-based publishing as well, I
>> > > suppose that means we could also have a key stored in the
>> > > database for pushing stuff over: does that make sense?
>> > 
>> > So you are saying we might need a new "publishing key". That seems
>> > fine, just a slightly different config option for our setup I'd
>> > think.
>> 
>> Yeah, mostly for the sanity (and symmetry) of our existing set up.
>> The way it's currently set up is that our publishing framework
>> accepts SSH connections with very limited permissions:
>> 
>>  - upload step which only allows sftp-ing
>> to /srv/snapshots.linaro.org/uploads which is not publicly accessible
>>  - trigger step which reshuffles the files into appropriate location
>> (restricted to running publish_to_snapshots.py script)
>> 
>> We use separate user accounts on mombin with two different SSH keys
>> (this was requested by IS so they could limit possible actions for
>> these passphrase-less SSH keys).  
>
> It should be also added that these SSH keys for additional security
> allow login only from a specific IP address. So, we indeed would need
> to publish from LAVA master, not directly from target boards (we have
> the same thing in Jenkins).

While I agree publishing from the master makes sense, the conclusion you
draw here is not valid -- all requests from the lab appear to come from
the same IP address by the wonders of NAT.  We have 5 IP addresses from
our ISP but currently only use one.

Cheers,
mwh

_______________________________________________
linaro-validation mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-validation

Reply via email to