Binary Tree Basics

LHR -> Left, Head, Right

A Simple example of a Binary Tree with LHR.

Assume that we have some values that are stored in the Binary Tree.  let's look at how we can traverse.

with LHR.

What's happening here? Dont get confused. It's simple LHR. Every node has three-pointers to it. those are LHR. you might already thought about it. yeah, it looks like a double-linked list. but it's not.

Let's go with another example.

with LHR we have two subtrees in data structure.

Left Subtree
L -> 1, 5, 6 

Root Node
H-> 7 

Right Subtree
R-> 8, 9, 10

Then the traverse will be 1, 5, 6, 7, 8, 9, 10

Depth and Height of a tree in terms of a node.

H denotes the Height of the tree

D denotes the Depth of the tree

As an example, the Root node has a Depth of 2 and a Height of 0

Successor.
with the understanding of traversing of the binary tree which is the successor of 7.
it's 8.

Predecessor.

with the understanding of traversing of the binary tree which is the predecessor of 7.
it's 6.

Every subtree ends with a right node while traversing.
in over case left subtree, it ends with 6.
and the right subtree, it starts with 8.

REMEMBER ITS NOT ARRAY.
for better understanding, we are writing down the traverse path in comma-separate.

the data is not stored sequentially, it's stored in a tree structure.

Delete a leaf node.
Simply detach the leaf node from its successor node.
for example. if we delete 1 from the structure. it will detach node from 5.

After deleting the node from the tree structure.
The traverse will be 5, 6, 7, 8, 9, 10.

Delete a Root node.
its little tricky if you delete the root node. 

In case if we have right side node.
We have to replace root node with its immediate successor. in our case 
replace 7 with 8
then delete 8;

After deleting the node from the tree structure.
Traverse will be 1, 5, 6, 7, 9, 10

else if its left sided tree.
then delete 7 there is no need of replacement.

Top 5 Linux Penetration Testing Distributions

Linux penetration testing distributions are useful and versatile tools that can help you to get the most out of your Linux system while simultaneously avoiding the malicious threats of the internet. Of course, the reason for using a Linux pen testing distribution may seem obvious to anyone who understands what penetration testing is or performs security auditing professionally, it’s often less clear to people outside of the security industry that a wealth of open source tools exist to help them perform there own security testing.

As usual with Linux there is plenty of choice! With plenty of penetration testing distributions out there to choose from, this can prove challenging for beginners or people who are from outside the security industry. Overall the standard of Linux distros has increased over the years, in the beginning these distros were essentially Linux live cd’s with scripts / precompiled binaries dropped in a directory. Today distros like Kali are setting the standard, all scripts and tools are packaged and updated using the Debian distributions package manager. 

However, with great choice, comes a great level of… indecisiveness :)

Narrowing down your decision and uncovering the best distro for the job can present some real difficulties.

Fortunately, we’re here to help. In this list, we've compiled what we believe to be some of the best options available today to help you get the most out of your security auditing.

Linux penetration testing distributions are useful and versatile tools that can help you to get the most out of your Linux system while simultaneously avoiding the malicious threats of the internet. Of course, the reason for using a Linux pen testing distribution may seem obvious to anyone who understands what penetration testing is or performs security auditing professionally, it’s often less clear to people outside of the security industry that a wealth of open source tools exist to help them perform there own security testing.

As usual with Linux there is plenty of choice! With plenty of penetration testing distributions out there to choose from, this can prove challenging for beginners or people who are from outside the security industry. Overall the standard of Linux distros has increased over the years, in the beginning these distros were essentially Linux live cd’s with scripts / precompiled binaries dropped in a directory. Today distros like Kali are setting the standard, all scripts and tools are packaged and updated using the Debian distributions package manager. 

However, with great choice, comes a great level of… indecisiveness :)

Narrowing down your decision and uncovering the best distro for the job can present some real difficulties.

Fortunately, we’re here to help. In this list, we've compiled what we believe to be some of the best options available today to help you get the most out of your security auditing.

Kali Linux (Authors Choice)

Developed by Offensive Security, Kali Linux is the rewrite of BackTrack and has certainly earned its place at the top of our list for its incredible capabilities as an operating system to aid in hacking purposes. This OS is a Debian-based system that features over 500

Pen testing applications and tools already installed. This gives you an impressive start on your security toolbox and leaves little room for you to want more. The flexible tools it comes with are updated on a regular basis, metasploit framework is a packaged install and kept up to date by Rapid7 directly. Kali supports many different platforms, including VMware and ARM. Additionally, Kali Linux is also a workable solution for computer forensics, as it includes a live boot feature that offers the ideal environment to detect vulnerabilities and take care of them appropriately.

In addition, Kali Linux has also just released a new version—of which we’re thoroughly impressed, and think you will be too. Kali Linux 2017.1 brings new exciting features and updates in comparison to older versions and other options. Updated packages, better and increased hardware support, and countless updated tools. If you want to be completely up-to-date and have the best of the best in terms of your Linux penetration testing distro, then you might like Kali Linux’s new release as much as we do.

Parrot Security OS

Parrot Security OS is another one of our top choices when it comes to selecting the right Linux penetration testing distribution for your needs. Like Kali Linux, it's another Debian-based OS option that packs a lot into its programming. Developed by the team at Frozenbox’s, Parrot Security is an option that’s cloud-friendly. The operating system is designed to specialize in ethical hacking, computer forensics, pen testing, cryptography, and more. Compared to other OS options on the market for these purposes, Parrot Security OS is a lightweight operating system that offers the utmost efficiency to users.

