Server+ Ch1 Text.txt

In order to effectively manage servers in an enterprise environment, you must understand the role of the systems administrator (sysadmin). You must also understand the differences between servers and workstations and how to manage the server lifecycle. Troubleshooting is a key skill for sysadmins. A...

In order to effectively manage servers in an enterprise environment, you must understand the role of the systems administrator (sysadmin). You must also understand the differences between servers and workstations and how to manage the server lifecycle. Troubleshooting is a key skill for sysadmins. A troubleshooting methodology will make it more efficient to address server and network issues. Finally, in this lesson, you will learn about licensing models and compare open source and proprietary software licenses. The role of the systems administrator is key to understanding the management of servers. Systems administrators have many different job roles and responsibilities. You must also understand the difference between workstations and servers. You will also examine the server lifecycle and the four major subsystems of computers. Finally, you will compare the two major server operating systems (OSs), Linux and Windows Server. Systems Administrator Job Roles and Responsibilities Systems administrators are responsible for managing the server and network hardware lifecycles, documentation, and security. The sysadmin may also advise the business on emerging technologies and may have a role in capacity planning. The primary skill of a systems administrator is problem-solving. Sysadmins typically have a variety of skills and work with a wide range of technologies. Common Sysadmin Responsibilities Installing, configuring, and managing server hardware, applications, and network components Managing the server lifecycle Monitoring server performance Providing capacity planning and growth Managing user and group accounts for access control Troubleshooting Working with other information technology (IT) teams, possibly including the service desk, developers, desktop support Accepting escalated service desk tickets Managing disparate technologies, such as databases, virtualization, cloud, backups, disaster recovery Managing network services, such as web, email, name resolution, Internet protocol (IP) address configuration Providing documentation Sharpening communications and presentation skills Advising the business on security policies, and implementing those policies Sysadmins may possess the following: Formal technical training Vendor and vendor-neutral certifications College degree Years of experience Sysadmins must differentiate workstation computers and server computers. Workstations are usually assigned to end users. These devices do not tend to have redundant hardware and often do not have high-performance capabilities. Workstations also typically have a client OS installed. These OSs are optimized for a single user, support single-user applications, and often have a very elegant user interface. Client OSs include Microsoft Windows 10, Apple macOS, and Ubuntu Desktop Linux. Server hardware is designed for high performance and redundancy. Often, a server includes multiple network interface cards (NICs), power supplies, and HDDs. The server may also have a great deal of random access memory (RAM) and multiple powerful central processing units (CPUs). The server's form factor may be measured in 1.75 inch (44.45 mm) units that permit it to be installed into standardized server racks. The server will be 19" wide and one or more units high. Servers typically have a server OS installed. These OSs are optimized for multiple users, support multiuser applications, and often have a more streamlined user interface. In fact, some server OSs do not use a graphical user interface (GUI) at all and instead are managed via a command-line interface (CLI). Server OSs include Microsoft Windows Server 2019 and Red Hat Enterprise Linux 8 (RHEL). Workstation Characteristics Assigned to end user No redundant hardware No high-performance hardware Client OS optimized for a single user Applications optimized for a single user Elegant graphical user interface Desktop or laptop form factor Server characteristics Secured in a server room Redundant hardware High-performance hardware Server operating system optimized for multiple users Applications optimized for multiple users Limited or no graphical user interface Rack-mounted form factor Workstation Operating Systems Microsoft Windows 10 Ubuntu Desktop Linux MacOS Server Operating Systems Microsoft Windows Server 2019 Red Hat Enterprise Linux 8 (RHEL 8) Workstation and Server Security Security is another factor that differentiates workstations and servers. End-user workstations are often exposed on the user's desk. Laptop computers may be removed from the business premises entirely. This represents a very significant security risk of damage, theft, loss, and dataexposure. Servers must be physically secured. Servers are usually housed in a locked server room that provides physical protection. They are also regularly backed up and equipped with redundant hardware to maintain a high degree of availability. Sysadmins must understand how the different features of servers and server OSs necessitate a different management approach from end-user workstations. Server Lifecycle Server administrators are responsible for the lifecycle of the server. The term "lifecycle" normally specifies four phases: procurement, usage, end of life, and disposal/recycling. These phases are covered in more detail later in the course. At this stage, it useful for you to recognize that the server administrator's role is to maintain the server through its lifecycle. The Four Major Subsystems Computer systems are specified based on the four major subsystems, which are also useful measurements for the system's performance. Servers often require more available resources than do end-user workstations. The four subsystems are the following: Processor---the CPU represents the amount of processing power the system has available. Memory---the RAM represents storage capacity available to the CPU for quick access to data. Storage---the storage drives represent storage capacity and access speeds available for the OS and user data. Network---the capacity for sending and receiving information across the network. Server OSs---Linux and Windows There are multiple OSs optimized for server roles, but this book focuses on Linux and Microsoft Windows Server. There are significant differences between the two. Linux Linux is actually a very big family of related OSs. Each version of Linux is referred to as a "distribution" (or "distro"). Each distribution is typically purpose specific. For example, Red Hat Enterprise Linux (RHEL) is designed to be used in a largescale business deployment. Kali Linux is designed to be used in penetration testing situations. Linux is licensed under the General Public License (GPL) and is an open-source OS. That means that the source code that makes up the OS is available to anyone to be modified and redistributed. The Linux OS is available for free download. Most Linux distributions trace their lineage back to either Debian Linux or Red Hat Linux. The primary difference between the two branches of the Linux family is how software is managed. Red Hat Linux Derivatives RHEL Fedora CentOS Debian Linux Derivatives Debian Linux Ubuntu Kali Two common areas of consideration for choosing between Linux and Windows Server OSs are device driver compatibility and software availability. Windows Server The Microsoft Windows Server OS is very common and is closely related to the Windows desktop OSs. Windows Server is designed to be used in a business setting to provide centralized administration. Windows is a closed-source OS. That means that the source code that makes up the OS is not available to be modified or redistributed. The Windows Server OS is available for purchase from Microsoft or resellers. One of the primary skills and duties of a systems administrator is to troubleshoot problems with servers, the network, and data access. It is important to have a methodology for troubleshooting. You should also recognize that troubleshooting methods may change by situation, skill level, and experience with the network environment. Troubleshooting Methodology A formalized and consistent troubleshooting methodology can make identifying issues and discovering fixes more efficient. While the steps can vary depending on the actual issue and components involved, there are several universal troubleshooting steps. The following list represents the basic steps in a troubleshooting methodology: Identify the problem Determine the scope of the problem Establish a theory of probable cause/question the obvious Test the theory to determine the cause Establish a plan of action Implement the solution or escalate the issue Verify full system functionality Implement preventive measures Perform a root cause analysis Document findings, actions, and outcomes throughout the process. Identify the Problem and Determine the Scope Identify the Problem The first troubleshooting phase is to identify the problem. The problem may be discovered for you by the end users you support, exposed by log files, identified by monitoring software, or indicated by lights on the server. There are many ways in which the problem may be detected. Once a problem is identified, a service desk ticket is used to track it. Determine the Scope of the Problem Once a problem is identified, gather additional information to determine the scope of the problem. Start this process by asking users for additional details or examining log files. Attempt to replicate the problem by asking users to show you what they were doing when the problem was encountered, or to try to recreate the situation where the problem first arose. It is a good practice to back up data if there is any risk to the data during the troubleshooting phase. You must use your own judgment as to whether a data backup is necessary before you begin troubleshooting. Finally, consider whether you have the skills to address the problem or if you need to escalate the service desk ticket to another administrator. One of the most important steps is to determine whether the problem exists on only one server, or on multiple servers. The scope of the problem could be hardware based and, if so, may be isolated to that device. It could be network based, in which case, multiple devices may be affected. It could be software based, such as a misconfiguration or a bug. This also may impact multiple servers. Example: If one workstation cannot access a file server, but all other workstations can, the problem likely lies with that workstation. If many workstations cannot access the file server, the problem likely lies with that server or with the network between the workstations and the server. Note: In Linux, the log file service is named "rsyslog." In Windows, the log file service is named "Event Viewer." Establish and Test a Theory of Probable Cause Establish a Theory of Probable Cause/Question the Obvious The next troubleshooting phase is to establish a probable cause for the problem. It is essential to keep this step as simple as possible. Newer administrators may be tempted to believe that because the server and network are complex, the problem must also be complex. Troubleshooting often begins with very simple steps, such as confirming that the system is plugged in and powered on. More complex problems may require you to examine log files, talk to users or other administrators, or check the hardware. When troubleshooting, identify any common elements or similar problems that might span multiple servers or network devices. Such common elements might include a new or updated piece of software, a new device driver, or a new configuration. Check for any recent changes to the environment. These changes may have been implemented by another IT staff member or a stakeholder, such as a manager or other user. Recent changes are common culprits for issues. Test the Theory to Determine the Cause Next, test the theory by verifying that the likely cause is indeed the culprit. This phase involves research or other testing. Very simple problems may actually be solved during this step. If your theory is confirmed, then move on to the next phase, which is to establish a plan of action. If your theory is not confirmed, then you must establish and test a new theory. Establish and Implement a Plan of Action Establish a Plan of Action The plan of action for addressing the problem must recognize that service interruptions and data loss should be avoided. If a server needs to be brought down to replace hardware, or if data has been lost due to a HDD failure, the end users must be notified. The plan of action defines the steps to be taken. These steps should be defined ahead of time rather than created during the implementation of the solution. It is useful to provide the impacted users with an expected duration of the outage. Implement the Solution or Escalate In this phase, follow the plan of action established earlier. It is important not to deviate from the plan. You may not have the knowledge to implement the plan and need to escalate the problem to the vendor's support team or other members of your own team. When following a plan of action, be sure to only make one change at a time, and then test the result. If you make multiple changes simultaneously, it is difficult to identify exactly which change corrected the problem. If a given change does not solve the problem, reverse that change, and then try another option. Verify, Prevent, Analyze, and Document Verify Full System Functionality Once the potential solution has been implemented, the next phase is to test for functionality. Your goal is to ensure that the server has returned to the service levels that are defined by the system parameters. The server performance baseline that you performed during the deployment portion of the server lifecycle will be very useful as a comparison. Implement Preventive Measures It may be possible to preemptively reconfigure other servers to avoid a repeat of the same problem. It may also be possible to implement additional technologies (such as a redundant array of independent/ inexpensive disks \[RAID\]) or additional practices (such as backups) to prevent future instances of failure. In some cases, additional training or documentation may also be necessary. Perform a Root Cause Analysis Once service is restored to your users, it is time to evaluate why the problem occurred. Identifying the root cause permits you to change processes or implement different technologies to avoid the problem in the future. Document Findings, Actions, and Outcomes Throughout the Process Documentation is maintained throughout the server's lifecycle, including during the troubleshooting process. Documenting the symptoms of the problem, the results of research into potential solutions, and the results of each step of the plan of action (whether the step was successful or not) permits you to understand your environment better and therefore helps to prevent possible future problems. Note that documentation is not a separate step but rather a good practice used during each phase of the troubleshooting process. Some service desk management software requires the use of tickets. Such software may require that troubleshooting documentation be entered before the ticket can be closed. Guidelines for Troubleshooting Methods Troubleshooting is a key skill for systems administrators. A troubleshooting methodology makes the process more efficient and accurate. A troubleshooting methodology may change somewhat depending on the situation. The following steps suggest a likely troubleshooting methodology: Identify the problem Determine the scope Establish a theory of probable cause/question the obvious Test the theory to determine the cause Establish a plan of action/implement the solution or escalate Verify full system functionality Implement preventive measures Perform a root cause analysis Document findings, actions, and outcomes throughout the process One of the responsibilities of a sysadmin is to properly understand and maximize software licensing. This can be a complex task, but it is an essential one. In the next section, you will compare open-source and proprietary licenses and investigate license models. Licenses Versus Maintenance and Support A software license is a legal contract that governs the distribution and use of software. Licenses typically define how many installations of the software are allowed or how many concurrent users are allowed to use the software. Software is governed by two different licensing structures. The first is the traditional proprietary software license. This license protects the source code of the software from modification or redistribution. The second type of license governs free and open-source software (FOSS). Open-source software may be modified and redistributed within the terms defined by the license. Microsoft Windows Server is governed by a proprietary license, and Linux is governed by an FOSS license. FOSS licensing---a licensing model where users are free to use, modify, and rerelease software voluntarily manner to improve the software. No cost Free to modify and redistribute Not necessarily reliable vendor support Not necessarily reliable documentation Proprietary---a licensing model where the source code for the software is hidden, and users are not allowed to freely modify and rerelease the software. Proprietary software may also have an associated purchase cost. Proprietary licenses may be subscription or volume based. Not free to use Not free to modify More likely reliable vendor support More likely reliable documentation While FOSS does not require a formal license, many vendors utilize a subscription service to maintain the OS or software. Red Hat, for example, has a subscription service associated with RHEL8. Earlier in the lesson you used a web browser to connect to https://distrowatch.com/ to view the latest Linux distribution releases. Reconnect to Distrowatch and select one of the distributions. Observe that you can download the distribution for free. Maintenance and Support Plans It is important not to confuse the licensing and maintenance concepts. Just because you have the legal right to use a piece of software or install an OS does not necessarily entitle you to vendor support for the product. Some licensing models may include support. Subscription license models are an example. Support plans are covered later in the book. Licensing Models There are many different license models. Licensing varies between on-premises and cloud solutions, OSs, applications, virtualization technologies, and even number of users. The following list is a summary of some common license types: Subscription---a license that permits the use of software hosted in the cloud. Subscription licenses are billed yearly or monthly. They may include support costs as part of the subscription. Volume licensing---a single license that covers a specified number of installations for the convenience of large businesses. This model simplifies the license management process. Per-instance---one license for each instance of the software installed. If you run twenty copies of the software, you will need twenty licenses. Per-concurrent-user---one license for each software instance in use by a user. This is typically less expensive than per-seat licensing. If your organization has ten of these licenses, and there are twenty copies of the software installed, then only ten users may use the software simultaneously. Per-seat license---one license for each potential user of the software. This is typically more expensive than per-concurrent-user licensing. Per-server---client access licenses (CALs) installed on the server. The number of licenses determines the number of simultaneous connections that clients may make to the server. A server with ten per-server CALs will permit up to ten simultaneous client connections. Per-socket---licenses allocated to each processor socket that is enabled on the server's motherboard. It is important to note that the motherboard may contain more sockets than are licensed, but the extra sockets are disabled. Per-core---licenses allocated to each processor core that is enabled on the CPU. It is important to note that the CPU may contain more cores than are licensed, but the extra cores are disabled. Site-based---licenses that permit the installation of software within a specified site, building, or organization. Node-locked---licenses stored on a single node or on a Universal Serial Bus (USB) dongle, and any number of instances of the software may run on that node. The goal is to permit the software to run only on one computer. Physical vs. virtual---not all licenses apply the same way between physical installations on a server and installations that are done on VMs. You need to further investigate the licenses when dealing with VMs. Consider the possible complexity of managing licenses in a small organization. If your organization has five Windows Server installations, you need a license for each installation. If your organization also has 100 Windows 10 clients, you need 100 licenses for your Windows 10 installations. You also need CALs to permit the Windows 10 clients to connect to the Windows Server servers. Those CALs may be managed in a per-set or per-server model. In addition, you still need to account for the licensing of all software that runs on the servers and the clients. One piece of software installed on your servers may use per-socket licensing, while another piece of software may use per-core licensing. Your organization must be able to prove license compliance if it is audited. "License count validation" refers to the ability to demonstrate that the number of installations or the number of users matches the license specifications. If a company exceeds the number of installations for which it has a license, the company must purchase the appropriate number of licenses to "true up" its compliance. Microsoft, for example, may audit organizations to ensure that they are compliant and then require those organizations to true up. Electronic Signatures In many cases, you may be required to provide a digital signature or e-signature acknowledging a license agreement. Organizations such as DocuSign provide electronic signing options for licenses, contacts, and other legal agreements. The digital signatures referenced in this section are not the same thing as the digital signature function found with the Public Key Infrastructure. In this case, the focus is on signatures for legal documents. Version Compatibility Licenses may permit users to use a specified software version and any version previous to that one. For example, a current software license for version three of a software package might also enable the use of versions one and two. This is an example of license backward compatibility. Licenses that are forward compatible permit the use of the current software version and one or more future releases of the software. As a systems administrator, you must understand the license requirements for OSs and software to ensure that your organization remains compliant. There can be legal and financial penalties for failing to maintain proper licensing. Guidelines for Managing Licenses Remember that FOSS licensing allows for the modification of source code and the distribution of the modified software. Remember that proprietary licensing does not permit modification of the source code. Determine a means to track licenses to ensure compliance. Understand the licensing methods, and recognize that a vendor may offer several license models. Understand whether a license includes maintenance and support. Cloud-based services often utilize a subscription-based licensing model. Systems administrators have a broad range of responsibilities. The sysadmin's role includes understanding the server's place in the network as a component that provides services to end-user workstations or remote clients and requires a high degree of security. Effectively troubleshooting servers calls for a reliable troubleshooting methodology that quickly narrows the scope of the problem and helps to prevent future issues. Sysadmins are also responsible for licensing, which can become complex very quickly. Frequently, server environments rely on a mix of proprietary licenses, as with Microsoft Windows Server, and open-source licenses, as with Linux distributions, such as RHEL or Ubuntu.