On Tue, Oct 2, 2012 at 12:25 PM, zperry <zack.pe...@sbcglobal.net> wrote:
> Hi Les,
>
> Finally, the first sentence in "Distributed builds" wiki and the list from
> Kohsuke Kawaguchi started making sense to me. Thank you once more for
> sharing your experience.
>
> Regarding the list (shown below, and somewhat shortened and edited by me,
> e.g. s#/var/jenkins#/var/lib/jenkins#), could you please comment on
>
> #1 (the bold faced part). Is it really necessary? For example, the uid/gid
> usage in Fedora differ quite much from that of Ubuntu. I doubt even NIS
> would make it simpler. My approach is to review the /etc/passwd and
> /etc/group of all target platforms, pick a pair of uid/gid that are not used
> by all, and assign the pair for Jenkins' use (on both the master and
> slaves). The packages provided on Jenkins pkg site (e.g
> http://pkg.jenkins-ci.org/redhat/) don't make this task transparent, so the
> above step seems to be necessary.
> #7. Do you think it's a nearly optimal way to do as part of setting up a
> slave?
> #8. IMHO this is optional. What would you recommend?
>
> 1. Each computer has an user called jenkins and a group called jenkins. All
> computers use the same UID and GID. (If you have access to NIS, this can be
> done more easily.) This is not a Jenkins requirement, but it makes the slave
> management easier.
The main (maybe only) reason this would matter is if you have common
NFS mounts across the slaves where uid matters. I have a read-only
export of common libs/tools shared via nfs and samba but it is all
public. For things I want back from the build, I let jenkins archive
the build artifacts specified for the job.
> 2. On each computer, /var/lib/jenkins directory is set as the home directory
> of
> user jenkins. Again, this is not a hard requirement, but having the same
> directory layout makes things easier to maintain.
Doesn't really matter, especially if you don't install the jenkins
package and create the user yourself. You do need to pay attention in
partition layout to have space for jenkin's workspace.
> 3 . All machines run sshd. Windows slaves run cygwin sshd.
Yes, for linux - and probably OK for windows. My windows slaves are
VM's cloned after installing a bunch of tools including setting up the
jenkins slave as service. In that scenario you just have to edit the
slave's own name in the jenkins-slave.xml file to match the
newly-added node in jenkins to come up working.
> 4. All machines have ntpdate client installed, and synchronize clock regularly
> with the same NTP server.
Yes, this is pretty much essential unless you are running VMs with a
good sync with their host clock.
> 5. Master's /var/lib/jenkins have all the build tools beneath it.
I don't build anything on the master. I do export the NFS/samba
share to the slaves from the jenkins server but that's just a matter
of convenience.
> 6. Master's /var/lib/jenkins/.ssh has private/public key and authorized_keys
> so
> that a master can execute programs on slaves through ssh, by using public
> key authentication.
Yes, but normally the only thing it needs to do directly is copy over
the slave.jar and execute it. The rest is done internally with java
remoting magic.
> 7. On master, I have a little shell script that uses rsync to synchronize
> master's /var/lib/jenkins to slaves (except /var/lib/jenkins/workspace) I
> use this to replicate tools on all slaves.
I avoid that with the common nfs/samba export. Copying just gives a
different tradeoff for setup time/disk usage/speed.
> 8. (optional) /var/lib/jenkins/bin/launch-slave is a shell script that Jenkins
> uses to execute jobs remotely.
Jenkins should take care of that by itself with the 'Jenkins SSH slaves plugin'.
> 9. Finally all computers have other standard build tools like svn and cvs
> installed and available in PATH.
Yes, it is painful to try to fight with the rpm/deb package managers
in that respect. In cases where you want to build with non-standard
versions of libs or tools, you can supply paths in the jenkins job,
but you might end up needing either a chroot environment or a whole
different slave to avoid conflicts. For example, on windows it is
easy enough to have multiple versions of the boost libs available and
specify which you want in your job, but I haven't come up with a good
way to do that on linux where there is an expected/packaged version
and changing it conflicts with other packages.
--
Les Mikesell
lesmikes...@gmail.com
