Intro
This page covers how one can manage the various needed parts of a complete release process. This includes the other SOP pages containing file configurations and/or quick command line references for the following procedures:
- Building packages
- Signing packages
- Creating repositories
- Composing images
Building Packages
Koji-Follow Source Code and Configuration SOPs
How-To-Run
- ssh <your_username>@japan
- sudo kojiadmin
- screen -xr follow
- python ~/koji-follow.py ~/koji-follow.conf > ~/logs/kfo.log 2> ~/logs/kfe.log
Post Commands
- Repo analysis:
repoclosure --arch=armv6hl --arch=noarch --repofrompath=v6,http://japan.proximity.on.ca/repos/f18-build/latest/armv6hl/ -r v6 | tee /tmp/reporeport.log
Sign, Mash, and Rsync Together!
Prerequisites
- Must setup passwordless logins from root@japan to all users in the script
- Must have a working mash configuration: See mash below
- Must have a configured sigul user with access to the signing key
- Make sure that any externally called scripts are in the correct locations
Running pidora-update.py
- ssh japan
- run as root /root/pidora-update/pidora-update.py
Usage: pidora-update.py [options]
Options:
-h, --help show this help message and exit
-i, --info check machine status and configuration
-a, --all sign, mash, rsync
-s, --sign sign all packages in listed tag
-m, --mash start a mash run
-r, --rync perform a rsync of the mash repos
-l, --list-unsigned list unsigned rpms
--koji-tag=KOJITAG specify the koji tag to sign
--sigul-user=agreene specify the user for sigul
--sigul-host=england specify the host for sigul
--mash-user=root specify the user for mash
--mash-host=japan specify the host for mash
--rsync-user=pidorapr
specify the user for rsync
--rsync-host=pidora.ca
specify the host for rsync
- All the configurations in the script can be changed with the command line options
- Can change the user to access: sigul, mash, and rsync
- Can change the host which runs: sigul, mash, and rsync
- Can change which koji tag will be used for signing
Examples runs
- Check which hosts can connect successfully
- Also shows default configurations
./pidora-update.py --info sigulhost = england mashhost = japan rsynchost = pidora.ca siguluser = agreene mashuser = root rsyncuser = pidorapr mashdir = /usr/local/bin/mash-pidora kojitags = ['f18-updates', 'f18-rpfr-updates', 'f18-updates-testing', 'f18-rpfr-updates-testing'] working hosts: ['japan', 'england', 'pidora.ca'] failed hosts: []=
- Get a list of unsigned packages
- Can check a single tag with --koji-tag=<tag-name>
./pidora-update.py --list-unsigned
- Using the default configuration, start a sign, mash, rsync
./pidora-update.py --all
- Change sigul user
./pidora-update.py --all --sigul-user=oatley
- Run sign, mash, or sync separately, instead of together with the --all option
./pidora-update.py --sign ./pidora-update.py --mash ./pidora-update.py --rsync
- Changing the configurations with command line options
- Sign using a different user, on a single koji tag
./pidora-update.py --sign --koji-tag=f18-updates-testing
Changing Default Configurations
- Can view all default configurations with the following command:
./pidora-update.py --info
- Modify the script with a text editor
- Change any of the variables listed below:
sigulhost = england mashhost = japan rsynchost = pidora.ca siguluser = agreene mashuser = root rsyncuser = pidorapr mashdir = /usr/local/bin/mash-pidora kojitags = ['f18-updates', 'f18-rpfr-updates', 'f18-updates-testing', 'f18-rpfr-updates-testing']
Source Code
Signing Packages
Sigul Configuration SOPs
Creating Repositories
Mash File Configuration Details
/etc/mash/pidora-18.mash
# mash config file [pidora-18] rpm_path = %(arch)s/os/Packages repodata_path = %(arch)s/os/ source_path = source/SRPMS debuginfo = True multilib = False multilib_method = devel tag = f18-rpfr inherit = True # Unsigned is temporary strict_keys = True #keys = 34E166FA, F8DF67E6, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9 #keys = CE8D31E3 keys = f1590cd5 repoviewurl = http://download.fedoraproject.org/pub/fedora-secondary/development/18/%(arch)s/os/ repoviewtitle = "Fedora Branched - %(arch)s" arches = armhfp # armv6 doesn't have horsepower to make delta useful delta = False # Change distro_tags as fedora-release version gets bumped # The cpe URI should be fixed up distro_tags = cpe:/o:fedoraproject:fedora:18 rawhide hash_packages = True
/etc/mash/pidora-18-updates.mash
[pidora-18-updates] rpm_path = %(arch)s/ repodata_path = %(arch)s/ source_path = SRPMS debuginfo = True multilib = False multilib_method = devel tag = f18-updates inherit = False # Unsigned is temporary strict_keys = True #keys = 34E166FA, F8DF67E6, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9 #keys = CE8D31E3 keys = f1590cd5 repoviewurl = http://download.fedoraproject.org/pub/fedora-secondary/development/18/%(arch)s/os/ repoviewtitle = "Fedora Branched - %(arch)s" arches = armhfp # armv6 doesn't have horsepower to make delta useful delta = False # Change distro_tags as fedora-release version gets bumped # The cpe URI should be fixed up distro_tags = cpe:/o:fedoraproject:fedora:18 update hash_packages = True
/etc/mash/pidora-18-updates-testing.mash
[pidora-18-updates-testing] rpm_path = %(arch)s/ repodata_path = %(arch)s/ source_path = SRPMS debuginfo = True multilib = False multilib_method = devel tag = f18-updates-testing inherit = False # Unsigned is temporary strict_keys = True #keys = 34E166FA, F8DF67E6, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9 #keys = CE8D31E3 keys = f1590cd5 repoviewurl = http://download.fedoraproject.org/pub/fedora-secondary/development/18/%(arch)s/os/ repoviewtitle = "Fedora Branched - %(arch)s" arches = armhfp # armv6 doesn't have horsepower to make delta useful delta = False # Change distro_tags as fedora-release version gets bumped # The cpe URI should be fixed up distro_tags = cpe:/o:fedoraproject:fedora:18 update hash_packages = True
/etc/mash/pidora-18-rpfr-updates.mash
[pidora-18-rpfr-updates] rpm_path = %(arch)s/ repodata_path = %(arch)s/ source_path = SRPMS debuginfo = True multilib = False multilib_method = devel tag = f18-rpfr-updates inherit = False # Unsigned is temporary strict_keys = True #keys = 34E166FA, F8DF67E6, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9 #keys = CE8D31E3 keys = f1590cd5 repoviewurl = http://download.fedoraproject.org/pub/fedora-secondary/development/18/%(arch)s/os/ repoviewtitle = "Fedora Branched - %(arch)s" arches = armhfp # armv6 doesn't have horsepower to make delta useful delta = False # Change distro_tags as fedora-release version gets bumped # The cpe URI should be fixed up distro_tags = cpe:/o:fedoraproject:fedora:18 update hash_packages = True
/etc/mash/pidora-18-rpfr-updates-testing.mash
[pidora-18-rpfr-updates-testing] rpm_path = %(arch)s/ repodata_path = %(arch)s/ source_path = SRPMS debuginfo = True multilib = False multilib_method = devel tag = f18-rpfr-updates-testing inherit = False # Unsigned is temporary strict_keys = True #keys = 34E166FA, F8DF67E6, A82BA4B7, 069C8460, 97A1071F, E8E40FDE, 57BBCCBA, D22E77F2, 4EBFC273, 0B86274E, 6DF2196F, DF9B0AE9 #keys = CE8D31E3 keys = f1590cd5 repoviewurl = http://download.fedoraproject.org/pub/fedora-secondary/development/18/%(arch)s/os/ repoviewtitle = "Fedora Branched - %(arch)s" arches = armhfp # armv6 doesn't have horsepower to make delta useful delta = False # Change distro_tags as fedora-release version gets bumped # The cpe URI should be fixed up distro_tags = cpe:/o:fedoraproject:fedora:18 update hash_packages = True
/etc/mash/mash.conf
[defaults] configdir = /etc/mash buildhost = http://japan.proximity.on.ca/kojihub repodir = file:///mnt/koji use_sqlite = True use_repoview = False
/usr/local/bin/mashrun-pidora-18
#!/bin/bash
#
# mashrun-pidora18 :: Compose a Pidora 18 repository
#
DISTNAME=pidora
RELEASE=18
# Default mash output dir is unique by dates (YYYYMMDD)
BASEDIR=/mnt/koji/mash
MASHDIR=${BASEDIR}/${DISTNAME}-${RELEASE}-$(date +%Y%m%d)
# If there is already a compose output directory for today,
# append -HHMMSS
if [ -d ${MASHDIR} ] # If YYYYMMDD exists, add -HHMMSS
then
MASHDIR=${MASHDIR}-$(date +%H%M%S)
fi
mkdir -p ${MASHDIR}
{
exec 2>&1
echo "Composing to ${MASHDIR}..."
time mash -o ${MASHDIR} ${DISTNAME}-${RELEASE} -f /usr/local/mash/comps-${DISTNAME}-${RELEASE}.xml.gz
rm ${BASEDIR}/${DISTNAME}-${RELEASE}-latest
ln -s ${MASHDIR} ${BASEDIR}/${DISTNAME}-${RELEASE}-latest
echo
echo "Warnings about unsigned packages are temporarily suppressed from email."
echo "Refer to ${MASHDIR}/mash.log for warnings."
}| cat -v | tee ${MASHDIR}/mash.log | fgrep -v '(signed with no key)' | mail -s "${DISTNAME}-${RELEASE} Mash Run" mashrun-alert
# The 'cat -v' above is there to prevent an unprintable code from throwing off the
# mail command.
Mash Command Line Execution
- /usr/local/bin/mashrun-pidora-18
Rsync to Pidora 18 Repositories
- ssh pidorapr@pidora.ca
- ~/bin/rsync-japan
Composing Images
Before you can attempt to run a compose you should check to make sure that the following packages are installed:
- anaconda
- lorax
SSH to the arm device you want to run the compose on. chroot into the armv6hl directory on the arm device.
- chroot /root/f17v6
cd into the livemedia directory or where ever your kickstart file is located.
- cd /livemedia
Run the provided Livemedia-Creator command provided below to start the compose process.
Example Kickstart File
http://scotland.proximity.on.ca/raspberrypi/test-releases/rpfr18v6/latest/pidora-18.ks
Example Livemedia-Creator Command
- livemedia-creator --make-disk --no-virt --image-only --keep-image --ks=rpfr-18.ks
Estimated time for compilation (27mins)
- command details
-h, --help For more info on commands
--make-disk Build a disk image
--no-virt Use Anaconda's image install instead of virt-install
--image-only Exit after creating disk image.
--ks KS Kickstart file defining the install.
Example Post Script Execution
You may have more than one %post section, which can be useful for cases where some post-installation scripts need to be run in the chroot and others that need access outside the chroot.
%post section is required to be closed with a corresponding %end
Post Section Options
- command details
--nochroot
Allows you to specify commands that you would like to run outside of the chroot environment.
--interpreter /usr/bin/python
Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice.
--erroronfail
If the post-installation script fails, this option will cause an error dialog to be displayed and will halt installation. The error message will direct you to where the cause of the failure is logged.
--log=
Example Post Installation Script "Creating/Modifying the fstab"
cat << EOF > /etc/fstab
LABEL="rootfs" / ext4 defaults,noatime 1 1
LABEL="boot" /boot vfat noauto,comment=systemd.automount 1 2
EOF
Ansible Builder Configuration Management
Details About Ansible
Ansible allows for remotely managing the configuration of all builders in a simple and efficient way. Ansible works by running a playbook, a playbook is a way to organize plays and run plays. A play is a set of ansible "command" or "modules" that are used on each builder, these modules can: copy files, change permissions, modify files, run commands, run scripts, and much more.
host = japan directory = /etc/ansible hosts file = /etc/ansible/ansible_hosts ansible config = /etc/ansible/ansible.cfg playbook = /etc/ansible/install_builder.yml plays = /etc/ansible/builders_tasks/ builders files = /etc/ansible/builders/
How To Use Ansible
- Log in to japan as root
ssh japan
- Change to the ansible directory
cd /etc/ansible
- Check the status of all hosts connected to ansible
- The word builders in the command below is specifying an ansible group
ansible -m ping builders
- Copy over all configurations required and start the koji service
ansible-playbook install_builders.yml --verbose
Change Builder Configurations
The best way to edit a play in ansible is to find the ansible module that is needed and read about it. Ansible modules have great documentation and there are tons of them, so many that there is one for every task that needs to be completed.
- The ansible modules can be found here: Ansible Modules
- All builder plays can be found inside /etc/ansible/builders_plays/ on japan.
- Make sure that if a new play is created, it is added into the playbook at /etc/ansible/install_builders.yml on japan
How To Set Up A New Builder
Before adding a builder to ansible, there are a few things that need to be completed.
Network
- Add a hostname to the /etc/hosts file on japan
- Add a hostname to the /etc/ansible/builders/config_files/hosts file on japan
- If it uses DHCP, then link the hostname to a host in /etc/dhcp/dhcpd.conf by specifying the mac address and host name
or
- If the builder has a changing mac address and can't use DHCP, get access to the builder and set the ip manually
ifconfig <interface> <ipaddr> netmask 255.255.255.0 up route add default gw 192.168.1.254
Services
- Initially change services on the builder, since ansible needs to gain access to the builder there are a few things that need to be done.
- NetworkManager - If it is a static address, stop this service, or if you have already setup DHCP on japan, start network manager
systemctl start NetworkManager
or
systemctl stop NetworkManager
- sshd - Start this service
systemctl start sshd
- firewalld - Stop this service
systemctl stop firewalld
- selinux - Stop selinux for now as it interferes with ansible ssh
setenforce 0
SSHD
- Copy the file /etc/ansible/builder/config_files/authorized_keys from japan to the builder
- This file contains public keys for users and ansible
scp /etc/ansible/builder/config_files/authorized_keys root@builder:
- Login to the builder
ssh root@builder
- Setup ssh and authorized keys
mkdir .ssh mv authorized_keys .ssh/ chmod 700 .ssh/ chmod 600 .ssh/authorized_keys
- Ansible should now have access to this builder
Ansible Groups
The following ansible groups are used to change the type of configuration that each builder receives. Once each builder has been added to the groups they should be in, run ansible and each group will get treated slightly differently, configuring all builders.
Group Structure
The following is a structure of groups, this shows parent groups with child groups.
- builders
- builders_default
- trimslices
- arndales
- cubies
- specials
- builders_nfs
- builders_swap
- trimslices
- builders_staticip
- arndales
- builders_default
The child groups link back to a list of hostnames.
- trimslices
- tri-1-1
- tri-1-2
- tri-1-3
- tri-1-4
- cubies
- cub-2-1
- cub-2-2
- arndales
- arn-3-1
- arn-3-2
- specials
- arm-4-1
- arm-4-2
- arm-4-3
- arm-4-4
builders_default
This group is a default group to for all builders. All builders should be in this group.
builders_nfs
This group is used for nfs configuration. This was previously used on older builders that did not have hard drives and required more building space and speed.
builder_swap
This group will allow for ansible to generate a 4GB swap file on the builders and turn that swap file on. This is primarily used for builders that require more swap than is set up on their swap partitions.
builder_staticip
This group should be used for all builders that require static ip addresses. It will setup the custom ip address based on the resolved hostname inside the /etc/ansible/ansible_hosts file.