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
|
|
@ -1,3 +1,4 @@
|
|||
* xref:orientation.adoc[Orientation for Sysadmin Guide]
|
||||
* xref:index.adoc[Sysadmin Guide]
|
||||
** xref:2-factor.adoc[Two factor auth]
|
||||
** xref:accountdeletion.adoc[Account Deletion SOP]
|
||||
|
|
@ -6,27 +7,19 @@
|
|||
** xref:apps-fp-o.adoc[apps-fp-o - SOP in review ]
|
||||
** xref:archive-old-fedora.adoc[archive-old-fedora - 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:basset.adoc[basset - 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:bodhi.adoc[bodhi - SOP in review ]
|
||||
** xref:bugzilla2fedmsg.adoc[bugzilla2fedmsg - 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:communishift.adoc[communishift - SOP in review ]
|
||||
** xref:compose-tracker.adoc[compose-tracker - SOP in review ]
|
||||
** xref:contenthosting.adoc[contenthosting - 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:datanommer.adoc[datanommer - 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:dns.adoc[dns - 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-websocket.adoc[fedmsg-websocket - 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:fedorawebsites.adoc[fedorawebsites - 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:gdpr_delete.adoc[gdpr_delete - SOP in review ]
|
||||
** xref:gdpr_sar.adoc[gdpr_sar - SOP in review ]
|
||||
** xref:geoip-city-wsgi.adoc[geoip-city-wsgi - SOP in review ]
|
||||
** xref:github2fedmsg.adoc[github2fedmsg - 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:guestdisk.adoc[guestdisk - SOP in review ]
|
||||
** xref:guestedit.adoc[guestedit - 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: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:infra-git-repo.adoc[infra-git-repo - SOP in review ]
|
||||
** xref:infra-hostrename.adoc[infra-hostrename - SOP in review ]
|
||||
** xref:infra-raidmismatch.adoc[infra-raidmismatch - SOP in review ]
|
||||
** xref:infra-repo.adoc[infra-repo - 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:iscsi.adoc[iscsi - SOP in review ]
|
||||
** xref:jenkins-fedmsg.adoc[jenkins-fedmsg - SOP in review ]
|
||||
|
|
@ -83,8 +65,6 @@
|
|||
** xref:koschei.adoc[koschei - SOP in review ]
|
||||
** xref:layered-image-buildsys.adoc[layered-image-buildsys - 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:making-ssl-certificates.adoc[making-ssl-certificates - SOP in review ]
|
||||
** xref:massupgrade.adoc[massupgrade - SOP in review ]
|
||||
|
|
@ -105,7 +85,6 @@
|
|||
** xref:openqa.adoc[openqa - SOP in review ]
|
||||
** xref:openshift.adoc[openshift - 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:packagedatabase.adoc[packagedatabase - SOP in review ]
|
||||
** xref:packagereview.adoc[packagereview - SOP in review ]
|
||||
|
|
@ -113,7 +92,6 @@
|
|||
** xref:pdc.adoc[pdc - SOP in review ]
|
||||
** xref:pesign-upgrade.adoc[pesign-upgrade - 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:rabbitmq.adoc[rabbitmq - SOP in review ]
|
||||
** xref:rdiff-backup.adoc[rdiff-backup - SOP in review ]
|
||||
|
|
@ -121,7 +99,6 @@
|
|||
** xref:requestforresources.adoc[requestforresources - SOP in review ]
|
||||
** xref:resultsdb.adoc[resultsdb - 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:selinux.adoc[selinux - SOP in review ]
|
||||
** xref:sigul-upgrade.adoc[sigul-upgrade - SOP in review ]
|
||||
|
|
|
|||
|
|
@ -16,18 +16,18 @@ ____
|
|||
|
||||
== Contents
|
||||
|
||||
* Disabling
|
||||
** Disable Accounts
|
||||
** Disable Groups
|
||||
* User Requested disables
|
||||
* Renames
|
||||
** Rename Accounts
|
||||
** Rename Groups
|
||||
* Deletion
|
||||
** Delete Accounts
|
||||
** Delete Groups
|
||||
* <<_disabling>>
|
||||
** <<_disable_accounts>>
|
||||
** <<_disable_groups>>
|
||||
* <<_user_requested_disables>>
|
||||
* <<_renames>>
|
||||
** <<_rename_accounts>>
|
||||
** <<_rename_groups>>
|
||||
* <<_deletion>>
|
||||
** <<_delete_accounts>>
|
||||
** <<_delete_groups>>
|
||||
|
||||
=== Disable
|
||||
=== Disabling
|
||||
|
||||
Disabling accounts is the easiest to accomplish as it just blocks people
|
||||
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
|
||||
|
||||
[arabic]
|
||||
. Contact Information
|
||||
. Description
|
||||
. <<_contact_information>>
|
||||
. <<_description>>
|
||||
. Welcome to the team
|
||||
|
||||
____
|
||||
[arabic]
|
||||
. Time commitment
|
||||
. Prove Yourself
|
||||
. <<_time_commitment>>
|
||||
. <<_prove_yourself>>
|
||||
____
|
||||
|
||||
[arabic, start=4]
|
||||
. Doing Work
|
||||
. <<_doing_work>>
|
||||
|
||||
____
|
||||
[arabic]
|
||||
. Ansible
|
||||
. <<_ansible>>
|
||||
____
|
||||
|
||||
[arabic, start=5]
|
||||
. Our Setup
|
||||
. Our Rules
|
||||
. <<_our_setup>>
|
||||
. <<_our_rules>>
|
||||
|
||||
== Contact Information
|
||||
|
||||
|
|
@ -159,7 +159,7 @@ ask about it.
|
|||
The Fedora Infrastructure Team does have some rules. First is the
|
||||
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
|
||||
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