From Fedora Project Wiki

(add more example fedmsgs)
Line 52: Line 52:
* Sign builds using scripts/sigulsign_unsigned.py from releng git repo
* Sign builds using scripts/sigulsign_unsigned.py from releng git repo
<pre>
<pre>
$ sigulsign_unsigned.py -vv --write-all fedora-19 $(cat Stable-F19 Testing-F19)
$ ./sigulsign_unsigned.py -vv --write-all fedora-19 $(cat /var/cache/sigul/Stable-F19 /var/cache/sigul/Testing-F19)
</pre>
</pre>
(Make sure you sign each release with the right key... ie, 'fedora-19' key with F19 packages, or 'epel-5' with EL-5 packages)
(Make sure you sign each release with the right key... ie, 'fedora-19' key with F19 packages, or 'epel-5' with EL-5 packages)
Line 58: Line 58:
Here is another example, inside a loop:
Here is another example, inside a loop:
<pre>
<pre>
for i in 20 19 18 ; do NSS_HASH_ALG_SUPPORT=+md5 sigulsign_unsigned.py fedora-$i -v --write-all $(cat {Stable,Testing}-F${i}) ; done
for i in 21 22 23 ; do NSS_HASH_ALG_SUPPORT=+MD5 ./sigulsign_unsigned.py fedora-$i -v --write-all $(cat /var/cache/sigul/{Stable,Testing}-F${i}) ; done
</pre>
</pre>



Revision as of 03:53, 3 September 2015

Description

Fedora updates are typically pushed once a day. This SOP covers the steps involved.

Coordinate

Releng has a rotation of who pushes updates when. Please coordinate and only push updates when you are expected to or have notified other releng folks you are doing so. See: https://apps.fedoraproject.org/calendar/release-engineering/ for the list or on irc you can run '.pushduty' in any channel with zodbot to see who is on duty this week.

Login to machine to sign updates

Login to a machine that is configured for sigul client support and has the bodhi client installed. Currently, this machine is: bodhi-backend01.phx2.fedoraproject.org

Decide what releases you're going to push.

  • If there is a Freeze ongoing, you SHOULD NOT push all stable requests for a branched release, only specific blocker or freeze exception requests that QA will request in a releng ticket.
  • If there is no Freeze ongoing you can push all Fedora and EPEL releases at the same time if you wish.
  • From time to time there may be urgent requests in some branches, you can only push those if requested. Note however that bodhi2 will automatically push branches with security updates before others.

Get a list of packages to push

$ cd /var/cache/sigul
$ sudo -u masher bodhi-push --releases '23 22 21 5 6 7' --username <yourusername>
<enter your password+2factorauth, then your fas password>

You can say 'n' to the push at this point if you wish to sign packages (see below). Or you can keep this request open in a window while you sign the packages, then come back and say y.

List the releases above you wish to push from: 23 22 21 5 6 7, etc

You can also specify '--request=testing' to limit pushes. Valid types are 'testing' or 'stable'.

The list of updates should be in the cache directory named 'Stable-$Branch' or 'Testing-$Branch' for each of the Branches you wished to push.

During freezes you will need to do two steps: (If say, fedora 23 branched was frozen):

$ cd /var/cache/sigul
$ sudo -u masher bodhi-push --releases 23 --request=testing --username <username>

Then

$ cd /var/cache/sigul
$ sudo -u masher bodhi-push --releases '22 21 5 6 7' --username <username>

Sign the packages.

  • Sign builds using scripts/sigulsign_unsigned.py from releng git repo
$ ./sigulsign_unsigned.py -vv --write-all fedora-19 $(cat /var/cache/sigul/Stable-F19 /var/cache/sigul/Testing-F19)

(Make sure you sign each release with the right key... ie, 'fedora-19' key with F19 packages, or 'epel-5' with EL-5 packages)

Here is another example, inside a loop:

for i in 21 22 23 ; do NSS_HASH_ALG_SUPPORT=+MD5 ./sigulsign_unsigned.py fedora-$i -v --write-all $(cat /var/cache/sigul/{Stable,Testing}-F${i}) ; done
  • You may need to add 'NSS_HASH_ALG_SUPPORT=+MD5' before sigulsign_unsigned (or add it to your ~/.bashrc).

Repeat gathering updates and signing steps

After gathering the list of updates and signing them, repeat the process until there are no new updates to be signed. You want to do this because as you are signing updates, maintainers are submitting new ones. There is a window while you are signing that a new update will be added and if you just push then, the push will fail with an unsigned package.

Perform the bodhi push

Re-run the earlier bodhi command from step 2 and say 'y' to push.

Verification

1. Monitor the sysemd journal

$ journalctl -u fedmsg-hub -l -f

2. Watch for fedmsgs through the process. It will indicate what releases it's working on, etc. You may want to watch in #fedora-fedmsg.

bodhi.masher.start -- kevin requested a mash of 48 updates
bodhi.mashtask.start -- bodhi masher started a push
bodhi.mashtask.mashing -- bodhi masher started mashing f23-updates
bodhi.mashtask.mashing -- bodhi masher started mashing f22-updates-testing
...
bodhi.update.complete.stable -- moceap's wondershaper-1.2.1-5.fc23 bodhi update completed push to stable https://admin.fedoraproject.org/updates/FEDORA-2015-13052
...
bodhi.errata.publish -- Fedora 23 Update: wondershaper-1.2.1-5.fc23 https://admin.fedoraproject.org/updates/FEDORA-2015-13052
bodhi.mashtask.complete -- bodhi masher successfully mashed f23-updates
bodhi.mashtask.sync.wait -- bodhi masher is waiting for f22-updates-testing to hit the master mirror

Consider Before Running

Pushes often fall over due to tagging issues or unsigned packages. Be prepared to work through the failures and restart pushes from time to time

$ sudo -u masher bodhi-push --resume

Bodhi will ask you which push(es) you want to resume.

Consider testing if the mash lock file exists. May indicate a previous push has not completed, or somehow failed:

$ ls /mnt/koji/mash/updates/MASHING-*

Common issues / problems with pushes

  • When the push fails due to new unsigned packages that were added after you started the process. re-run step 4a or 4b with just the package names that need to be signed, then resume.
  • When the push fails due to an old package that has no signature, run: koji write-signed-rpm <gpgkeyid> <n-v-r> and resume.
  • When the push fails due to a package moving from testing to stable and leaving an old version of the same package in testing: koji untag-pkg <tag> <n-v-r> to untag the package and resume. You may need to add --force.
  • When the push fails due to a package not being tagged with updates-testing when being moved stable: koji tag-pkg dist-<tag>-updates-testing <n-v-r>
  • When the push fails and you see in the server.log "Identity shutting down", bodhi has quit for some reason. Do "sudo service httpd restart" and resume the push.
  • When signing fails, you may need to ask that the sigul bridge or server be restarted.
  • When an update was deleted from bodhi, it may still be in the updates-testing tag. You may need to: koji untag-pkg <tag> <n-v-r> to untag the package and resume. You may need to add --force.

Other issues should be addressed by releng or bodhi developers in #fedora-releng.