Objectives: LPIC-OT Exam 701 - DevOps Tools Engineer

Topic 701: Software Engineering

701.1 Modern Software Development (weight: 6) 

Weight: 6

Description: Candidates should be able to design software solutions suitable for modern runtime environments. Candidates should understand how services handle data persistence, sessions, status information, transactions, concurrency, security, performance, availability, scaling, load balancing, messaging, monitoring and APIs. Furthermore, candidates should understand the implications of agile and DevOps on software development.

Key Knowledge Areas:

◈ Understand and design service based applications
◈ Understand common API concepts and standards
◈ Understand aspects of data storage, service status and session handling
◈ Design software to be run in containers
◈ Design software to be deployed to cloud services
◈ Awareness of risks in the migration and integration of monolithic legacy software
◈ Understand common application security risks and ways to mitigate them
◈ Understand the concept of agile software development
◈ Understand the concept of DevOps and its implications to software developers and operators

The following is a partial list of the used files, terms and utilities:

◈ REST, JSON
◈ Service Orientated Architectures (SOA)
◈ Microservices
◈ Immutable servers
◈ Loose coupling
◈ Cross site scripting, SQL injections, verbose error reports, API authentication, consistent enforcement of transport encryption
◈ CORS headers and CSRF tokens
◈ ACID properties and CAP theorem

701.2 Standard Components and Platforms for Software (weight: 2)

Weight: 2

Description: Candidates should understand services offered by common cloud platforms. They should be able to include these services in their application architectures and deployment toolchains and understand the required service configurations. OpenStack service components are used as a reference implementation.

Key Knowledge Areas:

◈ Features and concepts of object storage
◈ Features and concepts of relational and NoSQL databases
◈ Features and concepts of message brokers and message queues
◈ Features and concepts of big data services
◈ Features and concepts of application runtimes / PaaS
◈ Features and concepts of content delivery networks

The following is a partial list of the used files, terms and utilities:

◈ OpenStack Swift
◈ OpenStack Trove
◈ OpenStack Zaqar
◈ CloudFoundry
◈ OpenShift

701.3 Source Code Management (weight: 5)

Weight: 5

Description: Candidates should be able to use Git to manage and share source code. This includes creating and contributing to a repository as well as the usage of tags, branches and remote repositories. Furthermore, the candidate should be able to merge files and resolve merging conflicts.

Key Knowledge Areas:

◈ Understand Git concepts and repository structure
◈ Manage files within a Git repository
◈ Manage branches and tags
◈ Work with remote repositories and branches as well as submodules
◈ Merge files and branches
◈ Awareness of SVN and CVS, including concepts of centralized and distributed SCM solutions

The following is a partial list of the used files, terms and utilities:

◈ git
◈ .gitignore

701.4 Continuous Integration and Continuous Delivery (weight: 5)

Weight: 5

Description: Candidates should understand the principles and components of a continuous integration and continuous delivery pipeline. Candidates should be able to implement a CI/CD pipeline using Jenkins, including triggering the CI/CD pipeline, running unit, integration and acceptance tests, packaging software and handling the deployment of tested software artifacts. This objective covers the feature set of Jenkins version 2.0 or later.

Key Knowledge Areas:

◈ Understand the concepts of Continuous Integration and Continuous Delivery
◈ Understand the components of a CI/CD pipeline, including builds, unit, integration and acceptance tests, artifact management, delivery and deployment
◈ Understand deployment best practices
◈ Understand the architecture and features of Jenkins, including Jenkins Plugins, Jenkins API, notifications and distributed builds
◈ Define and run jobs in Jenkins, including parameter handling
◈ Fingerprinting, artifacts and artifact repositories
◈ Understand how Jenkins models continuous delivery pipelines and implement a declarative continuous delivery pipeline in Jenkins
◈ Awareness of possible authentication and authorization models
◈ Understanding of the Pipeline Plugin
◈ Understand the features of important Jenkins modules such as Copy Artifact Plugin, Fingerprint Plugin, Docker Pipeline, Docker Build and Publish plugin, Git Plugin, Credentials Plugin
◈ Awareness of Artifactory and Nexus

The following is a partial list of the used files, terms and utilities:

◈ Step, Node, Stage
◈ Jenkins SDL
◈ Jenkinsfile
◈ Declarative Pipeline
◈ Blue-green and canary deployment

Topic 702: Container Management

702.1 Container Usage (weight: 7)

Weight: 7

Description: Candidates should be able to build, share and operate Docker containers. This includes creating Dockerfiles, using a Docker registry, creating and interacting with containers as well as connecting containers to networks and storage volumes. This objective covers the feature set of Docker version 17.06 or later.

Key Knowledge Areas:

◈ Understand the Docker architecture
◈ Use existing Docker images from a Docker registry
◈ Create Dockerfiles and build images from Dockerfiles
◈ Upload images to a Docker registry
◈ Operate and access Docker containers
◈ Connect container to Docker networks
◈ Use Docker volumes for shared and persistent container storage

The following is a partial list of the used files, terms and utilities:

◈ docker
◈ Dockerfile
◈ .dockerignore

702.2 Container Deployment and Orchestration (weight: 5)

Weight: 5

Description: Candidates should be able to run and manage multiple containers that work together to provide a service. This includes the orchestration of Docker containers using Docker Compose in conjunction with an existing Docker Swarm cluster as well as using an existing Kubernetes cluster. This objective covers the feature sets of Docker Compose version 1.14 or later, Docker Swarm included in Docker 17.06 or later and Kubernetes 1.6 or later.

Key Knowledge Areas:

