Re: Server for Guix Hydra/Slave ?

[Nils Gillmann]

Andreas Enge <address@hidden> writes:

> Hi Nils,
>
> thanks for the generous offer of a server donation!
>
> So what could be done?
>
> On Thu, Mar 03, 2016 at 11:48:11PM +0100, Nils Gillmann wrote:
>> It's a 36€ / year server (I don't believe in the security of OVH,
>> but others say it's okay, I personally favor in-berlin.de over
>> most providers I had), specs:
>> Mainboard Intel Corporation DN2800MT CPU Intel(R) Atom(TM) CPU
>> N2800 @ 1.86GHz Cores : 4 Cache : 512 KB Speed : 1862 MHz RAM 1 x
>> 2048 MB
>> Atom™ N2800 640 346 2c / 4t  1.86 GHz+ 2 GB 500 GB 100 Mbit/s /128
>
> The specs look a bit too low to make it useful as a build slave, compared
> to what we already have; especially the low RAM could make a few packages
> fail, I think. Even more so since the bottleneck right now is not compilation
> power, but processing power by the hydra backend. Also, as you mention,
> there is a security question: Right now, we implicitly trust all build
> machines through the signature of hydra. If we add too many "random" machines
> in "random" data centres, this will not help the trust in the binaries.

On trust:
I agree. I personally distrust OVH/kimsufi due to their low
prices for dedicated servers, and the statements of other
sysadmins about OVH in general and one friend in france said,
that ovh are more friendly towards law enforcement agencies than
they would have to be in france.
I would be curious to hear if these assumptions or experiences
about ovh datacenters reflect with other people who were
customers with them or live in france and possibly get news about
breaches / LEA news related to OVH i don't get.
The statement and couple of years experience of a friend running
multiple services at OVH says they are better than his previous
ISP, 1and1.
Back then, I was looking for optimal datacenters for other
purposes than the ones I have now.
I question the security of every machine I can not control myself
down to the hardware and have no ultimate trust in anything I
use, even when I consider myself fairly experienced with servers
and capable of learning and solving problems.
For example, I would trust IN-Berlin with colocation. but I would
not trust them ultimately as servers itself are a security
failure. I trust IN-Berlin enough to run a tor relay with them,
and enough to introduce them to GuixSD at some point in the future.

On specs:
Okay, 2GB is really not much, as maybe stated in the 2nd or 3rd
email I might be able to upgrade ram. For the rest I think
there's not much I can do right now.

> On the other hand, an additional mirror cache could always be useful;
> with mirror.guixsd.org, we are experimenting right now, so I do not know
> whether an additional mirror will make a big difference or not. But the
> interesting thing is that this could be done completely independently of the
> central hydra infrastructure: Just set it up yourself and advertise it on the
> list or on IRC, and then people can use it. You should probably avoid
> downloading all the content on hydra and just act as a cache upon an external
> request. There would be no security implication, as the packages are signed
> by hydra.

I don't know enough of the software hydra to do this right
now. What do you recommend me to read into if I wanted to setup
something like GNUnet e.V. did with hydra.gnunet.org or simply a
mirror of hydra.gnu.org?
If it's just a simple webserver cache or rsync thing, I think we
can work it out, just to know the basics about how would be
good.

If the security is troublesome for me or someone else, I will
stop it and have a dedicated server over at IN-Berlin at some
point in the near future. A simple rsync mirror I could serve
there right now on virtual machines, my own dedicated server
would just be an increased trust for myself.

>
> Andreas

Hi Andreas,

have you read the messages I appended to correct myself and
express it in a different way?

Rest is inline comments above.

>
>
>

-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en