Parrot Security OS is the ideal blend of the best of Frozenbox OS and Kali Linux. Moreover, this incredibly customizable operating system is ideal for hacking and comes with a strong support community. If you run into trouble, this is one of the most user-friendly options when it comes to finding a right solution to get the OS to help you accomplish your goals.

Backbox

Backbox is our favorite Linux operating system for penetration testing that is not Debian-based. This is an Ubuntu-based operating system ideal for assessing the security of your computer and conducting penetration testing. Backbox Linux comes with a wide array of options in the way of security analysis tools, which can be applied for analysis of web applications, networks, and more. As a fast, easy to use, and efficient operating system, Backbox Linux is famous in the hacker’s community. The OS includes a complete desktop environment with software applications that are updated on a regular basis, always keeping you up to date and supplied with the most stable versions of all your most important programs.

If you are big on penetration testing and security assessment, then you will be happy to hear that these are exactly the things that Backbox’s OS specializes in. As one of the best distro in its field, Backbox always has its sights set on the best known ethical hacking tools and is always providing users with the latest stable versions available of an impressive array of tools for network analysis. The interface is designed with the goal of minimalism, and utilizes a XFCE environment for its desktop. The result is an effective, fast, customizable, comprehensive user experience with a helpful support community to back it.

BlackArch

If you are an ethical hacker or a researcher looking for a complete Linux distribution to cater to all your needs, then BlackArch Linux just might be the penetration testing distribution you want to set your sights on. The design was originally derived from Arch Linux, and users also have the option and capability to install the BlackArch Linux components over the top of it.

BlackArch, as an operating system, offers users over 1400 tools to use that are thoroughly tested prior to being added to the OS’s arsenal of tools and codebase. In addition, the developers are in a constant process of increasing the system’s capabilities, which is giving it a reputation that allows it to sit at the cool kid’s table of operating systems for hacking purposes. Even more good news about this distro? The list of tools groups, and tools contained within those groups, is constantly growing. Not only that, but if you are already a user of Arch Linux, you can set up the BlackArch tools collection on top of it to get the most out of your OS.

Fedora Security Spin

Fedora Security Spin was designed to be a variation of Fedora that is designed specifically for security testing and auditing. In addition, it can also be used for the purposes of teaching. This distro is designed to provide students and teachers alike with the support they need during learning or practicing security methodologies involving web application security, information security, forensics analysis, and more.

This just goes to show that not all Linux penetration testing distributions are made equal and there’s no one-size-fits-all answer when it comes to determining the best one on the market. If you’re more into the ethical hacking side of things, then you may find that Kali Linux or Parrot Security OS is more your style. However, if you are teaching others or still in the process of learning, or if you are more interested in forensics analysis than hacking, then you can’t go wrong with Fedora Security Spin.

The Verdict

We know there are plenty of options for you to choose from when it comes to choosing the best Linux penetration testing distributions. While this is by no means a comprehensive list and there are plenty of other admirable programs out there worthy of a shout out—Pentoo, Weakerth4n, and Matriux, to name a few—these are our favorites distros available today. After thorough trial and testing, although the list of operating systems worth their salt goes on and on, they are certainly not all made equal.

If you’re looking for the best of the best in terms of your penetration testing distro for your Linux system, you can’t go wrong with any of the top 5 we’ve included on our list. To narrow down your choice to the one and only match made in heaven that’s right for you, we recommend asking yourself the following questions:

• What do I want to accomplish with a penetration testing distro?
• What features do I need from a penetration testing distro to help me accomplish my goals?

Whether you are an aspiring information security expert, have already earned that title, or if you’re just looking to delve into the field to see what it can do, finding a decent Linux operating system that complements your goals is a necessity. Depending on your purposes, there are countless options for you to choose from, which is why it’s important to keep your goals in mind and narrow your options to those that will be able to help you accomplish your purposes.

The list we’ve compiled here, however, has something for everyone. Regardless of what you’re looking for, we’re confident that you will be able to find one that suits your needs. After a bit of research on each, you should find that one is standing out from the crowd in no time—and that will likely be your ideal Linux penetration testing distribution. 

Linux File Permissions

Although there are already a lot of good security features built into Linux-based systems, one very important potential vulnerability can exist when local access is granted - - that is file permission based issues resulting from a user not assigning the correct permissions to files and directories. So based upon the need for proper permissions, I will go over the ways to assign permissions and show you some examples where modification may be necessary.

Basic File Permissions

Permission Groups

Each file and directory has three user based permission groups:

• owner - The Owner permissions apply only the owner of the file or directory, they will not impact the actions of other users.
• group - The Group permissions apply only to the group that has been assigned to the file or directory, they will not effect the actions of other users.
• all users - The All Users permissions apply to all other users on the system, this is the permission group that you want to watch the most.

Permission Types

Each file or directory has three basic permission types:

• read - The Read permission refers to a user's capability to read the contents of the file.
• write - The Write permissions refer to a user's capability to write or modify a file or directory.
• execute - The Execute permission affects a user's capability to execute a file or view the contents of a directory.

Viewing the Permissions

You can view the permissions by checking the file or directory permissions in your favorite GUI File Manager (which I will not cover here) or by reviewing the output of the \"ls -l\" command while in the terminal and while working in the directory which contains the file or folder.

The permission in the command line is displayed as: _rwxrwxrwx 1 owner:group

1. User rights/Permissions
   1. The first character that I marked with an underscore is the special permission flag that can vary.
   2. The following set of three characters (rwx) is for the owner permissions.
   3. The second set of three characters (rwx) is for the Group permissions.
   4. The third set of three characters (rwx) is for the All Users permissions.
2. Following that grouping since the integer/number displays the number of hardlinks to the file.
3. The last piece is the Owner and Group assignment formatted as Owner:Group.