◈ Understand the application model of Docker Compose
◈ Create and run Docker Compose Files (version 3 or later)
◈ Understand the architecture and functionality of Docker Swarm mode
◈ Run containers in a Docker Swarm, including the definition of services, stacks and the usage of secrets
◈ Understand the architecture and application model Kubernetes
◈ Define and manage a container-based application for Kubernetes, including the definition of ◈ Deployments, Services, ReplicaSets and Pods

The following is a partial list of the used files, terms and utilities:

◈ docker-compose
◈ docker
◈ kubectl

702.3 Container Infrastructure (weight: 4)

Weight: 4

Description: Candidates should be able to set up a runtime environment for containers. This includes running containers on a local workstation as well as setting up a dedicated container host. Furthermore, candidates should be aware of other container infrastructures, storage, networking and container specific security aspects. This objective covers the feature set of Docker version 17.06 or later and Docker Machine 0.12 or later.

Key Knowledge Areas:

◈ Use Docker Machine to setup a Docker host
◈ Understand Docker networking concepts, including overlay networks
◈ Create and manage Docker networks
◈ Understand Docker storage concepts
◈ Create and manage Docker volumes
◈ Awareness of Flocker and flannel
◈ Understand the concepts of service discovery
◈ Basic feature knowledge of CoreOS Container Linux, rkt and etcd
◈ Understand security risks of container virtualization and container images and how to mitigate them

The following is a partial list of the used files, terms and utilities:

◈ docker-machine

Topic 703: Machine Deployment

703.1 Virtual Machine Deployment (weight: 4)

Weight: 4

Description: Candidates should be able to automate the deployment of a virtual machine with an operating system and a specific set of configuration files and software.

Key Knowledge Areas:

◈ Understand Vagrant architecture and concepts, including storage and networking
◈ Retrieve and use boxes from Atlas
◈ Create and run Vagrantfiles
◈ Access Vagrant virtual machines
◈ Share and synchronize folder between a Vagrant virtual machine and the host system
◈ Understand Vagrant provisioning, including File, Shell, Ansible and Docker
◈ Understand multi-machine setup

The following is a partial list of the used files, terms and utilities:

◈ vagrant
◈ Vagrantfile

703.2 Cloud Deployment (weight: 2)

Weight: 2

Description: Candidates should be able to configure IaaS cloud instances and adjust them to match their available hardware resources, specifically, disk space and volumes. Additinally, candidates should be able to configure instances to allow secure SSH logins and prepare the instances to be ready for a configuration management tool such as Ansible.

Key Knowledge Areas:

◈ Understanding the features and concepts of cloud-init, including user-data and initializing and configuring cloud-init
◈ Use cloud-init to create, resize and mount file systems, configure user accounts, including login credentials such as SSH keys and install software packages from the distribution’s repository
◈ Understand the features and implications of IaaS clouds and virtualization for a computing instance, such as snapshotting, pausing, cloning and resource limits.

703.3 System Image Creation (weight: 2)

Weight: 2

Description: Candidates should be able to create images for containers, virtual machines and IaaS cloud instances.

Key Knowledge Areas:

◈ Understand the functionality and features of Packer
◈ Create and maintain template files
◈ Build images from template files using different builders

The following is a partial list of the used files, terms and utilities:

◈ packer

Topic 704: Configuration Management

704.1 Ansible (weight: 8)

Weight: 8

Description: Candidates should be able to use Ansible to ensure a target server is in a specific state regarding its configuration and installed software. This objective covers the feature set of Ansible version 2.2 or later.

Key Knowledge Areas:

◈ Understand the principles of automated system configuration and software installation
◈ Create and maintain inventory files
◈ Understand how Ansible interacts with remote systems
◈ Manage SSH login credentials for Ansible, including using unprivileged login accounts
◈ Create, maintain and run Ansible playbooks, including tasks, handlers, conditionals, loops and registers
◈ Set and use variables
◈ Maintain secrets using Ansible vaults
◈ Write Jinja2 templates, including using common filters, loops and conditionals
◈ Understand and use Ansible roles and install Ansible roles from Ansible Galaxy
◈ Understand and use important Ansible tasks, including file, copy, template, ini_file, lineinfile, patch, replace, user, group, command, shell, service, systemd, cron, apt, debconf, yum, git, and debug
◈ Awareness of dynamic inventory
◈ Awareness of Ansibles features for non-Linux systems
◈ Awareness of Ansible containers

The following is a partial list of the used files, terms and utilities:

◈ ansible.cfg
◈ ansible-playbook
◈ ansible-vault
◈ ansible-galaxy
◈ ansible-doc

704.2 Other Configuration Management Tools (weight: 2)

Weight: 2

Description: Candidates should understand the main features and principles of important configuration management tools other than Ansible.

Key Knowledge Areas:

◈ Basic feature and architecture knowledge of Puppet.
◈ Basic feature and architecture knowledge of Chef.

The following is a partial list of the used files, terms and utilities:

◈ Manifest, Class, Recipe, Cookbook
◈ puppet
◈ chef
◈ chef-solo
◈ chef-client
◈ chef-server-ctl
◈ knife

Topic 705: Service Operations

705.1 IT Operations and Monitoring (weight: 4)

Weight: 4

Description: Candidates should understand how IT infrastructure is involved in delivering a service. This includes knowledge about the major goals of IT operations, understanding functional and nonfunctional properties of an IT services and ways to monitor and measure them using Prometheus. Furthermore candidates should understand major security risks in IT infrastructure. This objective covers the feature set of Prometheus 1.7 or later.

Key Knowledge Areas:

