Fixed typos

for better SiteImprove results.

Author: chabowski

adoc/CloudLS_Architecture.adoc

@@ -271,7 +271,7 @@ all aforementioned components.
 OpenStack users may rarely ever use Horizon. Clouds function on the principle of
 API interfaces that commands can be sent to in a specialized format to trigger
 a certain action, meaning that all components in OpenStack come with an API 
-component that accepts commands based on the ReSTful HTTP approach.
+component that accepts commands based on the RESTful HTTP approach.
 
 There are, however, some tasks where a graphical representation of the
 tasks at hand is helpful and maybe even desired. Horizon is written in Django 
@@ -485,7 +485,7 @@ configured so that it stores replicas of all data in all failure domains
 for every write process.
 
 Should the Ceph Object Gateway be in use to provide for S3/Swift storage
-via a ReSTful interface, that service must be evenly available in all
+via a RESTful interface, that service must be evenly available in all
 failure domains as well. It is necessary to include these
 servers in the loadbalancer setup that is in place for making the
 API services redundant and resilient.
@@ -600,7 +600,7 @@ installed and assigned to it. Four major roles exist:
 
 - *Management Nodes*: To run additional services such as Prometheus (a
   time-series database for monitoring, alerting and trending) and the ELK
-  stack (ElasticSearch, LogStash, Kibana - a log collection and index
+  stack (ElasticSearch, Logstash, Kibana - a log collection and index
   engine), further hardware is required. At least three machines per
   failure domain should be made available for this purpose.
 

adoc/CloudLS_Implementation_Phases.adoc

@@ -190,7 +190,7 @@ a short technical document detailing how to prepare the implementation.
 This not only includes the configuration information for the individual 
 nodes of the setup to ensure a smooth installation of the SUSE OpenStack 
 Cloud and SUSE Enterprise Storage components, but also information about
-any other required component such as autoYaST for the automated deployment 
+any other required component such as AutoYaST for the automated deployment 
 of physical servers.
 
 The technical document also contains relevant information for staff
@@ -219,7 +219,7 @@ are based on a catalogue of standard tests. If all tests are completed successfu
 the formal handover of the setup takes place and the responsibility for the
 installation is transferred to the customer.
 
-Depending on the support level included with the subcription for the 
+Depending on the support level included with the subscription for the 
 solution, you can open support requests and clarify your questions throughout
 the validity of your subscription.
 

adoc/CloudLS_Intro.adoc

@@ -23,7 +23,7 @@ This document provides an overview of the architecture and key aspects of
 an IaaS platform based on SUSE products. It is specifically designed and
 targeted for cloud native workloads running in a large environment. The
 architecture is based on real world implementations that have been
-deployed at scale with enterprise customers and utilises best practices
+deployed at scale with enterprise customers and utilizes best practices
 from these setups.
 
 === Cloud Primer
@@ -81,7 +81,7 @@ design tenets of clouds:
 
 - Cloud environments are based on the principle of API services
   and the ability to issue requests for resources to said API services
-  using a defined and well-known protocol such as ReST. Using such APIs,
+  using a defined and well-known protocol such as REST. Using such APIs,
   services can be implemented in clouds.
 
 - Cloud environments decouple hardware and software and use Software
@@ -146,8 +146,8 @@ Some of the key features of the OpenStack cloud computing software are as follow
   license renewal costs do not apply.
 
 The SUSE OpenStack Cloud product is based on the upstream OpenStack project. It enables the 
-operator to smoothly deal with the complexitiy of the project and control the deployment, the daily operation and 
-the maintanace of the platform. The integrated deployment tool allows for an easy setup and deployment of
+operator to smoothly deal with the complexity of the project and control the deployment, the daily operation and 
+the maintenace of the platform. The integrated deployment tool allows for an easy setup and deployment of
 the complex infrastructure. The professional support provided by SUSE ensures the provision of a stable and available platform,
 turning an open source project in an enterprise grade software solution.
 
@@ -228,7 +228,7 @@ running the platform.
   resembles "managed services" from the conventional world). The user is only 
   consuming the service and does not care about the underlying infrastructure.
 
