diff --git a/xml/obs_ag_administration.xml b/xml/obs_ag_administration.xml index 50d5053b..f0495f58 100644 --- a/xml/obs_ag_administration.xml +++ b/xml/obs_ag_administration.xml @@ -18,19 +18,19 @@ - + Backup &obs; configuration and content needs usually a backup. The following explains suggested strategies and places considered for a backup. - + Places to consider The following is pointing to the places with admin configurations or user content. The default location places are considered here. - + Frontend Configuration @@ -43,41 +43,41 @@ The configuration is not changing usually. It is enough to backup it after config changes. - + Frontend Database The MySQL/MariaDB database backup can be done in different ways. Please consider the database manual for details. One possible way is to create dumps via mysqldump tool. The backup should be done at the same point of time as the source server. Inconsistencies can be resolved using the check_consistency tool. - + Backend Configuration The backend has a single configuration file which may got altered. This is by default /usr/lib/obs/server/BSConfig.pm . The file is not supposed to be changed usually and it can only be done by the system root user. A backup after a change is sufficient. - + Backend Content All backend content is below /srv/obs directory. This include the sources, build results and also all configuration changes done by the OBS admin users. - + Backup strategies A backup is ideally taken only from a not running service. In real live this is usually not possible, so it is important to run a backup on a production system. - + Database MySQL backup either directly from a non-primary node in the galera cluster (table dump locks the database during operation) or from a mysql slave attached to the cluster. - + Sources The sources are supposed to be backup at the same time as the database. This can get achieved by either having a dedicated instance for the source server @@ -92,7 +92,7 @@ - + Build Results Full backups via snapshots, either offered by the SAN storage or via LVM snapshot methods. Consistency is normally on repository level. Any inconsistency @@ -103,13 +103,13 @@ - + Restore A restored system might contain inconsistencies if it was taken from a running service. These can be resolved as follows. - + Check and repair database inconsistencies If either database portions or sources got restored there are chances for inconsistencies. These can be found via @@ -128,7 +128,7 @@ &prompt.user;cd /srv/www/obs/api/ &prompt.user;./bin/rake fix_project project="YOUR_PROJECT" - + Binaries All build results are evaluated by the scheduler. Therefore any inconsistency can be detected by the scheduler. One way is to enforce a cold start, which means that the @@ -151,7 +151,7 @@ - + Repair Data Corruption On-disk data might be corrupted independent of a restore. For example due to power outage, filesystem diff --git a/xml/obs_ag_build_targets.xml b/xml/obs_ag_build_targets.xml index dd9d71dd..c85a170b 100644 --- a/xml/obs_ag_build_targets.xml +++ b/xml/obs_ag_build_targets.xml @@ -3,12 +3,12 @@ %entities; ]> - Managing Build Targets - + Interconnect Using another Open Build Service as source for build targets is the easiest way to start. The advantage is, that you save local resources and @@ -26,7 +26,7 @@ create a remote project using the osc meta prj command. A remote project differs from a local project as it has a remoteurl tag (see ). + linkend="meta-data-project-meta-data"/>). Example: <project name="openSUSE.org"> <title>openSUSE.org Project Link</title> @@ -38,7 +38,7 @@ This project refers to projects hosted on the &osbs; Sending this via osc to the server: osc meta prj -m "add openSUSE.org remote" -F /tmp/openSUSE.org.prj - + Importing Distributions FIXME: describe how to do it using DoD diff --git a/xml/obs_ag_dispatch_priority.xml b/xml/obs_ag_dispatch_priority.xml index d6c09abb..bbb5c01b 100644 --- a/xml/obs_ag_dispatch_priority.xml +++ b/xml/obs_ag_dispatch_priority.xml @@ -3,7 +3,7 @@ %entities; ]> - @@ -20,9 +20,9 @@ >/build/_dispatchpriosAPI call or via the dispatch_adjust array in the - BSConfig.pm configuration + BSConfig.pm configuration file. - + The <literal>/build/_dispatchprios</literal> API Call The /build/_dispatchprios API call allows an Admin to set a priority for defined projects and repositories using the HTTP @@ -224,7 +224,7 @@ - + <literal>dispatch_adjust</literal> Array With the dispatch_adjust array in the diff --git a/xml/obs_ag_installation_and_configuration.xml b/xml/obs_ag_installation_and_configuration.xml index 71759c0b..0ceb19ee 100644 --- a/xml/obs_ag_installation_and_configuration.xml +++ b/xml/obs_ag_installation_and_configuration.xml @@ -10,7 +10,7 @@ Installation and Configuration - + Planning For testing your own OBS instance, or for small setups, such as if you only want to package a few scripts into RPMS and create @@ -30,7 +30,7 @@ on one host, if it has sufficient resources. For flexibility and if you want some kind of high availability it is recommended to use virtualization for the different components. - + Resource Planning Normally, for an small or middle-sized installation, a setup with everything on one host (except workers) is sufficient. You should have a separate /srv @@ -74,7 +74,7 @@ worker hosts is more important than the other parts. - + Simple Installation In this document, we call "simple installation" an OBS installation where all OBS services are running on the same machine. @@ -86,7 +86,7 @@ Before you start the installation of the OBS, you should make sure that your hosts have the correct fully qualified hostname, and that DNS is working and can resolve all names. - + Back-end Installation The back-end hosts all sources and built packages. It also schedules the jobs. To install it, install the "obs-server" package. After installation, @@ -95,7 +95,7 @@ the defaults should be good enough for simple cases. - Read more about configuring the backend in . + Read more about configuring the backend in . The back-end consists of a number of systemd units (services): @@ -301,7 +301,7 @@ systemctl start obsrepserver.service outside. If the system is connected to an untrusted network, either block the ports with a firewall or do not run the commands at all. - + Cloud Upload Setup In order to setup the Cloud Upload feature you will need to configure the tools required per each cloud provider. Right now we only support the AWS Amazon Cloud () and Microsoft Azure @@ -341,9 +341,9 @@ our $clouduploadserver = "http://$hostname:5452"; Having an incorrect system time will cause cloud uploads to fail. - + AWS Amazon Cloud - + Authentication Workflow We are going to use the role based authentication provided by Amazon to enable the OBS instance to upload images to other user's accounts. @@ -358,7 +358,7 @@ our $clouduploadserver = "http://$hostname:5452"; The whole workflow is described in the AWS documentation. - + Credentials Setup For uploading images to AWS, OBS is using the AWS CLI tool. @@ -369,9 +369,9 @@ our $clouduploadserver = "http://$hostname:5452"; - + Microsoft Azure - + Authentication Workflow The authentication is done via Microsoft's Active Directory. The user has to create a new application and needs to @@ -391,7 +391,7 @@ our $clouduploadserver = "http://$hostname:5452"; OBS communicates with the REST API of Microsoft Azure to authenticate and upload images. - + Configuration The Application ID and the Application Key will be stored encrypted in @@ -407,7 +407,7 @@ openssl genrsa -out secret.pem openssl rsa -in secret.pem -out _pubkey -outform PEM -pubout - + Credentials setup It's important that the public key is named _pubkey and the secret key is named @@ -417,11 +417,11 @@ openssl rsa -in secret.pem -out _pubkey -outform PEM -pubout - + Front-end Installation You need to install the "obs-api" package for this and a MySQL server. - + MySQL Setup Make sure that the mysql server is started on every system reboot (use "insserv mysql" for permanent start). You should run @@ -469,7 +469,7 @@ sudo RAILS_ENV="production" rake writeconfiguration sudo chown -R wwwrun.www log tmp Now you are done with the database setup. - + Apache Setup Now we need to configure the Web server. By default, you can reach the familiar web user interface and also api both on port 443 speaking @@ -511,7 +511,7 @@ cat /srv/obs/certs/server.key /srv/obs/certs/server.crt \ cp /srv/obs/certs/server.pem /etc/ssl/certs/ c_rehash /etc/ssl/certs/ - + API Configuration Check and edit /srv/www/obs/api/config/options.yml @@ -519,9 +519,9 @@ c_rehash /etc/ssl/certs/ If you change the hostnames/ips of the API, you need to adjust frontend_host accordingly. If you want to use LDAP, you need to change the LDAP settings - as well. Look at the for + as well. Look at the for details. You will find examples and more details in the . + linkend="configuration-files"/>. It is strongly recommended to enable use_xforward: true as well here, to tell Rails to forward requests to the back-end for @@ -541,7 +541,7 @@ systemctl start memcached.service online configuration steps. - + Online Configuration To customize the OBS instance you may need to configure some settings via the OBS API and Web user interface. @@ -624,7 +624,7 @@ cat /tmp/obs.config If you want to use an interconnect to another OBS instance to reuse the build targets you can do this as Admin via the Web UI or create a project with a remoteurl tag (see ) + linkend="meta-data-project-meta-data"/>) <project name="openSUSE.org"> <title>openSUSE.org Project</title> <description> @@ -641,7 +641,7 @@ openSUSE:12.3 project as specified on the opensuse.org Build Service. this: osc -c ~/.obsadmin_osc.rc meta prj openSUSE.org -F /tmp/openSUSE.org.meta You also can import binary distribution, see for this. + linkend="managing-build-targets-importing-distributions"/> for this. The OBS has a list of available distributions used for build. This list is displayed to user, if they are adding repositories to their projects. This list can be managed via the API path /distributions @@ -664,7 +664,7 @@ openSUSE:12.3 project as specified on the opensuse.org Build Service. osc -c ~/.obsadmin_osc.rc api /distributions -T /tmp/distributions.xml - + Worker Farm To not burden your OBS back-end daemons with the unpredictable load package builds can produce (think someone builds a monstrous package like @@ -685,12 +685,12 @@ openSUSE:12.3 project as specified on the opensuse.org Build Service. OBS_SRC_SERVER, OBS_REPO_SERVERS and OBS_WORKER_INSTANCES need to be set. More details in the . + linkend="configuration-files"/>. start the worker: systemctl enable obsworker systemctl start obsworker - + Distributed Setup All OBS back-end daemons can also be started on individual machines in your network. Also, the front-end Web server and the MySQL server can run on @@ -825,15 +825,15 @@ systemctl start obswarden.service role="strong">OBS_REPO_SERVERS variable. You can also define workers with a subset of the repo servers to prioritize partitions. - + Monitoring In this chapter you will find some general monitoring instructions for the Open Build Service. All examples are based on Nagios plugins, but the information provided should be easily adaptable for other monitoring solutions. - + Endpoint Checks - + HTTP Checks: Checking Whether the HTTP Server Responds This check will output a critical if the HTTP server with ip address 172.19.19.19 (-I 172.19.19.19) listening on port 80 (-p 80) does not @@ -871,11 +871,11 @@ systemctl start obswarden.service - + Common Checks This is a list of common checks that should be run on each individual server. - + Disk Space: Checking Available Disk Space This check will output a warning if less than 10 percent disk space is available (-w 10) and output a critical if less than 5 percent disk @@ -883,7 +883,7 @@ systemctl start obswarden.service systems with type none (-x none). check_disk -w 10 -c 5 -x none - + Memory Usage: Checking Available Memory This check will output a warning if less than 10 percent memory is available (-w 10) and output a critical if less than 5 percent memory is @@ -894,7 +894,7 @@ systemctl start obswarden.service >https://exchange.nagios.org/. check_mem.pl -f -C -w 10 -c 5 - + NTP: Checking Date and Time This check will compare the local time with the time provided by the NTP server pool.ntp.org (-H pool.ntp.org). It will output a warning if the @@ -902,7 +902,7 @@ systemctl start obswarden.service differs by 1 seconds (-c 1). check_ntp_time -H pool.ntp.org -w 0.5 -c 1 - + Ping: Checking That the Server Is Alive This plugin checks if the server responds to a ping request and it will output a warning if the respond time exceeds 200ms or 30 percent @@ -910,7 +910,7 @@ systemctl start obswarden.service exceeds 500ms or 60 percent package loss. check_icmp -H server -w 200.0,30% -c 500.0,60% - + Load: Checking the Load on the Server This check will output a warning if the load value exceeded 7.0 in the last minute, 6.0 in the last 5 minutes or 5.0 in the last 15 minutes @@ -919,7 +919,7 @@ systemctl start obswarden.service minutes (-c 12.0,8.0,6.0). check_load -w 7.0,6.0,5.0 -c 12.0,8.0,6.0 - + Disk Health: Checking the Health of Local Hard Disks This check is only relevant on physical systems with local storage attached to it. It will check the disk status utilizing the S.M.A.R.T @@ -930,9 +930,9 @@ systemctl start obswarden.service check_smartmon --drive /dev/sda --drive /dev/sdb - + Other Checks - + MySQL: Checking That the MySQL Database Is Responding This check will check that the MySQL database server is running and that the database api_production is available. @@ -947,7 +947,7 @@ systemctl start obswarden.service - + Backup Status: Checking That a Valid Backup Is Available It is always advisable to check that the last backup run was successful and a recent backup is available. The check itself depends on diff --git a/xml/obs_ag_k8s_worker.xml b/xml/obs_ag_k8s_worker.xml index b68aff12..b8cd9242 100644 --- a/xml/obs_ag_k8s_worker.xml +++ b/xml/obs_ag_k8s_worker.xml @@ -1,7 +1,7 @@ - + Worker in Kubernetes Alpha Implementation diff --git a/xml/obs_ag_message_bus.xml b/xml/obs_ag_message_bus.xml index 291aa543..2ca82151 100644 --- a/xml/obs_ag_message_bus.xml +++ b/xml/obs_ag_message_bus.xml @@ -6,13 +6,13 @@ + xml:id="message-bus"> Message Bus for Event Notifications The OBS has an integrated notification subsystem for sending events that are happening in our app through a message bus. We have chosen RabbitMQ as our message bus server technology based on the AMQP protocol. - + RabbitMQ RabbitMQ claims to be "the most popular open source message broker". Meaning that it can deliver asynchronous messages in many @@ -22,7 +22,7 @@ RabbitMQ is lightweight and easy to deploy on premises and in the cloud. It supports multiple messaging protocols too. And can be deployed in distributed and federated configurations to meet high-scale, high-availability requirements. - + Configuration Currently the RabbitMQ configuration is in the file options.yml. diff --git a/xml/obs_ag_overview_filesystem.xml b/xml/obs_ag_overview_filesystem.xml index adb91030..7dbc8b95 100644 --- a/xml/obs_ag_overview_filesystem.xml +++ b/xml/obs_ag_overview_filesystem.xml @@ -10,11 +10,11 @@ File System Overview - + Configuration Files - + Front-end Configuration - The front-end is configured with 4 files: + The front-end is configured with four files: /srv/www/obs/api/config/database.yml @@ -29,7 +29,7 @@ /etc/apache2/vhosts.d/obs.conf - + <filename>database.yml</filename> This file has the information needed to access the database. It contain credentials for the database access and should be only readable by @@ -174,7 +174,7 @@ - + <filename>options.yml</filename> The configuration file /srv/www/obs/api/config/options.yml is the default configuration file for the Open Build Service Web UI and API. It @@ -637,7 +637,7 @@ development: memcached_host: cache - + <filename>feature.yml</filename> The configuration file /srv/www/obs/api/config/feature.yml contains the default configuration about features that can be enabled or @@ -727,7 +727,7 @@ test: ]]> - + Apache Virtual Host <filename>obs.conf</filename> The Apache configuration depends on the Apache version and which extra options are used, so use the documentation of the Apache version you @@ -837,7 +837,7 @@ LimitRequestFieldsize 20000 </VirtualHost> - + Back-end Configuration The Back-end is configured with 2 files: @@ -850,7 +850,7 @@ LimitRequestFieldsize 20000 global variables - + <filename>/etc/sysconfig/obs-server</filename> This script is used to set up the basic paths and the worker. the most important settings are the - + BSConfig.pm This file is a perl module used by most back-end scripts, it mainly defines global variables. Since it is a perl module, after changes @@ -2467,7 +2467,7 @@ OBS_WORKER_SCRIPT_URL="" - see + see @@ -2482,7 +2482,7 @@ OBS_WORKER_SCRIPT_URL="" - see + see @@ -2497,7 +2497,7 @@ OBS_WORKER_SCRIPT_URL="" - see + see @@ -2512,7 +2512,7 @@ OBS_WORKER_SCRIPT_URL="" - see + see @@ -2527,7 +2527,7 @@ OBS_WORKER_SCRIPT_URL="" 0 1 - see + see @@ -2542,7 +2542,7 @@ OBS_WORKER_SCRIPT_URL="" - see + see @@ -2557,7 +2557,7 @@ OBS_WORKER_SCRIPT_URL="" 0 1 - see + see @@ -2572,7 +2572,7 @@ OBS_WORKER_SCRIPT_URL="" - see + see @@ -2798,9 +2798,9 @@ if (-r $hostconfig) { - + Log Files - + Front-end The front-end log files are found under /srv/www/obs/api/log. @@ -2832,7 +2832,7 @@ if (-r $hostconfig) { - + Back-end The back-end log files are found by default under /srv/obs/log/. @@ -2884,7 +2884,7 @@ if (-r $hostconfig) { - + <filename>/srv/obs</filename> Tree The default back-end data directory is located under /srv/obs/. Here are a bunch of subdirectories used for @@ -2894,7 +2894,7 @@ if (-r $hostconfig) { which stores the global OBS configuration for the back-end. You should not modify this file directly, but use the API /configuration interface instead, since this information needs to kept in sync with the front-end. - + <filename>build</filename> Directory In this subdirectory managed by the repo server daemon, all repository data, metadata and build results are stored in a hierarchical @@ -2928,29 +2928,29 @@ if (-r $hostconfig) { │ ├── srtp │ └── wget - + <filename>cloudupload</filename> Directory Info for cloud upload jobs is stored here, it has a subdir named done for storing the already finished jobs. - + <filename>db</filename> Directory Back-end database root directory use by the source server, repo server scheduler and publisher. Nobody should touch this. - + <filename>diffcache</filename> Directory Cache for source server compare operations. - + <filename>events</filename> Directory Communication between services. - + <filename>info</filename> Directory Scheduler information managed by the scheduler and used by the repo server. - + <filename>jobs</filename> Directory The build jobs are stored in the /srv/obs/jobs directory. They are organized bybuild architecture: @@ -2963,34 +2963,34 @@ if (-r $hostconfig) { The jobs/load file contains statistical data about the build jobs. - + <filename>log</filename> Directory Contains the log files of the back-end daemons. - + <filename>projects</filename> Directory Contains the project hierarchy and metadata under revision control. - + <filename>remotecache</filename> Directory Cache for remote repository information. - + <filename>repos</filename> Directory Directory managed by the publisher to collect build results, also used by the repo server and scheduler to find build results. - + <filename>repos_sync</filename> Directory Directory with files pointing to the project root directories, helper for publisher rsync. - + <filename>run</filename> Directory State and lock information for the back-end daemons - + <filename>sources</filename> Directory All package sources under revision control in one directory per package, managed by the source server. Package sources are by default @@ -3011,24 +3011,24 @@ if (-r $hostconfig) { ├── :service └── :upload - + <filename>trees</filename> Directory Revision control data for project and packages, managed by the source server. - + <filename>upload</filename> Directory Temporary directory for uploading files for other back-end components. - + <filename>workers</filename> Directory Worker information - + Metadata - + &obsa; Revision Control This section gives a short generic overview how the revision information are stored in the OBS back-end for packages and projects. The @@ -3038,7 +3038,7 @@ if (-r $hostconfig) { /srv/obs/sources directories. The revision information is stored in separate files by the Source Server in the /srv/obs/projects directory. - + OBS revision control files The revision information is stored in simple CSV like file format with a bar (|) as delimiter between the 8 columns. The files do have the @@ -3198,7 +3198,7 @@ if (-r $hostconfig) { 0a17daaa913df9e50ee65e83a1898363 package1.spec 1f810b3521242a98333b7bbf6b2b7ef7 test1.sh - + &obsa; Revision API The revision info can be retrieved via API calls for the specific package, for example, using @@ -3210,7 +3210,7 @@ if (-r $hostconfig) { "comment=some+comment" can be used to set a commit message. - + Project Metadata Project metadata are XML files containing the meta project information, such as title, description, related user and groups with @@ -3445,7 +3445,7 @@ if (-r $hostconfig) { </repository> </project> - + Package Metadata XML file about package meta information, like Title, description, related user and groups with roles, build settings, publish settings, debug @@ -3468,7 +3468,7 @@ if (-r $hostconfig) { </debuginfo> </package> - + Attribute Metadata Attributes can be used to add special information to packages. Attributes can be used to trigger special actions. @@ -3483,7 +3483,7 @@ if (-r $hostconfig) { </attribute> </attributes> - + Job Files Jobs are stored by the scheduler in the /srv/obs/jobs directory and contain the build setup diff --git a/xml/obs_ag_publish_hooks.xml b/xml/obs_ag_publish_hooks.xml index 2e885001..b0bc558b 100644 --- a/xml/obs_ag_publish_hooks.xml +++ b/xml/obs_ag_publish_hooks.xml @@ -6,7 +6,7 @@ + xml:id="publisher-hooks"> Publisher Hooks The job of the publisher service is to publish the built packages and/or images by creating repositories that are made available through a web @@ -15,7 +15,7 @@ to different servers or do anything with them that comes to mind. These scripts are called publisher hooks. - + Configuring Publisher Hooks Hooks are configured via the configuration file /usr/lib/obs/server/BSConfig.pm, where one script per @@ -99,9 +99,9 @@ our $publishedhook = { script. The scripts are called without a timeout. - + Example Publisher Scripts - + Simple Publisher Hook The following example script ignores the packages that have changed and copies all RPMs from the repository directory to a target @@ -120,7 +120,7 @@ rsync -a --log-file=$LOGFILE --mkpath $PATH_TO_REPO/ $DST_REPO_DIR/$PRJ_PATH/$ sudo -u obsrun /usr/local/bin/publish-hook.sh Product/SLES11-SP1 \ /srv/obs/repos/Product/SLE11-SP1 - + Advanced Publisher Hook The following example script reads the destination path from a parameter that is configured with the hook script: diff --git a/xml/obs_ag_spider_identification.xml b/xml/obs_ag_spider_identification.xml index efdc09d0..c04c10b8 100644 --- a/xml/obs_ag_spider_identification.xml +++ b/xml/obs_ag_spider_identification.xml @@ -6,7 +6,7 @@ + xml:id="obs-spider-identification"> Spider Identification OBS is hiding specific parts/pages of the application from search crawlers (DuckDuckGo, Google, etc.), mostly for performance reasons. Which diff --git a/xml/obs_ag_tools.xml b/xml/obs_ag_tools.xml index 48a11a31..d6e7d625 100644 --- a/xml/obs_ag_tools.xml +++ b/xml/obs_ag_tools.xml @@ -3,9 +3,9 @@ %entities; ]> - + Tools - + <command>obs_admin</command> obs_admin is a command-line tool used on the back-end server(s) to manage running services, submit maintenance tasks, and debug problems. @@ -142,7 +142,7 @@ Note: the --update-*-db calls are usually only needed when corrupt data has been --show-delta-store <file> Show delta store statistics - + &osccmd; The osc command-line client is mainly used by developers and packagers. But for some tasks, admin people also need this tool. It too has builtin help: @@ -158,7 +158,7 @@ osc -A https://api.testobs.org give this file restrictive access rights, only read/write access for your user should be allowed. osc allows to store the password in other ways (in keyrings for example) and may use different methods for authentication like -Kerberos see +Kerberos see For admins the most important osc subcommands are: @@ -174,12 +174,12 @@ API - to read and write online configuration data - + <command>osc meta</command> Subcommand The osc meta subcommand is documented inside the "osc" tool itself. This documentation can be displayed by issuing the command: osc meta --help - + <command>osc api</command> Subcommand The osc api subcommand is documented inside the "osc" tool itself. This documentation can be displayed by issuing the command: osc api --help diff --git a/xml/obs_ag_troubleshooting.xml b/xml/obs_ag_troubleshooting.xml index 834d61f8..c7ffb47f 100644 --- a/xml/obs_ag_troubleshooting.xml +++ b/xml/obs_ag_troubleshooting.xml @@ -25,7 +25,7 @@ description and so on. Most of them should not happen if the packager does test the build locally before committing it to the OBS. This type of problems is not covered by this chapter. - + General Hints If you detect unexpected behavior of the open build service, you should follow some rules to locate the problem: @@ -34,7 +34,7 @@ Consult the log files, for the back-end look at /srv/obs/log for the back-end log files and /srv/www/obs/api/log for the front-end log files. - See the Log files for more details. + See the Log files for more details. @@ -64,7 +64,7 @@ - + Debugging Front-end Problems If you get unexpected results from submitting commands with the osc tool, you can diff --git a/xml/obs_ag_unpublish_hooks.xml b/xml/obs_ag_unpublish_hooks.xml index 31f7cddf..18e9a80d 100644 --- a/xml/obs_ag_unpublish_hooks.xml +++ b/xml/obs_ag_unpublish_hooks.xml @@ -6,7 +6,7 @@ + xml:id="unpublisher-hooks"> Unpublisher Hooks The job of the publisher service is to publish the built packages and/or images by creating repositories that are made available through a web @@ -16,7 +16,7 @@ called unpublisher hooks. Unpublisher hooks are run before the publisher hooks. - + Configuring Unpublisher Hooks Hooks are configured via the configuration file /usr/lib/obs/server/BSConfig.pm, where one script per @@ -107,9 +107,9 @@ our $unpublishedhook = { hook. - + Example Unpublisher Scripts - + Simple Unpublisher Hook The following example script deletes all packages from the target directory that have been removed from the repository. @@ -137,7 +137,7 @@ done x86_64/icinga-1.13.3-1.3.x86_64.rpm \ x86_64/icinga-devel-1.13.3-1.3.x86_64.rpm - + Advanced Unpublisher Hook The following example script reads the destination path from a parameter that is configured via the hook script: diff --git a/xml/obs_ag_user_management.xml b/xml/obs_ag_user_management.xml index 9c09b5be..4415e554 100644 --- a/xml/obs_ag_user_management.xml +++ b/xml/obs_ag_user_management.xml @@ -6,7 +6,7 @@ + xml:id="user-and-group-management"> Managing Users and Groups The OBS has an integrated user and group management with a role based access rights model. In every OBS instance, at least one user need to exist @@ -14,7 +14,7 @@ and instead of adding a list of users to a project/package role user can be added to a group and the group will be added to a project or package role. - + User and Group Roles The OBS role model has one global role: Admin, which can be granted to users. An OBS admin has access to all projects and packages via the API @@ -96,7 +96,7 @@ - + Standalone User and Group Database OBS provides its own user database which can also store a password. The authentication to the API happens via HTTP BASIC AUTH. See the API @@ -107,7 +107,7 @@ confirmation is needed after registration before the user may login. - + Users and Group Maintainers Administrators can create groups, add users to them, remove users from them and @@ -116,7 +116,7 @@ osc api -d "<group><title><group-title></title><email><group-email></email><maintainer userid="<user-name>"/><person><person userid="<user_name>"/></person></group>' -X PUT "/group/<group-title>" - + Gravatar for Groups In certain cases, it might be desirable to show a Gravatar for a group, similar to the users. In order to show a Gravatar, an email address is needed. @@ -125,7 +125,7 @@ osc api -X POST "/group/<group-title>?cmd=set_email&email=<groups-email-address>" - + Proxy Mode The proxy mode can be used for specially secured instances, where the OBS web server shall not get connected to the network directly. There @@ -144,7 +144,7 @@ With the proxy mode the user still need to be registered in the OBS and all OBS roles and user properties are managed inside the OBS. - + &obsa; Proxy Mode Configuration Currently the LDAP configuration is in the options.yml file. @@ -184,7 +184,7 @@ - + LDAP/Active Directory The LDAP support was considered experimental and not officially @@ -231,7 +231,7 @@ member attributes of the group are parsed and all current users which are in the local database become members. - + OBS LDAP Configuration Currently the main OBS LDAP configuration is in the @@ -741,9 +741,9 @@ ldap_group_objectclass_attr: group ldap_obs_admin_group: obsadmins - + Authentication Methods - + LDAP Methods The LDAP mode has 2 methods to check authorization: @@ -764,7 +764,7 @@ ldap_obs_admin_group: obsadmins will not be available until you are bind with a privilege user. - + Kerberos In OBS you can use single sign on via Kerberos tickets. OBS Kerberos configuration resides in the diff --git a/xml/obs_architecture.xml b/xml/obs_architecture.xml index 6e6edebe..641af8b7 100644 --- a/xml/obs_architecture.xml +++ b/xml/obs_architecture.xml @@ -16,7 +16,7 @@ - + Overview Graph &OBS; is not a monolithic server; it consists of multiple daemons that fulfill different tasks (see ). @@ -179,7 +179,7 @@ - + Communication Flow The communication flow can be split into the following major parts: diff --git a/xml/obs_best_practice_webui_usage.xml b/xml/obs_best_practice_webui_usage.xml index 69542cf9..f0928448 100644 --- a/xml/obs_best_practice_webui_usage.xml +++ b/xml/obs_best_practice_webui_usage.xml @@ -328,9 +328,8 @@ flood The minimal set of fields you have to enter are architecture, repository type and the URL that provides the binary packages. Detailed - information about the data you can enter here you can find at the DoD concept section. Press "Save" to create the repository. + information about the data you can enter here can be found at + . Press "Save" to create the repository.
Download on Demand Repository Form diff --git a/xml/obs_build_constraints.xml b/xml/obs_build_constraints.xml index 5d4471cc..4610283f 100644 --- a/xml/obs_build_constraints.xml +++ b/xml/obs_build_constraints.xml @@ -57,7 +57,7 @@ - + Constraint Qualifiers In general, build constraints are specified in terms of a qualifier and a value. The qualifier expresses "what" - the build worker parameter @@ -76,7 +76,7 @@ and unit=G means "the value is expressed in units of Gigabytes. For a full treatment of constraint syntax, see - . + . Constraint scope and precedence @@ -102,7 +102,7 @@ defined in the project config by adding lines as so: Constraint: <QUALIFIER> <VALUE> The QUALIFIER syntax is the same as used in RPM spec files, documented - in . Within the project configuration, + in . Within the project configuration, individual Constraint lines can be enclosed in guards to make a constraint apply only to certain architectures or repositories. For example: @@ -118,7 +118,7 @@ Constraint: hardware:disk:size unit=M 4000 project itself, but also all projects that build against it. For a full treatment of constraint syntax, see - . + . Package-scoped constraints @@ -144,7 +144,7 @@ Constraint: hardware:disk:size unit=M 4000 </constraints> For details on constraint qualifiers and how to specify them in a _constraints file, see - . + . Build recipe-scoped constraints @@ -173,18 +173,18 @@ Constraint: hardware:disk:size unit=M 4000 pool of compliant build workers down to a very low number, or even to zero. (A low number of compliant build workers means your build may not start for a long time, and no compliant workers at all will cause the build to fail. - See for details.) + See for details.) By default, constraints applied to build workers regardless of architecture. However, you may only be interested in certain architectures - and not in others. See + and not in others. See for how to get architecture-specific information on which workers satisfy your constraints. - + Constraint syntax This section describes the various constraint qualifiers and their syntax. @@ -425,7 +425,7 @@ Constraint: hardware:cpu:flag sse2 - + Constraint Handling What happens when someone sets a constraint so high, that the OBS instance does not have even a single worker that meets it? What happens @@ -470,7 +470,7 @@ no compliant workers (constraints mismatch hint: hardware:processors sandbox) Please adapt your constraints. - + Checking Constraints with &osccmd; You can check the constraints of a project or package with the osc tool. You have to be in an &osccmd; working directory. diff --git a/xml/obs_build_containers.xml b/xml/obs_build_containers.xml index 163c5d1c..69689472 100644 --- a/xml/obs_build_containers.xml +++ b/xml/obs_build_containers.xml @@ -19,7 +19,7 @@ libraries, executables and shared resource files. - + Supported Container Formats @@ -117,7 +117,7 @@ --> - + Container Registry @@ -184,7 +184,7 @@ xlink:href="https://registry.opensuse.org/">registry.opensuse.org - + Container Image Signatures diff --git a/xml/obs_concepts_dod.xml b/xml/obs_concepts_dod.xml index 2b900cf1..a062a597 100644 --- a/xml/obs_concepts_dod.xml +++ b/xml/obs_concepts_dod.xml @@ -3,7 +3,7 @@ %entities; ]> - diff --git a/xml/obs_image_templates.xml b/xml/obs_image_templates.xml index 7efd6949..0f05246b 100644 --- a/xml/obs_image_templates.xml +++ b/xml/obs_image_templates.xml @@ -30,7 +30,7 @@ page. --> For more information about &kiwi; images, see . + linkend="kiwi-appliance"/>. @@ -50,7 +50,7 @@ templates. For more information about interconnects, see - . + . diff --git a/xml/obs_package_formats.xml b/xml/obs_package_formats.xml index 9f4e0d93..58c8f2b8 100644 --- a/xml/obs_package_formats.xml +++ b/xml/obs_package_formats.xml @@ -176,7 +176,7 @@ --> - + &kiwi; Appliance KIWI is an OS