◈ Understand goals of IT operations and service provisioning, including nonfunctional properties such as availability, latency, responsiveness
◈ Understand and identify metrics and indicators to monitor and measure the technical functionality of a service
◈ Understand and identify metrics and indicators to monitor and measure the logical functionality of a service
◈ Understand the architecture of Prometheus, including Exporters, Pushgateway, Alertmanager and Grafana
◈ Monitor containers and microservices using Prometheus
◈ Understand the principles of IT attacks against IT infrastructure
◈ Understand the principles of the most important ways to protect IT infrastructure
◈ Understand core IT infrastructure components and their the role in deployment

The following is a partial list of the used files, terms and utilities:

◈ Prometheus, Node exporter, Pushgateway, Altermanager, Grafana
◈ Service exploits, brute force attacks, and denial of service attacks
◈ Security updates, packet filtering and application gateways
◈ Virtualization hosts, DNS and load balancers

705.2 Log Management and Analysis (weight: 4)

Weight: 4

Description: Candidates should understand the role of log files in operations and troubleshooting. They should be able to set up centralized logging infrastructure based on Logstash to collect and normalize log data. Furthermore, candidates should understand how Elasticsearch and Kibana help to store and access log data.

Key Knowledge Areas:

◈ Understand how application and system logging works
◈ Understand the architecture and functionality of Logstash, including the lifecycle of a log message and Logstash plugins
◈ Understand the architecture and functionality of Elasticsearch and Kibana in the context of log data management (Elastic Stack)
◈ Configure Logstash to collect, normalize, transform and store log data
◈ Configure syslog and Filebeat to send log data to Logstash
◈ Configure Logstash to send email alerts
◈ Understand application support for log management

The following is a partial list of the used files, terms and utilities:

◈ logstash
◈ input, filter, output
◈ grok filter
◈ Log files, metrics
◈ syslog.conf
◈ /etc/logstash/logstash.yml
◈ /etc/filebeat/filebeat.yml

Continue reading

Find Command in Linux with Examples

The find command in UNIX is a command line utility for walking a file hierarchy. It can be used to find files and directories and perform subsequent operations on them. It supports searching by file, folder, name, creation date, modification date, owner and permissions. By using the ‘-exec’ other UNIX commands can be executed on files or folders found.

Syntax :

$ find [where to start searching from]
 [expression determines what to find] [-options] [what to find]

Options :

◈ -exec CMD: The file being searched which meets the above criteria and returns 0 for as its exit status for sucessful command execution.
◈ -ok CMD : It works same as -exec except the user is prompted first.
◈ -inum N : Search for files with inode number ‘N’.
◈ -links N : Search for files with ‘N’ links.
◈ -name demo : Search for files that are specified by ‘demo’.
◈ -newer file : Search for files that were modified/created after ‘file’.
◈ -perm octal : Search for the file if permission is ‘octal’.
◈ -print : Display the path name of the files found by using the rest of the criteria.
◈ -empty : Search for empty files and directories.
◈ -size +N/-N : Search for files of ‘N’ blocks; ‘N’ followed by ‘c’can be used to measure size in characters; ‘+N’ means size > ‘N’ blocks and ‘-N’ means size < 'N' blocks.
◈ -user name : Search for files owned by user name or ID ‘name’.
◈ \(expr \) : True if ‘expr’ is true; used for grouping criteria combined with OR or AND.
◈ ! expr : True if ‘expr’ is false.

Examples :

Consider the following tree hirerachy :

1. Search a file with specific name.

$ find ./GFG -name sample.txt 

It will search for sample.txt in GFG directory.

Output :

2. Search a file with pattern.

$ find ./GFG -name *.txt 

It will give all files which have ‘.txt’ at the end.

Output :

3. How to find and delete a file with confirmation.

$ find ./GFG -name sample.txt -exec rm -i {} \; 

When this command is entered, a prompt will come for confirmation, if you want to delete sample.txt or not. if you enter ‘Y/y’ it will delete the file.

Output :

4. Search for empty files and directories.

$ find ./GFG -empty

This command find all empty folders and files in the entered directory or sub-directories.

Output :

5. Search for file with entered permissions.

$ find ./GFG -perm 664

This command find all the files in the GFG directory or sub-directory with the given permissions.

Output :

6. Search text within multiple files.

$ find ./ -type f -name "*.txt" -exec grep 'Geek'  {} \;

This command print lines which have ‘Geek’ in them and ‘-type f’ specifies the input type is a file.

Output :

Continue reading

Objective: Linux Essentials Exam 010

Topic 1: The Linux Community and a Career in open source (weight: 7)

1.1 Linux Evolution and Popular Operating Systems

Weight: 2

Description: Knowledge of Linux development and major distributions.

Key Knowledge Areas:

◈ open source Philosophy
◈ Distributions
◈ Embedded Systems

The following is a partial list of the used files, terms and utilities:

◈ Android
◈ Debian, Ubuntu (LTS)
◈ CentOS, openSUSE, Red Hat
◈ Linux Mint, Scientific Linux

1.2 Major open source Applications

Weight: 2

Description: Awareness of major applications as well as their uses and development.

Key Knowledge Areas:

◈ Desktop Applications
◈ Server Applications
◈ Development Languages
◈ Package Management Tools and repositories

Terms and Utilities:

◈ OpenOffice.org, LibreOffice, Thunderbird, Firefox, GIMP
◈ Apache HTTPD, NGINX, MySQL, NFS, Samba
◈ C, Java, Perl, shell, Python, Samba
◈ dpkg, apt-get, rpm, yum

1.3 Understanding open source Software and Licensing

Weight: 1

Description: Open communities and licensing open source Software for business.

Key Knowledge Areas:

◈ Licensing
◈ Free Software Foundation (FSF), open source Initiative (OSI)

Terms and Utilities:

◈ GPL, BSD, Creative Commons
◈ Free Software, open source Software, FOSS, FLOSS
◈ open source business models

1.4 ICT Skills and Working in Linux

Weight: 2

Description: Basic Information and Communication Technology (ICT) skills and working in Linux.

Key Knowledge Areas:

◈ Desktop Skills
◈ Getting to the Command Line
◈ Industry uses of Linux, Cloud Computing and Virtualization

Terms and Utilities:

◈ Using a browser, privacy concerns, configuration options, searching the web and saving content
◈ Terminal and Console
◈ Password issues
◈ Privacy issues and tools
◈ Use of common open source applications in presentations and projects

Topic 2: Finding Your Way on a Linux System (weight: 9)

2.1 Command Line Basics

Weight: 3

Description: Basics of using the Linux command line.

Key Knowledge Areas:

◈ Basic shell
◈ Command line syntax
◈ Variables
◈ Globbing
◈ Quoting

Terms and Utilities:

◈ Bash
◈ echo
◈ history
◈ PATH env variable
◈ export
◈ type

2.2 Using the Command Line to Get Help

Weight: 2

Description: Running help commands and navigation of the various help systems.

Key Knowledge Areas:

◈ Man
◈ Info

Terms and Utilities:

◈ man
◈ info
◈ Man pages
◈ /usr/share/doc/
◈ locate

2.3 Using Directories and Listing Files

Weight: 2

Description: Navigation of home and system directories and listing files in various locations.

Key Knowledge Areas:

◈ Files, directories
◈ Hidden files and directories
◈ Home
◈ Absolute and relative paths

Terms and Utilities:

◈ Common options for ls
◈ Recursive listings
◈ cd
◈ . and ..
◈ home and ~

2.4 Creating, Moving and Deleting Files

Weight: 2

Description: Create, move and delete files and directories under the home directory.

Key Knowledge Areas:

◈ Files and directories
◈ Case sensitivity
◈ Simple globbing and quoting

Terms and Utilities:

◈ mv, cp, rm, touch
◈ mkdir, rmdir

Topic 3: The Power of the Command Line (weight: 9)

3.1 Archiving Files on the Command Line

Weight:  2

Description: Archiving files in the user home directory.

Key Knowledge Areas:

◈ Files, directories
◈ Archives, compression

Terms and Utilities:

◈ tar
◈ Common tar options
◈ gzip, bzip2
◈ zip, unzip

3.2 Searching and Extracting Data from Files

Weight: 3

Description: Search and extract data from files in the home directory.

Key Knowledge Areas:

◈ Command line pipes
◈ I/O re-direction
◈ Basic Regular Expressions ., [  ], *, ?

Terms and Utilities:

◈ grep
◈ less
◈ cat, head, tail
◈ sort
◈ cut
◈ wc

3.3 Turning Commands into a Script

Weight: 4

Description: Turning repetitive commands into simple scripts.

Key Knowledge Areas:

◈ Basic shell scripting
◈ Awareness of common text editors

Terms and Utilities:

◈ #! (shebang)
◈ /bin/bash
◈ Variables
◈ Arguments
◈ for loops
◈ echo
◈ Exit status

Topic 4: The Linux Operating System (weight: 8)

4.1 Choosing an Operating System

Weight: 1

Description: Knowledge of major operating systems and Linux distributions.

Key Knowledge Areas:

◈ Windows, Mac, Linux differences
◈ Distribution life cycle management

Terms and Utilities:

◈ GUI versus command line, desktop configuration
◈ Maintenance cycles, Beta and Stable

4.2 Understanding Computer Hardware

Weight: 2

Description: Familiarity with the components that go into building desktop and server computers.

Key Knowledge Areas:

◈ Hardware

Terms and Utilities:

◈ Motherboards, processors, power supplies, optical drives, peripherals
◈ Hard drives and partitions, /dev/sd*
◈ Drivers

4.3 Where Data is Stored

Weight: 3

Description: Where various types of information are stored on a Linux system.

Key Knowledge Areas:

◈ Programs and configuration, packages and package databases
◈ Processes, memory addresses, system messaging and logging

Terms and Utilities:

◈ ps, top, free
◈ syslog, dmesg
◈ /etc/, /var/log/
◈ /boot/, /proc/, /dev/, /sys/

4.4 Your Computer on the Network

Weight: 2

Description: Querying vital networking configuration and determining the basic requirements for a computer on a Local Area Network (LAN).

Key Knowledge Areas:

◈ Internet, network, routers
◈ Querying DNS client configuration
◈ Querying Network configuration

Terms and Utilities:

◈ route, ip route show
◈ ifconfig, ip addr show
◈ netstat, ip route show
◈ /etc/resolv.conf, /etc/hosts
◈ IPv4, IPv6
◈ ping
◈ host

Topic 5: Security and File Permissions (weight: 7)

5.1 Basic Security and Identifying User Types

Weight: 2

Description: Various types of users on a Linux system.

Key Knowledge Areas:

◈ Root and Standard Users
◈ System users

Terms and Utilities:

◈ /etc/passwd, /etc/group
◈ id, who, w
◈ sudo, su

5.2 Creating Users and Groups

Weight: 2

Description: Creating users and groups on a Linux system.

Key Knowledge Areas:

◈ User and group commands
◈ User IDs

Terms and Utilities:

◈ /etc/passwd, /etc/shadow, /etc/group, /etc/skel/
◈ id, last
◈ useradd, groupadd
◈ passwd

5.3 Managing File Permissions and Ownership

Weight: 2

Description: Understanding and manipulating file permissions and ownership settings.

Key Knowledge Areas:

◈ File/directory permissions and owners
◈ Terms and Utilities:
◈ ls -l, ls -a
◈ chmod, chown