-.IT service consumation variants 
+.IT service consumption variants 
 image::cloudls_it_service_consumation_basics_v2.svg[align="center",width=400]
 
 ==== Private, Public, Hybrid
@@ -274,7 +274,7 @@ environments have in common.
 To build your IaaS solution, you need at least these resources:
 
 - Hardware (standard industry servers, Commercial off-the-shelf [COTS])
-to run the cloud, control servers, admininstration servers, and host storage.
+to run the cloud, control servers, administration servers, and host storage.
 Commodity hardware (one or two different types for the whole platform)
 is used for cost efficiency.
 
@@ -293,7 +293,7 @@ the subject of this guide.
   cloud's resources by adding additional nodes for compute or storage
   purposes.
 
-- Resiliance: The cloud service must be robust and fault-tolerant. A concept
+- Resilience: The cloud service must be robust and fault-tolerant. A concept
   for high availability must be in place. 
 
 - Standardization: Open standards, open source software, open APIs that
@@ -390,7 +390,7 @@ this document supports companies by being a solution for both needs. The
 companies deploying such a solution benefit from the following:
 
 - A highly cost-effective, rapidly responsible and elastic IT that is
-  very well aligned with its actual businees needs to support
+  very well aligned with its actual business needs to support
   the bimodal IT operations model.
 
 - A large portfolio of business and IT services that effectively

adoc/CloudLS_Operations.adoc

@@ -12,7 +12,7 @@ whilst the cloud can be scaled.
 
 This chapter focuses on the most important aspects of running and
 maintaining a large scale cloud environment. It covers the major tasks
-of the operational everyday's business: system maintenance, monitoring,
+of the operational everydays business: system maintenance, monitoring,
 and log files.
 
 === Maintaining Hundreds of Hosts
@@ -259,7 +259,7 @@ open source solution for visualizing trending data.
 
 ==== Variant 2: Prometheus and Its Components
 
-If Monascana is not the ideal solution for a particular setup, a good 
+If Monasca is not the ideal solution for a particular setup, a good 
 alternative is Prometheus. It features a TSDB that comes 
 with several additional components to allow for a smooth monitoring 
 experience. Prometheus itself is the core of the environment and takes

adoc/OS_Security_Hardening_Guide_for_SAP_HANA_SLES12.adoc

@@ -79,7 +79,7 @@ That prevented its use in many setups because each boot needed a manual step.
 Remote Disk Encryption removes this manual step as it allows the encryption keys to be stored safely on a remote key server and to be automatically used during system boot.
 
 Minimal package selection:: 
-The fewer operating system packages anb SAP HANA system has installed, the less possible security holes it should have. 
+The fewer operating system packages SAP HANA system has installed, the less possible security holes it should have. 
 Following that principle, this guide describes which packages are absolutely necessary and which packages can be safely discarded. 
 As a positive side effect, a minimized number of packages also reduces the number updates and patches that have to be applied to a system.
 
@@ -105,7 +105,7 @@ Introduction to Linux security hardening
 SUSE Linux Enterprise Server already provides a high level of security with the standard installation. 
 However, the standard security settings are generic, because they have to fit to all possible Linux server workloads. 
 Also, many security settings have impacts on the comfort of the system administration and possibly also for the users of the system. 
-Therefore, the SUSE Linux Enterprise Server 12 standard security settings provide a good tradeoff between compatibility to all workloads, administrative comfort and a secure operatingsSystem.
+Therefore, the SUSE Linux Enterprise Server 12 standard security settings provide a good tradeoff between compatibility to all workloads, administrative comfort and a secure operating system.
 
 SAP HANA is a very special workload with clearly defined requirements. 
 For such a workload, it is possible to have a more restrictive security configuration compared to the standard configuration. 
@@ -1266,7 +1266,7 @@ This chapter lists content changes for this document since its first release.
 - in section "Adjust sysctl variables to improve network security": Explanation for setting net.ipv4.conf.default.secure_redirects and net.ipv4.conf.all.secure_redirects corrected
 - in section "Restrict sudo for normal users" tip for using `Default targetpw` corrected
 - in section "Adjust default umask": tip about `pam_umask.so` added