Modifying the Permissions

When in the command line, the permissions are edited by using the command chmod. You can assign the permissions explicitly or by using a binary reference as described below.

Explicitly Defining Permissions

To explicity define permissions you will need to reference the Permission Group and Permission Types.

The Permission Groups used are:

u - Owner

g - Group

o - Others

a - All users

The potential Assignment Operators are + (plus) and - (minus); these are used to tell the system whether to add or remove the specific permissions.

The Permission Types that are used are:

• r - Read
• w - Write
• x - Execute

So for an example, lets say I have a file named file1 that currently has the permissions set to _rw_rw_rw, which means that the owner, group and all users have read and write permission. Now we want to remove the read and write permissions from the all users group.

To make this modification you would invoke the command: chmod a-rw file1
To add the permissions above you would invoke the command: chmod a+rw file1

As you can see, if you want to grant those permissions you would change the minus character to a plus to add those permissions.

Using Binary References to Set permissions

Now that you understand the permissions groups and types this one should feel natural. To set the permission using binary references you must first understand that the input is done by entering three integers/numbers.

A sample permission string would be chmod 640 file1, which means that the owner has read and write permissions, the group has read permissions, and all other user have no rights to the file.

The first number represents the Owner permission; the second represents the Group permissions; and the last number represents the permissions for all other users. The numbers are a binary representation of the rwx string.

• r = 4
• w = 2
• x = 1

You add the numbers to get the integer/number representing the permissions you wish to set. You will need to include the binary permissions for each of the three permission groups.

So to set a file to permissions on file1 to read _rwxr_____, you would enter chmod 740 file1.

Owners and Groups

I have made several references to Owners and Groups above, but have not yet told you how to assign or change the Owner and Group assigned to a file or directory.

You use the chown command to change owner and group assignments, the syntax is simplechown owner:group filename, so to change the owner of file1 to user1 and the group to family you would enter chown user1:family file1.

Advanced Permissions

The special permissions flag can be marked with any of the following:

• _ - no special permissions
• d - directory
• l- The file or directory is a symbolic link
• s - This indicated the setuid/setgid permissions. This is not set displayed in the special permission part of the permissions display, but is represented as a s in the read portion of the owner or group permissions.
• t - This indicates the sticky bit permissions. This is not set displayed in the special permission part of the permissions display, but is represented as a t in the executable portion of the all users permissions

Setuid/Setgid Special Permissions

The setuid/setguid permissions are used to tell the system to run an executable as the owner with the owner\'s permissions.

Be careful using setuid/setgid bits in permissions. If you incorrectly assign permissions to a file owned by root with the setuid/setgid bit set, then you can open your system to intrusion.

You can only assign the setuid/setgid bit by explicitly defining permissions. The character for the setuid/setguid bit is s.

So do set the setuid/setguid bit on file2.sh you would issue the command chmod g+s file2.sh.

Sticky Bit Special Permissions

The sticky bit can be very useful in shared environment because when it has been assigned to the permissions on a directory it sets it so only file owner can rename or delete the said file.

You can only assign the sticky bit by explicitly defining permissions. The character for the sticky bit is t.

To set the sticky bit on a directory named dir1 you would issue the command chmod +t dir1.

When Permissions Are Important

To some users of Mac- or Windows-based computers you don't think about permissions, but those environments don't focus so aggressively on user based rights on files unless you are in a corporate environment. But now you are running a Linux-based system and permission based security is simplified and can be easily used to restrict access as you please.

So I will show you some documents and folders that you want to focus on and show you how the optimal permissions should be set.

• home directories- The users\' home directories are important because you do not want other users to be able to view and modify the files in another user\'s documents of desktop. To remedy this you will want the directory to have the drwx______ (700)permissions, so lets say we want to enforce the correct permissions on the user user1\'s home directory that can be done by issuing the command chmod 700 /home/user1.
• bootloader configuration files- If you decide to implement password to boot specific operating systems then you will want to remove read and write permissions from the configuration file from all users but root. To do you can change the permissions of the file to 700.
• system and daemon configuration files- It is very important to restrict rights to system and daemon configuration files to restrict users from editing the contents, it may not be advisable to restrict read permissions, but restricting write permissions is a must. In these cases it may be best to modify the rights to 644.
• firewall scripts - It may not always be necessary to block all users from reading the firewall file, but it is advisable to restrict the users from writing to the file. In this case the firewall script is run by the root user automatically on boot, so all other users need no rights, so you can assign the 700 permissions.

Other examples can be given, but this article is already very lengthy, so if you want to share other examples of needed restrictions please do so in the comments.

Comments Welcome

If you have anything to add or want to make a comment or correction please do so in the comments. I look forward to your feedback and wish you the best in your future with Linux-based systems.

Economic survey of India

From Wikipedia, the free encyclopedia

The Department of Economic Affairs, Finance Ministry of India presents the Economic Survey in the parliament every year, just before the Union Budget.It is prepared under the guidance of the Chief Economic Adviser, Finance Ministry. It is the ministry's view on the annual economic development of the country. A flagship annual document of the Ministry of Finance, Government of India, Economic Survey reviews the developments in the Indian economy over the previous 12 months, summarizes the performance on major development programs, and highlights the policy initiatives of the government and the prospects of the economy in the short to medium term. This document is presented to both houses of Parliament during the Budget Session.The Economic survey of India 2014-15 said India could target foreign exchange reserves of $750 billion-$1 trillion.^[1]

Unlike the traditional Economic Survey, the Economic survey of 2016-17 doesn't have the detailed financial statistics of the government of India.These will be released later in 2017.