5.4 Special Directories and Files

Weight: 1

Description: Special directories and files on a Linux system including special permissions.

Key Knowledge Areas:

◈ Using temporary files and directories
◈ Symbolic links

Terms and Utilities:

◈ /tmp/, /var/tmp/ and Sticky Bit
◈ ls -d
◈ ln -s

Continue reading

Differentiating UNIX and Linux

1. Introduction

The history of UNIX® dates back to 1969. Through the years, it has developed and evolved through a number of different versions and environments. Most modern UNIX variants known today are licensed versions of one of the original UNIX editions. Sun's Solaris, Hewlett-Packard's HP-UX, and IBM's AIX® are all flavors of UNIX that have their own unique elements and foundations. For example, Sun's Solaris is UNIX, but incorporates many tools and extensions designed to get the best out of Sun's own workstation and server hardware.

Linux® was born out of the desire to create a free software alternative to the commercial UNIX environments. Its history dates back to 1991, or further back to 1983, when the GNU project, whose original aims where to provide a free alternative to UNIX, was introduced. Linux runs on a much wider range of platforms than most UNIX environments, such as the Intel®/AMD led x86 platform. Most UNIX variants run on just one architecture.

Because of this history and the heritage of the two products, Linux and UNIX have a common foundation, but are also very different. Many of the tools, utilities, and free software products that are standard under Linux were originally developed as free alternatives to the versions available on UNIX. Linux often provides support for many different options and applications, picking the best (or most popular) functionality from the UNIX and free software environment.

An administrator or developer who supports Linux systems might find it uncomfortable to move to a commercial UNIX system. On the whole, the foundations of any UNIX-like operating system (tools, filesystem layout, programming APIs) are fairly standardized. However, some details of the systems show significant differences. The remainder of this article covers the details of these differences.

2. Technical differences

The developers of commercial editions of UNIX have a specific target audience and platform for their operating system. They also have a pretty good idea of what applications they want to support and optimize. Commercial UNIX vendors do everything they can to maintain consistency between different versions. They have published standards that they follow for their customers.

The development of GNU/Linux, on the other hand, is more diverse. Developers come from many different backgrounds, and therefore have different experiences and opinions. There has not been as strict of a standard set of tools, environments, and functionality within the Linux community. The Linux Standards Base (LSB) project was formed in an attempt to alleviate this problem, but it has not provided as much help as hoped.

This lack of standards results in noticeable inconsistencies within Linux. It might seem a benefit to some for developers to have the freedom to emulate the best parts of other operating systems, but it can be very confusing when certain elements of Linux emulate different UNIX variants. For example, device names within Linux might emulate AIX, while the filesystem tools seem more like the tools supplied with HP-UX. These sorts of inconsistencies even exist between different Linux distributions. For example, Gentoo and RedHat have different methods for keeping their systems current with the latest patches and software releases.

By comparison, each new release of an operating system comes with a well-documented range of new features and changes within the UNIX space. Commands, tools, and other elements are rarely changed, and often the same command line arguments and interfaces remain over many editions of the software. Where there are significant changes, a commercial UNIX vendor often provides a compatibility layer, or the ability to run the older version of the tool.

This consistency means that tools and applications can be used on new editions of the operating system without a large body of testing. It is much easier for a UNIX user or administrator to update their skills on what is otherwise an unchanged UNIX operating system than the migration or adaptation of skills that might be required between Linux distributions.

3. Hardware architecture

Most commercial versions of UNIX are coded for a single, or possibly a small handful, of hardware architectures. HP-UX is available on PA-RISC and Itanium machines. Solaris is available on SPARC and x86. AIX is only for power processors, and so forth.

Because of these limitations, the UNIX vendors can optimize their code for these architectures. They can take advantage of every feature. Since they know their supported devices, their drivers can be better optimized as well. They are also not restricted by the weak BIOS limitations of most PCs.

Linux, on the other hand, has historically been designed to be as compatible as possible. Not only is Linux available for dozens of architectures, but the number of I/O and other external devices that might be used are almost limitless. The developers cannot assume that a specific hardware feature will be installed and, so often, cannot optimize as well. One example is the memory management on Linux. Since it was originally developed on x86 hardware, it used the segmented memory model. It adapted to use paged mode memory over time, but still retains some segmented memory requirements. This has caused problems for architectures that do not support segmented memory. This is not an issue for UNIX vendors. They know exactly which hardware features they have available.

4. The kernel

The kernel is the core of any operating system. The source code is not freely available for any of the commercial versions of UNIX. Quite the opposite exists for Linux. As such, procedures for compiling and patching kernels and drivers are vastly different. With Linux and other open source operating systems, a patch can be released in source code form and end users can install it, or even verify and modify it if desired. These patches tend to be far less tested than patches from UNIX vendors. Since there is not a complete list of applications and environments that need to be tested on Linux, the Linux developers have to depend on the many eyes of end users and other developers to catch bugs.

Commercial UNIX vendors only release their kernels in binary form. Some release the kernel as a single monolithic package, while others are ablfe to dismantle the kernel and upgrade just a single module. Either way, it is still in binary form. If an update is required, the administrator has to wait for the vendor to release the patch in binary form, but they can be more secure knowing that the vendor has performed sufficient regression testing.

All commercial versions of UNIX have evolved to support some sort of module-based kernel. Drivers and certain features are available as separate components and can be loaded or unloaded from the kernel as needed. None is quite as open and flexible as the module architecture in Linux. However, with the flexibility and adaptability of Linux comes constant change. The Linux code base is constantly changing and the API can change at the whim of a developer. When a module or driver is written for a commercial version of UNIX, that code works far longer than the same driver written for Linux.

