Server for Guix Hydra/Slave ?

Server for Guix Hydra/Slave ?

[Nils Gillmann]

So a friend is about to drop one of his dedicated servers, and we
are discussing what to do with it... another tor relay, some
other project, and I had the idea, wel maybe we could use it?

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

Somewhere around 100 or 150 MB/s in connection if I read the
conversation right.


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

Re: Server for Guix Hydra/Slave ?

[Nils Gillmann]

Addition: no limitations in bandwidth per month.
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

Re: Server for Guix Hydra/Slave ?

[Nils Gillmann]

Nils Gillmann <niasterisk@grrlz.net> writes:

> So a friend is about to drop one of his dedicated servers, and we
> are discussing what to do with it... another tor relay, some
> other project, and I had the idea, wel maybe we could use it?
>
> 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
>
> Somewhere around 100 or 150 MB/s in connection if I read the
> conversation right.
>
>
> What do you think?

If this inital post was written a bit strange and off in words,
what I meant to express was: hey, look. I got a server with
uncapped bandwidth, these specs, I could maybe (not sure about
the specifics as I am not an ovh customer myself yet) get more
disks if needed, setup any OS I want and offer it to us (Guix) as
a third mirror, hydra slave, or whatever you can think off we
need right now the most. I guess it is physically located in
France.


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

Re: Server for Guix Hydra/Slave ?

[Andreas Enge]

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 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.

Andreas

Re: Server for Guix Hydra/Slave ?

[Nils Gillmann]

Andreas Enge <andreas@enge.fr> 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

Re: Server for Guix Hydra/Slave ?

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> 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.

If you want to try this, just run nginx with the configuration that is
available at:

  http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf

Ludo’.

Re: Server for Guix Hydra/Slave ?

[Nils Gillmann]

ludo@gnu.org (Ludovic Courtès) writes:

> Andreas Enge <andreas@enge.fr> skribis:
>
>> 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.
>
> If you want to try this, just run nginx with the configuration that is
> available at:
>
>   http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf

Okay, thanks.
The obvious part from a quick look at the config is, to change
server_name to make it addressable at for example
mirror.libertad.pw, the rest will just be redirected at
hydra.gnu.org
(not much practical experience with reverse proxies here).

So mirror.gnu.org is not like rsync, but more like webcache
servers.

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

Re: Server for Guix Hydra/Slave ?

[Andreas Enge]

On Sun, Mar 06, 2016 at 06:42:11PM +0100, Nils Gillmann wrote:
> So mirror.gnu.org is not like rsync, but more like webcache
> servers.

Exactly!

Andreas

Re: Server for Guix Hydra/Slave ?

[Nils Gillmann]

To close this thread:

I had some discussion and listing reasons on the weekend against
OVH again, which is why I won't do this right here, right now.
Which is also why OVH is off the table for me for everything.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en