Hi Gordan.
On 27-03-2016 15:21, Gordan Bobic wrote:
Sound like a good plan. Note that it is only the builders that needs so
run on ARM architecture. The main controller and the web frontend can
run on any architecture (read - cheaper x86_64)
Sure - but it's much more convenient of it's armv5tel (or armv7hl or
aarch64 if you want to build it on CentOS) if I'm intending to run it
on the MP30-AR0. :)
Eh, are we talking about the same thing? the controller and webserver
can run on any os/arch. its only a web server with a python written
backend - "noarch" ;)
But of course if you have unlimited arm ressource available feel free to
run the koji controller and front end on a armv5tel server. it will not
make any difference
True. I use and even better solution - well the same that Fedoraproject,
CentOS etc use. I have stored all .spec files in git and just pull the
spec file from git. So your koji and my koji can pull from the same git
server. We could store it all at GitHub. I just prefer to have a private
git repository since there could be stored sensitive data after all (NSA
go.....)
I would rather like to think that there is nothing sensitive in the
spec files considering we are also making the src.rpm files containing
the spec files available. :p
That is also true. You can always instruct the Makefile for the spec to
get additional configuration from elsewhere.
>If you have instructions I could follow to create reproducible results
>running koji on an armv5tel machine so that I could containerize it on
>the new server, that would be quite awesome.
Sure, the documentation is (still) located at
http://www.saltbaek.dk/dokuwiki/
Erhm, site is up again. was down since Friday when I upgraded the
Synology Diskstation the webserver is running on, sorry.
Also a verification script that checks that all packages in git have a
build profile in koji.
Other than that it has been running for 3-4 weeks now 24/7 unless when
the builders crash - the Banana Pi M3 is the worst (do to poor design).
I'm rather hoping to reduce the entire build farm to a koji docker
container and a builder docker container (or 8, just to make sure that
all the CPU can end up getting used up even during single-threaded
parts of builds).
True. Optimal you can have the koji docker running 24/7. Then spawn a
RSEL6 (armv5tel) or RSEL7 (armv6l or armv7hl) whenever a build is
required. no need to have a idle server running taking up cpu cycles and
RAM.
But maybe I should offer running the sigul server. It would be good
security having the signing server apart from the build system - again
this can run on any type hardware/OS.
I very much prefer to have signing happen on a separate server,
offline, and out of band. When the build pass is complete, we take a
snapshot (gotta love ZFS...), send it over to the signing server,
snapshot that and send it to the FTP server. And except when signing,
the signing server is physically switched off. I don't like the idea
of having the private signing keys on anything that is accessible in
any way from the internet (or can access the internet, except when
sending/receiving the snapshots.
Agreed. best practice. and private key stored on an encrypted partition
(it is stored as AES256 in its sqlite database - dunno if thats secure
enough?).
If you look at my ancient *Plug wiki article here, that explains the
basics of how to boot it off the network:
http://redsleeve.wikia.com/wiki/Install_on_Sheeva/Guru/Dream_Plug
Will do.
LOL! You don't want much, do you! :-p
Most of the mentioned hardware only has 512MB of RAM. The Compulab
A510 has 1GB, the Arndale Octa has 4-ish GB, and the Cornfed Conserver
board has 4GB. The Compulab and Conserver are both in *TX form factor,
which means it's easier to tidy them away into standard cases.
Depending on which ones already gone i would like one or more of them in
the following order:
Cornfed
Arndale
Compulab
All of them will require some research (easiest way may be reverse
engineering instructions for getting debian or ubuntu up and running
on the same machines), cobbling together recent u-boot (ideally
mainline if possible), getting a reasonable LT kernel to build, rpm it
up, producing a publicly consumable (i.e. sanitized) image, and
documenting the process on the wiki, as per the terms of the deal.
No problem. Reverse engineering is one of the most fun things to do 3:)
Btw - can i get [email protected] <mailto:[email protected]> as an
alias/forward to [email protected]
<mailto:[email protected]>
Done. I CC-ed this email to it for testing, so you should get it twice.
Something is working and something is not. I have tested the forward
from another email and this worked. But with your emails i also got a
bounce from Hotmail:
Reporting-MTA: dns;DUB004-OMC2S9.hotmail.com
Received-From-MTA: dns;DUB408-EAS364
Arrival-Date: Sat, 26 Mar 2016 11:42:29 -0700
Final-Recipient:rfc822;[email protected]
Action: delayed
Status: 4.3.5
Diagnostic-Code: smtp;451 4.3.5 <dub004-omc2s9.hotmail.com[157.55.1.148]>:
Client host rejected: Server configuration error
Will-Retry-Until: Mon, 28 Mar 2016 11:42:26 -0700
Maybe a mail loop somewhere or it happened while you were re-configuring ?
BR,
Bjarne
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