• Economic Survey 2008-2009
• Economic Survey 2009-2010
• Economic Survey 2010-2011
• Economic Survey of India 2012-13
• Economic Survey 2014-2015
• Economic Survey Volume-I 2015-2016
• Economic Survey Volume-II 2015-2016
• Economic Survey of India 2016-17

Linux Package Management

Linux Package Management

Many tutorials reference “package managers” and “package management tools.” If you are new to the Linux world and don’t understand the purpose of these technologies, or if you are familiar with one package management tool but want to learn how to use another, this guide will provide an introduction to the major package management tools.

Package Management Concepts

Contemporary distributions of Linux-based operating systems install software in pre-compiled packages, which are archives that contain binaries of software, configuration files, and information about dependencies. Furthermore, package management tools keep track of updates and upgrades so that the user doesn’t have to hunt down information about bug and security fixes.

Without package management, users must ensure that all of the required dependencies for a piece of software are installed and up-to-date, compile the software from the source code (which takes time and introduces compiler-based variations from system to system), and manage configuration for each piece of software. Without package management, application files are located in the standard locations for the system to which the developers are accustomed, regardless of which system they’re using.

Package management systems attempt to solve these problems and are the tools through which developers attempt to increase the overall quality and coherence of a Linux-based operating system. The features that most package management applications provide are:

• Package downloading: Operating-system projects provide package repositories which allow users to download their packages from a single, trusted provider. When you download from a package manager, the software can be authenticated and will remain in the repository even if the original source becomes unreliable.
• Dependency resolution: Packages contain metadata which provides information about what other files are required by each respective package. This allows applications and their dependencies to be installed with one command, and for programs to rely on common, shared libraries, reducing bulk and allowing the operating system to manage updates to the packages.
• A standard binary package format: Packages are uniformly prepared across the system to make installation easier. While some distributions share formats, compatibility issues between similarly formatted packages for different operating systems can occur.
• Common installation and configuration locations: Linux distribution developers often have conventions for how applications are configured and the layout of files in the /etc/ and /etc/init.d/ directories; by using packages, distributions are able to enforce a single standard.
• Additional system-related configuration and functionality: Occasionally, operating system developers will develop patches and helper scripts for their software which get distributed within the packages. These modifications can have a significant impact on user experience.
• Quality control: Operating-system developers use the packaging process to test and ensure that the software is stable and free of bugs that might affect product quality and that the software doesn’t cause the system to become unstable. The subjective judgments and community standards that guide packaging and package management also guide the “feel” and “stability” of a given system.

In general, we recommend that you install the versions of software available in your distribution’s repository and packaged for your operating system. If packages for the application or software that you need to install aren’t available, we recommend that you find packages for your operating system, when available, before installing from source code.

The remainder of this guide will cover how to use specific package management systems and how to compile and package software yourself.

Debian and Ubuntu Package Management

The Debian package management system, based on a tool called dpkg with the very popular aptsystem, is a powerful, popular, and useful method of package management. In addition to Debian, a number of other prominent distributions of GNU/Linux are derived from the Debian system, most notably the Ubuntu family of distributions.

As a result, these instructions apply to Debian and Ubuntu systems. While Debian and derived systems are not necessarily binary-compatible, .debs packaged for Debian are often compatible with Ubuntu (though this is not a supported workflow).

Advanced Packaging Tool (APT)

You may already be familiar with apt-get, a command which uses the advanced packaging tool to interact with the operating system’s package system. The most relevant and useful commands are (to be run with root privileges):

• apt-get install package-name(s) - Installs the package(s) specified, along with any dependencies.
• apt-get remove package-name(s) - Removes the package(s) specified, but does not remove dependencies.
• apt-get autoremove - Removes any orphaned dependencies, meaning those that remain installed but are no longer required.
• apt-get clean - Removes downloaded package files (.deb) for software that is already installed.
• apt-get purge package-name(s) - Combines the functions of remove and clean for a specific package, as well as configuration files.
• apt-get update - Reads the /etc/apt/sources.list file and updates the system’s database of packages available for installation. Run this after changing sources.list.
• apt-get upgrade - Upgrades all packages if there are updates available. Run this after running apt-get update.

While apt-get provides the most often-used functionality, APT provides additional information in the apt-cache command.

• apt-cache search package-name(s) - If you know the name of a piece of software but apt-get install fails or points to the wrong software, this looks for other possible names.
• apt-cache show package-name(s) - Shows dependency information, version numbers and a basic description of the package.
• apt-cache depends package-name(s) - Lists the packages that the specified packages depends upon in a tree. These are the packages that will be installed with the apt-get installcommand.
• apt-cache rdepends package-name(s) - Outputs a list of packages that that depend upon the specified package. This list can often be rather long, so it is best to pipe its output through a command, like less.
• apt-cache pkgnames - Generates a list of the currently installed packages on your system. This list is often rather long, so it is best to pipe its output through a program, like less, or direct the output to a text file.

Combining most of these commands with apt-cache show can provide you with a lot of useful information about your system, the software that you might want to install, and the software that you have already installed. If you’re overwhelmed by apt-cache check out the following resources for easy-to-read lists of available packages:

• The Debian Package Directory
• The Ubuntu Package Directory

Aptitude

Aptitude is another front-end interface for APT. In addition to a graphical interface, Aptitude provides a combined command-line interface for most APT functionality. Some notable commands are:

• aptitude update, aptitude install, aptitude remove, aptitude clean, or aptitude purge - Same as their apt-get counterparts.
• aptitude search or aptitude show, - Same as their apt-cache counterparts.
• aptitude download - Downloads a .deb file for a given package into the current directory.

