Exclude content-related content for EL and Deb (#4250)

(cherry picked from commit bc27701)

Author: aneta-petrova

guides/common/assembly_common-deployment-scenarios.adoc

@@ -4,17 +4,15 @@ include::modules/con_common-deployment-scenarios.adoc[]
 
 include::modules/con_single-location-with-segregated-subnets.adoc[leveloffset=+1]
 
+ifdef::katello,orcharhino,satellite[]
 include::modules/con_multiple-locations.adoc[leveloffset=+1]
 
-ifdef::katello,orcharhino,satellite[]
 include::modules/con_content-view-scenarios.adoc[leveloffset=+1]
 
 include::modules/con_projectserver-with-multiple-manifests.adoc[leveloffset=+1]
-endif::[]
 
 include::modules/con_host-group-structures.adoc[leveloffset=+1]
 
-ifdef::katello,orcharhino,satellite[]
 include::modules/con_iss-scenarios.adoc[leveloffset=+1]
 endif::[]
 

guides/common/assembly_tools-for-administration-of-project.adoc

@@ -12,6 +12,6 @@ include::modules/con_remote-execution-in-project.adoc[leveloffset=+1]
 
 include::modules/con_automating-project-management-with-project-ansible-collection.adoc[leveloffset=+1]
 
-ifndef::foreman-deb,orcharhino[]
+ifdef::katello,satellite[]
 include::modules/con_kickstart-workflow.adoc[leveloffset=+1]
 endif::[]

guides/common/modules/con_configuring-project-server-with-external-database.adoc

@@ -19,10 +19,14 @@ Consider using external databases if you plan to use your {Project} deployment f
 
 * Frequent remote execution tasks.
 This requires a high volume of records in PostgreSQL and generates heavy database workloads.
+ifdef::katello,orcharhino,satellite[]
 * High disk I/O workloads from frequent repository synchronization or content view publishing.
 This requires {Project} to create a record in PostgreSQL for each job.
+endif::[]
 * High volume of hosts.
+ifdef::katello,orcharhino,satellite[]
 * High volume of synchronized content.
+endif::[]
 
 ifeval::["{context}" == "planning"]
 .Additional resources

guides/common/modules/con_major-project-components.adoc

@@ -3,4 +3,8 @@
 [id="Major-{Project}-Components_{context}"]
 = Major {Project} components
 
-A typical {Project} deployment consists of the following components: a {ProjectServer}, {SmartProxyServers} that mirror content from {ProjectServer}, and hosts that receive content and configuration from {ProjectServer} and {SmartProxyServers}.
+A typical {Project} deployment consists of the following components: a {ProjectServer}, {SmartProxyServers}, and hosts that receive
+ifdef::katello,orcharhino,satellite[]
+content and
+endif::[]
+configuration from {ProjectServer} and {SmartProxyServers}.

guides/common/modules/con_multiple-locations.adoc

@@ -8,7 +8,7 @@ This practice can save bandwidth since hosts obtain content from a local {SmartP
 Synchronization of content from remote repositories is done only by the {SmartProxy}, not by each host in a location.
 In addition, this layout makes the provisioning infrastructure more reliable and easier to configure.
 
-ifdef::foreman-el,foreman-deb,katello[]
+ifdef::katello[]
 image::common/planning-for-foreman-system-architecture.svg[Content flow in {ProjectName}]
 endif::[]
 ifdef::orcharhino[]

guides/common/modules/con_overview-of-hosts-in-project.adoc

@@ -17,5 +17,9 @@ ifdef::orcharhino[]
 such as Amazon EC2, Google Compute Engine, libvirt, Microsoft Azure, Proxmox, and VMware vSphere.
 endif::[]
 
-With {Project}, you can manage hosts at scale, including monitoring, provisioning, remote execution, configuration management, software management, and subscription management.
+With {Project}, you can manage hosts at scale, including monitoring, provisioning, remote execution,
+ifdef::katello,orcharhino,satellite[]
+subscription management, content management,
+endif::[]
+and configuration management.
 You can also group hosts by using features such as host groups and host collections.

guides/common/modules/con_planning-organization-and-location-context.adoc

@@ -7,11 +7,15 @@ Context in {Project} consists of organizations and locations.
 You can associate most resources, for example hosts, subnets, and domains, with at least one organization and location context.
 
 Organizations and locations enable you to arrange {Project} resources into logically structured groups.
-For example, you can create groups based on ownership, purpose, content, or security level.
+For example, you can create groups based on ownership, purpose,
+ifdef::katello,orcharhino,satellite[]
+content,
+endif::[]
+or security level.
 ifdef::satellite[]
 You can create and manage multiple organizations through {ProjectName}, then divide and assign your Red{nbsp}Hat subscriptions to each individual organization.
 endif::[]
-ifndef::satellite[]
+ifndef::foreman-deb,foreman-el,satellite[]
 You can create and manage multiple organizations through {ProjectName}, then divide and assign subscriptions to each individual organization.
 endif::[]
 
@@ -20,7 +24,7 @@ Organizations can represent different business units, departments, or teams, suc
 ifdef::satellite[]
 Each organization requires a separate Red{nbsp}Hat subscription manifest.
 endif::[]
-ifndef::satellite[]
+ifndef::foreman-deb,foreman-el,satellite[]
 To manage Red{nbsp}Hat content, each organization requires a separate Red{nbsp}Hat subscription manifest.
 endif::[]
 +
@@ -39,9 +43,17 @@ Unlike organizations, locations can have a hierarchical structure.
 Resources and users can generally only access resources within their own context, which makes configuring organizations and locations an integral part of access management in {Project}.
 
 {ProjectServer} defines all locations and organizations.
-Each {SmartProxyServer} synchronizes content and handles configuration of hosts in a different location.
+Each {SmartProxyServer}
+ifdef::katello,orcharhino,satellite[]
+synchronizes content and
+endif::[]
+handles configuration of hosts in a different location.
 
-Your {ProjectServer} retains the management function, while the content and configuration is synchronized between your {ProjectServer} and {SmartProxyServers} assigned to certain locations.
+Your {ProjectServer} retains the management function, while the
+ifdef::katello,orcharhino,satellite[]
+content and
+endif::[]
+configuration is synchronized between your {ProjectServer} and {SmartProxyServers} assigned to certain locations.
 
 [IMPORTANT]
 ====

guides/common/modules/con_projectserver-overview.adoc

@@ -3,18 +3,27 @@
 [id="{ProjectServerID}-Overview_{context}"]
 = {ProjectServer} overview
 
-{ProjectServer} is the central component of a {Project} deployment where you plan and manage the content lifecycle.
+{ProjectServer} is the central component of a {Project} deployment.
 
 A typical {Project} deployment includes one {ProjectServer} on which you perform the following operations:
 
+ifdef::katello,orcharhino,satellite[]
 * Content lifecycle management
+endif::[]
 * Configuration of {SmartProxyServers}
 * Configuration of hosts
 * Host provisioning
+ifdef::katello,orcharhino,satellite[]
 * Patch management
 * Subscription management
+endif::[]
 
+ifdef::foreman-deb,foreman-el[]
+{ProjectServer} delegates host provisioning and communication to {SmartProxyServers}.
+endif::[]
+ifdef::katello,orcharhino,satellite[]
 {ProjectServer} delegates content distribution, host provisioning, and communication to {SmartProxyServers}.
+endif::[]
 {ProjectServer} itself also includes a {SmartProxy}.
 
 {ProjectServer} also contains a fine-grained authentication system.