On 27/03/16 18:58, Bjarne Saltbaek wrote:
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
I'm pretty sure we are talking about the same thing. Remember that a
docker container isn't _just_ the app you intend to run, it includes the
rootfs and all the other dependencies.
And yes, my largest online always-on resource is now aarch64.
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.
Do we need this for all packages? Or only for the ones that require
proprietary patching?
>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.
I know the feeling. The main redsleeve site still isn't up after the
upgrade to the new server. Since it's WordPress, which has somewhat
patchy security history, I'm hoping to implement having it somewhere
safe behind a firewall and export it as a flattened, static content that
can run on a server with no CGI or PHP capabilities at all.
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.
If they aren't running, I don't think they'll burn a meaningful number
of CPU cycles, and with 128GB I have RAM to burn.
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?).
I prefer to have something with as much damage potential as distro
signing keys to be air gapped.
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
OK, I'll get this one ready for you. Please send me your address off list.
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 ?
I suspect it's to do with the fact that many MSPs have started having
extra requirements of mail sending machines that aren't strictly
required according to the RFCs. For example, I've had at least gmx and
yahoo start to bounce list emails because the reverse DNS lookup wasn't
to their liking. I've had this fixed from my ISP side recently, so
hopefully the problem will go away.
Gordan
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
