From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nils Gillmann Subject: Re: Server for Guix Hydra/Slave ? Date: Sat, 05 Mar 2016 13:15:47 +0100 Message-ID: <878u1xglxo.fsf@grrlz.net> References: <87oaav9o0k.fsf@grrlz.net> <20160305110411.GA23510@solar> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acB85-0008OC-SU for guix-devel@gnu.org; Sat, 05 Mar 2016 07:16:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1acB81-0008GV-Rt for guix-devel@gnu.org; Sat, 05 Mar 2016 07:16:17 -0500 Received: from plane.gmane.org ([80.91.229.3]:42996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acB81-0008GL-Km for guix-devel@gnu.org; Sat, 05 Mar 2016 07:16:13 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1acB7z-00039g-Be for guix-devel@gnu.org; Sat, 05 Mar 2016 13:16:11 +0100 Received: from x5d83e7a1.dyn.telefonica.de ([93.131.231.161]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Mar 2016 13:16:11 +0100 Received: from niasterisk by x5d83e7a1.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Mar 2016 13:16:11 +0100 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org Andreas Enge 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