Aptitude also includes safe upgrading, meaning it doesn’t remove existing packages, as well as holding, which prevents the system from upgrading specific packages.

/etc/apt/sources.list

The file /etc/apt/sources.list controls repositories from which APT constructs its database. This file contains lines in the following format:

1	deb location-of-resources distribution component(s)

Here are some examples:

1 2	deb http://mirrors.linode.com/debian/ jessie main contrib deb http://www.deb-multimedia.org jessie main non-free

The first line specifies the Linode mirror for the the Debian 8 (code named Jessie) Linux distribution, as well as the main and contributed components. The next line specifies the deb-multimedia.org repository for Jessie, which provides some multimedia packages unavailable in the main repositories for licensing reasons, and its main and non-free components.

In general, one does not want to add new entries to sources.list without a lot of scrutiny and diligence, as updating the package cache with additional repositories and running upgrades can sometimes result in the installation of broken packages, unmet dependencies, and system instability. In Debian systems, downgrading is often difficult.

For Debian systems, the repository names can either refer to the distribution code name (e.g., jessie for current-stable, stretch for testing, sid for unstable, wheezy for old-stable) or to a specific branch (e.g., oldstable, stable, testing, unstable). For more information about Debian versions and choosing a Debian version or branch, read the Debian releases and branches page.

The component section of the line divides the repository based on how much support the developers of the operating system are able to offer for the contained packages (e.g. main vs. contrib), or if the software is considered “free-software” or simply freely-distributable (e.g., non-free).

The layout of sources.list is a bit different in Ubuntu systems. The lines are in the same format but the names of the distributions and components are different:

• Ubuntu versions have a different naming scheme. Version 14.04 is named “trusty” in sources.list, 15.10 is “wily,” and 16.04 is “xenial.” These names follow an alphabetical pattern.
• Ubuntu components are: “main” and “restricted” for supported free and non-free packages; “universe” and “multiverse” for unsupported free and non-free software.

Using dpkg

Apt-get and apt-cache are merely frontend programs that provide a more usable interface and connections to repositories for the underlying package management tools called dpkg and debconf. These tools are quite powerful, and fully explaining their functionality is beyond the scope of this document. However, a basic understanding of how to use these tools is useful. Some important commands are:

• dpkg -i package-file-name.deb - Installs a .deb file.
• dpkg --list search-pattern - Lists packages currently installed on the system.
• dpkg --configure package-name(s) - Runs a configuration interface to set up a package.
• dpkg-reconfigure package-name(s) - Runs a configuration interface on an already installed package.

For information about building your own packages, refer to the Debian New Maintainers Guide.

Fedora and CentOS Package Management

Fedora and CentOS are closely related distributions, being upstream and downstream (respectively) from Red Hat Enterprise Linux (RHEL). Their main differences stem from how packages are chosen for inclusion in their repositories.

CentOS uses yum, Yellowdog Updater, Modified, as a front end to interact with system repositories and install dependencies, and also includes a lower-level tool called rpm, which allows you to interact with individual packages.

Starting with version 22, Fedora uses the dnf package manager instead of YUM to interact with rpm. DNF supports many of the same commands as YUM, with some slight changes.

Note: Many operating systems aside from RedHat use rpm packages. These include OpenSuSE, AIX, and Mandriva. While it may be possible to install an RPM packaged for one operating system on another, this is not supported or recommended, and the results of this action can vary greatly.

Yellow Dog Updater, Modified (YUM)

The YUM tool was developed for the Yellow Dog Linux system as a replacement for the Yellow Dog Updater (YUP). RedHat found the YUM tool to be a valuable addition to their systems. Today, YUM is the default package and repository management tool for a number of operating systems.

You can use the following commands to interact with YUM:

• yum install package-name(s) - Installs the specified package(s) along with any required dependencies.
• yum erase package-name(s) - Removes the specified package(s) from your system.
• yum search search-pattern - Searches the list of package names and descriptions for packages that match the search pattern and provides a list of package names, with architectures and a brief description of the package contents. Note that regular expression searches are not permitted.
• yum deplist package-name(s) - Lists all of the libraries and modules that the named package depends on, along with the names of the packages (including versions) that provide those dependencies.
• yum check-update - Refreshes the local cache of the yum database so that dependency information and the latest packages are always up to date.
• yum info package-name(s) - The results of the info command provides the name, description of the package, as well as a link to the upstream home page for the software, release versions and the installed size of the software.
• yum reinstall package-name(s) - Erases and then downloads a new copy of the package file and re-installs the software on your system.
• yum localinstall local-rpm-file - Checks the dependencies of a local .rpm file and then installs it.
• yum update optional-package-name(s) - Downloads and installs all updates including bug fixes, security releases, and upgrades, as provided by the distributors of your operating system. Note that you can specify package names with the update command.
• yum upgrade - Upgrades all packages installed in your system to the latest release.

/etc/yum.conf

The file located at /etc/yum.conf provides system-wide configuration options for YUM, as well as information about repositories. Repository information may also be located in files ending in .repounder /etc/yum.repos.d.

The options in the [main] stanza don’t need modification, though you may set alternate logging and cache locations for the database by adding the following lines:

/etc/yum.conf

1 2	logfile=/var/log/yum.log cachedir=/var/cache/yum

Dandified YUM (DNF)

DNF is the modern extension of the YUM package manager. It retains much of the same command usage and functionality as YUM, with a number of improvements for newer operating systems. DNF was first introduced in Fedora 18 and became the default package manager with the release of Fedora 22.

• dnf install package-name(s) - Installs the specified package(s) along with any required dependencies. dnf install can also accept .rpm files in place of a package name, to install directly from a downloaded RPM.
• dnf remove package-name(s) - Removes the specified package(s) from your system, along with any package(s) that depend upon them.
• dnf search search-pattern - Searches the list of package names and descriptions for packages that match the search pattern and provides a list of package names, with architectures and a brief description of the package contents. Note that regular expression searches are not permitted.
• dnf provides package-name(s) - Lists all of the libraries and modules that the named package depends on, along with the names of the packages (including versions) that provide those dependencies.
• dnf check-update - Refreshes the local cache of the DNF database so that dependency information and the latest packages are always up to date.
• dnf info package-name(s) - Provides the name and description of the package as well as a link to the upstream home page for the software, release versions, and the installed size of the software.
• dnf reinstall package-name(s) - Erases and then downloads a new copy of the package file and re-installs the software on your system.
• dnf upgrade optional-package-name(s) - Downloads and installs all updates including bug fixes, security releases, and upgrades for a specific package.
• dnf upgrade - With no arguments, upgrade upgrades all packages installed in your system to the latest release.
• dnf config-manager --add-repo example.repo Adds a .repo file as a DNF repository.
• dnf config-manager --set-enabled example-repo Enables a DNF repository.
• dnf config-manager --set-disabled example-repo Disables a DNF repository.

/etc/dnf/dnf.conf

The dnf.conf file provides global configuration settings for DNF. If DNF .repo files are being added manually, instead of with dnf config-manager, they should be added to /etc/yum.repos.d.

RPM Package Manager (RPM)

YUM and DNF are simply front-ends to a lower-level tool called RPM, similar to apt-get’s relationship with dpkg. You will likely not need to interact with RPM very often, but there are a few commands that you may find useful.

The following commands should be run as root. The flags are expanded here, but the abbreviated syntax is also included:

• rpm --install --verbose --hash local-rpm-file-name.rpm or rpm -ivh filename.rpm - Installs an rpm from the file. rpm is also capable of installing RPM files from http and ftp sources as well as local files.
• rpm --erase package-name(s) or rpm -e - Removes the given package. Usually will not complete if package-name matches more than one package, but will remove more than one match if used with the --allmatches flag.
• rpm --query --all or rpm -qa - lists the name of all packages currently installed.
• rpm --query package-name(s) or rpm -q - allows you to confirm whether a given package is installed in your system.
• rpm --query --info package-name(s) or rpm -qi - displays the information about an installed package.
• rpm --query --list package-name(s) or rpm -ql - generates a list of files installed by a given package. This is complemented by:
• rpm --query --file or rpm -q qf filename - checks to see what installed package “owns” a given file.

Note that RPM does not automatically check for dependencies, so you must install them manually. For more information please consult these external sources:

• iDevelopment Info - RPM Commands
• Quick Guide to RPM

You can use the following template to define a new stanza for a new repository, replacing the capitalized strings with your own values:

/etc/yum.repos.d/example.repo

1 2 3 4 5 6

[REPO-NAME] name=REPOSITORY-NAME mirrorlist=HTTP-ACCESSIBLE-MIRROR-LIST #baseurl=BASE-URL-FOR-REPOSITORY gpgcheck=BOOLEAN-VALUE-TO-VERIFY-REPOSITORY gpgkey=FILE-PATH-TO-GPG-KEY

The following example is the default configuration for the “Base” repository in CentOS 7:

/etc/yum.repos.d/CentOS-Base.repo

1 2 3 4 5 6

[base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

Slackware Package Management

Credit: This section was kindly provided by JK Wood.

Packages in Slackware Linux are distributed as compressed tarballs, generally using gzip or lzma compression. These tarballs can be recognized by their suffixes, .tgz or .txz. This format includes a complete filesystem layout, as well as additional scripts to be run upon installation or removal of the software. Slackware packages do not offer dependency resolution information; this is generally viewed as allowing more flexibility and control.

Packages can also be built using SlackBuilds, shell scripts that compile source or repackage binary distribution packages for easy installation and removal on Slackware. These scripts have been adopted as a community standard by such sites as SlackBuilds.org, which provides many common third-party packages not available in Slackware proper.

Slackware includes pkgtool for local package management and slackpkg for remote installation of packages from official mirrors. For less interactive tasks, there are installpkg, upgradepkg, and removepkg.

Working With Packages Locally

The pkgtool program offers the ability to manage packages on the local system through a text-based menu interface. Each option is self-explanatory, from installing packages from the Current or an Other directory, to Removing installed packages, Viewing a list of files in a package, and running Slackware Setup scripts.

The package installation operations offer a list of packages in a menu, with the ability to choose which packages to install and which to leave alone. The package removal option offers a similar choice, with a list of installed packages. Viewing a package can be useful to determine what is in it. This information includes a description written by the creator of the package along with the expected list of files.

The Setup scripts options do not often apply to Linode, though there is a netconfig option that may be helpful to some users.

For those seeking a command-line approach, the *pkg commands are fairly straightforward in their use.

• installpkg package-name(s) - Installs a package from the current directory, or a pathname you specify. It accepts full filenames, as well as globs such as */*.t?z for all tgz, tbz, tlz, or txz packages in all immediately adjacent directories.
• upgradepkg package-name(s) - Upgrades a package from the current directory, or a pathname you specify. If also accepts full filenames and globs like installpkg. Note that the --install-new flag can be passed to allow upgradepkg to operate like installpkg on packages that are not currently installed on the system.
• removepkg package-name(s) - Removes a package from the system. This command does not require a full filename, but can often operate with only the software name associated with the package.

Working With Packages Remotely

The slackpkg program is a recent addition to Slackware that allows official Slackware packages to be installed and upgraded using a remote FTP or HTTP mirror. Before using Slackpkg, a mirror should be set in /etc/slackpkg/mirrors, and can be added or selected from the available list. Only one mirror can ever be active, and is chosen by uncommenting it (deleting the initial #).

While slackpkg offers a menu-based interface, it can also be run in a console-only mode by setting DIALOG=off in /etc/slackpkg/slackpkg.conf.

• slackpkg check-updates - Checks for new entries to the changelog on the remote mirror. This can be useful in a cron script to notify the system administrator of new patches.
• slackpkg update - Downloads updates to the Slackware changelog and file lists. This check is useful for finding security updates, and must be run before attempting to download updated software.
• slackpkg install-new - Looks for new packages. While rarely useful on a static release, this command should be run before others on machines running the current development release or when upgrading to a new release.
• slackpkg install package-name(s) - Looks for any packages matching the name given, and presents the user with a menu allowing the choice of installation. Note that all commands accepting a package name will also work with Slackware installation series, such as ap, d, or xap.
• slackpkg upgrade-all - Presents the user with a menu listing all packages on the remote mirror that do not match the versions currently installed on your system. While this will generally result in upgrades, outdated software can sometimes be listed as an upgrade, such as when changing to an outdated mirror, or using self-built packages to replace standard Slackware packages. One common area this occurs is using alienBOB’s multilib glibc packages on Slackware 64-bit. Upon choosing and confirmation of upgrades, the chosen packages will be downloaded and upgraded.
• slackpkg upgrade package-name(s) - Searches for any packages matching the name given, and presents a menu to allow upgrades.
• slackpkg clean-system - Presents a menu listing all packages on the local system that are not present on upstream mirrors. This includes self-built packages, packages installed from a third-party source, and packages that were once included in Slackware, but have since been removed.
• slackpkg remove package-name(s) - Attempts to find any installed packages matching the name given, and presents the user with a menu allowing the choice of removal.
• slackpkg reinstall package-name(s) - Reinstalls the given package. This is useful if certain files in that package have been corrupted.
• slackpkg search package-name(s) - Searches for the given package name, and displays matching packages as well as installation status.
• slackpkg file-search filename - Searches installed and remote package descriptions for the given filename, and displays matching packages as well as installation status.
• slackpkg blacklist package-name(s) - Adds the given package to the blacklist located in /etc/slackpkg/blacklist. Blacklisted packages will not be installed, upgraded, or removed by slackpkg.
• slackpkg info package-name(s) - Displays standard information about the given package.

SlackBuilds, sbopkg, and Third-Party Packages

Slackware does not offer as large a selection of official software as some other more community-oriented distributions, so it can include dubious third-party packages. For this reason, the use of third-party software repositories in Slackware is generally discouraged. Third-party package management tools such as slapt-get are also frowned upon, as they have a reputation for disrupting systems.

The Slackware community has produced SlackBuilds.org, offering SlackBuild scripts for a growing volume of third-party software. These scripts are heavily vetted for integrity and proper operation. Dependencies are noted in README files, and all builds are verified to work as advertised in a clean build environment. Local compilation also verifies that packages for your machine will work on your machine.

To facilitate the management of SlackBuilds, sbopkg.org offers sbopkg, which operates similarly to slackpkg, but works with the SlackBuilds.org repository.

The sbopkg program, like pkgtool, offers a text-based menu interface. There is also a Sync option, which ensures that you are working with the latest version of all SlackBuilds. SlackBuilds can be browsed or searched for, as can their respective Changelogs. Sbopkg offers an Updates option, which compares local versions of your packages to remote versions of the SlackBuilds. Unlike slackpkg, sbopkg will not overwrite a newer package than what’s on the server by default. In addition, sbopkg offers the ability to manage the order in which SlackBuilds are built using a queue system, and allows the user to make changes to the SlackBuild locally. You can also view which SlackBuilds packages are installed, choose a different repository version to work with, or look for updates to sbopkg itself.

Package Management in Arch Linux with Pacman

Arch Linux uses binary packages in a .tar.xz format, and also provides a “ports” build system that facilitates building packages.

Arch Linux runs on a rolling release schedule, which means packages are added to the main repository when they (and their dependencies) are ready for production. This means that there aren’t release versions of Arch, as all systems, once upgraded, are equivalent.

Therefore, administrators of Arch Linux must consider the output of pacman carefully before agreeing to upgrade or update any packages.

Pacman

The pacman tool is very powerful, but it is also very simple. There are three core commands for basic package management:

• pacman --query package-name(s) or pacman -Q - Searches the package database for a package name and version number.
• pacman --sync package-name(s) or pacman -S - Installs new packages, downloads new content for the database and/or upgrades the system, depending on the options and the named package or packages.
• pacman --remove package-name(s) or pacman -R - Removes the named package or packages.

Note that the terse flags are all uppercase and case-sensitive. These terse flags are often combined with additional flags for additional functionality. Here are some examples with brief descriptions:

• pacman -Qi package-name(s) - Displays information about a given package, including dependency information, the date of the package, a link to the upstream source and other useful information.
• pacman -Qo filename - Outputs the version number and name of the package that “owns” a given file.
• pacman -Qs package-name(s) - Searches among the installed packages for a given package.
• pacman -Qu - Lists out-of-date installed packages that are in need of an update.
• pacman -Sy - Triggers a database refresh, and synchronizes the local database with the remote database.
• pacman -Su - Triggers a full system update and downloads new packages to upgrade the system. The update and refresh command can (and should) be run together, as in: pacman -Syu.
• pacman -Sc - Removes uninstalled packages from the cache and attempts to clean up old copies of the repository database.
• pacman -S --ignore package-name(s) - Ignores upgrades to a given package or list of packages.
• pacman -Rs Removes a package and its dependencies, as long as the dependencies are not needed and were not explicitly installed by the user. This command is the inverse of pacman -S.
• pacman -Ru Removes packages that are unneeded by any other packages.

Configuration Options

The configuration for pacman is defined in the /etc/pacman.conf file, while the addresses of the repository mirrors are contained in /etc/pacman.d/mirrorlist. The mirror list was created and prioritized during the installation process and you probably will not need to alter this.

The options in the stock /etc/pacman.conf are documented in comments, and are beyond the scope of this document. You may access the manual page for this configuration file with the command man pacman.conf.

While it is unlikely that you will need to modify the default pacman.conf for most installations, you can change default installation and logging directories and specify packages to be held back from upgrades.

If you need to add an additional third-party repository, add a repository stanza:

/etc/pacman.conf

1 2 3

[REPOSITORY-NAME] Server = SERVER-LOCATION Include = REPOSITORY-LIST

The Server = and Include = lines are both optional, and the order indicates their priority. By default, the testing repository is disabled, which is wise if you’re planning to use the system for production work; however, if you need bleeding-edge packages, uncomment those lines.

The Arch Build System (ABS)

The Arch Build System allows users to compile and install software not included in the Arch repository. This brief guide outlines the steps to building a package using the ABS.

All commands explained here should be run as root unless otherwise specified.

Begin by installing the abs framework and the base-devel packages:

1	pacman -Sy abs base-devel

Edit /etc/abs.conf so that the REPOS line indicates the proper repositories. Note, repositories prefixed with a bang (!) are disabled. The line might look like:

1	REPOS=(core extra community !testing)

To create a local ABS tree in /var/abs, run the the abs command as root. You may now browse /var/abs, which contains a representation of the package collection with folders representing each repository, category, and piece of software.

Arch recommends that you create a build directory at another location, such as ~/abs/, where actual building will occur.

Begin the build process by copying the files from the ABS tree into your build directory as a non-root user:

1	cp -r /var/abs/REPO/PACKAGE ~/abs

Change to the package’s directory:

1	cd ~/abs/PACKAGE

You have the option of modifying the PKGBUILD file. There’s a build shell function that you can use to add additional patches to the files if you have modifications to the software or the build process. That shell function generally looks like:

~/abs/PACKAGE/PKGBUILD

1 2 3 4 5 6 7 8 9 10

build() { cd $startdir/src/$pkgname-$pkgver.orig patch -Np1 -i $startdir/src/${pkgname}_${pkgver}-$_patchlevel.diff || return 1 ./configure --prefix=/usr make || return 1 make install }

To build the package, use the following command as a non-root user:

1	makepkg -s

The makepkg command creates a package that contains dependency information. As root, issue the following command:

1	pacman -U PACKAGE.pkg.tar.xz

Make sure to replace PACKAGE with the full package name exactly as it appears in the file system. Arch will now install the package and any required dependencies.

Because ABS downloads source versions of the PKGBUILD file as it creates the package - sometimes checking out a copy of the source code from the version control system - we don’t recommend removing files from the build directory hierarchy.

More Information About Pacman and ABS

If you’re interested in learning more about Arch and its package management tools, consult these external sources for the documentation provided by the Arch community:

• The Arch Build System
• Pacman

Gentoo Linux Package Management

Gentoo provides its entire operating system in source format. These source packages, in concert with ebuild scripts, provide a package management system that borrows and builds on many concepts from the BSD’s “portage” system.

Like Arch, the Gentoo project produces new versions of Gentoo Linux on a rolling release cycle.

This section addresses common package management tasks and functions using the emerge front end for the portage system. We encourage you to install the “gentoolkit” to provide additional package management tools, such as equery. Install this package with the following command:

1	emerge app-portage/gentoolkit

Emerge/Portage Commands

• emerge --sync - Updates the local copy of the portage tree, so that your local system can download and install the latest version of the software.
• emerge --update --deep world - Checks and updates all packages on the system to the latest version. This should be run regularly to avoid falling behind on a critical update.
• emerge --search keyword or emerge -s keyword - Searches the names of all of the packages for the given keyword. This command accepts a regular expression as the keyword argument.
• emerge --searchdoc keyword or emerge -S keyword - Searches the full description for a given keyword. This command accepts a regular expression as the keyword argument.
• emerge package-name(s) - Installs the specified package or packages.
• emerge -u package-name(s) - Updates the specified package to the latest version. Using the flag -uD also updates dependencies.
• emerge --depclean package-name(s) or emerge -c package-name(s) - Removes the specified package or packages.
• emerge --depclean - Removes packages that are orphaned. This means removal of all packages that weren’t explicitly installed and do not depend upon any specific package. We recommend that you run it with the --pretend option before running this command on a production system.
• emerge -evp --deep world - Lists all of the packages currently installed on the system.
• equery depends package-name(s) - Lists all of the packages that depend upon the specified package.
• equery files package-name(s) - Lists all of the files “owned” by a package.
• equery belongs filename - Lists the package that “owns” a particular file.

USE Flags

Portage also makes it possible to install additional variants of a package with USE flags, which allow the user to enable support for a particular option related to that package. To discover which USE flags are available for a given package, issue the following command:

1	equery uses package-name

The equery command depends on the gentoolkit package. This will provide information about what USE flags are available and which have been installed. To specify additional USE flags:

1 2	echo "package-name USE-flags" >> /etc/portage/package.use emerge package-name

This will install the specified package with the appropriate options enabled.