Filesystem support

One of the reasons Linux has become such a powerful tool is its immense compatibility with other operating systems. One of the most obvious features is the plethora of filesystems that are available. Most commercial version of UNIX supports two, or possibly three, different local filesystem types. Linux, however, supports almost all of the filesystems that are currently available on any operating system. Table 1 shows which filesystems are supported under which version of UNIX. You can mount each of these filesystems under Linux, although not all of them allow full read-write support.

Table 1. Filesystems that come standard with UNIX versions

System	Filesystem
AIX	jfs, gpfs
HP-UX	hfs, vxfs
Solaris	ufs, zfs
Irix	xfs

Most commercial UNIX versions have at least some sort of journaling filesystem available. For instance, HP-UX uses hfs as its standard filesystem, but it also supports the journaling vxfs filesystems. Solaris is similar with ufs and zfs. Journaling filesystems are a critical component of any enterprise server environment. Linux was relatively late to support journaling filesystems, but now there are several options ranging from ports of commercial filesystems (xfs, jfs) to native Linux-only filesystems (ext3, reiserfs).

Other filesystem features include quota support, file access control lists, mirroring, snapshots, and resizing. These are are supported in some form or another on some of the Linux filesystems. Most of these features are not standardized on Linux. They might work one way on one filesystem, but another method is required on another filesystem. Some of these features are just not available on some Linux filesystems, and some require additional tools to be installed, such as a certain version of LVM or software raid package. Linux historically had difficulty reaching consensus on programming interfaces and standard tools, since there are so many filesystems that present these features so differently.

Since commercial versions of UNIX have a limited number of filesystems to support, their tools and methods are more standardized. For instance, since there is only one main filesystem on Irix, there is only one method used to set access control lists. This makes it much simpler for the end user as well as for vendor support.

5. Application availability

Most of the core applications are the same between UNIX and Linux. For instance, cp, ls, vi, and cc are commands that are available in both UNIX and Linux, and are very similar, if not apparently identical. The Linux versions tend to be based on the GNU version of these tools, whereas the current UNIX versions are based on the original UNIX tools. The tools on UNIX have had a very stable history and rarely change anymore.

This is not to say that commercial versions of UNIX cannot use the GNU tools. In fact, many commercial UNIX vendors include many of the GNU tools in their installations, or as free options. They are just not the standard tools in the customary locations. Certain free programs, such as emacs or Perl, do not have non-free counterparts. Most vendors offer these as pre-compiled packages that are either automatically installed or available as an optional component.

Free and open source applications are almost always assumed to be available and function on all Linux distributions. There are huge amounts of free software available for Linux. Many of these applications have been ported and are available in some form on commercial versions of UNIX.

When it comes to non-free and/or closed-source applications (CAD, financial, graphics design), however, Linux comes up short. While some software vendors have released versions of their programs for Linux, the majority seem to be delaying their releases until Linux adoption reaches a critical mass.

On the other hand, commercial versions of UNIX have historically had large amounts of support for enterprise-level applications, such as Oracle or SAP. Linux lacks in this regard, because of the difficulty of larger applications to be certified, whereas commercial versions of UNIX do not change very much from release to release. Linux can change wildly not only between different distributions, but sometimes between releases of the same distribution. This makes it very difficult for application vendors to understand the exact environment in which their tool will be used.

6. System administration

Although some Linux distributions come with a standard system management tool, such as SUSE's YaST, there is not a Linux-wide standard on tools for system management. Text files and command-line tools are available, but these can be cumbersome and sometimes difficult to remember. Each commercial version of UNIX has its own separate management interface. From this interface, aspects of the entire system can be manipulated and altered. One example of this is the System Administration Manager (SAM) on HP-UX.

From within SAM, there are modules where:

◈ Users or groups can be managed.
◈ Kernel parameters can be modified.
◈ Networking is configured.
◈ Disks are configured and initialized.
◈ X server configuration can be changed.

This tool is well-written and incorporates well with the back-end text files. There is no such tool for Linux. Even SUSE's YaST is not nearly as complete, or compatible.

One aspect of UNIX and Linux that appears to be different for almost every version of UNIX and Linux is the location of system initialization scripts. Luckily /sbin/init and /etc/inittab are in standard locations. But beyond that, all the startup scripts are in different locations. Table 2 lists the location of system initialization scripts for various UNIX and Linux distributions.

Table 2. Location of system initialization scripts on various UNIX versions

System	Location
HP-UX	/sbin/init.d
AIX	/etc/rc.d/init.d
Irix	/etc/init.d
Solaris	/etc/init.d
Redhat	/etc/rc.d/init.d
SUSE	/etc/rc.d/init.d
Debian	/etc/init.d
Slackware	/etc/rc.d

Because of the many different distributions of Linux and the almost infinite number of application and version differences, package management on Linux has always been a little tricky. There are a range of different package management tools available. The correct tool depends on which Linux distribution you are using. Further confusion results from different distributions using the Redhat Package Manager (RPM) file format, but their packages remain incompatible. This fragmentation has led to a myriad of different options, and it is not always obvious which system is in use within a particular environment

On the other hand, UNIX vendors use standard package managers. Even though there are different applications and formats among the different commercial UNIX variants within a specific version, the application environment is consistent and stable. For instance, Solaris has used the same package management tools since its inception. It has been, and will most likely always be, the same tools to identify, add, or remove packages on Solaris.

Recalling that commercial UNIX vendors supply the hardware that accompanies their operating systems, they are able to introduce hardware features that are much harder for Linux to include. For instance, recent Linux versions have attempted to support hot-swap components in hardware (with varied success). Commercial UNIX versions have had these features for many years. There is also more advanced hardware monitoring on commercial UNIX versions. The vendors can write drivers and hooks into their operating system that can monitor hardware health, such as ECC memory failures or power supply parameters, or any other hardware component. This sort of support on Linux is very premature.

Commercial UNIX hardware also has far more advanced initial boot options. Before the operating system boots, there are many options to decide how to boot, check system health, or set hardware parameters. The BIOS that is standard in PCs has few, if any, of these features.

7. Support

One of the most obvious differences between Linux and UNIX is the cost perspective. Commercial UNIX vendors charge significant amounts of money to acquire and use their versions of UNIX on their optimized hardware. Linux distributions, on the other hand, charge relatively little, if anything, for their operating system.

If a commercial version of UNIX is purchased, the vendors usually provide technical support to make sure the system works as expected. Most Linux users do not have the luxury of a company to stand behind their systems. They depend on the support of email lists, forums, and various Linux users groups. These support tools are not only restricted to Linux. Many administrator and users of commercial versions of UNIX participate in these free support groups to find and provide help. Many people even claim the free support groups are more responsive than the commercial vendor's support systems.

Continue reading

An Introduction to the Linux Terminal

Introduction

This tutorial, which is the first in a series that teaches Linux basics to get new users on their feet, covers getting started with the terminal, the Linux command line, and executing commands. If you are new to Linux, you will want to familiarize yourself with the terminal, as it is the standard way to interact with a Linux server. Using the command line may seem like a daunting task but it is actually very easy if you start with the basics, and build your skills from there.

Let's get started by going over what a terminal emulator is.

Terminal Emulator

A terminal emulator is a program that allows the use of the terminal in a graphical environment. As most people use an OS with a graphical user interface (GUI) for their day-to-day computer needs, the use of a terminal emulator is a necessity for most Linux server users.

Here are some free, commonly-used terminal emulators by operating system:

◈ Mac OS X: Terminal (default), iTerm 2
◈ Windows: PuTTY
◈ Linux: Terminal, KDE Konsole, XTerm

Each terminal emulator has its own set of features, but all of the listed ones work great and are easy to use.

The Shell

In a Linux system, the shell is a command-line interface that interprets a user's commands and script files, and tells the server's operating system what to do with them. There are several shells that are widely used, such as Bourne shell (sh) and C shell (csh). Each shell has its own feature set and intricacies, regarding how commands are interpreted, but they all feature input and output redirection, variables, and condition-testing, among other things.

This tutorial was written using the Bourne-Again shell, usually referred to as bash, which is the default shell for most Linux distributions, including Ubuntu, CentOS, and RedHat.

The Command Prompt

When you first login to a server, you will typically be greeted by the Message of the Day (MOTD), which is typically an informational message that includes miscellaneous information such as the version of the Linux distribution that the server is running. After the MOTD, you will be dropped into the command prompt, or shell prompt, which is where you can issue commands to the server.

The information that is presented at the command prompt can be customized by the user, but here is an example of the default Ubuntu 14.04 command prompt:

sammy@webapp:~$

Here is a breakdown of the composition of the command prompt:

◈ sammy: The username of the current user
◈ webapp: The hostname of the server
◈ ~: The current directory. In bash, which is the default shell, the ~, or tilde, is a special character that expands to the path of the current user's home directory; in this case, it represents /home/sammy
◈ $: The prompt symbol. This denotes the end of the command prompt, after which the user's keyboard input will appear

Here is an example of what the command prompt might look like, if logged in as root and in the /var/log directory:

root@webapp:/var/log#

Note that the symbol that ends the command prompt is a #, which is the standard prompt symbol for root. In Linux, the root user is the superuser account, which is a special user account that can perform system-wide administrative functions--it is an unrestricted user that has permission to perform any task on a server.

Executing Commands

Commands can be issued at the command prompt by specifying the name of an executable file, which can be a binary program or a script. There are many standard Linux commands and utilities that are installed with the OS, that allow you navigate the file system, install and software packages, and configure the system and applications.

An instance of a running command is known as a process. When a command is executed in the foreground, which is the default way that commands are executed, the user must wait for the process to finish before being returned to the command prompt, at which point they can continue issuing more commands.

It is important to note that almost everything in Linux is case-sensitive, including file and directory names, commands, arguments, and options. If something is not working as expected, double-check the spelling and case of your commands!

We will run through a few examples that will cover the basics of executing commands.

Without Arguments or Options

To execute a command without any arguments or options, simply type in the name of the command and hit RETURN.

If you run a command like this, it will exhibit its default behavior, which varies from command to command. For example, if you run the cd command without any arguments, you will be returned to your current user's home directory. The ls command will print a listing of the current directory's files and directories. The ip command without any arguments will print a message that shows you how to use the ip command.

Try running the ls command with no arguments to list the files and directories in your current directory (there may be none):

ls

With Arguments

Many commands accept arguments, or parameters, which can affect the behavior of a command. For example, the most common way to use the cd command is to pass it a single argument that specifies which directory to change to. For example, to change to the /usr/bin directory, where many standard commands are installed, you would issue this command:

cd /usr/bin

The cd component is the command, and the first argument /usr/bin follows the command. Note how your command prompt's current path has updated.

If you would like, try running the ls command to see the files that are in your new current directory.

ls

With Options

Most commands accept options, also known as flags or switches, that modify the behavior of the command. As they are special arguments, options follow a command, and are indicated by a single - character followed by one or more options, which are represented by individual upper- or lower-case letters. Additionally, some options start with --, followed by a single, multi-character (usually a descriptive word) option.

For a basic example of how options work, let's look at the ls command. Here are a couple of common options that come in handy when using ls:

◈ -l: print a "long listing", which includes extra details such as permissions, ownership, file sizes, and timestamps
◈ -a: list all of a directory's files, including hidden ones (that start with .)
To use the -l flag with ls, use this command:

ls -l

Note that the listing includes the same files as before, but with additional information about each file.

As mentioned earlier, options can often be grouped together. If you want to use the -l and -a option together, you could run ls -l -a, or just combine them like in this command:

ls -la

Note that the listing includes the hidden . and .. directories in the listing, because of the -a option.

With Options and Arguments

Options and arguments can almost always be combined, when running commands.

For example, you could check the contents of /home, regardless of your current directory, by running this ls command:

ls -la /home

ls is the command, -la are the options, and /home is the argument that indicates which file or directory to list. This should print a detailed listing of the /home directory, which should contain the home directories of all of the normal users on the server.

Environment Variables

Environment variables are named values that are used to change how commands and processes are executed. When you first log in to a server, several environment variables will be set according to a few configuration files by default.

View All Environment Variables

To view all of the environment variables that are set for a particular terminal session, run the env command:

env

There will likely be a lot of output, but try and look for PATH entry:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

The PATH environment variable is a colon-delimited list of directories where the shell will look for executable programs or scripts when a command is issued. For example, the env command is located in /usr/bin, and we are able to execute it without specifying its fully-qualified location because its path is in the PATH environment variable.

View the Value of a Variable

The value of an environment variable can be retrieved by prefixing the variable name with a $. Doing so will expand the referenced variable to its value.

For example, to print out the value of the PATH variable, you may use the echo command:

echo $PATH

Or you could use the HOME variable, which is set to your user's home directory by default, to change to your home directory like this:

cd $HOME

If you try to access an environment variable that hasn't been set, it will be expanded to nothing; an empty string.

Setting Environment Variables

Now that you know how to view your environment variables, you should learn how to set them.

To set an environment variable, all you need to do is start with a variable name, followed immediately by an = sign, followed immediately by its desired value:

VAR=value

Note that if you set an existing variable, the original value will be overwritten. If the variable did not exist in the first place, it will be created.

Bash includes a command called export which exports a variable so it will be inherited by child processes. In simple terms, this allows you to use scripts that reference an exported environment variable from your current session. If you're still unclear on what this means, don't worry about it for now.

You can also reference existing variables when setting a variable. For example, if you installed an application to /opt/app/bin, you could add that directory to the end of your PATH environment variable with this command:

export PATH=$PATH:/opt/app/bin

Now verify that /opt/app/bin has been added to the end of your PATH variable with echo:

echo $PATH

Keep in mind that setting environment variables in this way only sets them for your current session. This means if you log out or otherwise change to another session, the changes you made to the environment will not be preserved. There is a way to permanently change environment variables, but this will be covered in a later tutorial.

Continue reading

LPI Certifications

LPI Linux Essentials

◈ What: Ability to use basic console line editor and demonstrate an understanding of processes, programs and components of the Linux Operating System.

◈ How: Pass the LPI 010 exam; 40 multiple-choice questions in 60 minutes.

◈ Cost: $110 USD (1 exam, certificate does not expire). Price may vary per region. Learn More

LPIC-OT 701: DevOps Tools Engineer

◈ What: Have a working knowledge of DevOps-related domains such as Software Engineering and Architecture, Container and Machine Deployment, Configuration Management and Monitoring.

◈ How: Pass LPI 701 exam; 60 multiple-choice and fill-in-the-blank questions in 90 minutes.

◈ Cost: $200 USD (1 exam, certification valid for 5 years). Price may vary per region. Learn More

LPIC-1 Certified Linux Administrator

◈ What: Ability to perform maintenance tasks with the command line, install and configure a computer running Linux and be able to configure basic networking.

◈ How: Pass LPI 101 and 102 exams; each exam is 60 multiple-choice and fill-in-the-blank questions in 90 minutes.

◈ Cost: $200 USD per exam (2 exams, certification valid for 5 years). Price may vary per region. Learn More

LPIC-2 Certified Linux Engineer

◈ What: Ability to administer small to medium–sized mixed networks.

◈ How: Pass LPI 201 and 202 exams; each exam is 60 multiple-choice and fill-in-the-blank questions in 90 minutes. Must also have active LPIC-1 certification.

◈ Cost: $200 USD per exam (2 exams, certification valid for 5 years). Price may vary per region. Learn More

LPIC-3 300: Linux Enterprise Professional Mixed Environment

◈ What: Ability to integrate Linux services in an enterprise-wide mixed environment.

◈ How: Pass LPI 300 exam; 60 multiple-choice and fill-in-the-blank questions in 90 minutes. Must also have active LPIC-2 certification.

◈ Cost: $200 USD (1 exam, certification valid for 5 years). Price may vary per region. Learn More

LPIC-3 303: Linux Enterprise Professional Security

◈ What: Ability to secure and harden Linux-based servers, services and networks enterprise-wide.

◈ How: Pass LPI 303 exam; 60 multiple-choice and fill-in-the-blank questions in 90 minutes. Must also have active LPIC-2 certification.

◈ Cost: $200 USD (1 exam, certification valid for 5 years). Price may vary per region. Learn More

LPIC-3 304: Linux Enterprise Professional Virtualization and High Availability

◈ What: Ability to plan and implement enterprise-wide virtualization and high availability setups using Linux-based technologies.

◈ How: Pass LPI 304 exam; 60 multiple-choice and fill-in-the-blank questions in 90 minutes. Must also have active LPIC-2 certification.

◈ Cost: $200 USD (1 exam, certification valid for 5 years). Price may vary per region. Learn More

Continue reading