Incorporate Kevins comments and remove obsolete guides
This commit is contained in:
Adam Saleh
parent
7b5a1b27d5
commit
e918914bcf
26 changed files with 21 additions and 2745 deletions
|
|
@ -16,5 +16,3 @@ nav:
|
||||||
- modules/ROOT/nav.adoc
|
- modules/ROOT/nav.adoc
|
||||||
- modules/developer_guide/nav.adoc
|
- modules/developer_guide/nav.adoc
|
||||||
- modules/sysadmin_guide/nav.adoc
|
- modules/sysadmin_guide/nav.adoc
|
||||||
- modules/old_sysadmin_guide/nav.adoc
|
|
||||||
- modules/communishift/nav.adoc
|
|
||||||
|
|
|
||||||
|
|
@ -1,3 +1,4 @@
|
||||||
|
* xref:orientation.adoc[Orientation for Sysadmin Guide]
|
||||||
* xref:index.adoc[Sysadmin Guide]
|
* xref:index.adoc[Sysadmin Guide]
|
||||||
** xref:2-factor.adoc[Two factor auth]
|
** xref:2-factor.adoc[Two factor auth]
|
||||||
** xref:accountdeletion.adoc[Account Deletion SOP]
|
** xref:accountdeletion.adoc[Account Deletion SOP]
|
||||||
|
|
@ -6,27 +7,19 @@
|
||||||
** xref:apps-fp-o.adoc[apps-fp-o - SOP in review ]
|
** xref:apps-fp-o.adoc[apps-fp-o - SOP in review ]
|
||||||
** xref:archive-old-fedora.adoc[archive-old-fedora - SOP in review ]
|
** xref:archive-old-fedora.adoc[archive-old-fedora - SOP in review ]
|
||||||
** xref:arm.adoc[arm - SOP in review ]
|
** xref:arm.adoc[arm - SOP in review ]
|
||||||
** xref:askbot.adoc[askbot - SOP in review ]
|
|
||||||
** xref:aws-access.adoc[aws-access - SOP in review ]
|
** xref:aws-access.adoc[aws-access - SOP in review ]
|
||||||
** xref:basset.adoc[basset - SOP in review ]
|
|
||||||
** xref:bastion-hosts-info.adoc[bastion-hosts-info - SOP in review ]
|
** xref:bastion-hosts-info.adoc[bastion-hosts-info - SOP in review ]
|
||||||
** xref:bladecenter.adoc[bladecenter - SOP in review ]
|
|
||||||
** xref:blockerbugs.adoc[blockerbugs - SOP in review ]
|
** xref:blockerbugs.adoc[blockerbugs - SOP in review ]
|
||||||
** xref:bodhi.adoc[bodhi - SOP in review ]
|
** xref:bodhi.adoc[bodhi - SOP in review ]
|
||||||
** xref:bugzilla2fedmsg.adoc[bugzilla2fedmsg - SOP in review ]
|
** xref:bugzilla2fedmsg.adoc[bugzilla2fedmsg - SOP in review ]
|
||||||
** xref:bugzilla.adoc[bugzilla - SOP in review ]
|
** xref:bugzilla.adoc[bugzilla - SOP in review ]
|
||||||
** xref:cloud.adoc[cloud - SOP in review ]
|
|
||||||
** xref:collectd.adoc[collectd - SOP in review ]
|
** xref:collectd.adoc[collectd - SOP in review ]
|
||||||
** xref:communishift.adoc[communishift - SOP in review ]
|
|
||||||
** xref:compose-tracker.adoc[compose-tracker - SOP in review ]
|
** xref:compose-tracker.adoc[compose-tracker - SOP in review ]
|
||||||
** xref:contenthosting.adoc[contenthosting - SOP in review ]
|
** xref:contenthosting.adoc[contenthosting - SOP in review ]
|
||||||
** xref:copr.adoc[copr - SOP in review ]
|
** xref:copr.adoc[copr - SOP in review ]
|
||||||
** xref:cyclades.adoc[cyclades - SOP in review ]
|
|
||||||
** xref:darkserver.adoc[darkserver - SOP in review ]
|
|
||||||
** xref:database.adoc[database - SOP in review ]
|
** xref:database.adoc[database - SOP in review ]
|
||||||
** xref:datanommer.adoc[datanommer - SOP in review ]
|
** xref:datanommer.adoc[datanommer - SOP in review ]
|
||||||
** xref:debuginfod.adoc[debuginfod - SOP in review ]
|
** xref:debuginfod.adoc[debuginfod - SOP in review ]
|
||||||
** xref:denyhosts.adoc[denyhosts - SOP in review ]
|
|
||||||
** xref:departing-admin.adoc[departing-admin - SOP in review ]
|
** xref:departing-admin.adoc[departing-admin - SOP in review ]
|
||||||
** xref:dns.adoc[dns - SOP in review ]
|
** xref:dns.adoc[dns - SOP in review ]
|
||||||
** xref:docs.fedoraproject.org.adoc[docs.fedoraproject.org - SOP in review ]
|
** xref:docs.fedoraproject.org.adoc[docs.fedoraproject.org - SOP in review ]
|
||||||
|
|
@ -40,38 +33,27 @@
|
||||||
** xref:fedmsg-relay.adoc[fedmsg-relay - SOP in review ]
|
** xref:fedmsg-relay.adoc[fedmsg-relay - SOP in review ]
|
||||||
** xref:fedmsg-websocket.adoc[fedmsg-websocket - SOP in review ]
|
** xref:fedmsg-websocket.adoc[fedmsg-websocket - SOP in review ]
|
||||||
** xref:fedocal.adoc[fedocal - SOP in review ]
|
** xref:fedocal.adoc[fedocal - SOP in review ]
|
||||||
** xref:fedorapackages.adoc[fedorapackages - SOP in review ]
|
|
||||||
** xref:fedorapastebin.adoc[fedorapastebin - SOP in review ]
|
|
||||||
** xref:fedora-releases.adoc[fedora-releases - SOP in review ]
|
** xref:fedora-releases.adoc[fedora-releases - SOP in review ]
|
||||||
** xref:fedorawebsites.adoc[fedorawebsites - SOP in review ]
|
** xref:fedorawebsites.adoc[fedorawebsites - SOP in review ]
|
||||||
** xref:fmn.adoc[fmn - SOP in review ]
|
** xref:fmn.adoc[fmn - SOP in review ]
|
||||||
** xref:fpdc.adoc[fpdc - SOP in review ]
|
|
||||||
** xref:freemedia.adoc[freemedia - SOP in review ]
|
|
||||||
** xref:freenode-irc-channel.adoc[freenode-irc-channel - SOP in review ]
|
|
||||||
** xref:freshmaker.adoc[freshmaker - SOP in review ]
|
|
||||||
** xref:gather-easyfix.adoc[gather-easyfix - SOP in review ]
|
** xref:gather-easyfix.adoc[gather-easyfix - SOP in review ]
|
||||||
** xref:gdpr_delete.adoc[gdpr_delete - SOP in review ]
|
** xref:gdpr_delete.adoc[gdpr_delete - SOP in review ]
|
||||||
** xref:gdpr_sar.adoc[gdpr_sar - SOP in review ]
|
** xref:gdpr_sar.adoc[gdpr_sar - SOP in review ]
|
||||||
** xref:geoip-city-wsgi.adoc[geoip-city-wsgi - SOP in review ]
|
** xref:geoip-city-wsgi.adoc[geoip-city-wsgi - SOP in review ]
|
||||||
** xref:github2fedmsg.adoc[github2fedmsg - SOP in review ]
|
** xref:github2fedmsg.adoc[github2fedmsg - SOP in review ]
|
||||||
** xref:github.adoc[github - SOP in review ]
|
** xref:github.adoc[github - SOP in review ]
|
||||||
** xref:gitweb.adoc[gitweb - SOP in review ]
|
|
||||||
** xref:greenwave.adoc[greenwave - SOP in review ]
|
** xref:greenwave.adoc[greenwave - SOP in review ]
|
||||||
** xref:guestdisk.adoc[guestdisk - SOP in review ]
|
** xref:guestdisk.adoc[guestdisk - SOP in review ]
|
||||||
** xref:guestedit.adoc[guestedit - SOP in review ]
|
** xref:guestedit.adoc[guestedit - SOP in review ]
|
||||||
** xref:haproxy.adoc[haproxy - SOP in review ]
|
** xref:haproxy.adoc[haproxy - SOP in review ]
|
||||||
** xref:hosted_git_to_svn.adoc[hosted_git_to_svn - SOP in review ]
|
|
||||||
** xref:hotfix.adoc[hotfix - SOP in review ]
|
** xref:hotfix.adoc[hotfix - SOP in review ]
|
||||||
** xref:hotness.adoc[hotness - SOP in review ]
|
** xref:hotness.adoc[hotness - SOP in review ]
|
||||||
** xref:hubs.adoc[hubs - SOP in review ]
|
|
||||||
** xref:ibm_rsa_ii.adoc[ibm_rsa_ii - SOP in review ]
|
|
||||||
** xref:index.adoc[index - SOP in review ]
|
** xref:index.adoc[index - SOP in review ]
|
||||||
** xref:infra-git-repo.adoc[infra-git-repo - SOP in review ]
|
** xref:infra-git-repo.adoc[infra-git-repo - SOP in review ]
|
||||||
** xref:infra-hostrename.adoc[infra-hostrename - SOP in review ]
|
** xref:infra-hostrename.adoc[infra-hostrename - SOP in review ]
|
||||||
** xref:infra-raidmismatch.adoc[infra-raidmismatch - SOP in review ]
|
** xref:infra-raidmismatch.adoc[infra-raidmismatch - SOP in review ]
|
||||||
** xref:infra-repo.adoc[infra-repo - SOP in review ]
|
** xref:infra-repo.adoc[infra-repo - SOP in review ]
|
||||||
** xref:infra-retiremachine.adoc[infra-retiremachine - SOP in review ]
|
** xref:infra-retiremachine.adoc[infra-retiremachine - SOP in review ]
|
||||||
** xref:infra-yubikey.adoc[infra-yubikey - SOP in review ]
|
|
||||||
** xref:ipsilon.adoc[ipsilon - SOP in review ]
|
** xref:ipsilon.adoc[ipsilon - SOP in review ]
|
||||||
** xref:iscsi.adoc[iscsi - SOP in review ]
|
** xref:iscsi.adoc[iscsi - SOP in review ]
|
||||||
** xref:jenkins-fedmsg.adoc[jenkins-fedmsg - SOP in review ]
|
** xref:jenkins-fedmsg.adoc[jenkins-fedmsg - SOP in review ]
|
||||||
|
|
@ -83,8 +65,6 @@
|
||||||
** xref:koschei.adoc[koschei - SOP in review ]
|
** xref:koschei.adoc[koschei - SOP in review ]
|
||||||
** xref:layered-image-buildsys.adoc[layered-image-buildsys - SOP in review ]
|
** xref:layered-image-buildsys.adoc[layered-image-buildsys - SOP in review ]
|
||||||
** xref:librariesio2fedmsg.adoc[librariesio2fedmsg - SOP in review ]
|
** xref:librariesio2fedmsg.adoc[librariesio2fedmsg - SOP in review ]
|
||||||
** xref:linktracking.adoc[linktracking - SOP in review ]
|
|
||||||
** xref:loopabull.adoc[loopabull - SOP in review ]
|
|
||||||
** xref:mailman.adoc[mailman - SOP in review ]
|
** xref:mailman.adoc[mailman - SOP in review ]
|
||||||
** xref:making-ssl-certificates.adoc[making-ssl-certificates - SOP in review ]
|
** xref:making-ssl-certificates.adoc[making-ssl-certificates - SOP in review ]
|
||||||
** xref:massupgrade.adoc[massupgrade - SOP in review ]
|
** xref:massupgrade.adoc[massupgrade - SOP in review ]
|
||||||
|
|
@ -105,7 +85,6 @@
|
||||||
** xref:openqa.adoc[openqa - SOP in review ]
|
** xref:openqa.adoc[openqa - SOP in review ]
|
||||||
** xref:openshift.adoc[openshift - SOP in review ]
|
** xref:openshift.adoc[openshift - SOP in review ]
|
||||||
** xref:openvpn.adoc[openvpn - SOP in review ]
|
** xref:openvpn.adoc[openvpn - SOP in review ]
|
||||||
** xref:orientation.adoc[orientation - SOP in review ]
|
|
||||||
** xref:outage.adoc[outage - SOP in review ]
|
** xref:outage.adoc[outage - SOP in review ]
|
||||||
** xref:packagedatabase.adoc[packagedatabase - SOP in review ]
|
** xref:packagedatabase.adoc[packagedatabase - SOP in review ]
|
||||||
** xref:packagereview.adoc[packagereview - SOP in review ]
|
** xref:packagereview.adoc[packagereview - SOP in review ]
|
||||||
|
|
@ -113,7 +92,6 @@
|
||||||
** xref:pdc.adoc[pdc - SOP in review ]
|
** xref:pdc.adoc[pdc - SOP in review ]
|
||||||
** xref:pesign-upgrade.adoc[pesign-upgrade - SOP in review ]
|
** xref:pesign-upgrade.adoc[pesign-upgrade - SOP in review ]
|
||||||
** xref:planetsubgroup.adoc[planetsubgroup - SOP in review ]
|
** xref:planetsubgroup.adoc[planetsubgroup - SOP in review ]
|
||||||
** xref:privatefedorahosted.adoc[privatefedorahosted - SOP in review ]
|
|
||||||
** xref:publictest-dev-stg-production.adoc[publictest-dev-stg-production - SOP in review ]
|
** xref:publictest-dev-stg-production.adoc[publictest-dev-stg-production - SOP in review ]
|
||||||
** xref:rabbitmq.adoc[rabbitmq - SOP in review ]
|
** xref:rabbitmq.adoc[rabbitmq - SOP in review ]
|
||||||
** xref:rdiff-backup.adoc[rdiff-backup - SOP in review ]
|
** xref:rdiff-backup.adoc[rdiff-backup - SOP in review ]
|
||||||
|
|
@ -121,7 +99,6 @@
|
||||||
** xref:requestforresources.adoc[requestforresources - SOP in review ]
|
** xref:requestforresources.adoc[requestforresources - SOP in review ]
|
||||||
** xref:resultsdb.adoc[resultsdb - SOP in review ]
|
** xref:resultsdb.adoc[resultsdb - SOP in review ]
|
||||||
** xref:retrace.adoc[retrace - SOP in review ]
|
** xref:retrace.adoc[retrace - SOP in review ]
|
||||||
** xref:reviewboard.adoc[reviewboard - SOP in review ]
|
|
||||||
** xref:scmadmin.adoc[scmadmin - SOP in review ]
|
** xref:scmadmin.adoc[scmadmin - SOP in review ]
|
||||||
** xref:selinux.adoc[selinux - SOP in review ]
|
** xref:selinux.adoc[selinux - SOP in review ]
|
||||||
** xref:sigul-upgrade.adoc[sigul-upgrade - SOP in review ]
|
** xref:sigul-upgrade.adoc[sigul-upgrade - SOP in review ]
|
||||||
|
|
|
||||||
|
|
@ -16,18 +16,18 @@ ____
|
||||||
|
|
||||||
== Contents
|
== Contents
|
||||||
|
|
||||||
* Disabling
|
* <<_disabling>>
|
||||||
** Disable Accounts
|
** <<_disable_accounts>>
|
||||||
** Disable Groups
|
** <<_disable_groups>>
|
||||||
* User Requested disables
|
* <<_user_requested_disables>>
|
||||||
* Renames
|
* <<_renames>>
|
||||||
** Rename Accounts
|
** <<_rename_accounts>>
|
||||||
** Rename Groups
|
** <<_rename_groups>>
|
||||||
* Deletion
|
* <<_deletion>>
|
||||||
** Delete Accounts
|
** <<_delete_accounts>>
|
||||||
** Delete Groups
|
** <<_delete_groups>>
|
||||||
|
|
||||||
=== Disable
|
=== Disabling
|
||||||
|
|
||||||
Disabling accounts is the easiest to accomplish as it just blocks people
|
Disabling accounts is the easiest to accomplish as it just blocks people
|
||||||
from using their account. It does not remove the account name and
|
from using their account. It does not remove the account name and
|
||||||
|
|
|
||||||
|
|
@ -1,359 +0,0 @@
|
||||||
= Ask Fedora SOP
|
|
||||||
|
|
||||||
To set up https://ask.fedoraproject.org based on Askbot as a question
|
|
||||||
and answer support forum for the Fedora community. A production instance
|
|
||||||
could be seen at https://ask.fedoraproject.org and the staging instance
|
|
||||||
is at http://ask.stg.fedoraproject.org/
|
|
||||||
|
|
||||||
This page describes how to set up and customize it from scratch.
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. Creating database
|
|
||||||
. Setting up the forum
|
|
||||||
. Adding administrators
|
|
||||||
. Change settings within the forum
|
|
||||||
. Database tweaks
|
|
||||||
. Debugging
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin
|
|
||||||
Persons::
|
|
||||||
anyone from the sysadmin team
|
|
||||||
Sponsor::
|
|
||||||
nirik
|
|
||||||
Location::
|
|
||||||
phx2
|
|
||||||
Servers::
|
|
||||||
ask01 , ask01.stg
|
|
||||||
Purpose::
|
|
||||||
To host Ask Fedora
|
|
||||||
|
|
||||||
== Creating database
|
|
||||||
|
|
||||||
We use the postgresql database backend. To add the database to a
|
|
||||||
postgresql server:
|
|
||||||
|
|
||||||
....
|
|
||||||
# psql -U postgres
|
|
||||||
postgres# create user askfedora with password 'xxx';
|
|
||||||
postgres# create database askfedora;
|
|
||||||
postgres# ALTER DATABASE askfedora owner to askfedora;
|
|
||||||
postgres# \q;
|
|
||||||
....
|
|
||||||
|
|
||||||
Now setup the db tables if this is a new install:
|
|
||||||
|
|
||||||
....
|
|
||||||
python manage.py syncdb
|
|
||||||
python manage.py migrate askbot
|
|
||||||
python manage.py migrate django_authopenid #embedded login application
|
|
||||||
....
|
|
||||||
|
|
||||||
== Setting up the forum
|
|
||||||
|
|
||||||
Askbot is packaged and available in Rawhide, Fedora 16 and EPEL 6. On a
|
|
||||||
RHEL 6 system, you need to install EPEL 6 repo first.:
|
|
||||||
|
|
||||||
....
|
|
||||||
# yum install askbot
|
|
||||||
....
|
|
||||||
|
|
||||||
The /etc/askbot/sites/ask/conf/settings.py file should look something
|
|
||||||
like:
|
|
||||||
|
|
||||||
....
|
|
||||||
DATABASE_ENGINE = 'postgresql_psycopg2'
|
|
||||||
DATABASE_NAME = 'testaskbot'
|
|
||||||
DATABASE_USER = 'askbot'
|
|
||||||
DATABASE_PASSWORD = 'xxxxx'
|
|
||||||
DATABASE_HOST = '127.0.0.1'
|
|
||||||
DATABASE_PORT = '5432'
|
|
||||||
|
|
||||||
# Outgoing mail server settings
|
|
||||||
#
|
|
||||||
DEFAULT_FROM_EMAIL = 'askfedora@fedoraproject.org'
|
|
||||||
EMAIL_SUBJECT_PREFIX = '[Askfedora]'
|
|
||||||
EMAIL_HOST='127.0.0.1'
|
|
||||||
EMAIL_PORT='25'
|
|
||||||
|
|
||||||
# This variable points to the Askbot plugin which will be used for user
|
|
||||||
# authentication. Not enabled yet because we don't need FAS auth but use
|
|
||||||
# Fedora id as a openid provider.
|
|
||||||
#
|
|
||||||
# ASKBOT_CUSTOM_AUTH_MODULE = 'authfas'
|
|
||||||
|
|
||||||
Now Ask Fedora website should be accessible from the browser.
|
|
||||||
....
|
|
||||||
|
|
||||||
== Adding administrators
|
|
||||||
|
|
||||||
As of Askbot version 0.7.21, the first user who logs in automatically
|
|
||||||
becomes the administrator. In previous versions, you have to do the
|
|
||||||
following.:
|
|
||||||
|
|
||||||
....
|
|
||||||
# cd /etc/askbot/sites/ask/conf/
|
|
||||||
# python manage.py add_admin 1
|
|
||||||
Do you really wish to make user (id=1, name=pjp) a site administrator?
|
|
||||||
yes/no: yes
|
|
||||||
....
|
|
||||||
|
|
||||||
Once a user is marked as a administrator, he or she can go into anyone's
|
|
||||||
profile, go the "moderation" tab in the end and mark them as
|
|
||||||
administrator or moderator as well as block or suspend a user.
|
|
||||||
|
|
||||||
== Change settings within the forum
|
|
||||||
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Data entry and display:::
|
|
||||||
** Disable "Allow asking questions anonymously"
|
|
||||||
** Enable "Force lowercase the tags"
|
|
||||||
** Change "Format of tag list" to "cloud"
|
|
||||||
** Change "Minimum length of search term for Ajax search" to "3"
|
|
||||||
** Change "Number of questions to list by default" to "50"
|
|
||||||
** Change "What should "unanswered question" mean?" to "Question has
|
|
||||||
no
|
|
||||||
** answers"
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Email and email alert settings::
|
|
||||||
** Change "Default news notification frequency" to "Instantly"
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Flatpages - about, privacy policy, etc.::
|
|
||||||
Change "Text of the Q&A forum About page (html format)" to the
|
|
||||||
following:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
Ask Fedora provides a community edited knowledge base and support forum
|
|
||||||
for the Fedora community. Make sure you read the FAQ and search for
|
|
||||||
existing questions before asking yours. If you want to provide feedback,
|
|
||||||
just a question in this site! Tag your questions "meta" to highlight your
|
|
||||||
questions to the administrators of Ask Fedora.
|
|
||||||
....
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Login provider settings::
|
|
||||||
** Disable "Activate local login"
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Q&A forum website parameters and urls::
|
|
||||||
** {blank}
|
|
||||||
+
|
|
||||||
Change "Site title for the Q&A forum" to "Ask Fedora: Community
|
|
||||||
Knowledge;;
|
|
||||||
Base and Support Forum"
|
|
||||||
** {blank}
|
|
||||||
+
|
|
||||||
Change "Comma separated list of Q&A site keywords" to "Ask Fedora,
|
|
||||||
forum,;;
|
|
||||||
community, support, help"
|
|
||||||
** {blank}
|
|
||||||
+
|
|
||||||
Change "Copyright message to show in the footer" to "All content is
|
|
||||||
under;;
|
|
||||||
Creative Commons Attribution Share Alike License. Ask Fedora is
|
|
||||||
community maintained and Red Hat or Fedora Project is not
|
|
||||||
responsible for content"
|
|
||||||
** {blank}
|
|
||||||
+
|
|
||||||
Change "Site description for the search engines" to "Ask Fedora:
|
|
||||||
Community;;
|
|
||||||
Knowledge Base and Support Forum"
|
|
||||||
** Change "Short name for your Q&A forum" to "Ask Fedora"
|
|
||||||
** {blank}
|
|
||||||
+
|
|
||||||
Change "Base URL for your Q&A forum, must start with http or https"
|
|
||||||
to;;
|
|
||||||
"http://ask.fedoraproject.org"
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Sidebar widget settings - main page::
|
|
||||||
** Disable "Show avatar block in sidebar"
|
|
||||||
** Disable "Show tag selector in sidebar"
|
|
||||||
* Skin and User Interface settings
|
|
||||||
** Upload "Q&A site logo"
|
|
||||||
** Upload "Site favicon". Must be a ICO format file because that is the
|
|
||||||
only one IE supports as a fav icon.
|
|
||||||
** Enable "Apply custom style sheet (CSS)"
|
|
||||||
** Upload the following custom CSS:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
#ab-main-nav a {
|
|
||||||
color: #333333;
|
|
||||||
background-color: #d8dfeb;
|
|
||||||
border: 1px solid #888888;
|
|
||||||
border-bottom: none;
|
|
||||||
padding: 0px 12px 3px 12px;
|
|
||||||
height: 25px;
|
|
||||||
line-height: 30px;
|
|
||||||
margin-right: 10px;
|
|
||||||
font-size: 18px;
|
|
||||||
font-weight: 100;
|
|
||||||
text-decoration: none;
|
|
||||||
display: block;
|
|
||||||
float: left;
|
|
||||||
}
|
|
||||||
|
|
||||||
#ab-main-nav a.on {
|
|
||||||
height: 24px;
|
|
||||||
line-height: 28px;
|
|
||||||
border-bottom: 1px solid #0a57a4;
|
|
||||||
border-right: 1px solid #0a57a4;
|
|
||||||
border-top: 1px solid #0a57a4;
|
|
||||||
border-left: 1px solid #0a57a4; /*background:#A31E39; */
|
|
||||||
background: #0a57a4;
|
|
||||||
color: #FFF;
|
|
||||||
font-weight: 800;
|
|
||||||
text-decoration: none
|
|
||||||
}
|
|
||||||
|
|
||||||
#ab-main-nav a.special {
|
|
||||||
font-size: 18px;
|
|
||||||
color: #072b61;
|
|
||||||
font-weight: bold;
|
|
||||||
text-decoration: none;
|
|
||||||
}
|
|
||||||
|
|
||||||
/* tabs stuff */
|
|
||||||
.tabsA { float: right; }
|
|
||||||
.tabsC { float: left; }
|
|
||||||
|
|
||||||
.tabsA a.on, .tabsC a.on, .tabsA a:hover, .tabsC a:hover {
|
|
||||||
background: #fff;
|
|
||||||
color: #072b61;
|
|
||||||
border-top: 1px solid #babdb6;
|
|
||||||
border-left: 1px solid #babdb6;
|
|
||||||
border-right: 1px solid #888a85;
|
|
||||||
border-bottom: 1px solid #888a85;
|
|
||||||
height: 24px;
|
|
||||||
line-height: 26px;
|
|
||||||
margin-top: 3px;
|
|
||||||
}
|
|
||||||
|
|
||||||
.tabsA a.rev.on, tabsA a.rev.on:hover {
|
|
||||||
padding: 0px 2px 0px 7px;
|
|
||||||
}
|
|
||||||
|
|
||||||
.tabsA a, .tabsC a{
|
|
||||||
background: #f9f7eb;
|
|
||||||
border-top: 1px solid #eeeeec;
|
|
||||||
border-left: 1px solid #eeeeec;
|
|
||||||
border-right: 1px solid #a9aca5;
|
|
||||||
border-bottom: 1px solid #888a85;
|
|
||||||
color: #888a85;
|
|
||||||
display: block;
|
|
||||||
float: left;
|
|
||||||
height: 20px;
|
|
||||||
line-height: 22px;
|
|
||||||
margin: 5px 0 0 4px;
|
|
||||||
padding: 0 7px;
|
|
||||||
text-decoration: none;
|
|
||||||
}
|
|
||||||
|
|
||||||
.tabsA .label, .tabsC .label {
|
|
||||||
float: left;
|
|
||||||
font-weight: bold;
|
|
||||||
color: #777;
|
|
||||||
margin: 8px 0 0 0px;
|
|
||||||
}
|
|
||||||
|
|
||||||
.tabsB a {
|
|
||||||
background: #eee;
|
|
||||||
border: 1px solid #eee;
|
|
||||||
color: #777;
|
|
||||||
display: block;
|
|
||||||
float: left;
|
|
||||||
height: 22px;
|
|
||||||
line-height: 28px;
|
|
||||||
margin: 5px 0px 0 4px;
|
|
||||||
padding: 0 11px 0 11px;
|
|
||||||
text-decoration: none;
|
|
||||||
}
|
|
||||||
|
|
||||||
a {
|
|
||||||
color: #072b61;
|
|
||||||
text-decoration: none;
|
|
||||||
cursor: pointer;
|
|
||||||
}
|
|
||||||
|
|
||||||
div.side-box
|
|
||||||
{
|
|
||||||
width:200px;
|
|
||||||
padding:10px;
|
|
||||||
border:3px solid #CCCCCC;
|
|
||||||
margin:0px;
|
|
||||||
background: -moz-linear-gradient(top, #DDDDDD, #FFFFFF);
|
|
||||||
}
|
|
||||||
....
|
|
||||||
|
|
||||||
== Database tweaks
|
|
||||||
|
|
||||||
To automatically delete expired sessions, we run a trigger that makes
|
|
||||||
PostgreSQL delete them upon inserting a new one.
|
|
||||||
|
|
||||||
The code used to create this trigger was:
|
|
||||||
|
|
||||||
....
|
|
||||||
askfedora=# CREATE FUNCTION delete_old_sessions() RETURNS trigger
|
|
||||||
askfedora-# LANGUAGE plpgsql
|
|
||||||
askfedora-# AS $$
|
|
||||||
askfedora$# BEGIN
|
|
||||||
askfedora$# DELETE FROM django_session WHERE expire_date<current_timestamp;
|
|
||||||
askfedora$# RETURN NEW;
|
|
||||||
askfedora$# END
|
|
||||||
askfedora$# $$;
|
|
||||||
CREATE FUNCTION
|
|
||||||
askfedora=# CREATE TRIGGER old_sessions_gc
|
|
||||||
askfedora-# AFTER INSERT ON django_session
|
|
||||||
askfedora-# EXECUTE PROCEDURE delete_old_sessions();
|
|
||||||
....
|
|
||||||
|
|
||||||
In case this trigger causes any problems, please remove it by running:
|
|
||||||
`DROP TRIGGER old_sessions_gc;`
|
|
||||||
|
|
||||||
To make this perform, we have a custom index that's not in upstream
|
|
||||||
askbot, please remember to add that when recreating the trigger:
|
|
||||||
|
|
||||||
....
|
|
||||||
CREATE INDEX CONCURRENTLY django_session_expire_date ON django_session (expire_date);
|
|
||||||
....
|
|
||||||
|
|
||||||
If you deleted the trigger, or reinstalled without trigger, please make
|
|
||||||
sure to run `manage.py clean_sessions` regularly, so you don't end up
|
|
||||||
with a database that's too massive in size.
|
|
||||||
|
|
||||||
== Debugging
|
|
||||||
|
|
||||||
Set DEBUG to True in settings.py file and restart Apache.
|
|
||||||
|
|
||||||
== Auth issues
|
|
||||||
|
|
||||||
Users can login to ask with a variety of social media accounts. Once
|
|
||||||
they login with one they can attach other ones as well.
|
|
||||||
|
|
||||||
If a user forgets what social media they used, you can look in the
|
|
||||||
database:
|
|
||||||
|
|
||||||
Login to database host (db01.phx2.fedoraproject.org) # sudo -u postgres
|
|
||||||
psql askfedora psql> select * from django_authopenid_userassociation
|
|
||||||
where user_id like '%username%';
|
|
||||||
|
|
||||||
If they can login again with the same auth, ask them to do so. If not,
|
|
||||||
you can add the fedora account system openid auth to allow them to login
|
|
||||||
with that:
|
|
||||||
|
|
||||||
psql> insert into django_authopenid_userassociation (user_id,
|
|
||||||
openid_url,provider_name) VALUES (2595,
|
|
||||||
'http://name.id.fedoraproject.org', 'fedoraproject');
|
|
||||||
|
|
||||||
Use the ID from the previous query and replace name with the users fas
|
|
||||||
name.
|
|
||||||
|
|
@ -1,118 +0,0 @@
|
||||||
= Basset anti-spam service
|
|
||||||
|
|
||||||
Since the Fedora Project has come under targeted spam attacks, we have
|
|
||||||
decided to create a service that all our applications can hook into to
|
|
||||||
have a central repository for anti-spam procedures. Basset is this
|
|
||||||
service, and it's hosted on https://pagure.io/basset.
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. Overview
|
|
||||||
. FAS
|
|
||||||
. Trac
|
|
||||||
. Wiki
|
|
||||||
. Setup
|
|
||||||
. Outage
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Patrick Uiterwijk (puiterwijk)
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, #fedora-apps, #fedora-noc, sysadmin-main
|
|
||||||
Location::
|
|
||||||
basset01
|
|
||||||
Purpose::
|
|
||||||
Centralized anti-spam
|
|
||||||
|
|
||||||
== Overview
|
|
||||||
|
|
||||||
Basset is a central anti-spam service: it received messages from
|
|
||||||
services that certain actions happened, and will then decide to accept
|
|
||||||
or deny the request, or pass it on to an administrator.
|
|
||||||
|
|
||||||
At the moment, we have the following modules live: FAS, trac, wiki.
|
|
||||||
|
|
||||||
== FAS
|
|
||||||
|
|
||||||
This module receives notifications from FAS about new users
|
|
||||||
registrations and new users signing the FPCA. With Basset enabled, FAS
|
|
||||||
will not automatically accept a new user registration or a FPCA signing,
|
|
||||||
but instead let Basset know a user tried to perform these actions and
|
|
||||||
then depend on Basset to enact this.
|
|
||||||
|
|
||||||
In the case of registration this is done by setting the user to a
|
|
||||||
spamcheck_awaiting status. As soon as Basset made a decision, it will
|
|
||||||
set the user to spamcheck_manual, spamcheck_denied or active. If it sets
|
|
||||||
the user to active, it will also send the welcome email to the user. If
|
|
||||||
it made a wrong decision, and the user is set as spamcheck_manual or
|
|
||||||
spamcheck_denied, a member of the accounts team can go to that users'
|
|
||||||
page and click the "Enable" button to override the decision. If this
|
|
||||||
needed to be done, please notify puiterwijk so that the rules Basset
|
|
||||||
uses can be updated.
|
|
||||||
|
|
||||||
For the case of the FPCA, FAS will request the cla_fpca group
|
|
||||||
membership, but not sponsor the user. At the moment that Basset decides
|
|
||||||
it accepts the request, it will sponsor the user into the group. If it
|
|
||||||
declined the FPCA request, it will remove the user from the group. To
|
|
||||||
override this decision, a member of the accounts group can go to FAS and
|
|
||||||
manually add the user to the cla_fpca group and sponsor them into it.
|
|
||||||
|
|
||||||
== Trac
|
|
||||||
|
|
||||||
For Trac, if a post gets denied, the content item gets deleted, the Trac
|
|
||||||
account gets blocked cross-instance and the FAS account gets blocked.
|
|
||||||
|
|
||||||
To unblock the user, log in to hosted03, and remove
|
|
||||||
/srv/web/trac/blocks/$username. For info on how to unblock the FAS user,
|
|
||||||
see the notes under FAS.
|
|
||||||
|
|
||||||
== Wiki
|
|
||||||
|
|
||||||
For Wiki, if an edit gets denied, the page gets deleted, the wiki
|
|
||||||
account blocked and the FAS account gets blocked.
|
|
||||||
|
|
||||||
For the wiki parts of undoing this, follow the regular mediawiki unblock
|
|
||||||
procedures using:::
|
|
||||||
* https://fedoraproject.org/wiki/Special:BlockList to check if an user
|
|
||||||
is blocked or not
|
|
||||||
* https://fedoraproject.org/wiki/Special:Unblock to unblock that user
|
|
||||||
|
|
||||||
Don't forget to unblock the account as in FAS.
|
|
||||||
|
|
||||||
== Setup
|
|
||||||
|
|
||||||
At this moment, Basset runs on a single server (basset01(.stg)), and
|
|
||||||
runs the frontend, message broker and worker all on a single server. For
|
|
||||||
all of it to work, the following services are used: - httpd (frontend) -
|
|
||||||
rabbitmq-server (broker) - mongod (mongo database server for storage of
|
|
||||||
internal info) - basset-worker (worker)
|
|
||||||
|
|
||||||
== Outage
|
|
||||||
|
|
||||||
The consequences of certain services not being up results in various
|
|
||||||
conditions:
|
|
||||||
|
|
||||||
If the httpd or frontend aren't up, no new messages will come in. FAS
|
|
||||||
will set the user to spamcheck_awaiting, but not submit it to Basset.
|
|
||||||
Work is in progress on a script to submit such entries to the queue
|
|
||||||
after Basset frontend is back. However, since this part of the code is
|
|
||||||
so small, this is not likely to be the part that's down. (You can know
|
|
||||||
that it is because the FAS logs will log an error instead of "result:
|
|
||||||
checking".)
|
|
||||||
|
|
||||||
If the worker or the mongo server are down, no messages will be
|
|
||||||
processed, but all messages queued up will be processed the moment both
|
|
||||||
of the services start again: as long as a message makes it into the
|
|
||||||
queue, it will be processed until completion.
|
|
||||||
|
|
||||||
If the worker encounters an error during processing of a message, it
|
|
||||||
will dump a tracedump into the journal log file, and stop processing any
|
|
||||||
messages. Resolve the condition reported in the error and restart the
|
|
||||||
basset-worker service, and all work will be continued, starting with the
|
|
||||||
message it was processing when it errored out.
|
|
||||||
|
|
||||||
This means that as long as the message is queued, the worker will pick
|
|
||||||
it up and handle it.
|
|
||||||
|
|
@ -1,52 +0,0 @@
|
||||||
= BladeCenter Access Infrastructure SOP
|
|
||||||
|
|
||||||
Many of the builders in PHX are blades in a blade center. A few other
|
|
||||||
machines are also on blades.
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. Common Tasks
|
|
||||||
|
|
||||||
____
|
|
||||||
[arabic]
|
|
||||||
. Logging into the web interface
|
|
||||||
. Using the Serial Console of Blades
|
|
||||||
____
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, sysadmin-main
|
|
||||||
Location::
|
|
||||||
PHX
|
|
||||||
Purpose::
|
|
||||||
Contains blades used for buildsystems, etc
|
|
||||||
|
|
||||||
== Common Tasks
|
|
||||||
|
|
||||||
=== Logging into the web interface
|
|
||||||
|
|
||||||
The web interface to the bladecenters let you reset power, etc. They are
|
|
||||||
bc01-mgmt and bc02-mgmt.
|
|
||||||
|
|
||||||
=== Using the Serial Console of Blades
|
|
||||||
|
|
||||||
All of the blades are set up with a serial console over lan (SOL). To
|
|
||||||
use this, ssh into the bladecenter. You can then pick your system and
|
|
||||||
bring up a console with:
|
|
||||||
|
|
||||||
....
|
|
||||||
env -T system:blade[x]
|
|
||||||
console -o
|
|
||||||
....
|
|
||||||
|
|
||||||
where x is the blade number (can be determined from web interface, etc)
|
|
||||||
|
|
||||||
To leave the console session, press Esc (
|
|
||||||
|
|
||||||
For more details on BladeCenter SOL, see
|
|
||||||
http://www-304.ibm.com/systems/support/supportsite.wss/docdisplay?brandind=5000008&lndocid=MIGR-54666
|
|
||||||
|
|
@ -1,169 +0,0 @@
|
||||||
= Fedora OpenStack
|
|
||||||
|
|
||||||
== Quick Start
|
|
||||||
|
|
||||||
Controller:
|
|
||||||
|
|
||||||
....
|
|
||||||
sudo rbac-playbook hosts/fed-cloud09.cloud.fedoraproject.org.yml
|
|
||||||
....
|
|
||||||
|
|
||||||
Compute nodes:
|
|
||||||
|
|
||||||
....
|
|
||||||
sudo rbac-playbook groups/openstack-compute-nodes.yml
|
|
||||||
....
|
|
||||||
|
|
||||||
== Description
|
|
||||||
|
|
||||||
If you need to install OpenStack install, either make sure the machine
|
|
||||||
is clean. Or use `ansible.git/files/fedora-cloud/uninstall.sh` script to
|
|
||||||
brute force wipe off.
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
by default, the script does not wipe LVM group with VM, you have to
|
|
||||||
clean them manually. There is commented line in that script.
|
|
||||||
====
|
|
||||||
On fed-cloud09, remove the file
|
|
||||||
`/etc/packstack_sucessfully_finished` to enforce run of packstack and
|
|
||||||
few other commands.
|
|
||||||
|
|
||||||
After that wipe, you have to:
|
|
||||||
|
|
||||||
....
|
|
||||||
ifdown eth1
|
|
||||||
configure eth1 to become normal Ethernet with ip
|
|
||||||
yum install openstack-neutron-openvswitch
|
|
||||||
/usr/bin/systemctl restart neutron-ovs-cleanup
|
|
||||||
ifup eth1
|
|
||||||
....
|
|
||||||
|
|
||||||
Additionally when reprovision OpenStack, all volumes on DellEqualogic
|
|
||||||
are preserved and you have to manually remove them (or remove them from
|
|
||||||
OS before it is reprovision). SSH to DellEqualogic (credentials are at
|
|
||||||
the bottom of `/etc/cinder/cinder.conf`) and run:
|
|
||||||
|
|
||||||
....
|
|
||||||
show (to get list of volumes)
|
|
||||||
volume select <volume_name> offline
|
|
||||||
volume delete <volume_name>
|
|
||||||
....
|
|
||||||
|
|
||||||
Before installing make sure:
|
|
||||||
|
|
||||||
____
|
|
||||||
* make sure rdo repo is enabled
|
|
||||||
* `yum install openstack-packstack openstack-packstack-puppet openstack-puppet-modules`
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
`vim /usr/lib/python2.7/site-packages/packstack/plugins/dashboard_500.py`::
|
|
||||||
and missing parentheses:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
``host_resources.append((ssl_key, 'ssl_ps_server.key'))``
|
|
||||||
....
|
|
||||||
____
|
|
||||||
|
|
||||||
Now you can run playbook:
|
|
||||||
|
|
||||||
....
|
|
||||||
sudo rbac-playbook hosts/fed-cloud09.cloud.fedoraproject.org.yml
|
|
||||||
....
|
|
||||||
|
|
||||||
If you run it after wipe (i.e. db has been reset), you have to:
|
|
||||||
|
|
||||||
____
|
|
||||||
* import ssh keys of users (only possible via webUI - RHBZ 1128233
|
|
||||||
* reset user passwords
|
|
||||||
____
|
|
||||||
|
|
||||||
== Compute nodes
|
|
||||||
|
|
||||||
Compute node is much easier and is written as role. Use:
|
|
||||||
|
|
||||||
....
|
|
||||||
vars_files:
|
|
||||||
- ... SNIP
|
|
||||||
- /srv/web/infra/ansible/vars/fedora-cloud.yml
|
|
||||||
- "{{ private }}/files/openstack/passwords.yml"
|
|
||||||
|
|
||||||
roles:
|
|
||||||
... SNIP
|
|
||||||
- cloud_compute
|
|
||||||
....
|
|
||||||
|
|
||||||
Define a host variable in `inventory/host_vars/FQDN.yml`:
|
|
||||||
|
|
||||||
....
|
|
||||||
compute_private_ip: 172.23.0.10
|
|
||||||
....
|
|
||||||
|
|
||||||
You should also add IP to `vars/fedora-cloud.yml`
|
|
||||||
|
|
||||||
And when adding new compute node, please update
|
|
||||||
`files/fedora-cloud/hosts`
|
|
||||||
|
|
||||||
[IMPORTANT]
|
|
||||||
.Important
|
|
||||||
====
|
|
||||||
When reinstalling make sure you removed all members on Dell Equalogic
|
|
||||||
(credentials are in /etc/cinder/cinder.conf on compute node) otherwise
|
|
||||||
the space will be blocked!!!
|
|
||||||
====
|
|
||||||
== Updates
|
|
||||||
|
|
||||||
Our openstack cloud should have updates applied and reboots when the
|
|
||||||
rest of our servers are updated and rebooted. This will cause an outage,
|
|
||||||
please make sure to schedule it.
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Stop copr-backend process on copr-be.cloud.fedoraproject.org
|
|
||||||
. Kill all copr-builder instances.
|
|
||||||
. Kill all transient/scratch instances.
|
|
||||||
. Update all instances we control. copr, persistent, infrastructure, qa
|
|
||||||
etc.
|
|
||||||
. Shutdown all instances
|
|
||||||
. Update and reboot fed-cloud09
|
|
||||||
. Update and reboot all compute nodes
|
|
||||||
. Start up all instances that are shutdown in step 5.
|
|
||||||
|
|
||||||
TODO: add commands for above as we know them.
|
|
||||||
|
|
||||||
== Troubleshooting
|
|
||||||
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
could not connect to VM? - check your security group, default SG does
|
|
||||||
not::
|
|
||||||
allow any connection.
|
|
||||||
* packstack end up with error, it is likely race condition in puppet -
|
|
||||||
BZ 1135529. Just run it again.
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
ERROR : append() takes exactly one argument (2 given::
|
|
||||||
`vi /usr/lib/python2.7/site-packages/packstack/plugins/dashboard_500.py`
|
|
||||||
and add one more surrounding ()
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Local ip for ovs agent must be set when tunneling is enabled::
|
|
||||||
restart fed-cloud09 or: ssh to fed-cloud09; ifdown eth1; ifup eth1;
|
|
||||||
ifup br-ex
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
mongodb problem? follow::
|
|
||||||
https://ask.openstack.org/en/question/54015/mongodbpp-error-when-installing-rdo-on-centos-7/?answer=54076#post-id-54076
|
|
||||||
* `WARNING:keystoneclient.httpclient:Failed to retrieve management_url from token`:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
keystone --os-token $ADMIN_TOKEN --os-endpoint \
|
|
||||||
https://fedorainfracloud.org:35357/v2.0/ endpoint-create --region 'RegionOne' \
|
|
||||||
--service 91358b81b1aa40d998b3a28d0cfc86e7 --region 'RegionOne' --publicurl \
|
|
||||||
'https://fedorainfracloud.org:5000/v2.0' --adminurl 'http://172.24.0.9:35357/v2.0' \
|
|
||||||
--internalurl 'http://172.24.0.9:5000/v2.0'
|
|
||||||
....
|
|
||||||
|
|
||||||
== Fedora Classroom about our instance
|
|
||||||
|
|
||||||
http://meetbot.fedoraproject.org/fedora-classroom/2015-05-11/fedora-classroom.2015-05-11-15.02.log.html
|
|
||||||
|
|
@ -1,76 +0,0 @@
|
||||||
= Communishift SOP
|
|
||||||
|
|
||||||
Communishift is an OpenShift deployment hosted and maintained by Fedora
|
|
||||||
Infrastructure that is available to the community to host applications.
|
|
||||||
Fedora Infrastructure does not maintain the applications in Communishift
|
|
||||||
and is only responsible for the OpenShift deployment itself.
|
|
||||||
|
|
||||||
Production instance:
|
|
||||||
https://console-openshift-console.apps.os.fedorainfracloud.org/
|
|
||||||
|
|
||||||
Contents
|
|
||||||
|
|
||||||
== Contact information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin
|
|
||||||
Persons::
|
|
||||||
nirik
|
|
||||||
Location::
|
|
||||||
Phoenix
|
|
||||||
Servers::
|
|
||||||
* os-node01.fedorainfracloud.org
|
|
||||||
* os-node02.fedorainfracloud.org
|
|
||||||
* os-node03.fedorainfracloud.org
|
|
||||||
* os-node04.fedorainfracloud.org
|
|
||||||
* os-node05.fedorainfracloud.org
|
|
||||||
* os-node06.fedorainfracloud.org
|
|
||||||
* os-node07.fedorainfracloud.org
|
|
||||||
* os-node08.fedorainfracloud.org
|
|
||||||
* os-node09.fedorainfracloud.org
|
|
||||||
* os-node10.fedorainfracloud.org
|
|
||||||
* os-node11.fedorainfracloud.org
|
|
||||||
* virthost-os01.fedorainfracloud.org
|
|
||||||
* virthost-os02.fedorainfracloud.org
|
|
||||||
* virthost-os03.fedorainfracloud.org
|
|
||||||
* virthost-aarch64-os01.fedorainfracloud.org
|
|
||||||
* virthost-aarch64-os02.fedorainfracloud.org
|
|
||||||
Purpose::
|
|
||||||
Allow community members to host services for the Fedora Project.
|
|
||||||
|
|
||||||
== Onboarding new users
|
|
||||||
|
|
||||||
To allow new users to create projects in Communishift, begin by adding
|
|
||||||
them to the `communishift` FAS group.
|
|
||||||
|
|
||||||
At the time of this writing, there is no automation to sync users from
|
|
||||||
the `communishift` FAS group to OpenShift, so you will need to log in to
|
|
||||||
the Communishift instance and grant that user permissions to create
|
|
||||||
projects. For example, to grant `bowlofeggs` permissions, you would do
|
|
||||||
this:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ oc adm policy add-cluster-role-to-user self-provisioner bowlofeggs
|
|
||||||
$ oc create clusterquota for-bowlofeggs --project-annotation-selector openshift.io/requester=bowlofeggs --hard pods=10 --hard persistentvolumeclaims=5
|
|
||||||
....
|
|
||||||
|
|
||||||
This will grant bowlofeggs the ability to provision up to 10 pods and 5
|
|
||||||
volumes.
|
|
||||||
|
|
||||||
== KVM access
|
|
||||||
|
|
||||||
We allow applications access to the kvm device so they can run emulation
|
|
||||||
faster. Anytime the cluster is re-installed, run:
|
|
||||||
|
|
||||||
!/bin/bash set -eux if ! oc get --namespace=default ds/device-plugin-kvm
|
|
||||||
&>/dev/null; then oc create --namespace=default -f
|
|
||||||
https://raw.githubusercontent.com/kubevirt/kubernetes-device-plugins/master/manifests/kvm-ds.yml
|
|
||||||
fi
|
|
||||||
|
|
||||||
See the
|
|
||||||
https://github.com/kubevirt/kubernetes-device-plugins/blob/master/docs/README.kvm.md[upstream
|
|
||||||
docs] as well as the
|
|
||||||
https://pagure.io/fedora-infrastructure/issue/8208[original request] for
|
|
||||||
this.
|
|
||||||
|
|
@ -1,31 +0,0 @@
|
||||||
= Cyclades
|
|
||||||
|
|
||||||
cyclades notes
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. login as root - default password is tslinux
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
change password for root and admin to our password from the::
|
|
||||||
phx2-access.txt file in the private repo
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
port forward to the web browser for the cyclades::
|
|
||||||
`ssh -L 8080:rack47-serial.phx2.fedoraproject.org:80`
|
|
||||||
. connect to localhost:8080 in your web browser
|
|
||||||
. login with root and the password you set above
|
|
||||||
. click on 'security'
|
|
||||||
. click on 'moderate'
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
logout, port forward port 443 as above:::
|
|
||||||
`ssh -L 8080:rack47-serial.phx2.fedoraproject.org:443`
|
|
||||||
. click on the 'wizard' button at lower left
|
|
||||||
. proceed through the wizard Info needed:
|
|
||||||
* serial ports are set to 115200 8N1 by default
|
|
||||||
* do not setup buffering
|
|
||||||
* give it the ip of our syslog server
|
|
||||||
. click 'apply changes'
|
|
||||||
. hope
|
|
||||||
. log back in
|
|
||||||
. name/setup the port aliases
|
|
||||||
|
|
@ -1,108 +0,0 @@
|
||||||
= Darkserver SOP
|
|
||||||
|
|
||||||
To setup a http://darkserver.fedoraproject.org based on Darkserver
|
|
||||||
project to provide GNU_BUILD_ID information for packages. A devel
|
|
||||||
instance can be seen at http://darkserver01.dev.fedoraproject.org and
|
|
||||||
staging instance is http://darkserver01.stg.phx2.fedoraproject.org/.
|
|
||||||
|
|
||||||
This page describes how to set up the server.
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. Installing the server
|
|
||||||
. Setting up the database
|
|
||||||
. SELinux Configuration
|
|
||||||
. Koji plugin setup
|
|
||||||
. Debugging
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner:::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact:::
|
|
||||||
#fedora-admin
|
|
||||||
Persons:::
|
|
||||||
kushal mether
|
|
||||||
Sponsor:::
|
|
||||||
nirik
|
|
||||||
Location:::
|
|
||||||
phx2
|
|
||||||
Servers:::
|
|
||||||
darkserver01 , darkserver01.stg, darkserver01.dev
|
|
||||||
Purpose:::
|
|
||||||
To host Darkserver
|
|
||||||
|
|
||||||
== Installing the Server
|
|
||||||
|
|
||||||
....
|
|
||||||
root@localhost# yum install darkserver
|
|
||||||
....
|
|
||||||
|
|
||||||
== Setting up the database
|
|
||||||
|
|
||||||
We are using MySQL as database. We will need two users, one for
|
|
||||||
koji-plugin and one for darkserver.:
|
|
||||||
|
|
||||||
....
|
|
||||||
root@localhost# mysql -u root
|
|
||||||
mysql> CREATE DATABASE darkserver;
|
|
||||||
mysql> GRANT INSERT ON darkserver.* TO kojiplugin@'koji-hub-ip' IDENTIFIED BY 'XXX';
|
|
||||||
mysql> GRANT SELECT ON darkserver.* TO dark@'darkserver-ip' IDENTIFIED BY 'XXX';
|
|
||||||
....
|
|
||||||
|
|
||||||
Setup this db configuration in the conf file under
|
|
||||||
`/etc/darkserver/darkserverweb.conf`:
|
|
||||||
|
|
||||||
....
|
|
||||||
[darkserverweb]
|
|
||||||
host=db host name
|
|
||||||
user=dark
|
|
||||||
password=XXX
|
|
||||||
database=darkserver
|
|
||||||
....
|
|
||||||
|
|
||||||
Now setup the db tables if it is a new install.
|
|
||||||
|
|
||||||
(For this you may need to `'GRANT * ON darkserver.*'` to the web user,
|
|
||||||
and then `'REVOKE * ON darkserver.*'` after running.)
|
|
||||||
|
|
||||||
....
|
|
||||||
root@localhost# python /usr/lib/python2.6/site-packages/darkserverweb/manage.py syncdb
|
|
||||||
....
|
|
||||||
|
|
||||||
== SELinux Configuration
|
|
||||||
|
|
||||||
Do the follow to allow the webserver to connect to the database.:
|
|
||||||
|
|
||||||
....
|
|
||||||
root@localhost# setsebool -P httpd_can_network_connect_db 1
|
|
||||||
....
|
|
||||||
|
|
||||||
== Setting up the Koji plugin
|
|
||||||
|
|
||||||
Install the package.:
|
|
||||||
|
|
||||||
....
|
|
||||||
root@localhost# yum install darkserver-kojiplugin
|
|
||||||
....
|
|
||||||
|
|
||||||
Then fill up the configuration file under
|
|
||||||
`/etc/koji-hub/plugins/darkserver.conf`:
|
|
||||||
|
|
||||||
....
|
|
||||||
[darkserver]
|
|
||||||
host=db host name
|
|
||||||
user=kojiplugin
|
|
||||||
password=XXX
|
|
||||||
database=darkserver
|
|
||||||
port=3306
|
|
||||||
....
|
|
||||||
|
|
||||||
Then enable the plugin in the koji hub configuration.
|
|
||||||
|
|
||||||
== Debugging
|
|
||||||
|
|
||||||
Set DEBUG to True in `/etc/darkserver/settings.py` file and restart
|
|
||||||
Apache.
|
|
||||||
|
|
@ -1,52 +0,0 @@
|
||||||
= Denyhosts Infrastructure SOP
|
|
||||||
|
|
||||||
Denyhosts provides a protection against brute force attacks.
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. Description
|
|
||||||
. Troubleshooting and Resolution
|
|
||||||
|
|
||||||
____
|
|
||||||
[arabic]
|
|
||||||
. Connection issues
|
|
||||||
____
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, sysadmin-main group
|
|
||||||
Location::
|
|
||||||
Anywhere
|
|
||||||
Servers::
|
|
||||||
All
|
|
||||||
Purpose::
|
|
||||||
Denyhosts provides a protection against brute force attacks.
|
|
||||||
|
|
||||||
== Description
|
|
||||||
|
|
||||||
All of our servers now implement denyhosts to protect against brute
|
|
||||||
force attacks. Very few boxes should be in the 'allowed' list.
|
|
||||||
Especially internally.
|
|
||||||
|
|
||||||
== Troubleshooting and Resolution
|
|
||||||
|
|
||||||
=== Connection issues
|
|
||||||
|
|
||||||
The most common issue will be legitimate logins failing. First, try to
|
|
||||||
figure out why a host ended up on the deny list (tcptraceroute, failed
|
|
||||||
login attempts, etc are all good candidates). Next do the following
|
|
||||||
directions. The below example is for a host (10.0.0.1) being banned.
|
|
||||||
Login to the box from a different host and as root do the following.:
|
|
||||||
|
|
||||||
....
|
|
||||||
cd /var/lib/denyhosts
|
|
||||||
sed -si '/10.0.0.1/d' * /etc/hosts.deny
|
|
||||||
/etc/init.d/denyhosts restart
|
|
||||||
....
|
|
||||||
|
|
||||||
That should correct the problem.
|
|
||||||
|
|
@ -1,108 +0,0 @@
|
||||||
= Fedora Packages SOP
|
|
||||||
|
|
||||||
This SOP is for the Fedora Packages web application.
|
|
||||||
https://apps.fedoraproject.org/packages
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. Deploying to the servers
|
|
||||||
. Maintenance
|
|
||||||
. Checking for AGPL violations
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, #fedora-apps
|
|
||||||
Persons::
|
|
||||||
cverna
|
|
||||||
Location::
|
|
||||||
PHX2
|
|
||||||
Servers::
|
|
||||||
packages03.phx2.fedoraproject.org packages04.phx2.fedoraproject.org
|
|
||||||
packages03.stg.phx2.fedoraproject.org
|
|
||||||
Purpose::
|
|
||||||
Web interface for searching packages information
|
|
||||||
|
|
||||||
== Deploying to the servers
|
|
||||||
|
|
||||||
=== Deploying
|
|
||||||
|
|
||||||
Once the new version is built, it needs to be deployed. To deploy the
|
|
||||||
new version, you need
|
|
||||||
https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/sshaccess.html[ssh
|
|
||||||
access] to batcave01.phx2.fedoraproject.org and
|
|
||||||
https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/ansible.html[permissions
|
|
||||||
to run the Ansible playbook].
|
|
||||||
|
|
||||||
All the following commands should be run from batcave01.
|
|
||||||
|
|
||||||
You can check the upstream documentation, on how to build a new release.
|
|
||||||
This process results in a fedora-packages rpm available in the infra-tag
|
|
||||||
rpm repo.
|
|
||||||
|
|
||||||
You should make use of the staging instance in order to test the new
|
|
||||||
version of the application.
|
|
||||||
|
|
||||||
=== Upgrading
|
|
||||||
|
|
||||||
To upgrade, run the upgrade playbook:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ sudo rbac-playbook manual/upgrade/packages.yml
|
|
||||||
....
|
|
||||||
|
|
||||||
This will upgrade the fedora-pacages package and restart the Apache web
|
|
||||||
server and fedmsg-hub service.
|
|
||||||
|
|
||||||
=== Rebuild the xapian Database
|
|
||||||
|
|
||||||
If you need to rebuild the xapian database then you can run the
|
|
||||||
following playbook:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ sudo rbac-playbook manual/rebuild/fedora-packages.yml
|
|
||||||
....
|
|
||||||
|
|
||||||
== Maintenance
|
|
||||||
|
|
||||||
The web application is served by httpd and managed by the httpd
|
|
||||||
service.:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ sudo systemctl restart httpd
|
|
||||||
....
|
|
||||||
|
|
||||||
can be used to restart the service if needed. The application log files
|
|
||||||
are available under [.title-ref]#/var/log/httpd/# directory.
|
|
||||||
|
|
||||||
The xapian database is updated by a fedmsg consumer. You can restart the
|
|
||||||
fedmsg-hub serivce if needed by using:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ sudo systemctl restart fedmsg-hub
|
|
||||||
....
|
|
||||||
|
|
||||||
To check the consumer logs you can use:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ sudo journalctl -u fedmsg-hub
|
|
||||||
....
|
|
||||||
|
|
||||||
== Checking for AGPL violations
|
|
||||||
|
|
||||||
To remain AGPL compliant, we must ensure that all modifications to the
|
|
||||||
code are made available in the SRPM that we link to in the footer of the
|
|
||||||
application. You can easily query our app servers to determine if any
|
|
||||||
AGPL violating code modifications have been made to the package.:
|
|
||||||
|
|
||||||
....
|
|
||||||
func-command --host="*app*" --host="community*" "rpm -V fedoracommunity"
|
|
||||||
....
|
|
||||||
|
|
||||||
You can safely ignore any changes to non-code files in the output. If
|
|
||||||
any violations are found, the Infrastructure Team should be notified
|
|
||||||
immediately.
|
|
||||||
|
|
@ -1,82 +0,0 @@
|
||||||
= Fedora Pastebin SOP
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. Introduction
|
|
||||||
. Installation
|
|
||||||
. Dashboard
|
|
||||||
. Add a word to censored list
|
|
||||||
|
|
||||||
== 1. Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin
|
|
||||||
Persons::
|
|
||||||
athmane herlo
|
|
||||||
Sponsor::
|
|
||||||
nirik
|
|
||||||
Location::
|
|
||||||
phx2
|
|
||||||
Servers::
|
|
||||||
paste01.stg, paste01.dev
|
|
||||||
Purpose::
|
|
||||||
To host Fedora Pastebin
|
|
||||||
|
|
||||||
== 2. Introduction
|
|
||||||
|
|
||||||
Fedora pastebin is powered by sticky-notes which is included in EPEL.
|
|
||||||
|
|
||||||
Fedora theming (skin) is included in ansible role.
|
|
||||||
|
|
||||||
== 3. Installation
|
|
||||||
|
|
||||||
Sticky-notes needs a MySQL db and a user with 'select, update, delete,
|
|
||||||
insert' privileges.
|
|
||||||
|
|
||||||
It's recommended to dump and import db from a working installation to
|
|
||||||
save time (skipping the installation and tweaking).
|
|
||||||
|
|
||||||
By default the installation is locked ie: you can't relaunch it.
|
|
||||||
|
|
||||||
However, you can unlock the installation by commenting the line
|
|
||||||
containing `$gsod->trigger` in `/etc/sticky-notes/install.php` then
|
|
||||||
pointing the web browser to '/install'
|
|
||||||
|
|
||||||
The configuration file containing general settings and DB credentials is
|
|
||||||
located in `/etc/sticky-notes/config.php`
|
|
||||||
|
|
||||||
== 4. Dashboard
|
|
||||||
|
|
||||||
Sticky-notes has a dashboard (URL: /admin/) that can be used to :
|
|
||||||
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Manage pastes:::
|
|
||||||
** deleting paste
|
|
||||||
** getting information about the paste author (IP/Date/time etc...)
|
|
||||||
* Manage users (aka admins) which can log into the dashboard
|
|
||||||
* Manage IP Bans (add / delete banned IPs).
|
|
||||||
* Authentication (not needed)
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Site configuration:::
|
|
||||||
** General configuration (included in config.php).
|
|
||||||
** Project Honey Pot configuration (not a FOSS service)
|
|
||||||
** Word censor configuration: a list of words to be censored in
|
|
||||||
pastes.
|
|
||||||
|
|
||||||
== 5. Add a word to censored list
|
|
||||||
|
|
||||||
If a word is in censored list, any paste containing that word will be
|
|
||||||
rejected, to add one, edit the variable '$sg_censor' in sticky-notes
|
|
||||||
configuration file.:
|
|
||||||
|
|
||||||
....
|
|
||||||
$sg_censor = "WORD1
|
|
||||||
WORD2
|
|
||||||
...
|
|
||||||
...
|
|
||||||
WORDn";
|
|
||||||
....
|
|
||||||
|
|
@ -1,100 +0,0 @@
|
||||||
= FPDC SOP
|
|
||||||
|
|
||||||
Fedora Product Definition Center is a service that aims to replace
|
|
||||||
https://pdc.fedoraproject.org/[PDC] in Fedora. It is meant to be a
|
|
||||||
database with REST API access used to store data needed by other
|
|
||||||
services.
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-apps, #fedora-admin
|
|
||||||
Persons::
|
|
||||||
cverna, abompard
|
|
||||||
Location::
|
|
||||||
Phoenix (Openshift)
|
|
||||||
Public addresses::
|
|
||||||
* fpdc.fedoraproject.org
|
|
||||||
* fpdc.stg.fedoraproject.org
|
|
||||||
Servers::
|
|
||||||
* os.fedoraproject.org
|
|
||||||
* os.stg.fedoraproject.org
|
|
||||||
Purpose::
|
|
||||||
Centralize metadata and facilitate access.
|
|
||||||
|
|
||||||
== Systems
|
|
||||||
|
|
||||||
FPDC is built using the DJANGO REST FRAMEWORK and uses a POSTGRESQL
|
|
||||||
database to store the metadata. The application is run on Openshift and
|
|
||||||
uses the Source-to-image technology to build the container directly from
|
|
||||||
the https://github.com/fedora-infra/fpdc[git repository].
|
|
||||||
|
|
||||||
In the staging and production environments, the application is
|
|
||||||
automatically rebuilt for every new commit in the [.title-ref]#staging#
|
|
||||||
or [.title-ref]#production# branch, this is achieved by configuring a
|
|
||||||
github webhook's to trigger an openshift deployment.
|
|
||||||
|
|
||||||
For example a new deployment to staging would look like that:
|
|
||||||
|
|
||||||
____
|
|
||||||
git clone git@github.com:fedora-infra/fpdc.git cd fpdc git checkout
|
|
||||||
staging git rebase master git push origin staging
|
|
||||||
____
|
|
||||||
|
|
||||||
The initial Openshift project deployment is manual and is done using the
|
|
||||||
following ansible playbook :
|
|
||||||
|
|
||||||
....
|
|
||||||
sudo rbac-playbook openshift-apps/fpdc.yml
|
|
||||||
....
|
|
||||||
|
|
||||||
This will create a new fpdc project in Openshift with all the needed
|
|
||||||
configuration.
|
|
||||||
|
|
||||||
== Logs
|
|
||||||
|
|
||||||
Logs can be retrive using the openshift command line:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ oc login os-master01.phx2.fedoraproject.org
|
|
||||||
You must obtain an API token by visiting https://os.fedoraproject.org/oauth/token/request
|
|
||||||
|
|
||||||
$ oc login os-master01.phx2.fedoraproject.org --token=<Your token here>
|
|
||||||
$ oc -n fpdc get pods
|
|
||||||
fpdc-28-bfj52 1/1 Running 522 28d
|
|
||||||
$ oc logs fpdc-28-bfj52
|
|
||||||
....
|
|
||||||
|
|
||||||
== Database migrations
|
|
||||||
|
|
||||||
FPDC uses the [.title-ref]#recreate# deployment configuration of
|
|
||||||
openshift, which means that openshift will bring down the pods currently
|
|
||||||
running and recreate new ones with the new version of the application.
|
|
||||||
In the phase between the pods being down and the new pods being up, the
|
|
||||||
database migrations are run in an independent pod.
|
|
||||||
|
|
||||||
== Things that could go wrong
|
|
||||||
|
|
||||||
Hopefully not much. If something goes wrong is it currently advised to
|
|
||||||
kill the pods to trigger a fresh deployment. :
|
|
||||||
|
|
||||||
....
|
|
||||||
$ oc login os-master01.phx2.fedoraproject.org
|
|
||||||
You must obtain an API token by visiting https://os.fedoraproject.org/oauth/token/request
|
|
||||||
|
|
||||||
$ oc login os-master01.phx2.fedoraproject.org --token=<Your token here>
|
|
||||||
$ oc -n fpdc get pods
|
|
||||||
fpdc-28-bfj52 1/1 Running 522 28d
|
|
||||||
$ oc delete pod fpdc-28-bfj52
|
|
||||||
....
|
|
||||||
|
|
||||||
It is also possible to rollback to a previous version :
|
|
||||||
|
|
||||||
....
|
|
||||||
$ oc -n fpdc get dc
|
|
||||||
NAME REVISION DESIRED CURRENT TRIGGERED BY
|
|
||||||
fpdc 39 1 1 config,image(fpdc:latest)
|
|
||||||
$ oc -n fpdc rollback fpdc
|
|
||||||
....
|
|
||||||
|
|
@ -1,261 +0,0 @@
|
||||||
= FreeMedia Infrastructure SOP
|
|
||||||
|
|
||||||
This page is for defining the SOP for Fedora FreeMedia Program. This
|
|
||||||
will cover the infrastructural things as well as procedural things.
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Location of Resources
|
|
||||||
. Location on Ansible
|
|
||||||
. Opening of the form
|
|
||||||
. Closing of the Form
|
|
||||||
. Tentative timeline
|
|
||||||
. How to
|
|
||||||
|
|
||||||
____
|
|
||||||
[arabic]
|
|
||||||
. Open
|
|
||||||
. Close
|
|
||||||
____
|
|
||||||
|
|
||||||
____
|
|
||||||
[arabic, start=7]
|
|
||||||
. Handling of tickets
|
|
||||||
____
|
|
||||||
|
|
||||||
____
|
|
||||||
[arabic]
|
|
||||||
. Login
|
|
||||||
. Rejecting Invalid Tickets
|
|
||||||
. Accepting Valid Tickets
|
|
||||||
____
|
|
||||||
|
|
||||||
____
|
|
||||||
[arabic, start=8]
|
|
||||||
. Handling of non fulfilled requests
|
|
||||||
. How to handle membership applications
|
|
||||||
____
|
|
||||||
|
|
||||||
== Location of Resources
|
|
||||||
|
|
||||||
* The web form is at
|
|
||||||
https://fedoraproject.org/freemedia/FreeMedia-form.html
|
|
||||||
* The TRAC is at [63]https://fedorahosted.org/freemedia/report
|
|
||||||
|
|
||||||
== Location on ansible
|
|
||||||
|
|
||||||
$PWD = `roles/freemedia/files`
|
|
||||||
|
|
||||||
Freemedia form::
|
|
||||||
FreeMedia-form.html
|
|
||||||
Backup form::
|
|
||||||
FreeMedia-form.html.orig
|
|
||||||
Closed form::
|
|
||||||
FreeMedia-close.html
|
|
||||||
Backend processing script::
|
|
||||||
process.php
|
|
||||||
Error Document::
|
|
||||||
FreeMedia-error.html
|
|
||||||
|
|
||||||
== Opening of the form
|
|
||||||
|
|
||||||
The form will be opened on the First day of each month.
|
|
||||||
|
|
||||||
== Closing of the Form
|
|
||||||
|
|
||||||
=== Tentative timeline
|
|
||||||
|
|
||||||
The form will be closed after a couple of days. This may vary according
|
|
||||||
to the capacity.
|
|
||||||
|
|
||||||
== How to
|
|
||||||
|
|
||||||
* The form is available at `roles/freemedia/files/FreeMedia-form.html`
|
|
||||||
and `roles/freemedia/files//FreeMedia-form.html.orig`
|
|
||||||
* The closed form is at `roles/freemedia/files/FreeMedia-close.html`
|
|
||||||
|
|
||||||
=== Open
|
|
||||||
|
|
||||||
* Goto roles/freemedia/tasks
|
|
||||||
* Open `main.yml`
|
|
||||||
* Goto line 32.
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
To Open: Change the line to read::::
|
|
||||||
src="FreeMedia-form.html"
|
|
||||||
* After opening the form, go to trac and grant "Ticket Create and Ticket
|
|
||||||
View" privilege to "Anonymous".
|
|
||||||
|
|
||||||
=== Close
|
|
||||||
|
|
||||||
* Goto roles/freemedia/tasks
|
|
||||||
* Open main.yml
|
|
||||||
* Goto line 32.
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
To Close: Change the line to read::::
|
|
||||||
src="FreeMedia-close.html",
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
After closing the form, go to trac and remove "Ticket Create and::
|
|
||||||
Ticket View" privilege from "Anonymous".
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
* Have to check about monthly cron. * Have to write about changing
|
|
||||||
init.pp for closing and opening
|
|
||||||
====
|
|
||||||
|
|
||||||
== Handling of tickets
|
|
||||||
|
|
||||||
=== Login
|
|
||||||
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Contributors are requested to visit::
|
|
||||||
https://fedorahosted.org/freemedia/report
|
|
||||||
* Please login with your FAS account.
|
|
||||||
|
|
||||||
=== Rejecting Invalid Tickets
|
|
||||||
|
|
||||||
* If a ticket is invalid, don't accept the request. Go to "resolve as:"
|
|
||||||
and select "invalid" and then press "Submit Changes".
|
|
||||||
* A ticket is Invalid if
|
|
||||||
+
|
|
||||||
|
|
||||||
____
|
|
||||||
** No Valid email-id is provided.
|
|
||||||
** The region does not match the country.
|
|
||||||
** No Proper Address is given.
|
|
||||||
____
|
|
||||||
|
|
||||||
* If a ticket is duplicate, accept one copy, close the others as
|
|
||||||
duplicate Go to "resolve as:" and select "duplicate" and then press
|
|
||||||
"Submit Changes".
|
|
||||||
|
|
||||||
=== Accepting Valid Tickets
|
|
||||||
|
|
||||||
* If you wish to fulfill a request, please ensure it from the above
|
|
||||||
section, it is not liable to be discarded.
|
|
||||||
* Now "Accept" the ticket from the "Action" field at the bottom, and
|
|
||||||
press the "Submit Changes" button.
|
|
||||||
* These accepted tickets will be available from
|
|
||||||
https://fedorahosted.org/freemedia/report user both "My Tickets" and
|
|
||||||
"Accepted Tickets for XX" (XX= your region e.g APAC)
|
|
||||||
* When You ship the request, please go to the ticket again, go to
|
|
||||||
"resolve as:" from the "Action" field and select "Fixed" and then press
|
|
||||||
"Submit Changes".
|
|
||||||
* If an accepted ticket is not finalised by the end of the month, is
|
|
||||||
should be closed with "shipping status unknown" in a comment
|
|
||||||
|
|
||||||
=== Handling of non fulfilled requests
|
|
||||||
|
|
||||||
We shall close all the pending requests by the end of the Month.
|
|
||||||
|
|
||||||
* Please Check your region
|
|
||||||
|
|
||||||
=== How to handle membership applications
|
|
||||||
|
|
||||||
Steps to become member of Free-media Group.
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Create an account in Fedora Account System (FAS)
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
Create an user page in Fedora Wiki with contact data. Like::
|
|
||||||
User:<nick-name>. There are templates.
|
|
||||||
. Apply to Free-Media Group in FAS
|
|
||||||
. Apply to Free-Media mailing list subscription
|
|
||||||
|
|
||||||
==== Rules for deciding over membership applications
|
|
||||||
|
|
||||||
[cols=",,,,",]
|
|
||||||
|===
|
|
||||||
|Case |Applied to Free-Media Group |User Page Created |Applied to
|
|
||||||
Free-Media List a|
|
|
||||||
____
|
|
||||||
Action
|
|
||||||
____
|
|
||||||
|
|
||||||
|======= |================ |========== |===============
|
|
||||||
|=========================
|
|
||||||
|
|
||||||
|1 |Yes a|
|
|
||||||
____
|
|
||||||
Yes
|
|
||||||
____
|
|
||||||
|
|
||||||
|Yes |Approve Group and mailing list applications
|
|
||||||
|
|
||||||
a|
|
|
||||||
|
|
||||||
'''''
|
|
||||||
|
|
||||||
a|
|
|
||||||
|
|
||||||
'''''
|
|
||||||
|
|
||||||
a|
|
|
||||||
|
|
||||||
'''''
|
|
||||||
|
|
||||||
a|
|
|
||||||
|
|
||||||
'''''
|
|
||||||
|
|
||||||
|-------------------------Put on hold + Write to
|
|
||||||
|
|
||||||
|2 |Yes a|
|
|
||||||
____
|
|
||||||
Yes
|
|
||||||
____
|
|
||||||
|
|
||||||
|No |subscribe to list Within a Week
|
|
||||||
|
|
||||||
a|
|
|
||||||
|
|
||||||
'''''
|
|
||||||
|
|
||||||
a|
|
|
||||||
|
|
||||||
'''''
|
|
||||||
|
|
||||||
a|
|
|
||||||
|
|
||||||
'''''
|
|
||||||
|
|
||||||
a|
|
|
||||||
|
|
||||||
'''''
|
|
||||||
|
|
||||||
|-------------------------Put on hold + Write to
|
|
||||||
|
|
||||||
|3 |Yes a|
|
|
||||||
____
|
|
||||||
No
|
|
||||||
____
|
|
||||||
|
|
||||||
|whatever |make User Page Within a Week
|
|
||||||
|
|
||||||
|------- |---------------- |---------- |---------------
|
|
||||||
|-------------------------
|
|
||||||
|
|
||||||
|4 |No a|
|
|
||||||
____
|
|
||||||
No
|
|
||||||
____
|
|
||||||
|
|
||||||
|Yes |Reject
|
|
||||||
|===
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
{empty}1. As you need to have an FAS account for steps 2 and 3, this is
|
|
||||||
not included in the decision rules above 2. The time to be on hold is
|
|
||||||
one week. If not action is taken after one week, the application has to
|
|
||||||
be rejected. 3. When writing asking to fulfil steps, send CC to other
|
|
||||||
Free-media sponsors to let them know the application has been reviewed.
|
|
||||||
====
|
|
||||||
|
|
@ -1,149 +0,0 @@
|
||||||
= Freshmaker SOP
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
Freshmaker is very new and changing rapidly. We'll try to keep this up
|
|
||||||
to date as best we can.
|
|
||||||
====
|
|
||||||
|
|
||||||
Freshmaker is a service that watches message bus activity and tries
|
|
||||||
to rebuild _compound_ artifacts when their constituent pieces change.
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Factory2 Team, Release Engineering Team, Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-modularity, #fedora-admin, #fedora-releng
|
|
||||||
Persons::
|
|
||||||
jkaluza, cqi, qwan, sochotni, threebean
|
|
||||||
Location::
|
|
||||||
Phoenix
|
|
||||||
Public addresses::
|
|
||||||
* freshmaker.fedoraproject.org
|
|
||||||
Servers::
|
|
||||||
* freshmaker-frontend0[1-2].phx2.fedoraproject.org
|
|
||||||
* freshmaker-backend01.phx2.fedoraproject.org
|
|
||||||
Purpose::
|
|
||||||
Rebuild compound artifacts. See description for more detail.
|
|
||||||
|
|
||||||
== Description
|
|
||||||
|
|
||||||
See also
|
|
||||||
http://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker
|
|
||||||
for some of the original (old) thinking on Freshmaker.
|
|
||||||
|
|
||||||
As per the summary above, Freshmaker is a bus-oriented system that
|
|
||||||
watches for changes to smaller pieces of content, and triggers rebuilds
|
|
||||||
of larger pieces of content.
|
|
||||||
|
|
||||||
It doesn't do the actual _builds_ itself, but instead requests rebuilds
|
|
||||||
in our existing build systems.
|
|
||||||
|
|
||||||
It handles a number of different content types. In Fedora, we would like
|
|
||||||
to roll out rebuilds in the following order:
|
|
||||||
|
|
||||||
=== Module Builds
|
|
||||||
|
|
||||||
When a spec file changes on a particular dist-git branch, trigger
|
|
||||||
rebuilds of all modules that declare dependencies on that rpm branch.
|
|
||||||
|
|
||||||
Consider the _traditional workflow_ today. You make a patch to the
|
|
||||||
[.title-ref]#f27# of your package, and you know you need to build that
|
|
||||||
patch for f27, and then later submit an update for this single build.
|
|
||||||
Packagers know what to do.
|
|
||||||
|
|
||||||
Consider the _modular workflow_. You make a patch to the
|
|
||||||
[.title-ref]#2.2# branch of your package, but now, which modules do you
|
|
||||||
rebuild? Maybe you had one in mind that you wanted to fix, but are there
|
|
||||||
others that you forgot about -- that you don't even know about? Kevin
|
|
||||||
could maintain a module that pulls in my rpm branch and he never told
|
|
||||||
me. Even if he did, I have to now maintain a list of modules that depend
|
|
||||||
on my rpm, and request rebuilds of them everytime I patch my .spec file.
|
|
||||||
This is unmanageable.
|
|
||||||
|
|
||||||
Freshmaker deals with this by watching the bus for dist-git fedmsg
|
|
||||||
messages. When it sees a change on a branch, it looks up the list of
|
|
||||||
modules that depend on that branch, and requests rebuilds of them in the
|
|
||||||
MBS.
|
|
||||||
|
|
||||||
=== Container Slow Flow
|
|
||||||
|
|
||||||
When a traditional rpm or modular rpm is _shipped stable_, this trigger
|
|
||||||
rebuilds of all containers that ever included previous versions of this
|
|
||||||
rpm.
|
|
||||||
|
|
||||||
This applies to both modular and non-modular contexts. Today, you build
|
|
||||||
an rpm that fixes a CVE, but _some other person_ maintains a container
|
|
||||||
that includes your RPM. Maybe they never told you about this. Maybe they
|
|
||||||
didn't notice your CVE fix. Their container will remain outdated and
|
|
||||||
vulnerable.. forever?
|
|
||||||
|
|
||||||
Freshmaker deals with this by watching the bus for dist-git messages
|
|
||||||
about rpms being shipped to the stable updates repo. When they're
|
|
||||||
shipped, it looks up all containers that ever included pervious versions
|
|
||||||
of the rpm in question, and it triggers rebuilds of them.
|
|
||||||
|
|
||||||
_Waiting_ until the rpm ships to stable is _necessary_ because the
|
|
||||||
container build process doesn't know about unshipped content. This is
|
|
||||||
how containers are built manually today, and it is annoying. Which
|
|
||||||
brings us to the more complicated...
|
|
||||||
|
|
||||||
=== Container Fast Flow
|
|
||||||
|
|
||||||
When a traditional rpm or modular rpm is _signed_, generate a repo
|
|
||||||
containing it and rebuild all containers that ever included that rpm
|
|
||||||
before. This is the better version of the slow flow, but is more
|
|
||||||
complicated so we're deferring it until after we've proved the first two
|
|
||||||
cases out.
|
|
||||||
|
|
||||||
Freshmaker will do this by requesting an interim build repo from ODCS
|
|
||||||
(the On Demand Compose Service). ODCS can be given the appropriate koji
|
|
||||||
tag and will produce a repo of (pre-signed) rpms. Freshmaker will
|
|
||||||
request a rebuild of the container and will pass the ODCS repo url in.
|
|
||||||
This gives us an auditable trail of disposable repos.
|
|
||||||
|
|
||||||
== Systems
|
|
||||||
|
|
||||||
There is a frontend and a backend.
|
|
||||||
|
|
||||||
Everything in the previous section describes the backend behavior.
|
|
||||||
|
|
||||||
The frontend exists to provide an HTTP API that can be queried to find
|
|
||||||
out the status of the backend: What is it doing? What is it planning to
|
|
||||||
do? What has it done already?
|
|
||||||
|
|
||||||
== Observing Freshmaker Behavior
|
|
||||||
|
|
||||||
There is currently no command line tool to query Freshmaker, but
|
|
||||||
Freshmaker provides REST API which can be used to observe Freshmaker
|
|
||||||
behavior. This is available at the following URLs:
|
|
||||||
|
|
||||||
* https://freshmaker.fedoraproject.org/api/1/events
|
|
||||||
* https://freshmaker.fedoraproject.org/api/1/builds
|
|
||||||
|
|
||||||
The first [.title-ref]#/events# URL should return a list of events that
|
|
||||||
Freshmaker has noticed, recorded, and is handling. Handled events should
|
|
||||||
produce associated builds.
|
|
||||||
|
|
||||||
The second [.title-ref]#/builds# URL should return a list of builds that
|
|
||||||
Freshmaker has submitted and is monitoring. Each build should be
|
|
||||||
traceable back to the event that triggered it.
|
|
||||||
|
|
||||||
== Logs
|
|
||||||
|
|
||||||
The frontend logs are on freshmaker-frontend0[1-2] in
|
|
||||||
`/var/log/httpd/error_log`.
|
|
||||||
|
|
||||||
The backend logs are on freshmaker-backend01. Look in the journal for
|
|
||||||
the [.title-ref]#fedmsg-hub# service.
|
|
||||||
|
|
||||||
== Upgrading
|
|
||||||
|
|
||||||
The package in question is [.title-ref]#freshmaker#. Please use the
|
|
||||||
[.title-ref]#playbooks/manual/upgrade/freshmaker.yml# playbook.
|
|
||||||
|
|
||||||
== Things that could go wrong
|
|
||||||
|
|
||||||
TODO. We don't know yet. Probably lots of things.
|
|
||||||
|
|
@ -1,26 +0,0 @@
|
||||||
= Gitweb Infrastructure SOP
|
|
||||||
|
|
||||||
Gitweb-caching is the web interface we use to expose git to the web at
|
|
||||||
http://git.fedorahosted.org/git/
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, sysadmin-hosted
|
|
||||||
Location::
|
|
||||||
Serverbeach
|
|
||||||
Servers::
|
|
||||||
hosted[1-2]
|
|
||||||
Purpose::
|
|
||||||
Http access to git sources.
|
|
||||||
|
|
||||||
== Basic Function
|
|
||||||
|
|
||||||
* Users go to [46]http://git.fedorahosted.org/git/
|
|
||||||
* Pages are generated from cache stored in `/var/cache/gitweb-caching/`.
|
|
||||||
* The website is exposed via
|
|
||||||
`/etc/httpd/conf.d/git.fedoraproject.org.conf`.
|
|
||||||
* Main config file is `/var/www/gitweb-caching/gitweb_config.pl`. This
|
|
||||||
pulls git repos from /git/.
|
|
||||||
|
|
@ -1,191 +0,0 @@
|
||||||
= Fedorahosted migrations
|
|
||||||
|
|
||||||
Migrating hosted repositories to that of another type.
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. Description
|
|
||||||
. SVN to GIT migration
|
|
||||||
|
|
||||||
____
|
|
||||||
[arabic]
|
|
||||||
. Questions left to be answered with this SOP
|
|
||||||
____
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, sysadmin-hosted
|
|
||||||
Location::
|
|
||||||
Serverbeach
|
|
||||||
Servers::
|
|
||||||
hosted1, hosted2
|
|
||||||
Purpose::
|
|
||||||
Migrate hosted SCM repositories to that of another SCM.
|
|
||||||
|
|
||||||
== Description
|
|
||||||
|
|
||||||
fedorahosted.org can be used to host open source projects. Occasionally
|
|
||||||
those projects want to change the SCM they utilize. This document
|
|
||||||
provides documentation for doing so.
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. An scm for maintaining the code. The currently supported scm's include
|
|
||||||
Mercurial, Git, Bazaar, or SVN. Note: There is no cvs
|
|
||||||
. A trac instance, which provides a mini-wiki for hosting information
|
|
||||||
and also provides a ticketing system.
|
|
||||||
. A mailing list
|
|
||||||
|
|
||||||
[IMPORTANT]
|
|
||||||
.Important
|
|
||||||
====
|
|
||||||
This page is for administrators only. People wishing to request a hosted
|
|
||||||
project should use the [50]Ticketing System ; see the new project
|
|
||||||
request template. (Requires Fedora Account)
|
|
||||||
====
|
|
||||||
== SVN to GIT migration
|
|
||||||
|
|
||||||
=== FAS User Prep
|
|
||||||
|
|
||||||
Currently you must manually generate $PROJECTNAME-users.txt by grabbing
|
|
||||||
a list of people in the FAS group - and recording them in th following
|
|
||||||
format:
|
|
||||||
|
|
||||||
....
|
|
||||||
$fasusername = FirstName LastName <$emailaddress>
|
|
||||||
....
|
|
||||||
|
|
||||||
This is error prone, and will stop the git-svn fetch below if an author
|
|
||||||
appears that doesn't exist in the list of users.:
|
|
||||||
|
|
||||||
....
|
|
||||||
svn log --quiet | awk '/^r/ {print $3}' | sort -u
|
|
||||||
....
|
|
||||||
|
|
||||||
The above will generate a list of users in the svn repo.
|
|
||||||
|
|
||||||
If all users are FAS users you can use the following script to create a
|
|
||||||
users file (written by tmz (Todd Zullinger):
|
|
||||||
|
|
||||||
....
|
|
||||||
#!/bin/bash
|
|
||||||
|
|
||||||
if [ -z "$1" ]; then
|
|
||||||
echo "usage: $0 <svn repo>" >&2
|
|
||||||
exit 1
|
|
||||||
fi
|
|
||||||
|
|
||||||
svnurl=file:///svn/$1
|
|
||||||
|
|
||||||
if ! svn info $svnurl &>/dev/null; then
|
|
||||||
echo "$1 is not a valid svn repo." >&2
|
|
||||||
fi
|
|
||||||
|
|
||||||
svn log -q $svnurl | awk '/^r[0-9]+/ {print $3}' | sort -u | while read user; do
|
|
||||||
name=$( (getent passwd $user 2>/dev/null | awk -F: '{print $5}') || '' )
|
|
||||||
[ -z "$name" ] && name=$user
|
|
||||||
email="$user@fedoraproject.org"
|
|
||||||
echo "$user=$name <$email>"
|
|
||||||
done
|
|
||||||
....
|
|
||||||
|
|
||||||
=== Doing the conversion
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Log into hosted1
|
|
||||||
. Make a temporary directory to convert the repos in:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
$ sudo mkdir /tmp/tmp-$PROJECTNAME.git
|
|
||||||
|
|
||||||
$ cd /tmp/tmp-$PROJECTNAME.git
|
|
||||||
....
|
|
||||||
. Create an git repo ready to receive migrated SVN data:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
$ sudo git-svn init http://svn.fedorahosted.org/svn/$PROJECTNAME --no-metadata
|
|
||||||
....
|
|
||||||
. Tell git to fetch and convert the repository:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
$ git svn fetch
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
This creation of a temporary repository is necessary because SVN leaves a
|
|
||||||
number of items floating around that git can ignore, and we want those
|
|
||||||
essentially ignored.
|
|
||||||
....
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
From here, you'll wanted to follow [53]Creating a new git repo as if::
|
|
||||||
cloning an existing git repository to Fedorahosted.
|
|
||||||
. After that process is done - kindly remove the temporary repo that was
|
|
||||||
created:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
$ sudo rm -rf /tmp/tmp-$PROJECTNAME.git
|
|
||||||
....
|
|
||||||
|
|
||||||
=== Doing the converstion (alternate)
|
|
||||||
|
|
||||||
Alternately, here's another way to do this (tmz):
|
|
||||||
|
|
||||||
Setup a working dir:
|
|
||||||
|
|
||||||
....
|
|
||||||
[tmz@hosted1 tmp (master)]$ mkdir im-chooser-conversion && cd im-chooser-conversion
|
|
||||||
....
|
|
||||||
|
|
||||||
Create authors file mapping svn usernames to Name <email> form git
|
|
||||||
uses.:
|
|
||||||
|
|
||||||
....
|
|
||||||
[tmz@hosted1 im-chooser-conversion (master)]$ ~tmz/svn-to-git-authors im-chooser > authors
|
|
||||||
....
|
|
||||||
|
|
||||||
Convert svn to git:
|
|
||||||
|
|
||||||
....
|
|
||||||
[tmz@hosted1 im-chooser-conversion (master)]$ git svn clone -s -A authors --no-metadata file:///svn/im-chooser
|
|
||||||
....
|
|
||||||
|
|
||||||
Move svn branches and tags into proper locations for the new git repo.
|
|
||||||
(git-svn leaves them as 'remote' branches/tags.):
|
|
||||||
|
|
||||||
....
|
|
||||||
[tmz@hosted1 im-chooser-conversion (master)]$ cd im-chooser
|
|
||||||
[tmz@hosted1 im-chooser (master)]$ mv .git/refs/remotes/tags/* .git/refs/tags/ && rmdir .git/refs/remotes/tags
|
|
||||||
[tmz@hosted1 im-chooser (master)]$ mv .git/refs/remotes/* .git/refs/heads/
|
|
||||||
....
|
|
||||||
|
|
||||||
Now 'git branch' and 'git tag' should display the branches/tags.
|
|
||||||
|
|
||||||
Create a bare repo from the converted git repo. Using `file://$(pwd)`
|
|
||||||
here ensures that git copies all objects to the new bare repo.:
|
|
||||||
|
|
||||||
....
|
|
||||||
[tmz@hosted1 im-chooser-conversion (master)]$ git clone --bare --shared file://$(pwd)/im-chooser im-chooser.git
|
|
||||||
....
|
|
||||||
|
|
||||||
Follow the steps in
|
|
||||||
https://fedoraproject.org/wiki/Hosted_repository_setup to finish setting
|
|
||||||
proper modes and permissions for the repo. Don't forget to update the
|
|
||||||
description file.
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
This still leaves moving the converted bare repo (im-chooser.git) to
|
|
||||||
/git and fixing up the user/group.
|
|
||||||
====
|
|
||||||
== Questions left to be answered with this SOP
|
|
||||||
|
|
||||||
* Obviously we need to have requestor review the migration and confirm
|
|
||||||
it's ok.
|
|
||||||
* Do we then delete the old SCM contents?
|
|
||||||
* Do we need to change the FAS-group type to grant them access to
|
|
||||||
pull/push from it?
|
|
||||||
|
|
@ -1,144 +0,0 @@
|
||||||
= Fedora Hubs SOP
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, sysadmin-main, sysadmin-tools, sysadmin-hosted
|
|
||||||
Location::
|
|
||||||
?
|
|
||||||
Servers::
|
|
||||||
<prod-srv-hostname>, <stg-srv-hostname>, hubs-dev.fedorainfracloud.org
|
|
||||||
Purpose::
|
|
||||||
Contributor and team portal.
|
|
||||||
|
|
||||||
== Description
|
|
||||||
|
|
||||||
Fedora Hubs aggregates user and team activity throughout the Fedora
|
|
||||||
infrastructure (and elsewhere) to show what a user or a team is doing.
|
|
||||||
It helps new people find a place to contribute.
|
|
||||||
|
|
||||||
=== Components
|
|
||||||
|
|
||||||
Fedora Hubs has the following components:
|
|
||||||
|
|
||||||
* a SQL database like PostgreSQL (in the Fedora infra we're using the
|
|
||||||
shared database).
|
|
||||||
* a Redis server that is used as a message bus (it is not critical if
|
|
||||||
the content is lost). System service: `redis`.
|
|
||||||
* a MongoDB server used to store the contents of the activity feeds.
|
|
||||||
It's JSON data, limited to 100 entries per user or group. Service:
|
|
||||||
`mongod`.
|
|
||||||
* a Flask-based WSGI app served by Apache + mod_wsgi, that will also
|
|
||||||
serve the JS front end as static files. System service: `httpd`.
|
|
||||||
* a Fedmsg listener that receives messages from the fedmsg bus and puts
|
|
||||||
them in Redis. System service: `fedmsg-hub`.
|
|
||||||
* a set of "triage" workers that pull the raw messages from Redis,
|
|
||||||
process them using SQL queries and puts work items in another Redis
|
|
||||||
queue. System service: `fedora-hubs-triage@`.
|
|
||||||
* a set of "worker" daemons that pull from this other Redis queue, work
|
|
||||||
on the items by making SQL queries and external HTTP requests (to Github
|
|
||||||
for example), and put reload notifications in the SSE Redis queue. They
|
|
||||||
also access the caching system, which can be local files or memcached.
|
|
||||||
System service: `fedora-hubs-worker@`.
|
|
||||||
* The SSE server (Twisted-based) that pulls from that Redis queue and
|
|
||||||
sends reload notifications to the connected browsers. It handles
|
|
||||||
long-lived HTTP connection but there is little activity: only the
|
|
||||||
notifications and a "keepalive ping" message every 30 seconds to every
|
|
||||||
connected browser. System service: `fedora-hubs-sse`. Apache is
|
|
||||||
configured to proxy the `/sse` path to this server.
|
|
||||||
|
|
||||||
== Managing the services
|
|
||||||
|
|
||||||
Restarting all the services:
|
|
||||||
|
|
||||||
....
|
|
||||||
systemctl restart fedmsg-hub fedora-hubs-\*
|
|
||||||
....
|
|
||||||
|
|
||||||
By default, 4 `triage` daemons and 4 `worker` daemons are enabled. To
|
|
||||||
add another `triage` daemon and another `worker` daemon, you can run:
|
|
||||||
|
|
||||||
....
|
|
||||||
systemctl enable --now fedora-hubs-triage@5.service
|
|
||||||
systemctl enable --now fedora-hubs-worker@5.service
|
|
||||||
....
|
|
||||||
|
|
||||||
It is not necessary to have the same number of `triage` and `worker`
|
|
||||||
daemons, in fact it is expected that more `worker` than `triage` daemons
|
|
||||||
will be necessary, as they do more time-consuming work.
|
|
||||||
|
|
||||||
== Hubs-specific operations
|
|
||||||
|
|
||||||
Other Hubs-specific operations are done using the
|
|
||||||
[.title-ref]#fedora-hubs# command:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ fedora-hubs
|
|
||||||
Usage: fedora-hubs [OPTIONS] COMMAND [ARGS]...
|
|
||||||
|
|
||||||
Options:
|
|
||||||
--help Show this message and exit.
|
|
||||||
|
|
||||||
Commands:
|
|
||||||
cache Cache-related operations.
|
|
||||||
db Database-related operations.
|
|
||||||
fas FAS-related operations.
|
|
||||||
run Run daemon processes.
|
|
||||||
....
|
|
||||||
|
|
||||||
=== Manipulating the cache
|
|
||||||
|
|
||||||
The `cache` subcommand is used to do cache-related operations:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ fedora-hubs cache
|
|
||||||
Usage: fedora-hubs cache [OPTIONS] COMMAND [ARGS]...
|
|
||||||
|
|
||||||
Cache-related operations.
|
|
||||||
|
|
||||||
Options:
|
|
||||||
--help Show this message and exit.
|
|
||||||
|
|
||||||
Commands:
|
|
||||||
clean Clean the specified WIDGETs (id or name).
|
|
||||||
coverage Check the cache coverage.
|
|
||||||
list List widgets for which there is cached data.
|
|
||||||
....
|
|
||||||
|
|
||||||
For example, to check the cache coverage:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ fedora-hubs cache coverage
|
|
||||||
107 cached values found, 95 are missing.
|
|
||||||
52.97 percent cache coverage.
|
|
||||||
....
|
|
||||||
|
|
||||||
The cache coverage value is an interesting metric that could be used in
|
|
||||||
a Nagios check. A value below 50% could be considered as significant of
|
|
||||||
application slowdowns and could thus generate a warning.
|
|
||||||
|
|
||||||
=== Interacting with FAS
|
|
||||||
|
|
||||||
The `fas` subcommand is used to get information from FAS:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ fedora-hubs fas
|
|
||||||
Usage: fedora-hubs fas [OPTIONS] COMMAND [ARGS]...
|
|
||||||
|
|
||||||
FAS-related operations.
|
|
||||||
|
|
||||||
Options:
|
|
||||||
--help Show this message and exit.
|
|
||||||
|
|
||||||
Commands:
|
|
||||||
create-team Create the team hub NAME from FAS.
|
|
||||||
sync-teams Sync all the team hubs NAMEs from FAS.
|
|
||||||
....
|
|
||||||
|
|
||||||
To add a new team hub for a FAS group, run:
|
|
||||||
|
|
||||||
....
|
|
||||||
$ fedora-hubs fas create-team <fas-group-name>
|
|
||||||
....
|
|
||||||
|
|
@ -1,60 +0,0 @@
|
||||||
= IBM RSA II Infrastructure SOP
|
|
||||||
|
|
||||||
Many of our physical machines use RSA II cards for remote management.
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, sysadmin-main
|
|
||||||
Location::
|
|
||||||
PHX, ibiblio
|
|
||||||
Servers::
|
|
||||||
All physical IBM machines
|
|
||||||
Purpose::
|
|
||||||
Provide remote management for our physical IBM machines
|
|
||||||
|
|
||||||
== Restarting the RSA II card
|
|
||||||
|
|
||||||
Normally, the RSA II can be restarted from the web/ssh interface. If you
|
|
||||||
are locked out of any outside access to the RSA II, follow these
|
|
||||||
instructions on the physical machine.
|
|
||||||
|
|
||||||
If the machine can be rebooted without issue, cut off all power to the
|
|
||||||
machine, wait a few seconds, and restart everything.
|
|
||||||
|
|
||||||
Otherwise, to restart the card without rebooting the machine:
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Download and install the IBM Remote Supervisor Adapter II Daemon
|
|
||||||
+
|
|
||||||
____
|
|
||||||
[arabic]
|
|
||||||
.. `yum install usbutils libusb-devel` # (needed by the RSA II daemon)
|
|
||||||
.. {blank}
|
|
||||||
+
|
|
||||||
Download the correct tarball from::
|
|
||||||
http://www-947.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-5071676&brandind=5000008
|
|
||||||
(TODO: check if this can be packaged in Fedora)
|
|
||||||
.. Extract the tarball and run `sudo ./install.sh --update`
|
|
||||||
____
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
Download and extract the IBM Advanced Settings Utility::
|
|
||||||
http://www-947.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=TOOL-ASU&brandind=5000016
|
|
||||||
+
|
|
||||||
____
|
|
||||||
[WARNING]
|
|
||||||
.Warning
|
|
||||||
====
|
|
||||||
this tarball dumps files in the current working directory
|
|
||||||
====
|
|
||||||
____
|
|
||||||
. Issue a `sudo ./asu64 rebootrsa` to reboot the RSA II.
|
|
||||||
. Clean up: `yum remove ibmusbasm64`
|
|
||||||
|
|
||||||
== Other Resources
|
|
||||||
|
|
||||||
http://www.redbooks.ibm.com/abstracts/sg246495.html may be a useful
|
|
||||||
resource to refer to when working with this.
|
|
||||||
|
|
@ -1,140 +0,0 @@
|
||||||
= Infrastructure/SOP/Yubikey
|
|
||||||
|
|
||||||
This document describes how yubikey authentication works
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. User Information
|
|
||||||
. Host Admins
|
|
||||||
+
|
|
||||||
____
|
|
||||||
[arabic]
|
|
||||||
.. pam_yubico
|
|
||||||
____
|
|
||||||
. Server Admins
|
|
||||||
+
|
|
||||||
____
|
|
||||||
[arabic]
|
|
||||||
.. Basic architecture
|
|
||||||
.. ykval
|
|
||||||
.. ykksm
|
|
||||||
.. Physical Yubikey info
|
|
||||||
____
|
|
||||||
. fas integration
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, sysadmin-main
|
|
||||||
Location::
|
|
||||||
Phoenix
|
|
||||||
Servers::
|
|
||||||
fas*, db02
|
|
||||||
Purpose::
|
|
||||||
Provides yubikey authentication in Fedora
|
|
||||||
|
|
||||||
== Config Files
|
|
||||||
|
|
||||||
* `/etc/httpd/conf.d/yk-ksm.conf`
|
|
||||||
* `/etc/httpd/conf.d/yk-val.conf`
|
|
||||||
* `/etc/ykval/ykval-config.php`
|
|
||||||
* `/etc/ykksm/ykksm-config.php`
|
|
||||||
* `/etc/fas.cfg`
|
|
||||||
|
|
||||||
== User Information
|
|
||||||
|
|
||||||
See [57]Infrastruture/Yubikey
|
|
||||||
|
|
||||||
== Host Admins
|
|
||||||
|
|
||||||
pam_yubico
|
|
||||||
|
|
||||||
Generated from fas, the /etc/yubikeyid works like a authroized_keys file
|
|
||||||
and maps valid keys to users. It is downloaded from FAS:
|
|
||||||
|
|
||||||
[58]https://admin.fedoraproject.org/accounts/yubikey/dump
|
|
||||||
|
|
||||||
== Server Admins
|
|
||||||
|
|
||||||
=== Basic architecture
|
|
||||||
|
|
||||||
Yubikey authentication takes place in 3 basic phases.
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. User presses yubikey which generates a one time password
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
The one time password makes its way to the yk-val application which::
|
|
||||||
verifies it is not a replay
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
yk-val passes that otp on to the yk-ksm application which verifies the::
|
|
||||||
key itself is a valid key
|
|
||||||
|
|
||||||
If all of those steps succeed, the ykval application sends back an OK
|
|
||||||
and authentication is considered successful. The two applications are
|
|
||||||
defined below, if either of them is unavailable, yubikey authentication
|
|
||||||
will fail.
|
|
||||||
|
|
||||||
==== ykval
|
|
||||||
|
|
||||||
Database: db02:ykval
|
|
||||||
|
|
||||||
The database contains 3 tables. clients: just a valid client. These are
|
|
||||||
not users, these are systems able to authenticate against ykval. In our
|
|
||||||
case Fedora is the only client so there's just one entry here queue:
|
|
||||||
Used for distributed setups (we don't do this) yubikeys: maps which
|
|
||||||
yubikey belongs to which user
|
|
||||||
|
|
||||||
ykval is installed on fas* and is located at:
|
|
||||||
[59]http://localhost/yk-val/verify
|
|
||||||
|
|
||||||
Purpose: Is to map keys to users and protect against replay attacks
|
|
||||||
|
|
||||||
==== ykksm
|
|
||||||
|
|
||||||
Database: db02:ykksm
|
|
||||||
|
|
||||||
The database contains one table: yubikeys: maps who created keys, what
|
|
||||||
key was created, when, and the public name and serial number, whether
|
|
||||||
its active, etc.
|
|
||||||
|
|
||||||
ykksm is installed on fas* at [60]http://localhost/yk-ksm
|
|
||||||
|
|
||||||
Purpose: verify if a key is a valid known key or not. Nothing contacts
|
|
||||||
this service directly except for ykval. This should be considered the
|
|
||||||
“high security” portion of the system as access to this table would
|
|
||||||
allow users to make their own yubikeys.
|
|
||||||
|
|
||||||
==== Physical Yubikey info
|
|
||||||
|
|
||||||
The actual yubikey contains information to generate a one time password.
|
|
||||||
The important bits to know are the begining of the otp contains the
|
|
||||||
identifier of the key (used similar to how ssh uses authorized_keys) and
|
|
||||||
note the rest of it contains lots of bits of information, including a
|
|
||||||
serial incremental.
|
|
||||||
|
|
||||||
Sample key: `ccccfcdaivjrvdhvzfljbbievftnvncljhibkulrftt`
|
|
||||||
|
|
||||||
Breaking this up, the first 12 characters are the identifier. This can
|
|
||||||
be considered 'public'
|
|
||||||
|
|
||||||
ccccfcdaivj rvdhvzfljbbievftnvncljhibkulrftt
|
|
||||||
|
|
||||||
The second half is the otp part.
|
|
||||||
|
|
||||||
== fas integration
|
|
||||||
|
|
||||||
Fas integration has two main parts. First is key generation, the next is
|
|
||||||
activation. The fas-plugin-yubikey contains the bits for both, and
|
|
||||||
verification. Users call on this page to generate the key info:
|
|
||||||
|
|
||||||
[61]https://admin.fedoraproject.org/accounts/yubikey/genkey
|
|
||||||
|
|
||||||
The fas password field automatically detects whether someone is using a
|
|
||||||
otp or a regular password. It then sends otp requests to yk-val for
|
|
||||||
verification.
|
|
||||||
|
|
@ -1,77 +0,0 @@
|
||||||
= Link tracking
|
|
||||||
|
|
||||||
Using link tracking is [43]an easy way for us to find out how people are
|
|
||||||
getting to our download page. People might click over to our download
|
|
||||||
page from any of a number of areas, and knowing the relative usage of
|
|
||||||
those links can help us understand what materials we're producing are
|
|
||||||
more effective than others.
|
|
||||||
|
|
||||||
== Adding links
|
|
||||||
|
|
||||||
Each link should be constructed by adding ? to the URL, followed by a
|
|
||||||
short code that includes:
|
|
||||||
|
|
||||||
* an indicator for the link source (such as the wiki release notes)
|
|
||||||
* an indicator for the Fedora release in specific (such as F15 for the
|
|
||||||
final, or F15a for the Alpha test release)
|
|
||||||
|
|
||||||
So a link to get.fp.o from the one-page release notes would become
|
|
||||||
http://get.fedoraproject.org/?opF15.
|
|
||||||
|
|
||||||
== FAQ
|
|
||||||
|
|
||||||
I want to copy a link to my status update for social networking, or my
|
|
||||||
blog.::
|
|
||||||
If you're posting a status update to identi.ca, for example, use the
|
|
||||||
link tracking code for status updates. Don't copy a link straight from
|
|
||||||
an announcement that includes link tracking from the announcement. You
|
|
||||||
can copy the link itself but remember to change the portion after the
|
|
||||||
? to instead use the st code for status updates and blogs, followed by
|
|
||||||
the Fedora release version (such as F16a, F16b, or F16), like this:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
http://fedoraproject.org/get-prerelease?stF16a
|
|
||||||
....
|
|
||||||
I want to point people to the announcement from my blog. Should I use
|
|
||||||
the announcement link tracking code?::
|
|
||||||
The actual URL link itself is the announcement URL. Add the link
|
|
||||||
tracking code for blogs, which would start with ?st and end with the
|
|
||||||
Fedora release version, like this:
|
|
||||||
+
|
|
||||||
....
|
|
||||||
http://fedoraproject.org/wiki/F16_release_announcement?stF16a
|
|
||||||
....
|
|
||||||
|
|
||||||
== The codes
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
Additions to this table are welcome.
|
|
||||||
====
|
|
||||||
|
|
||||||
[cols=",",options="header",]
|
|
||||||
|===
|
|
||||||
|Link source |Code
|
|
||||||
|Email announcements |an
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|Wiki announcements |wkan
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|Front page |fp
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|Front page of wiki |wkfp
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|The press release Red Hat makes |rhpr
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|http://redhat.com/fedora |rhf
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|Test phase release notes on |wkrn
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|Official release notes |rn
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|Official installation guide |ig
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|One-page release notes |op
|
|
||||||
|----------------------------------------------- |----------
|
|
||||||
|Status links (blogs, social media) |st
|
|
||||||
|===
|
|
||||||
|
|
@ -1,148 +0,0 @@
|
||||||
= Loopabull
|
|
||||||
|
|
||||||
https://github.com/maxamillion/loopabull[Loopabull] is an event-driven
|
|
||||||
https://www.ansible.com/[Ansible]-based automation engine. This is used
|
|
||||||
for various tasks, originally slated for
|
|
||||||
https://pagure.io/releng-automation[Release Engineering Automation].
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. Overview
|
|
||||||
. Setup
|
|
||||||
. Outage
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Adam Miller (maxamillion) Pierre-Yves Chibon (pingou)
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, #fedora-releng, #fedora-noc, sysadmin-main,
|
|
||||||
sysadmin-releng
|
|
||||||
Location::
|
|
||||||
loopabull01.phx2.fedoraproject.org
|
|
||||||
loopabull01.stg.phx2.fedoraproject.org
|
|
||||||
Purpose::
|
|
||||||
Event Driven Automation of tasks within the Fedora Infrastructure and
|
|
||||||
Fedora Release Engineering
|
|
||||||
|
|
||||||
== Overview
|
|
||||||
|
|
||||||
The https://github.com/maxamillion/loopabull[loopabull] system is setup
|
|
||||||
such that an event will take place within the infrastructure and a
|
|
||||||
http://www.fedmsg.com/en/latest/[fedmsg] is sent, then loopabull will
|
|
||||||
consume that message, trigger an https://www.ansible.com/[Ansible]
|
|
||||||
http://docs.ansible.com/ansible/playbooks.html[playbook] that shares a
|
|
||||||
name with the fedmsg topic, and provide the payload of the fedmsg to the
|
|
||||||
playbook as
|
|
||||||
https://github.com/ansible/ansible/blob/devel/docs/man/man1/ansible-playbook.1.asciidoc.in[extra
|
|
||||||
variables].
|
|
||||||
|
|
||||||
== Setup
|
|
||||||
|
|
||||||
The setup is relatively simple, the Overview above describes it and a
|
|
||||||
more detailed version can be found in the [.title-ref]#releng docs#.
|
|
||||||
|
|
||||||
....
|
|
||||||
+-----------------+ +-------------------------------+
|
|
||||||
| | | |
|
|
||||||
| fedmsg +------------>| Looper |
|
|
||||||
| | | (fedmsg handler plugin) |
|
|
||||||
| | | |
|
|
||||||
+-----------------+ +-------------------------------+
|
|
||||||
|
|
|
||||||
|
|
|
||||||
+-------------------+ |
|
|
||||||
| | |
|
|
||||||
| | |
|
|
||||||
| Loopabull +<-------------+
|
|
||||||
| (Event Loop) |
|
|
||||||
| |
|
|
||||||
+---------+---------+
|
|
||||||
|
|
|
||||||
|
|
|
||||||
|
|
|
||||||
|
|
|
||||||
V
|
|
||||||
+----------+-----------+
|
|
||||||
| |
|
|
||||||
| ansible-playbook |
|
|
||||||
| |
|
|
||||||
+----------------------+
|
|
||||||
....
|
|
||||||
|
|
||||||
=== Deployment
|
|
||||||
|
|
||||||
Loopabull is deployed on two hosts, one for the production instance:
|
|
||||||
`loopabull01.prod.phx2.fedoraproject.org` and one for the staging
|
|
||||||
instance: `loopabull01.stg.phx2.fedoraproject.org`.
|
|
||||||
|
|
||||||
Each host is running loopabull with 5 workers reacting to fedmsg
|
|
||||||
notifications.
|
|
||||||
|
|
||||||
== Expanding loopabull
|
|
||||||
|
|
||||||
The documentation to expand loopabull's usage is documented at:
|
|
||||||
https://pagure.io/Fedora-Infra/loopabull-tasks
|
|
||||||
|
|
||||||
== Outage
|
|
||||||
|
|
||||||
In the event that loopabull isn't responding or isn't running playbooks
|
|
||||||
as it should be, the following scenarios should be approached.
|
|
||||||
|
|
||||||
=== What is going on?
|
|
||||||
|
|
||||||
There are a few commands that may help figuring out what is going:
|
|
||||||
|
|
||||||
* Check the status of the different services:
|
|
||||||
|
|
||||||
....
|
|
||||||
systemctl |grep loopabull
|
|
||||||
....
|
|
||||||
|
|
||||||
* Follow the logs of the different services:
|
|
||||||
|
|
||||||
....
|
|
||||||
journalctl -lfu loopabull -u loopabull@1 -u loopabull@2 -u loopabull@3 \
|
|
||||||
-u loopabull@4 -u loopabull@5
|
|
||||||
....
|
|
||||||
|
|
||||||
If a playbook returns a non-zero error code, the worker running it will
|
|
||||||
be stopped. If that happens, you may want to carefully review the logs
|
|
||||||
to assess what lead to this situation so it can be prevented in the
|
|
||||||
future.
|
|
||||||
|
|
||||||
* Monitoring the queue size
|
|
||||||
|
|
||||||
The loopabull service listens to the fedmsg bus and puts the messages as
|
|
||||||
they come into a rabbitmq/amqp queue for the workers to process. If you
|
|
||||||
want to see the number of messages pending to be processed by the
|
|
||||||
workers you can check the queue size using:
|
|
||||||
|
|
||||||
....
|
|
||||||
rabbitmqctl list_queues
|
|
||||||
....
|
|
||||||
|
|
||||||
The output will be something like:
|
|
||||||
|
|
||||||
....
|
|
||||||
Listing queues ...
|
|
||||||
workers 489989
|
|
||||||
...done.
|
|
||||||
....
|
|
||||||
|
|
||||||
Where `workers` is the name of the queue used by loopabull and `489989`
|
|
||||||
the number of messages in that queue (yes that day we were recovering
|
|
||||||
from a several-day long outage).
|
|
||||||
|
|
||||||
=== Network Interruption
|
|
||||||
|
|
||||||
Sometimes if the network is interrupted, the loopabull service will hang
|
|
||||||
because the fedmsg listener will hold a dead socket open. The service
|
|
||||||
and its workers simply needs to be restarted at that point.
|
|
||||||
|
|
||||||
....
|
|
||||||
systemctl restart loopabull loopabull@1 loopabull@2 loopabull@3 \
|
|
||||||
loopabull@4 loopabull@5
|
|
||||||
....
|
|
||||||
|
|
@ -6,27 +6,27 @@ aboard!
|
||||||
== Contents
|
== Contents
|
||||||
|
|
||||||
[arabic]
|
[arabic]
|
||||||
. Contact Information
|
. <<_contact_information>>
|
||||||
. Description
|
. <<_description>>
|
||||||
. Welcome to the team
|
. Welcome to the team
|
||||||
|
|
||||||
____
|
____
|
||||||
[arabic]
|
[arabic]
|
||||||
. Time commitment
|
. <<_time_commitment>>
|
||||||
. Prove Yourself
|
. <<_prove_yourself>>
|
||||||
____
|
____
|
||||||
|
|
||||||
[arabic, start=4]
|
[arabic, start=4]
|
||||||
. Doing Work
|
. <<_doing_work>>
|
||||||
|
|
||||||
____
|
____
|
||||||
[arabic]
|
[arabic]
|
||||||
. Ansible
|
. <<_ansible>>
|
||||||
____
|
____
|
||||||
|
|
||||||
[arabic, start=5]
|
[arabic, start=5]
|
||||||
. Our Setup
|
. <<_our_setup>>
|
||||||
. Our Rules
|
. <<_our_rules>>
|
||||||
|
|
||||||
== Contact Information
|
== Contact Information
|
||||||
|
|
||||||
|
|
@ -159,7 +159,7 @@ ask about it.
|
||||||
The Fedora Infrastructure Team does have some rules. First is the
|
The Fedora Infrastructure Team does have some rules. First is the
|
||||||
security policy. Please ensure you are compliant with:
|
security policy. Please ensure you are compliant with:
|
||||||
|
|
||||||
https://infrastructure.fedoraproject.org/csi/security-policy/
|
https://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-single/
|
||||||
|
|
||||||
before logging in to any of our servers. Many of those items rely on the
|
before logging in to any of our servers. Many of those items rely on the
|
||||||
honor system.
|
honor system.
|
||||||
|
|
|
||||||
|
|
@ -1,63 +0,0 @@
|
||||||
= Private fedorahosted tickets Infrastructure SOP
|
|
||||||
|
|
||||||
Provides for users only viewing tickets they are involved with.
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact::
|
|
||||||
#fedora-admin, sysadmin-hosted
|
|
||||||
Location::
|
|
||||||
<not sure what to put here>
|
|
||||||
Servers::
|
|
||||||
hosted1
|
|
||||||
Purpose::
|
|
||||||
Provides for users only viewing tickets they are involved with.
|
|
||||||
|
|
||||||
== Description
|
|
||||||
|
|
||||||
Fedora Hosted Projects have the option of setting ticket permissions so
|
|
||||||
that only users involved with tickets can see them. This plugin requires
|
|
||||||
someone in sysadmin-hosted to set it up, and requires justification to
|
|
||||||
use. The only current implementation is a request tracking system at
|
|
||||||
[45]https://fedorahosted.org/famnarequests for tracking requests for
|
|
||||||
North American ambassadors since mailing addresses, etc will be put in
|
|
||||||
there.
|
|
||||||
|
|
||||||
== Implementation
|
|
||||||
|
|
||||||
On hosted1:
|
|
||||||
|
|
||||||
....
|
|
||||||
sudo -u apache vim /srv/web/trac/projects/<project name>/conf/trac.ini
|
|
||||||
....
|
|
||||||
|
|
||||||
Add the following to the appropriate sections of `trac.ini`:
|
|
||||||
|
|
||||||
....
|
|
||||||
[privatetickets]
|
|
||||||
group_blacklist = anonymous, authenticated
|
|
||||||
|
|
||||||
[components]
|
|
||||||
privatetickets.* = enabled
|
|
||||||
|
|
||||||
[trac]
|
|
||||||
permission_policies = PrivateTicketsPolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy
|
|
||||||
....
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
For projects not currently using plugins, you'll have to add the
|
|
||||||
[components] section, and you'll need to add the permission_policies to
|
|
||||||
the [trac] section.
|
|
||||||
====
|
|
||||||
|
|
||||||
Next, someone with TRAC_ADMIN needs to grant TICKET_VIEW_SELF (a new
|
|
||||||
permission) to authenticated. This permission allows users to view
|
|
||||||
tickets that they are either owner, CC, or reporter on. There are other
|
|
||||||
options more fully described at [46]the upstream site.
|
|
||||||
|
|
||||||
Make sure that TICKET_VIEW is removed from anonymous, or else this
|
|
||||||
plugin will have no effect.
|
|
||||||
|
|
@ -1,185 +0,0 @@
|
||||||
= ReviewBoard Infrastructure SOP
|
|
||||||
|
|
||||||
Review Board is a powerful web-based code review tool that offers
|
|
||||||
developers an easy way to handle code reviews. It scales well from small
|
|
||||||
projects to large companies and offers a variety of tools to take much
|
|
||||||
of the stress and time out of the code review process.
|
|
||||||
|
|
||||||
== Contents
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Contact Information
|
|
||||||
. File Locations
|
|
||||||
. Troubleshooting and Resolution
|
|
||||||
|
|
||||||
____
|
|
||||||
* Restarting
|
|
||||||
____
|
|
||||||
|
|
||||||
[arabic, start=4]
|
|
||||||
. Create a new repository in ReviewBoard
|
|
||||||
|
|
||||||
____
|
|
||||||
* Creating a new git repository
|
|
||||||
* Creating a new bzr repository
|
|
||||||
* Create a default reviewer for a repository
|
|
||||||
____
|
|
||||||
|
|
||||||
== Contact Information
|
|
||||||
|
|
||||||
Owner:::
|
|
||||||
Fedora Infrastructure Team
|
|
||||||
Contact:::
|
|
||||||
#fedora-admin, sysadmin-main, sysadmin-hosted
|
|
||||||
Location:::
|
|
||||||
ServerBeach
|
|
||||||
Servers:::
|
|
||||||
hosted[1-2]
|
|
||||||
Purpose:::
|
|
||||||
Provide our fedorahosted users a way to review code.
|
|
||||||
|
|
||||||
== File Locations
|
|
||||||
|
|
||||||
Main Config File:::
|
|
||||||
hosted[1-2]:/srv/reviewboard/conf/settings_local.py
|
|
||||||
ReviewBoard:::
|
|
||||||
hosted[1-2]:/etc/httpd/conf.d/fedorahosted.org/reviewboard.conf
|
|
||||||
Upstream:::
|
|
||||||
https://fedorahosted.org/reviewboard/
|
|
||||||
|
|
||||||
== Troubleshooting and Resolution
|
|
||||||
|
|
||||||
=== Restarting
|
|
||||||
|
|
||||||
After an update, to restart reviewboard just restart apache. Doing a
|
|
||||||
service httpd stop and then a service httpd start should do it.
|
|
||||||
|
|
||||||
== Create a new repository in ReviewBoard
|
|
||||||
|
|
||||||
=== Creating a new git repository
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
Enter the admin interface. If you have admin privilege, a link will be::
|
|
||||||
visible in the upper-right corner of the dashboard.
|
|
||||||
. In the admin dashboard click "Add" next to "Repositories"
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
For the name, enter the Fedora Hosted project short name. (e.g. if the::
|
|
||||||
project is [53]https://fedorahosted.org/sssd, then the repository name
|
|
||||||
should be sssd)
|
|
||||||
. "Show this repository" must be checked.
|
|
||||||
. Hosting service is "Custom"
|
|
||||||
. Repository type is Git
|
|
||||||
. Path should be /srv/git/project_short_name.git (e.g.
|
|
||||||
/srv/git/sssd.git)
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
Mirror path should be::
|
|
||||||
git://git.fedorahosted.org/git/project_short_name.git
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
Mirror path is used by client tools such as post-review to determine to
|
|
||||||
which repository a submission belongs
|
|
||||||
====
|
|
||||||
[arabic, start=9]
|
|
||||||
. Raw file URL mask should be left blank
|
|
||||||
. Username and Password should both be left blank
|
|
||||||
. The bug tracker URL may vary from project to project, but if they are
|
|
||||||
using the Fedora Hosted Trac bugtracker, it should be
|
|
||||||
* Type: Trac
|
|
||||||
* {blank}
|
|
||||||
+
|
|
||||||
Bug Tracker URL: [54]https://fedorahosted.org/project_short_name::
|
|
||||||
(e.g. [55]https://fedorahosted.org/sssd)
|
|
||||||
. Do not set a Bug Tracker URL
|
|
||||||
|
|
||||||
=== Creating a new bzr repository
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Go to the admin dashboard to [56]add a new repository.
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
For the name, enter the Fedora Hosted project short name. (e.g. if the::
|
|
||||||
project is [57]https://fedorahosted.org/kitchen, then the repository
|
|
||||||
name should be kitchen)
|
|
||||||
. "Show this repository" must be checked.
|
|
||||||
. Hosting service is "Custom"
|
|
||||||
. Repository type is Bazaar
|
|
||||||
. Path should be /srv/git/project_short_name/branch_name (e.g.
|
|
||||||
/srv/bzr/kitchen/devel) -- reviewboard doesn't understand how to work
|
|
||||||
with repository conventions; it just works on branches.
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
Mirror path should be::
|
|
||||||
bzr://bzr.fedorahosted.org/bzr/project_short_name/branch_name
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
Mirror path is used by client tools such as post-review to determine to
|
|
||||||
which repository a submission belongs
|
|
||||||
====
|
|
||||||
[arabic, start=8]
|
|
||||||
. Username and Password should both be left blank
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
The bug tracker URL may vary from project to project, but if they are::
|
|
||||||
using the Fedora Hosted Trac bugtracker, it should be
|
|
||||||
+
|
|
||||||
* Type: Trac
|
|
||||||
* Bug Tracker URL: [58]https://fedorahosted.org/project_short_name
|
|
||||||
(e.g. [59]https://fedorahosted.org/kitchen)
|
|
||||||
. Do not set a Bug Tracker URL
|
|
||||||
|
|
||||||
=== Create a default reviewer for a repository
|
|
||||||
|
|
||||||
Reviews should be sent to the project development mailing list unless
|
|
||||||
otherwise requested.
|
|
||||||
|
|
||||||
[arabic]
|
|
||||||
. Enter the admin interface. If you have admin privilege, a link will be
|
|
||||||
visible in the upper-right corner of the dashboard.
|
|
||||||
. In the admin dashboard click "Add" next to "Review Groups"
|
|
||||||
. Enter the following values:
|
|
||||||
|
|
||||||
____
|
|
||||||
* Name: The project short name
|
|
||||||
* Display Name: project_short_name Review Group
|
|
||||||
* Mailing List: Development discussion list for the project
|
|
||||||
____
|
|
||||||
|
|
||||||
[arabic, start=4]
|
|
||||||
. Do not select any users
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
Return to the main admin dashboard and click on "Add" next to "Default::
|
|
||||||
Reviewers"
|
|
||||||
. Enter the following values:
|
|
||||||
|
|
||||||
____
|
|
||||||
* Name: Something unique and sensible
|
|
||||||
* File Regular Expression: enter '.*' (without the quotes)
|
|
||||||
____
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
.Note
|
|
||||||
====
|
|
||||||
This means that by default, the mailing list should receive email for
|
|
||||||
reviews of all files in the repository
|
|
||||||
====
|
|
||||||
|
|
||||||
[arabic, start=7]
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
Under "Default groups", select the group you created above and click::
|
|
||||||
the arrow pointing right.
|
|
||||||
. Do not select any default people
|
|
||||||
. {blank}
|
|
||||||
+
|
|
||||||
Under "Repositories", select the repository added above and click the::
|
|
||||||
arrow pointing right.
|
|
||||||
. Save your changes.
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue