Bootstrapping a new version of Fedora

This is a quick account of what I needed to do to get started with FC5 x86_64

1. Install FC5 x86_64 from DVD

2. Use the install time wizard to configure the system to use kerberos authentication and ldap for user information (point it at Also configure the system to use ntp, it should have picked up the correct ntp servers . This is essential as kerberos requires that the clocks on the client and servers are very close together.

3. Create required fake afs home directories, e.g. /afs/ and chown to the correct user and group (normally something like squinney:people)

4. Log in and do basic setup for building packages

  • Set up rpmbuild directories and .rpmmacros file

5. Use yum to get all packages up-to-date

6. Install required packages:

  • zile, emacs
  • fedora-rpmdevtools

7. Add linux and lcfg users and also add local and lcfg groups

8. kerberos

  • Use kadmin to add the necessary keys to /etc/krb5.keytab

9. amd

  • Install am-utils package
  • Copied over the various amd configs from /var/lcfg/conf/amd/, into /etc/ and editted appropriately
  • Started amd
  • Made all convenience symlinks in / and /pkgs

10. openssh

  • Install audit-libs-devel
  • Build the local version and install packages: openssh openssh-askpass openssh-server openssh-clients
  • Copy over the sshd_config and ssh_config
  • Restart sshd

11. openafs

  • Install kernel-devel packages
  • Install openafs src package from /pkgs/master/srpms/fc5/ed
  • Build userspace and install built packages: openafs-krb5 openafs-kernel-smp openafs-devel openafs-authlibs openafs-client openafs openafs-docs openafs-server openafs-authlibs-devel openafs-kernel-source openafs-kernel
  • Build kernel module and install openafs-kernel package (and openafs-kernel-smp where needed)
  • Edit /usr/vice/etc/ThisCell and /etc/sysconfig/openafs to match the standard dice/informatics setup
  • Restart openafs-client
  • Build and install gafstoken and pam_afs2
  • Alter /etc/pam.d/system-auth so pam_afs2 is used

12. core packages

  • lcfg-buildtools
    • Install perl-Time-Modules
    • Build and install lcfg-buildtools from cvs
  • lcfg-utils
    • Install perl-Template-Toolkit (and dependencies)
    • Build, test and install lcfg-utils from cvs
  • lcfg-ngeneric
    • Build, test and install lcfg-ngeneric from cvs
    • test002 will fail as there is currently no profile for the machine
  • lcfg-file
    • Build, test and install lcfg-file from cvs
    • All tests will fail due to lack of profile for machine
  • lcfg-om, lcfg-authorize, lcfg-nsu
    • Build, test and install
  • lcfg-client
    • Build and install local packages perl-W3C-SAX-XmlParser and perl-W3C-Util-Basekit
    • Build, test and install lcfg-client

Once these lcfg core packages are all installed the next stage is to grab the profile for the machine using rdxprof and then go back and carry out the testing on the component that previously failed. As root do:

rdxprof -u

If all these tests pass then do some real testing of the installed lcfg packages using a simple component which won't break the system if all goes wrong. A good choice is lcfg-etcservices as this uses the file component and nothing fatal can go wrong if everything breaks. If porting to a new version of fedora then it will be necessary to add a new template for the services file, e.g. services.tmpl_fc5, to the lcfg-etcservices package.

Before starting the client and file component the system profile needs some mangling to make it ignore all the non-existent components:

#include <dice/options/inf-site.h>
#include <lcfg/os/fc5.h>
#include <lcfg/hw/dell_optiplex_gx620.h>
#include <live/wire_k.h>

!profile.release mSET(develop)

!       mSET()

!file.components mSET(etcservices file nsu)
!file.files mSET(i18n selinux minirc)

!profile.components mSET(authorize client etcservices file nsu)

Once this is all done, on the machine do:

om client start
om file start

There should now be a couple of local lcfg entries at the end of the file /etc/services.

After this build, test and install a simple component. logserver is good as it is generally useful to be able to get the component logs, resources and status via the webpage.

-- StephenQuinney - 27 Sep 2006

Topic revision: r6 - 28 Sep 2006 - 13:27:35 - StephenQuinney
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies