<br><div class="gmail_quote">2009/2/11 Mike McLean <span dir="ltr"><<a href="mailto:mikem@redhat.com">mikem@redhat.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Greg Swift wrote:<br>
> On Tue, Feb 10, 2009 at 19:28, ³Â±«×Î <<a href="mailto:chenbaozi@gmail.com">chenbaozi@gmail.com</a>> wrote:<br>
</div><div class="Ih2E3d">>> At the beginning of wiki "<br>
>> <a href="https://fedoraproject.org/wiki/Koji/ServerHowToProposed" target="_blank">https://fedoraproject.org/wiki/Koji/ServerHowToProposed</a>", it is mentioned<br>
>> that - "<br>
>><br>
>>> Builders<br>
>>> By default these will be referred to as *kojibuilderX*, but can also<br>
>>> be the hostname(s) of the boxes that will be setup as builders. TODO: can<br>
>>> also or should ?<br>
>>><br>
>> "<br>
>> I think this may be why I can't make it correctly. What I'm confused now is<br>
>> what the mentioned "hostname(s)".<br>
><br>
> Yeah, as you can tell I was even a bit confused by that section (thus the<br>
> TODO with the question, I was hoping for some input). The impression I got<br>
> from the original box was that kojibuilder1, kojibuilder2 etc was the naming<br>
> they were using on their hosts, so by having the username be the same it<br>
> helped you tie the koji user to the build box. When I implemented this on<br>
> my network I used the name of the box as the koji userid. This does not<br>
> cause koji to automatically associate the two, but allows you as the admin<br>
> to make the association. If someone has a better explanation i'm open to<br>
> suggestions since my attempt at clarification didn't quite hit the mark.<br>
<br>
</div>The koji database has tables for both hosts and users. Each host has an<br>
associated user that the host authenticates as. Due to a bad choice on<br>
my part, both the host table and user table have a 'name' column, so it<br>
is theoretically possible (if you muck around in the db manually) to<br>
create a situation where the name of the host entry is not the same as<br>
the name of the associated user entry. /However/ the cli (and the api)<br>
do not facilitate this. In all normal situations the name of the host<br>
and the name of the associated user will be the same.<br>
<br>
When you run 'koji add-host', the hub will create both the host and user<br>
entries. There is no need to manually add a user for the host, the<br>
add-host command will do it for you. If a user of the same name already<br>
exists (host or not) the command will fail.<br>
<br>
You are free to name the hosts anything you like. You do not have to use<br>
the fqdn or anything.<br>
</blockquote><div><br>so in the example:<br><pre>admin-user-name@kojihub$ koji add-host <a href="http://kojibuilder1.example.com">kojibuilder1.example.com</a> i386 x86_64<br><br>You could actually just put kojibuilder1 and then in /etc/koji/kojid.conf do this:<br>
<br>user = kojibuilder1<br><br>If that is the case, awesome.. that through me off because the original documentation used the <a href="http://kojibuilder1.example.com">kojibuilder1.example.com</a>. Should I adjust that to take that into consideration in the Proposed doc? <br>
</pre> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
The user kojid authenticates as determines which host it represents. The<br>
machine it is running on is not a direct factor.<br>
<div class="Ih2E3d"><br>
> Anyways, in the Builder Setup section you add the host to koji's database<br>
> and then on the builder you specify the host as the user in<br>
> /etc/kojid/kojid.conf, these should match. It was my impression that this<br>
> should match the user name that you created in the SSL configuration. I'm<br>
> not sure if you are using SSL, and that might be adding to the confusion if<br>
> you are not *shrug*<br>
<br>
</div>Authentication in koji can get messy. Sometimes when getting started, it<br>
is easier to start out using password auth and tackle ssl/krb later.<br>
Note that you should not use password auth in production.<br>
<div></div></blockquote><div><br>I guess i can see that point since the ssl certificates were one of the first things I got hung up on.<br><br>-greg <br></div></div><br>