<davidlt[m]>
Because it's host server (which also runs kojid in our setup), which is aarch64 AWS VM.
<davidlt[m]>
The "task" of that kojid to "take" jobs like tagged, etc. that has no actual compute requirements.
<Entei[m]>
davidlt[m]: And the name of the builder is fedora-x86_64?
<davidlt[m]>
So it is configured with a very large maxjobs setting.
<davidlt[m]>
We migrated to a new VM, and thus from x86_64 to aarch64.
<Entei[m]>
davidlt[m]: Oh I see
<davidlt[m]>
I cannot change machine host name without generating a new certificate for it.
<davidlt[m]>
I can tell you that the official guide how to setup Koji has some things wrong/missing.
<davidlt[m]>
Then you will also find that tweaking is something you need to do to find a balance between apache / postresql to handle that amount of load you plan to have.
<davidlt[m]>
That means the number of connections, reserved connected, share memory buffer sizes, etc. on postgre side.
<Entei[m]>
davidlt[m]: If you could point some things out, that would be really helpful. I have been reading and learning from it for about 4-5 days now. I finally completed the server set up, but found things missing, presumably because the article hasn;t been updated in a while
<davidlt[m]>
You also need to decide on one thing nowish.
<davidlt[m]>
Do you need a full proper Fedora infra, or only something what we run which is super minimal setup.
<Entei[m]>
For eg, in generating CSRs for components, there's a line `cat ssl.cnf | sed 's/insert_hostname/'${user}'/'> ssl2.cnf`, but there's no string like *insert_hostname* in the ssl.cnf file
<davidlt[m]>
That means pungi for repos and composes, Bodhi for updates, RPM singing infra, etc. Do you need dist-git overlay? Do you need to cache sources, or do you plan to use the ones from Fedora infra directly, etc.
<davidlt[m]>
I haven't touched that file in many years :)
<Entei[m]>
davidlt[m]: Umm... I don't really know much of this tbh. Is it required for building my spin of Fedora?
<davidlt[m]>
Checking, I don't have any insert_hostname
<davidlt[m]>
That sounds like something template.
<Entei[m]>
davidlt[m]: How are you configuring the server then?
<davidlt[m]>
WE are running with SSL/TLS, but remember that we had been doing that for years now.
<davidlt[m]>
Ah
<davidlt[m]>
This is for the user setup.
<davidlt[m]>
I assume openssl genrsa generates that config.
<davidlt[m]>
Btw, don't use 2048 for RSA.
<Entei[m]>
One thing after I set this thing up, is request someone to let me edit that page.
<Entei[m]>
davidlt[m]: 4096 bit then?
<davidlt[m]>
Regarding what is required depends on how "proper" you want things to do be.
<davidlt[m]>
Yeah.
<davidlt[m]>
IIRC some components would require kerberos setup.
<Entei[m]>
Is it feasible to run everything on one machine? Suppose I set up every components including the kojihub, psql, kojibuilders on one single RISCV VM
<davidlt[m]>
That's what we do right now. We moved everything to a single server, but it doesn't need to be riscv.
<davidlt[m]>
It can be x86_64, aarch64, ppc64le, etc.
<davidlt[m]>
Only builders needs to be riscv64.
<Entei[m]>
davidlt[m]: This riscv koji instance, did you setup yourself?
<davidlt[m]>
Yes
<davidlt[m]>
And helped to setup another in China (run by RH folks).
<davidlt[m]>
And then there is some magical glue that you will need to figure out as you go and actually run Koji.
<davidlt[m]>
Like postgre DB tunning. That really depends how hard you use your koji hub APIs, how many builders, etc.
<davidlt[m]>
We run a very minimal setup, enough to build and produce repositories and disk images.
<davidlt[m]>
Not a proper thing, but we plan/hope to become a proper arch in the main Koji infra thus we don't exactly care (unless we need to).
<davidlt[m]>
I don't what your are your or/and you employer requirements.
<davidlt[m]>
Like we don't sign our RPMs. That's fine with me, don't trust our RPMs basically :)
<davidlt[m]>
That's no-go if something like that is do be used by some paying customer.
<davidlt[m]>
I don't know, but IIUC from the talks with folks that some components would require usage of Kerberos (krb5) for auth instead of SSL/TLS stuff with self-signed cert.
<davidlt[m]>
There are also better ways to do it these days too (Let's Encrypt for example).
<davidlt[m]>
Any of these things change the instructions.
<Entei[m]>
Right now I am kind of in the same boat, I just need to get some things working for now. This distro wouldn't be official anyway, just for internal use probably.
<Entei[m]>
I come from Embedded background, but before getting into drivers, I need to get this OS working on emulator. Learning a lot of CS tools and concepts along the way, especially setting up Koji
<davidlt[m]>
In that case just spin a VM somewhere x86_64 or aarch64, and try to follow Koji setup instructions.
<davidlt[m]>
If something is off/missing/etc. attempt to find if something changed otherwise simply ignore.
<davidlt[m]>
Get it up and running, then you can adjust things.
<davidlt[m]>
Btw, for storage (especially /mnt/koji) I highly advice to use NVMe storage.
<davidlt[m]>
I also advice not to enable email / notification support. Especially if you are a single person working on it.
<davidlt[m]>
Save your indox from spam :)
<Entei[m]>
davidlt[m]: Yeah that's the plan. I've been trying to understand concepts actually, which is taking time. For eg, I was very confused in first step, so I took about 3 days to get an overview of digital certificates. From hashing, diffie-hellman, encryption, signature...
<Entei[m]>
Likewise I am trying to understand what's the use of PSQL database and some apache configurations
<Entei[m]>
Btw, when I am using Koji and bootstrapping it with packages (either manually or from a repo I create), I don't have to worry about the chroot creation right? Like how for using mock, you would have to provide a mock config describing the repositories and the packages to be installed.
<davidlt[m]>
You don't need to.
<davidlt[m]>
Koji will generate mock config before calling mock.
<Entei[m]>
davidlt[m]: That is very convenient.
<Entei[m]>
Is core group the minimum amount of packages I have to populate koji with to start building all packages comfortably?
<davidlt[m]>
No/yes/complicated.
<Entei[m]>
davidlt[m]: Ok so I take that as a yes
<davidlt[m]>
You will have to configure Koji COMPS (groups of packages). That will mean "build", "appliance", source, etc.
<davidlt[m]>
So for each tasks it will create different kind of chroot in which the task is executed.
<davidlt[m]>
If bootstrap is enabled (and it should) it should happen twice.
<davidlt[m]>
The 1st one to have a new DNF working, then using then the final chroot is constructed.
<davidlt[m]>
(in some cases host DNF is not capable of creating the final chroot)
fuwei has quit [Ping timeout: 245 seconds]
jednorozec has quit [Ping timeout: 264 seconds]
jednorozec_ has joined #fedora-riscv
jednorozec_ is now known as jednorozec
fuwei has joined #fedora-riscv
alexfanqi has quit [Ping timeout: 240 seconds]
alexfanqi has joined #fedora-riscv
zsun has joined #fedora-riscv
esv has quit [Remote host closed the connection]
zsun has quit [Quit: Leaving.]
fuwei has quit [Ping timeout: 264 seconds]
esv has joined #fedora-riscv
fuwei has joined #fedora-riscv
<davidlt[m]>
This is interesting: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
<davidlt[m]>
Maybe we should give it a try.
<davidlt[m]>
Almost all Haskell packages now have a different ABI (C backend replaced by LLVM backend)
jcajka has quit [Quit: Leaving]
cwt[m] has quit [Server closed connection]
cwt[m] has joined #fedora-riscv
Guest27 has joined #fedora-riscv
<Guest27>
hello
brianmcarey[m] has joined #fedora-riscv
Cambridge[m] has joined #fedora-riscv
Guest27 has quit [Quit: Client closed]
fuwei has quit [Quit: Konversation terminated!]
Jo[m]1 has quit [Ping timeout: 255 seconds]
davide has quit [Ping timeout: 255 seconds]
brianmcarey[m] has quit [Ping timeout: 255 seconds]
acharles has quit [Ping timeout: 255 seconds]
Kevinsadminaccou has quit [Ping timeout: 255 seconds]
AutiBoyRobotics[ has quit [Ping timeout: 255 seconds]