-- in section "Set up password for single user mode": renamed single user mode more correctly to resuce mode
+- in section "Set up password for single user mode": renamed single user mode more correctly to rescue mode
 - in "Adjust sysctl variables to improve network security": now recommends creating a file in `/etc/sysctl.d/` instead of changing `/etc/sysctl.conf`
 - in section "Modify permissions on certain system files": correct some errors in permissions and usage
 - in "SUSE Linux Enterprise Server Update Channels": reference to unavailable document 'SUSE Linux Enterprise Server Maintenance made simple' in resource-library removed

adoc/OS_Security_Hardening_Guide_for_SAP_HANA_SLES15_SP2_and_later.adoc

@@ -376,7 +376,7 @@ Recommendation::
 This is only a good strategy if important security updates are installed outside of the usual maintenance windows.
 
 
-Selectively installating new updates and patches
+Selectively installing new updates and patches
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Description:: 
 A selective installation of patches and updates, for example of security updates only, further reduces the probability of installing problematic updates. 

adoc/SAP-NetWeaver-7.50-SLE-15-Setup-Guide-AliCloud.adoc

@@ -277,8 +277,8 @@ In this example, a VPC named *ASEHADR* in the Region *EU Central 1 (Frankfurt)*
 
 image::Alicloud_VPC_ASE.png[vpc,width="46%"]
 
-There should be at least two VSwitches (subnets) defined within the VPC network. Each VSwitch should
-be bound to a different Zone. In this example, the following two VSwitches (subnets) are defined:
+There should be at least two vSwitches (subnets) defined within the VPC network. Each vSwitch should
+be bound to a different Zone. In this example, the following two vSwitches (subnets) are defined:
 
 * Switch1 "vs_a" 192.168.1.0/24  Zone A, for SAP HANA Primary Node;
 * Switch2 "vs_b" 192.168.2.0/24  Zone B, for SAP HANA Secondary Node;

adoc/SAPDI3-Harvester-Installation.adoc

@@ -19,7 +19,7 @@ For the Harvester deployment, the following information should be handy:
 * Gateway address
 * IP address of name server
 * Access to a time server
-* Access to the Internet (for airgapped installations see: https://docs.harvesterhci.io/v1.1/airgap)
+* Access to the Internet (for air-gapped installations see: https://docs.harvesterhci.io/v1.1/airgap)
 
 For more information, see the product documentation for Harvester:
 https://docs.harvesterhci.io/v1.1/

adoc/SAPDI31-RKE2-Instguide.adoc

@@ -847,13 +847,13 @@ Install NetApp Trident according to the documentation at https://netapp-trident.
 
 * Create a storage class on top of NetApp Trident and make it the default storage class.
 
-* Create an *igroup* and add the initator names from the RKE 2 worker nodes:
+* Create an *igroup* and add the initiator names from the RKE 2 worker nodes:
 
 ** Log in to the RKE2 worker nodes and query the initiator names from `/etc/iscsi/initiator.iscsi`.
 
 ** Make sure the initiator names are unique! If they are not, replace them with new ones, generated with `iscsi-iname`.
 
-** Create an *igroup* inside your *vserver* and add all initator names.
+** Create an *igroup* inside your *vserver* and add all initiator names.
 
 ==== Installing NetApp StorageGRID
 

adoc/SAP_S4HA10_SetupGuide_SLE12.adoc

@@ -1447,7 +1447,7 @@ IMPORTANT: Do not use diskless SBD as a fencing mechanism for two-node clusters.
 in clusters with three or more nodes. SBD in diskless mode cannot handle split brain scenarios for
 two-node clusters.
 
-==== Preparing the operating system and installating the cluster software
+==== Preparing the operating system and installing the cluster software
 
 In general the OS preparation is similar to the procedure described for the two node cluster.
 This includes the setup of NTP as well as installing the software pattern *ha_sles* using *yast2* or *zypper*.