One of the brilliant features of Fedora is that it only comes on one CD disc. Not every operating system can brag about that. Indeed, many Linux distributions are delivered to users through multiple disks.
Formerly, the strategy in delivering a Linux distribution to your home or office was not very complex: all of the applications a user needed or would ever need in the future would be delivered on one complete set of CDs (or, later, one or two DVDs). The advantage here was that once you downloaded and burned all of those CDs, you would be all set to run that distribution without having to download additional software later. But the average CD image download, discussed. That’s a lot of data, even for today’s broadband connections. Having to do this for three, five, or even seven CDs is a very time-consuming undertaking for most users, unless they are willing to pay to have those same CDs delivered by mail.
Fedora flips the model around a bit. Working with the knowledge that a majority of Internet users now have broadband access, the Fedora Project has decided to send out just the absolutely necessary Fedora applications on one CD and leave the rest online on servers scattered around the world for users to download as needed.
This may seem inefficient, since you must have Internet access of some kind to make this work. But consider that most operating systems update themselves via Internet anyway, so in order to keep Fedora up to date, online access was needed anyway. And only downloading and burning one CD is a lot faster than downloading and burning CDs plural. Delivering a ‘‘core’’ distribution also gives users much greater flexibility in picking and choosing what software applications they want on their system. It also means their hard drives won’t be loaded with stuff they don’t need.
To give you an idea of just how much more software is available, consider these numbers: a standard installation of Fedora has around 1,100 packages. Currently, there are over 12,000 total application packages available.
Fedora, like its sibling Red Hat Enterprise Linux, organizes its software in repositories. There are three primary repositories for Fedora, each holding a specific class of software. Let’s walk through them now.
The three official Fedora repositories are pretty clearly named, but let’s examine them anyway.
» Fedora. This repository holds all of Fedora’s officially supported software. Everything that Fedora must have to actually run is in here, and all of the software is under a free software license. Additional applications in this repository include AbiWord, Evolution, Firefox, Gaim, OpenOffice.org, and Thunderbird.
» Updates. This repository contains any software that has been updated because of a bug or security fix.
» Source. All of the source code packages for Fedora software are found in this repository.
Adding Repositories
These are not the only repositories that Fedora can use. There aremany communityrun repositories on the Internet for Fedora, each holding specialized software that the Fedora Project does not want to host.
There are many software applications out there that can run on Linux, but because their licenses are completely proprietary, some Linux distributions won’t touch them with a 10-foot pole. By virtue of its Linux origins, Fedora’s makers feel obligated to abide by this philosophy, keeping totally commercial packages away from Fedora.
But there is an important distinction here. While the Fedora Project does not release commercial software with Fedora, that does not preclude letting users have access to a commercial repository after they have downloaded and installed
Fedora. A fine distinction, to be sure, but it gives users the advantage of making their own choices about what software they want to use. All of the package managers in Fedora work off a master list of repositories stored on your PC. From this file, known as sources.list, the package managers know which repositories to check for new software and if there are any updates available for software installed on your system. If you want these managers to peruse another repository, you will need to modify sources.list with the new information.
Fedora users in the know are aware of three such third-party repositories that will get you access to the latest in cutting-edge software for Fedora. These are the Dribble, Freshrpms, and rpm.livna.org repositories. Fortunately, you won’t have to add these repositories one at a time. Instead, you can use one command to add RPM Fusion to your sources.list, which will accomplish the same thing.
This operation will be done using a command-line application. Command-line applications are always run in a Terminal window, one of the plainest and most versatile tools found in Fedora. To start Terminal, click on the Applications | System Tools | Terminal menu command
Source of Information : Cengage-Introducing Fedora 2010
Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts
Tuesday, August 23, 2011
Thursday, August 18, 2011
How Fedora Installs Software
In the Windows world, there is usually one way to install software: clicking on an installation application that starts up and runs the whole setup for you from start to finish.
In Fedora, like most Linux distributions, there are three methods of software installation. Admittedly, one way to install sure sounds attractive and less confusing, but the one-size-fits-all installation service comes with a potentially bad price: Windows installation routines can often overwrite important underpinnings in the operating system for the sake of the application that’s currently being installed. This is good for your installed application, but potentially very bad for any pre-existing application on your system that was using that same section of Windows’ code.
In Fedora, all of the three installation methods take great pains to install applications using only what’s already in Fedora. If what the application needs is not installed in Fedora already, it has what is known as a dependency. The installing user (that would be you) will be told about any dependencies and asked how to proceed. A description of the three installation methods is easy to provide:
» Self-Contained Installation Program. This methodology is very much like the method used by Windows. A special installation application is run that automagically handles the application’s setup on your PC. This type of installation is not common on Fedora machines, though some of the larger consumer applications (OpenOffice.org or Firefox) can be installed in this manner. There is one important difference from Windows: no existing software is changed by the installation application. Dependencies are usually handled well, but it’s not foolproof.
» Compiled from Source. Remember how any user can get to the source code of any free software application? Well, once you have that code, you can perform what’s known as a compilation to turn that code (which only humans, at least the smart ones, can read) into something the PC can read and work with. Software compilation isn’t hard, but it is time-consuming at times, and dependencies are not automatically handled.
» Package Management. This method is unique to UNIX-based systems. All of the files and settings needed to install and run an application are included in one package. Fedora uses RPM-based, or .rpm, packages. (Other Linux distributions, such as Debian or Ubuntu, use Debian-based, or .deb, packages.)
As you may have guessed, package management is the preferred method of software installation in Fedora. Package installation is actually performed by an application known as a package manager. It helps keep track of all of the applications that are already installed on your PC and also helps keep track of those dependencies we mentioned. If you install a package that needs some additional software tools to properly operate on your Fedora system, it’s the package manager that will figure out what other packages you need.
In Fedora, there are actually three package managers that will assist you in your installation needs:
» PackageKit. This robust graphical package manager lists every package available for Fedora, which lets you search for software applications from a very big list. Applications are categorized by type, status on your system (installed or not), or origin.
» Software Update. Another graphical tool, this package manager has one job to do: keep your system as up to date as possible. If there’s a new version of any of your installed applications out there, Software Update will know about it and flag it for you to download and install.
» yum. The core package manager for Fedora, this command line application makes getting new packages as easy as typing one line of text and pressing the Enter key.
Each of these three package managers is configured to find all of the packages from Fedora’s package repositories. In the next section, we’ll walk through repositories and how they work.
Source of Information : Cengage-Introducing Fedora 2010
In Fedora, like most Linux distributions, there are three methods of software installation. Admittedly, one way to install sure sounds attractive and less confusing, but the one-size-fits-all installation service comes with a potentially bad price: Windows installation routines can often overwrite important underpinnings in the operating system for the sake of the application that’s currently being installed. This is good for your installed application, but potentially very bad for any pre-existing application on your system that was using that same section of Windows’ code.
In Fedora, all of the three installation methods take great pains to install applications using only what’s already in Fedora. If what the application needs is not installed in Fedora already, it has what is known as a dependency. The installing user (that would be you) will be told about any dependencies and asked how to proceed. A description of the three installation methods is easy to provide:
» Self-Contained Installation Program. This methodology is very much like the method used by Windows. A special installation application is run that automagically handles the application’s setup on your PC. This type of installation is not common on Fedora machines, though some of the larger consumer applications (OpenOffice.org or Firefox) can be installed in this manner. There is one important difference from Windows: no existing software is changed by the installation application. Dependencies are usually handled well, but it’s not foolproof.
» Compiled from Source. Remember how any user can get to the source code of any free software application? Well, once you have that code, you can perform what’s known as a compilation to turn that code (which only humans, at least the smart ones, can read) into something the PC can read and work with. Software compilation isn’t hard, but it is time-consuming at times, and dependencies are not automatically handled.
» Package Management. This method is unique to UNIX-based systems. All of the files and settings needed to install and run an application are included in one package. Fedora uses RPM-based, or .rpm, packages. (Other Linux distributions, such as Debian or Ubuntu, use Debian-based, or .deb, packages.)
As you may have guessed, package management is the preferred method of software installation in Fedora. Package installation is actually performed by an application known as a package manager. It helps keep track of all of the applications that are already installed on your PC and also helps keep track of those dependencies we mentioned. If you install a package that needs some additional software tools to properly operate on your Fedora system, it’s the package manager that will figure out what other packages you need.
In Fedora, there are actually three package managers that will assist you in your installation needs:
» PackageKit. This robust graphical package manager lists every package available for Fedora, which lets you search for software applications from a very big list. Applications are categorized by type, status on your system (installed or not), or origin.
» Software Update. Another graphical tool, this package manager has one job to do: keep your system as up to date as possible. If there’s a new version of any of your installed applications out there, Software Update will know about it and flag it for you to download and install.
» yum. The core package manager for Fedora, this command line application makes getting new packages as easy as typing one line of text and pressing the Enter key.
Each of these three package managers is configured to find all of the packages from Fedora’s package repositories. In the next section, we’ll walk through repositories and how they work.
Source of Information : Cengage-Introducing Fedora 2010
Wednesday, May 25, 2011
Fedore Desktop Environments
It would be a good idea to discuss what is different—specifically, the graphical interfaces that users work with when they work with any kind of Linux.
Most computer users are used to seeing just one graphical interface when they run their PCs. Windows 7 Home Edition users get to use the basic Windows interface, Windows 7 Premium and Ultimate Editions use the fancier Aero interface, and OS X users use Aqua. Graphical interfaces are the technical name for the windows, menus, and icons that so many computer users have grown accustomed to.
In these operating systems, you get the interface that comes with the OS. You can change the colors and the sizes of some items (bigger icons, for instance), but at the end of the day, you're still using the same interface.
In Linux, this is not the case: There are literally dozens of interfaces for you to choose from. This goes back to the whole modular nature of Linux. Unlike Windows 7, the interface applications are separate from the core operating system. So, if something creates a glitch on a Linux interface, known as a desktop environment, the core operating system is not affected.
These desktop environments do more than just look different; they are managed by completely different tools, and each carries its own set of specialized applications. For example, a text editor (like Windows Notepad) called Gedit is available for the GNOME desktop environment, and in the K Desktop Environment (KDE) the same kind of editor is known as Kate. (The first letter of an application is often a clue to the preferred environment for that application.)
Confusing? It shouldn't be. The good news is that applications for one desktop environment usually work in other environments without a hitch. (The author, for instance, prefers to work in KDE but won't part with the Gedit text editor. The two work together quite well.)
Source of Information : Cengage-Introducing Fedora 2010
Most computer users are used to seeing just one graphical interface when they run their PCs. Windows 7 Home Edition users get to use the basic Windows interface, Windows 7 Premium and Ultimate Editions use the fancier Aero interface, and OS X users use Aqua. Graphical interfaces are the technical name for the windows, menus, and icons that so many computer users have grown accustomed to.
In these operating systems, you get the interface that comes with the OS. You can change the colors and the sizes of some items (bigger icons, for instance), but at the end of the day, you're still using the same interface.
In Linux, this is not the case: There are literally dozens of interfaces for you to choose from. This goes back to the whole modular nature of Linux. Unlike Windows 7, the interface applications are separate from the core operating system. So, if something creates a glitch on a Linux interface, known as a desktop environment, the core operating system is not affected.
These desktop environments do more than just look different; they are managed by completely different tools, and each carries its own set of specialized applications. For example, a text editor (like Windows Notepad) called Gedit is available for the GNOME desktop environment, and in the K Desktop Environment (KDE) the same kind of editor is known as Kate. (The first letter of an application is often a clue to the preferred environment for that application.)
Confusing? It shouldn't be. The good news is that applications for one desktop environment usually work in other environments without a hitch. (The author, for instance, prefers to work in KDE but won't part with the Gedit text editor. The two work together quite well.)
Source of Information : Cengage-Introducing Fedora 2010
Monday, May 23, 2011
Yes, There’s More Than One Way to Spin Fedora
You could almost say that Fedora is a victim of its own popularity. Because Fedora is so efficient and easy to use (even among Linux distributions), developers of all persuasions have taken a good thing and recrafted it into something they prefer even more. These variations of Fedora are known as spins, and they follow the same release cycle as the main version (though they might be offset by a few days here and there). Most of the differences between the flavors of Fedora are purely cosmetic: sometimes it’s a different desktop environment, sometimes it’s a different set of installed applications.
It is important to note that these spins are not completely different versions of Fedora; they are just Fedora pre-packaged in different ways. You can, if you wish, download and install all of the software needed to created identical versions of these spins. But having the spins already set up will save you a great deal of time and effort.
Fedora Desktop
The Fedora Desktop is the primary version among the Fedora ‘‘family’’ of spins, the one from which all the others are based. One of Fedora’s main characteristics is that it uses, by default, the GNOME desktop environment. GNOME, along with its predecessor KDE, is one of the most popular desktop environments around for Linux and other UNIX-based operating systems. It’s often regarded as an easier-to-use environment, with fewer controls for users to worry about. Free software purists prefer it for the totally free nature of the code that is used to build GNOME.
Fedora KDE
Fedora KDE is the most popular ‘‘alternate’’ Fedora spin, and as you might have guessed from the name, it features the KDE. The KDE environment came before GNOME, but quite a few people in the Linux community don’t like it because initially it was built with the help of nonfree code. (The Debian Project, for instance, initially would not ship any release with KDE.) The GNOME Project was started as a result of this concern. Today, the code in KDE is more open, and those objections have been rendered moot. Fedora KDE makes exclusive use of KDE and its attendant applications.
Fedora LXDE Spin
LXDE stands for ‘‘Lightweight X11 Desktop Environment,’’ and it is designed to be very fast and light on its electronic feet. While not as popular as GNOME and KDE, the LXDE interface features multi-language support, standard keyboard shortcuts, and tabbed file browsing. LXDE is a good environment for low-power devices such as netbooks, mobile Internet devices, or older machines.
Fedora Xfce Spin
This Fedora spin uses the Xfce environment, a simple and fast environment based on the old UNIX CDE environment. Xfce takes a bit of getting used to, because the graphic interface tools are a bit less intuitive than the more robust GNOME and KDE environments. But using Xfce gives this Fedora spin the added advantage of not being as resource-hungry as other Linux distributions and makes it ideal for running on slower, older PCs.
Fedora Games Spin
Like to get your game on? The Fedora Games spin offers a great collection of games available for Fedora. Not every Fedora game is included with this spin, but the designers have tried to put together a good representation of the different styles of games that you can get for the Fedora distribution.
Fedora Edu Spin
Unlike the other Fedora spins, Fedora Edu is not different because of its look or feel. Rather Fedora Edu’s differences lie in the content and tools it provides to users. Fedora Edu is sometimes referred to as the ‘‘kids’ Fedora,’’ and indeed, the addition of educational and development software certainly matches that description. But the overall goal of the project is to provide an easy-to-use distribution for all ages of students. According to the project’s home page, ‘‘The purpose of this spin is to create a ready-to-go development environment for contributing to educational projects inside, but also outside of the Fedora ecosystem....’’ Edu runs a GNOME desktop, with the differences mostly in the set of educational applications that ships with the distribution. These include various language, science, and development learning tools.
Fedora BrOffice Spin
One of the interesting results of working on the international stage of the Internet is how names can be used for different things in different nations. For instance, the office suite found in Fedora, OpenOffice.org, gets the ‘‘.org’’ in its official name from the fact that OpenOffice is actually a trademarked company name in the Netherlands, as well as a trademark owned by Orange UK, the British telecommunications company. Rather than raise a ruckus, the project’s organizers decided to simply tack on the ‘‘.org’’ to the name. But even that didn’t work, as OpenOffice.org is a trademark held in Brazil. So, OpenOffice.org users in Brazil use BrOffice. BrOffice, as you may have surmised,
is the centerpiece of the Fedora BrOffice spin. But the spin’s creators didn’t stop there. This spin is loaded with language packs and applications that are well suited for Central and South American users, whether they converse in Spanish or Portuguese.
Fedora FEL Spin
Very likely the most specialized Fedora spin is the Fedora Electronic Laboratory (FEL) spin. FEL was put together solely to provide a solid platform for the Electronic Design Automation (EDA) community. These are the people who put together things like microchips, processors, and robots. You know, easy stuff. According to the project’s Web site, FEL ‘‘provides a complete electronic laboratory setup with reliable open source design tools in order to help you keep in pace with the current technological race. It reduces the risk assessment of open source hardware development and enables electronic designers to create their work quickly and efficiently.’’
Source of Information : Cengage-Introducing Fedora 2010
It is important to note that these spins are not completely different versions of Fedora; they are just Fedora pre-packaged in different ways. You can, if you wish, download and install all of the software needed to created identical versions of these spins. But having the spins already set up will save you a great deal of time and effort.
Fedora Desktop
The Fedora Desktop is the primary version among the Fedora ‘‘family’’ of spins, the one from which all the others are based. One of Fedora’s main characteristics is that it uses, by default, the GNOME desktop environment. GNOME, along with its predecessor KDE, is one of the most popular desktop environments around for Linux and other UNIX-based operating systems. It’s often regarded as an easier-to-use environment, with fewer controls for users to worry about. Free software purists prefer it for the totally free nature of the code that is used to build GNOME.
Fedora KDE
Fedora KDE is the most popular ‘‘alternate’’ Fedora spin, and as you might have guessed from the name, it features the KDE. The KDE environment came before GNOME, but quite a few people in the Linux community don’t like it because initially it was built with the help of nonfree code. (The Debian Project, for instance, initially would not ship any release with KDE.) The GNOME Project was started as a result of this concern. Today, the code in KDE is more open, and those objections have been rendered moot. Fedora KDE makes exclusive use of KDE and its attendant applications.
Fedora LXDE Spin
LXDE stands for ‘‘Lightweight X11 Desktop Environment,’’ and it is designed to be very fast and light on its electronic feet. While not as popular as GNOME and KDE, the LXDE interface features multi-language support, standard keyboard shortcuts, and tabbed file browsing. LXDE is a good environment for low-power devices such as netbooks, mobile Internet devices, or older machines.
Fedora Xfce Spin
This Fedora spin uses the Xfce environment, a simple and fast environment based on the old UNIX CDE environment. Xfce takes a bit of getting used to, because the graphic interface tools are a bit less intuitive than the more robust GNOME and KDE environments. But using Xfce gives this Fedora spin the added advantage of not being as resource-hungry as other Linux distributions and makes it ideal for running on slower, older PCs.
Fedora Games Spin
Like to get your game on? The Fedora Games spin offers a great collection of games available for Fedora. Not every Fedora game is included with this spin, but the designers have tried to put together a good representation of the different styles of games that you can get for the Fedora distribution.
Fedora Edu Spin
Unlike the other Fedora spins, Fedora Edu is not different because of its look or feel. Rather Fedora Edu’s differences lie in the content and tools it provides to users. Fedora Edu is sometimes referred to as the ‘‘kids’ Fedora,’’ and indeed, the addition of educational and development software certainly matches that description. But the overall goal of the project is to provide an easy-to-use distribution for all ages of students. According to the project’s home page, ‘‘The purpose of this spin is to create a ready-to-go development environment for contributing to educational projects inside, but also outside of the Fedora ecosystem....’’ Edu runs a GNOME desktop, with the differences mostly in the set of educational applications that ships with the distribution. These include various language, science, and development learning tools.
Fedora BrOffice Spin
One of the interesting results of working on the international stage of the Internet is how names can be used for different things in different nations. For instance, the office suite found in Fedora, OpenOffice.org, gets the ‘‘.org’’ in its official name from the fact that OpenOffice is actually a trademarked company name in the Netherlands, as well as a trademark owned by Orange UK, the British telecommunications company. Rather than raise a ruckus, the project’s organizers decided to simply tack on the ‘‘.org’’ to the name. But even that didn’t work, as OpenOffice.org is a trademark held in Brazil. So, OpenOffice.org users in Brazil use BrOffice. BrOffice, as you may have surmised,
is the centerpiece of the Fedora BrOffice spin. But the spin’s creators didn’t stop there. This spin is loaded with language packs and applications that are well suited for Central and South American users, whether they converse in Spanish or Portuguese.
Fedora FEL Spin
Very likely the most specialized Fedora spin is the Fedora Electronic Laboratory (FEL) spin. FEL was put together solely to provide a solid platform for the Electronic Design Automation (EDA) community. These are the people who put together things like microchips, processors, and robots. You know, easy stuff. According to the project’s Web site, FEL ‘‘provides a complete electronic laboratory setup with reliable open source design tools in order to help you keep in pace with the current technological race. It reduces the risk assessment of open source hardware development and enables electronic designers to create their work quickly and efficiently.’’
Source of Information : Cengage-Introducing Fedora 2010
Friday, May 20, 2011
The Fedora Connection
Fedora actually began its existence as a simple collection of software. One of the community outreach projects started by Red Hat as it was working to keep community interest high was the Fedora Linux project, a collection of newer and more experimental software that, when installed on Red Hat Linux, would give users a chance to enhance their computers without introducing risky software to the main Red Hat Linux distribution.
It’s important to note that Fedora Linux was not a stand-alone version of Linux, like other distributions, but was actually what’s known as a repository of software. But it would play a key role in what was to come next.
In September 2003, Red Hat made a stunning announcement: Red Hat Linux would cease to be a product. Instead, users who wanted to have commercial grade support (such as those coveted enterprise customers) would now use and pay for Red Hat Enterprise Linux. Users who wished to continue using Red Hat Linux for free and without support would use Fedora Core, a formal merging of Red Hat Linux and the software from the Fedora Linux project.
The new Fedora Core distribution would be governed not by Red Hat, but by an independent nonprofit organization known as the Fedora Project. At the time, this was considered to be a radical move, but as Linux became more commercially viable, vendors like Red Hat were able to make the jump to a pure commercial distribution.
Initially, reaction was mixed. After all, many people wondered, what about home and small business users who wanted some level of support? In response, in 2004 Red Hat (rather quietly) released Red Hat Professional Workstation, a $100 version of Red Hat Linux that came with direct Red Hat support. It was, unfortunately, a commercial failure.
What happened next would shape the commercial/community distribution model for all future releases—not just for Red Hat, but also for other followers of the model.
Simply put, the Fedora community took care of the support problem itself. By becoming a cohesive, flexible body, members of the Fedora Project began to fill the gaps that were once occupied by Red Hat. Documentation was created; support issues resolved; bugs tracked, identified, and removed. In short, the Fedora Core distribution became as robust and powerful as Red Hat Linux ever was and soon surpassed its parent distribution in terms of ease of use and features.
In fact, the Fedora Project became so strong that eventually Red Hat would drop its efforts for a home/small business desktop product and put time, effort, and resources back into Fedora Core.
Ultimately, this approach worked out very well for both sides. Power users and developers got a complete and robust distribution to experiment with and use, and Red Hat kept its commercial distribution solid and mature. And, as an added benefit, Fedora Core, later named just Fedora, would become a test bed for new technologies and applications, which would later be included in Red Hat Enterprise Linux.
It’s a good example of a win-win situation for users, developers, and commercial vendors alike.
Source of Information : Cengage-Introducing Fedora 2010
It’s important to note that Fedora Linux was not a stand-alone version of Linux, like other distributions, but was actually what’s known as a repository of software. But it would play a key role in what was to come next.
In September 2003, Red Hat made a stunning announcement: Red Hat Linux would cease to be a product. Instead, users who wanted to have commercial grade support (such as those coveted enterprise customers) would now use and pay for Red Hat Enterprise Linux. Users who wished to continue using Red Hat Linux for free and without support would use Fedora Core, a formal merging of Red Hat Linux and the software from the Fedora Linux project.
The new Fedora Core distribution would be governed not by Red Hat, but by an independent nonprofit organization known as the Fedora Project. At the time, this was considered to be a radical move, but as Linux became more commercially viable, vendors like Red Hat were able to make the jump to a pure commercial distribution.
Initially, reaction was mixed. After all, many people wondered, what about home and small business users who wanted some level of support? In response, in 2004 Red Hat (rather quietly) released Red Hat Professional Workstation, a $100 version of Red Hat Linux that came with direct Red Hat support. It was, unfortunately, a commercial failure.
What happened next would shape the commercial/community distribution model for all future releases—not just for Red Hat, but also for other followers of the model.
Simply put, the Fedora community took care of the support problem itself. By becoming a cohesive, flexible body, members of the Fedora Project began to fill the gaps that were once occupied by Red Hat. Documentation was created; support issues resolved; bugs tracked, identified, and removed. In short, the Fedora Core distribution became as robust and powerful as Red Hat Linux ever was and soon surpassed its parent distribution in terms of ease of use and features.
In fact, the Fedora Project became so strong that eventually Red Hat would drop its efforts for a home/small business desktop product and put time, effort, and resources back into Fedora Core.
Ultimately, this approach worked out very well for both sides. Power users and developers got a complete and robust distribution to experiment with and use, and Red Hat kept its commercial distribution solid and mature. And, as an added benefit, Fedora Core, later named just Fedora, would become a test bed for new technologies and applications, which would later be included in Red Hat Enterprise Linux.
It’s a good example of a win-win situation for users, developers, and commercial vendors alike.
Source of Information : Cengage-Introducing Fedora 2010
Monday, May 16, 2011
The Red Hat Connection with Fedora
Red Hat Linux is one of the earliest created Linux distributions, having been invented by Marc Ewing in 1994. Ewing actually began working on the distribution, then known as Red Hat Software Linux, in December of 1992, soon after he graduated from Carnegie Mellon University.
According to legend—because you can have legends in under 20 years on the Internet—the name ‘‘Red Hat’’ came from Ewing’s habit of wearing a red hat while at CMU. The name stuck, even after Ewing’s company was purchased by entrepreneur Bob Young in 1995.
Red Hat’s initial popularity is attributed to some key technological advantages it had over other Linux distributions of the time. One such advantage was the addition of a graphical configuration system used when installing Red Hat. Primitive by today’s standards, nonetheless this simple series of installation screens was hugely helpful for those early adopters who wanted to try out Linux.
Another advantage Red Hat had was how software applications were distributed for the Red Hat Linux platform. Recall that while open source and free software is always available in its source code form, such a format is not easy to use. What software developers must do is deliver their application in a form that’s easy to install. On Windows, this is done with a self-executing file that users can double-click and have the new program installed.
On Linux, such an approach is not a good idea. Self-executing installs can bring a host of mistakes and potentially malicious changes to a computer, and at the most fundamental level, all Linux systems resist such packages. Instead, applications are installed using packages. A Linux package can contain many of the same files as a Windows installation routine, but the control of the installation lies with the package manager—not the package itself.
Package managers will not only ensure the package is properly and safely put together, but they will also make sure that any other software the application needs will be installed as well.
Red Hat’s advantage here was the introduction of the RPM package management system. RPM packages are one of two major Linux packaging systems (the other being Debian GNU/Linux’s DEB package system).
Over the next nine years, Red Hat Linux would continue to capitalize on these and other advantages, devoting much of its marketing and sales efforts to getting Linux into the workplace; specifically, the enterprises which are organizations with 500 or more computer users. By targeting this market, Red Hat was essentially aiming for the low-hanging fruit; there aren’t a lot of enterprise-level customers out there, but it only takes a few to really build your revenue stream.
But this approach, while commercially successful, gave Red Hat a problem. While Red Hat Linux was becoming increasingly popular in the corporate world, the community-oriented developer and user bases that had helped to bring Red Hat Linux to where it was technologically were feeling increasingly disenfranchised. What good was it to develop cutting-edge software, the community complained, when Red Hat, fearing any software instability for its well-heeled enterprise customers, would only include it after a laborious quality control process?
This issue was serious enough to prompt Red Hat to launch several community outreach programs—because if the community began to vote with their feet and walk away from Red Hat, highly valuable development resources could be lost, and Red Hat’s community reputation would plummet. Some of this outreach helped, but in the end, it took the birth of a new distribution and the death of Red Hat Linux to help save Red Hat.
Red Hat Linux is one of three major branches of Linux distributions that exist today. Many successful distributions, including Fedora, are based on Red Hat Linux, such as Red Flag, a popular Chinese distribution, and Yellow Dog, a flavor of Linux designed to run on Apple's Mac hardware.
Source of Information : Cengage-Introducing Fedora 2010
According to legend—because you can have legends in under 20 years on the Internet—the name ‘‘Red Hat’’ came from Ewing’s habit of wearing a red hat while at CMU. The name stuck, even after Ewing’s company was purchased by entrepreneur Bob Young in 1995.
Red Hat’s initial popularity is attributed to some key technological advantages it had over other Linux distributions of the time. One such advantage was the addition of a graphical configuration system used when installing Red Hat. Primitive by today’s standards, nonetheless this simple series of installation screens was hugely helpful for those early adopters who wanted to try out Linux.
Another advantage Red Hat had was how software applications were distributed for the Red Hat Linux platform. Recall that while open source and free software is always available in its source code form, such a format is not easy to use. What software developers must do is deliver their application in a form that’s easy to install. On Windows, this is done with a self-executing file that users can double-click and have the new program installed.
On Linux, such an approach is not a good idea. Self-executing installs can bring a host of mistakes and potentially malicious changes to a computer, and at the most fundamental level, all Linux systems resist such packages. Instead, applications are installed using packages. A Linux package can contain many of the same files as a Windows installation routine, but the control of the installation lies with the package manager—not the package itself.
Package managers will not only ensure the package is properly and safely put together, but they will also make sure that any other software the application needs will be installed as well.
Red Hat’s advantage here was the introduction of the RPM package management system. RPM packages are one of two major Linux packaging systems (the other being Debian GNU/Linux’s DEB package system).
Over the next nine years, Red Hat Linux would continue to capitalize on these and other advantages, devoting much of its marketing and sales efforts to getting Linux into the workplace; specifically, the enterprises which are organizations with 500 or more computer users. By targeting this market, Red Hat was essentially aiming for the low-hanging fruit; there aren’t a lot of enterprise-level customers out there, but it only takes a few to really build your revenue stream.
But this approach, while commercially successful, gave Red Hat a problem. While Red Hat Linux was becoming increasingly popular in the corporate world, the community-oriented developer and user bases that had helped to bring Red Hat Linux to where it was technologically were feeling increasingly disenfranchised. What good was it to develop cutting-edge software, the community complained, when Red Hat, fearing any software instability for its well-heeled enterprise customers, would only include it after a laborious quality control process?
This issue was serious enough to prompt Red Hat to launch several community outreach programs—because if the community began to vote with their feet and walk away from Red Hat, highly valuable development resources could be lost, and Red Hat’s community reputation would plummet. Some of this outreach helped, but in the end, it took the birth of a new distribution and the death of Red Hat Linux to help save Red Hat.
Red Hat Linux is one of three major branches of Linux distributions that exist today. Many successful distributions, including Fedora, are based on Red Hat Linux, such as Red Flag, a popular Chinese distribution, and Yellow Dog, a flavor of Linux designed to run on Apple's Mac hardware.
Source of Information : Cengage-Introducing Fedora 2010
Thursday, May 12, 2011
Distributions of All Shapes and Sizes
In the very beginning, there was one distribution of Linux, known as MCC Interim Linux. Its singular status didn’t last long. Very soon, there were a handful of distributions. Today, nearly 18 years later, there are upwards of 200 distributions. No one knows the exact number, since new ones are being created every week, and old ones are being allowed to languish into obscurity.
Whatever the exact number, there are a lot of distributions out there, and they all fall into one of two categories: commercial (like RHEL) or noncommercial (like Fedora).
The commercial distributions exist for a pretty self-explanatory reason: someone, either a company or a group of developers, wants to make money. These distributions tend to be the most well-known of the Linux distributions, although they are not necessarily the most influential.
Distributions in this category include RHEL, SUSE Linux Enterprise Server, Mandriva Linux, and Ubuntu Server. Those are the more commercially successful distributions; it is by no means a complete list.
Noncommercial distributions are generally run as not-for-profits, if they are well organized, or even as a hobby for one of a group of developers. The motivation for developers is varied. Some want to create something meaningful. Some do it to earn extra money. (Actually, some nonprofit distributions do receive some funding through voluntary support and donations.) Some want to have fun coding. Whatever the reason, developers have made noncommercial distributions very popular and extremely influential among all Linux developers.
Noncommercial distributions include Debian GNU/Linux, Slackware Linux, Ubuntu, openSUSE, and SimplyMEPIS. Just to give you an idea of how influential noncommercial distributions can be, know that SimplyMEPIS, Freespire, Linspire, and Xandros are among the many Linux distributions (commercial or otherwise) based on what has become the most popular noncommercial distribution today: Debian GNU/Linux.
Source of Information : Cengage-Introducing Fedora 2010
Whatever the exact number, there are a lot of distributions out there, and they all fall into one of two categories: commercial (like RHEL) or noncommercial (like Fedora).
The commercial distributions exist for a pretty self-explanatory reason: someone, either a company or a group of developers, wants to make money. These distributions tend to be the most well-known of the Linux distributions, although they are not necessarily the most influential.
Distributions in this category include RHEL, SUSE Linux Enterprise Server, Mandriva Linux, and Ubuntu Server. Those are the more commercially successful distributions; it is by no means a complete list.
Noncommercial distributions are generally run as not-for-profits, if they are well organized, or even as a hobby for one of a group of developers. The motivation for developers is varied. Some want to create something meaningful. Some do it to earn extra money. (Actually, some nonprofit distributions do receive some funding through voluntary support and donations.) Some want to have fun coding. Whatever the reason, developers have made noncommercial distributions very popular and extremely influential among all Linux developers.
Noncommercial distributions include Debian GNU/Linux, Slackware Linux, Ubuntu, openSUSE, and SimplyMEPIS. Just to give you an idea of how influential noncommercial distributions can be, know that SimplyMEPIS, Freespire, Linspire, and Xandros are among the many Linux distributions (commercial or otherwise) based on what has become the most popular noncommercial distribution today: Debian GNU/Linux.
Source of Information : Cengage-Introducing Fedora 2010
Wednesday, August 25, 2010
Avoiding a Trojan Horse
A Trojan horse is a program that does something destructive or disruptive to a system while appearing to be benign. As an example, you could store the following script in an executable file named mkfs:
If you are running as Superuser when you run this command, it would continuously write a message to the console. If the programmer were malicious, it could do worse. The only thing missing in this plot is access permissions. A malicious user could implement this Trojan horse by changing Superuser’s PATH variable to include a publicly writable directory at the start of the PATH string. (The catch is that you need to be able to write to /etc/profile-where the PATH variable is set for root-and only root can do that.) Then you would need to put the bogus mkfs program file in that directory. Because the fraudulent version appears in a directory mentioned earlier than the real one in PATH, the shell would run it rather than the legitimate version. The next time Superuser tries to run mkfs, the fraudulent version would run.
Trojan horses that lie in wait for and take advantage of the misspellings that most people make are among the most insidious types. For example, you might type sl instead of ls. Because you do not regularly execute a utility named sl and you may not remember typing the command sl, it is more difficult to track down this type of Trojan horse than one that takes the name of a more familiar utility.
A good way to help prevent the execution of a Trojan horse is to make sure that your PATH variable does not contain a single colon (:) at the beginning or end of the PATH string or a period (.) or double colon (::) anywhere in the PATH string. This precaution ensures that you will not execute a file in the working directory by accident. To check for a possible Trojan horse, examine the filesystem periodically for files with setuid permission. The following command lists these files:
This command uses find to locate all files that have their setuid bit set (mode 4000). The hyphen preceding the mode causes find to report on any file that has this bit set, regardless of how the other bits are set. The output sent to standard error is redirected to /dev/null so that it does not clutter the screen.
You can also set up a program, such as AIDE (Advanced Intrusion Detection Environment; part of the aide package), that will take a snapshot of the system and check it periodically. See sourceforge.net/projects/aide for more information.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
while true
do
echo 'Good Morning Mr. Jones. How are you? Ha Ha Ha.' > /dev/console
done
If you are running as Superuser when you run this command, it would continuously write a message to the console. If the programmer were malicious, it could do worse. The only thing missing in this plot is access permissions. A malicious user could implement this Trojan horse by changing Superuser’s PATH variable to include a publicly writable directory at the start of the PATH string. (The catch is that you need to be able to write to /etc/profile-where the PATH variable is set for root-and only root can do that.) Then you would need to put the bogus mkfs program file in that directory. Because the fraudulent version appears in a directory mentioned earlier than the real one in PATH, the shell would run it rather than the legitimate version. The next time Superuser tries to run mkfs, the fraudulent version would run.
Trojan horses that lie in wait for and take advantage of the misspellings that most people make are among the most insidious types. For example, you might type sl instead of ls. Because you do not regularly execute a utility named sl and you may not remember typing the command sl, it is more difficult to track down this type of Trojan horse than one that takes the name of a more familiar utility.
A good way to help prevent the execution of a Trojan horse is to make sure that your PATH variable does not contain a single colon (:) at the beginning or end of the PATH string or a period (.) or double colon (::) anywhere in the PATH string. This precaution ensures that you will not execute a file in the working directory by accident. To check for a possible Trojan horse, examine the filesystem periodically for files with setuid permission. The following command lists these files:
# find / -perm -4000 -exec ls -lh {} \; 2> /dev/null
-rws--x--x. 1 root root 30K Oct 5 12:10 /usr/sbin/userhelper
-r-s--x---. 1 root apache 11K Aug 21 07:15 /usr/sbin/suexec
-rws--x--x. 1 root root 1.9M Oct 4 21:38 /usr/bin/Xorg
-rws--x--x. 1 root root 15K Oct 5 08:28 /usr/bin/chsh
-rwsr-xr-x. 1 root root 23K Sep 14 05:14 /usr/bin/passwd
-rws--x--x. 1 root root 16K Oct 5 08:28 /usr/bin/chfn
---s--x--x. 2 root root 169K Aug 21 04:24 /usr/bin/sudoedit
-rwsr-sr-x. 1 root root 45K Aug 21 03:26 /usr/bin/crontab
---s--x--x. 2 root root 169K Aug 21 04:24 /usr/bin/sudo
-rwsr-xr-x. 1 root root 60K Sep 7 08:04 /usr/bin/gpasswd
-rwsr-xr-x. 1 root root 51K Sep 29 11:58 /usr/bin/at
...
This command uses find to locate all files that have their setuid bit set (mode 4000). The hyphen preceding the mode causes find to report on any file that has this bit set, regardless of how the other bits are set. The output sent to standard error is redirected to /dev/null so that it does not clutter the screen.
You can also set up a program, such as AIDE (Advanced Intrusion Detection Environment; part of the aide package), that will take a snapshot of the system and check it periodically. See sourceforge.net/projects/aide for more information.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Tuesday, August 24, 2010
Rescue Mode
Rescue mode is an environment you can use to fix a system that does not boot normally. To bring a system up in rescue mode, boot the system from the first installation CD, the Net Boot CD, or the install DVD. From the install DVD, select Rescue installed system from the Welcome menu (page 56). From the first installation CD and the Net Boot CD, enter the rescue (FEDORA) or boot rescue (RHEL) boot parameter. The boot process may take several minutes. The system then comes up in rescue mode.
In rescue mode, you can change or replace configuration files, check and repair partitions using fsck, rewrite boot information, and more. The rescue screen first asks if you want to set up the network interface. This interface is required if you want to copy files from other systems on the LAN or download files from the Internet. When you choose to set up the network interface, you need to decide whether to have DHCP automatically configure the network connection or to manually supply the IP address and netmask of the interface, as well as the IP addresses of the gateway and DNS server(s).
If the rescue setup finds an existing Linux installation, you can choose to mount it under /mnt/sysimage, optionally in readonly mode. With the existing installation mounted, once the system displays a shell prompt (similar to sh-3.2#), you can give the command chroot /mnt/sysimage to access the existing installation as it would be if you booted normally, with the existing installation’s root directory available as / (root). If you choose not to mount the existing installation, you are running a rescue system with standard tools mounted in standard locations (/bin, /usr/bin, and so on). Partitions from your local installation are available for fixing or mounting. When you exit from the rescue shell, the system reboots. Remove the CD or DVD if you want to boot from the hard drive.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
In rescue mode, you can change or replace configuration files, check and repair partitions using fsck, rewrite boot information, and more. The rescue screen first asks if you want to set up the network interface. This interface is required if you want to copy files from other systems on the LAN or download files from the Internet. When you choose to set up the network interface, you need to decide whether to have DHCP automatically configure the network connection or to manually supply the IP address and netmask of the interface, as well as the IP addresses of the gateway and DNS server(s).
If the rescue setup finds an existing Linux installation, you can choose to mount it under /mnt/sysimage, optionally in readonly mode. With the existing installation mounted, once the system displays a shell prompt (similar to sh-3.2#), you can give the command chroot /mnt/sysimage to access the existing installation as it would be if you booted normally, with the existing installation’s root directory available as / (root). If you choose not to mount the existing installation, you are running a rescue system with standard tools mounted in standard locations (/bin, /usr/bin, and so on). Partitions from your local installation are available for fixing or mounting. When you exit from the rescue shell, the system reboots. Remove the CD or DVD if you want to boot from the hard drive.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Monday, August 23, 2010
consolehelper: Runs Programs as root
The consolehelper utility can make it easier for someone who is logged in on the system console but not logged in as root to run system programs that normally can be run only by root. PAM, which authenticates users, can be set to trust all console users, to require user passwords (not the root password), or to require the root password before granting trust. The concept underlying consolehelper is that you may want to consider as trustworthy anyone who has access to the console. For example, Alex can log in on the console as himself and run halt without knowing the root password.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Sunday, August 22, 2010
su: Gives You Another User’s Privileges
The su (substitute user) utility can create a shell or execute a program with the identity and permissions of a specified user. Follow su on the command line with the name of a user; if you are working with root privileges or if you know the user’s password, you take on the identity of that user. When you give an su command without an argument, su defaults to Superuser so that you take on the identity of root (you have to know the root password).
To ensure that you are using the system’s official version of su (and not one planted on your system by a malicious user), specify su’s absolute pathname (/bin/su) when you use it. (Of course, if someone has compromised your system enough that you are running a fake su command, you are in serious trouble anyway-but using an absolute pathname for su is still a good idea.)
When you give an su command to become Superuser, you spawn a new shell, which displays the # prompt. You return to your normal status (and your former shell and prompt) by terminating this shell: Press CONTROL-D or give an exit command. Giving an su command by itself changes your user and group IDs but makes minimal changes to your environment. You still have the same PATH you did when you logged in as yourself. When you run a utility that is normally run by root (the utilities in /sbin and /usr/sbin), you may need to specify an absolute pathname for the utility (such as /sbin/service). When you give the command su - (you can use -l or --login in place of the hyphen), you get a root login shell: It is as though you logged in as root. Not only are your user and group IDs the same as those of root, but your entire environment is that of root. The login shell executes the appropriate startup scripts before displaying a prompt, and your PATH is set to what it would be if you had logged in as root, typically including /sbin and /usr/sbin.
Use the id utility to display the changes in your user and group IDs and in the groups you are associated with. In the following example, the information that starts with context pertains to SELinux:
You can use su with the -c option to run a single command with root privileges, returning to your original shell when the command finishes executing. The following example first shows that a user is not permitted to kill a process. With the use of su -c and the root password, the user is permitted to kill (page 409) the process. The quotation marks are necessary because su -c takes its command in the form of a single argument.
Superuser, PATH, and security
The fewer directories you keep in your PATH when you are working with root privileges, the less likely you will be to execute an untrusted program as root. If possible, keep only the default directories, along with /sbin and /usr/sbin, in root’s PATH. Never include the working directory (as . or : : anywhere in PATH, or : as the last element of PATH).
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
To ensure that you are using the system’s official version of su (and not one planted on your system by a malicious user), specify su’s absolute pathname (/bin/su) when you use it. (Of course, if someone has compromised your system enough that you are running a fake su command, you are in serious trouble anyway-but using an absolute pathname for su is still a good idea.)
When you give an su command to become Superuser, you spawn a new shell, which displays the # prompt. You return to your normal status (and your former shell and prompt) by terminating this shell: Press CONTROL-D or give an exit command. Giving an su command by itself changes your user and group IDs but makes minimal changes to your environment. You still have the same PATH you did when you logged in as yourself. When you run a utility that is normally run by root (the utilities in /sbin and /usr/sbin), you may need to specify an absolute pathname for the utility (such as /sbin/service). When you give the command su - (you can use -l or --login in place of the hyphen), you get a root login shell: It is as though you logged in as root. Not only are your user and group IDs the same as those of root, but your entire environment is that of root. The login shell executes the appropriate startup scripts before displaying a prompt, and your PATH is set to what it would be if you had logged in as root, typically including /sbin and /usr/sbin.
Use the id utility to display the changes in your user and group IDs and in the groups you are associated with. In the following example, the information that starts with context pertains to SELinux:
$ id
uid=500(alex) gid=500(alex) groups=500(alex) context=user_u:system_r:unconfined_t
$ su
Password:
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys), ...
You can use su with the -c option to run a single command with root privileges, returning to your original shell when the command finishes executing. The following example first shows that a user is not permitted to kill a process. With the use of su -c and the root password, the user is permitted to kill (page 409) the process. The quotation marks are necessary because su -c takes its command in the form of a single argument.
$ kill -15 4982
-bash: kill: (4982) - Operation not permitted
$ su -c "kill -15 4982"
Password:
$
Superuser, PATH, and security
The fewer directories you keep in your PATH when you are working with root privileges, the less likely you will be to execute an untrusted program as root. If possible, keep only the default directories, along with /sbin and /usr/sbin, in root’s PATH. Never include the working directory (as . or : : anywhere in PATH, or : as the last element of PATH).
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Saturday, August 21, 2010
System Administrator and Superuser
Much of what a system administrator does is work that ordinary users do not have permission to do. When performing one of these tasks, the system administrator logs in as root (or uses another method; see the list starting on page 406) to have systemwide powers that are beyond those of ordinary users: A user with root privileges is referred to as Superuser. The username is root by default. Superuser has the following powers and more:
• Some commands, such as those that add new users, partition hard drives, and change system configuration, can be executed only by root. Superuser can use certain tools, such as sudo, to give specific users permission to perform tasks that are normally reserved for Superuser.
• Read, write, and execute file access and directory access permissions do not affect root: Superuser can read from, write to, and execute all files, as well as examine and work in all directories.
• Some restrictions and safeguards that are built into some commands do not apply to root. For example, root can change any user’s password without knowing the old password.
When you are running with root (Superuser) privileges, the shell by convention displays a special prompt to remind you of your status. By default, this prompt is or ends with a pound sign (#).
When you are working on the computer, especially when you are working as the system administrator, perform any task while using the least privilege possible. When you can perform a task logged in as an ordinary user, do so. When you must be logged in as Superuser, do as much as you can as an ordinary user, log in or use su so you have root privileges, complete the part of the task that has to be done as Superuser, and revert to being an ordinary user as soon as you can. Because you are more likely to make a mistake when you are rushing, this concept becomes more important when you have less time to apply it.
You can gain or grant Superuser privileges in a number of ways:
1. When you bring the system up in single-user mode, you are Superuser.
2. Once the system is up and running in multiuser mode, you can log in as root. When you supply the proper password, you will be Superuser.
3. You can give an su (substitute user) command while you are logged in as yourself and, with the proper password, you will have Superuser privileges.
4. You can use sudo selectively to give users Superuser privileges for a limited amount of time on a per-user and per-command basis. The sudo utility is controlled by the /etc/sudoers file, which must be set up by root. Refer to the sudo man page for more information.
5. Any user can create a setuid (set user ID) file. Setuid programs run on behalf of the owner of the file and have all the access privileges that the owner has. While you are running as Superuser, you can change the permissions of a file owned by root to setuid. When an ordinary user executes a file that is owned by root and has setuid permissions, the program has full root privileges. In other words, the program can do anything root can do and that the program does or allows the user to do. The user’s privileges do not change. When the program finishes running, all user privileges revert to the way they were before the program started. Setuid programs that are owned by root are both extremely powerful and extremely dangerous to system security, which is why a system contains very few of them. Examples of setuid programs that are owned by root include passwd, at, and crontab. The following example shows two ways for Superuser to give a program setuid privileges:
The s in the owner execute position of the ls -l output (page 203) indicates that the file has setuid permission.
6. Some programs ask you for a password (either your password or the root password, depending on the particular command and the configuration of the system) when they start. When you provide the root password, the program runs with root privileges. When a program requests the root password when it starts, you stop running as the privileged user when you quit using the program. This setup keeps you from remaining logged in as Superuser when you do not need or intend to do so.
Some techniques limit the number of ways to become Superuser. For example, PAM controls the who, when, and how of logging in. The /etc/securetty file controls which terminals (ttys) a user can log in on as root. The /etc/security/access.conf file adds another dimension to login control (see the file for details).
root-owned setuid programs are extremely dangerous
Because root-owned setuid programs allow someone who does not know the root password to exercise the powers of Superuser, they are tempting targets for a malicious user. A system should have as few of these programs as possible. You can disable setuid programs at the filesystem level by mounting a filesystem with the nosuid option. You can also use SELinux to disable setuid programs.
Do not allow root access over the Internet
Prohibiting root logins using login over a network is the default policy of Fedora/RHEL and is implemented by the PAM securetty module. The /etc/security/access.conf file must contain the names of all users and terminals/workstations that you want a user to be able to log in on as root. Initially every line in access.conf is commented out.
You can, however, log in as root over a network using ssh. As shipped by Fedora/RHEL, ssh does not follow the instructions in securetty or access.conf. Also, in /etc/ssh/sshd_config, Fedora/RHEL sets PermitRootLogin to YES (it is set by default) to permit root to log in using ssh.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
• Some commands, such as those that add new users, partition hard drives, and change system configuration, can be executed only by root. Superuser can use certain tools, such as sudo, to give specific users permission to perform tasks that are normally reserved for Superuser.
• Read, write, and execute file access and directory access permissions do not affect root: Superuser can read from, write to, and execute all files, as well as examine and work in all directories.
• Some restrictions and safeguards that are built into some commands do not apply to root. For example, root can change any user’s password without knowing the old password.
When you are running with root (Superuser) privileges, the shell by convention displays a special prompt to remind you of your status. By default, this prompt is or ends with a pound sign (#).
When you are working on the computer, especially when you are working as the system administrator, perform any task while using the least privilege possible. When you can perform a task logged in as an ordinary user, do so. When you must be logged in as Superuser, do as much as you can as an ordinary user, log in or use su so you have root privileges, complete the part of the task that has to be done as Superuser, and revert to being an ordinary user as soon as you can. Because you are more likely to make a mistake when you are rushing, this concept becomes more important when you have less time to apply it.
You can gain or grant Superuser privileges in a number of ways:
1. When you bring the system up in single-user mode, you are Superuser.
2. Once the system is up and running in multiuser mode, you can log in as root. When you supply the proper password, you will be Superuser.
3. You can give an su (substitute user) command while you are logged in as yourself and, with the proper password, you will have Superuser privileges.
4. You can use sudo selectively to give users Superuser privileges for a limited amount of time on a per-user and per-command basis. The sudo utility is controlled by the /etc/sudoers file, which must be set up by root. Refer to the sudo man page for more information.
5. Any user can create a setuid (set user ID) file. Setuid programs run on behalf of the owner of the file and have all the access privileges that the owner has. While you are running as Superuser, you can change the permissions of a file owned by root to setuid. When an ordinary user executes a file that is owned by root and has setuid permissions, the program has full root privileges. In other words, the program can do anything root can do and that the program does or allows the user to do. The user’s privileges do not change. When the program finishes running, all user privileges revert to the way they were before the program started. Setuid programs that are owned by root are both extremely powerful and extremely dangerous to system security, which is why a system contains very few of them. Examples of setuid programs that are owned by root include passwd, at, and crontab. The following example shows two ways for Superuser to give a program setuid privileges:
# ls -l my*
-rwxr-xr-x 1 root other 24152 Apr 29 16:30 myprog
-rwxr-xr-x 1 root other 24152 Apr 29 16:31 myprog2
# chmod 4755 myprog
# chmod u+s myprog2
# ls -l my*
-rwsr-xr-x 1 root other 24152 Apr 29 16:30 myprog
-rwsr-xr-x 1 root other 24152 Apr 29 16:31 myprog2
The s in the owner execute position of the ls -l output (page 203) indicates that the file has setuid permission.
6. Some programs ask you for a password (either your password or the root password, depending on the particular command and the configuration of the system) when they start. When you provide the root password, the program runs with root privileges. When a program requests the root password when it starts, you stop running as the privileged user when you quit using the program. This setup keeps you from remaining logged in as Superuser when you do not need or intend to do so.
Some techniques limit the number of ways to become Superuser. For example, PAM controls the who, when, and how of logging in. The /etc/securetty file controls which terminals (ttys) a user can log in on as root. The /etc/security/access.conf file adds another dimension to login control (see the file for details).
root-owned setuid programs are extremely dangerous
Because root-owned setuid programs allow someone who does not know the root password to exercise the powers of Superuser, they are tempting targets for a malicious user. A system should have as few of these programs as possible. You can disable setuid programs at the filesystem level by mounting a filesystem with the nosuid option. You can also use SELinux to disable setuid programs.
Do not allow root access over the Internet
Prohibiting root logins using login over a network is the default policy of Fedora/RHEL and is implemented by the PAM securetty module. The /etc/security/access.conf file must contain the names of all users and terminals/workstations that you want a user to be able to log in on as root. Initially every line in access.conf is commented out.
You can, however, log in as root over a network using ssh. As shipped by Fedora/RHEL, ssh does not follow the instructions in securetty or access.conf. Also, in /etc/ssh/sshd_config, Fedora/RHEL sets PermitRootLogin to YES (it is set by default) to permit root to log in using ssh.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Saturday, July 17, 2010
Linux System Network
A Linux system attached to a network is probably communicating on an Ethernet, which may in turn be linked to other local area networks (LANs) and wide area networks (WANs). Communication between LANs and WANs requires the use of gateways and routers. Gateways translate the local data into a format suitable for the\ WAN, and routers make decisions about the optimal routing of the data along the way. The most widely used network, by far, is the Internet.
Basic networking tools allow Linux users to log in and run commands on remote systems (ssh, telnet) and copy files quickly from one system to another (scp, ftp/sftp). Many tools that were originally designed to support communication on a singlehost computer (for example, finger and talk) have since been extended to recognize network addresses, thus allowing users on different systems to interact with one another. Other features, such as the Network Filesystem (NFS), were created to extend the basic UNIX model and to simplify information sharing.
Concern is growing about our ability to protect the security and privacy of machines connected to networks and of data transmitted over networks. Toward this end, many new tools and protocols have been created: ssh, scp, HTTPS, IPv6, firewall hardware and software, VPN, and so on. Many of these tools take advantage of newer, more impenetrable encryption techniques. In addition, some weaker concepts (such as that of trusted hosts) and some tools (such as finger and rwho) are being discarded in the name of security.
Computer networks offer two major advantages of over other ways of connecting computers: They enable systems to communicate at high speeds and they require few physical interconnections (typically one per system, often on a shared cable). The Internet Protocol (IP), the universal language of the Internet, has made it possible for dissimilar computer systems around the world to readily communicate with one another. Technological advances continue to improve the performance of computer systems and the networks that link them.
One way to gather information on the Internet is via Usenet. Many Linux users routinely peruse Usenet news (netnews) to learn about the latest resources available for their systems. Usenet news is organized into newsgroups that cover a wide range of topics, computer-related and otherwise. To read Usenet news, you need to have access to a news server and the appropriate client software. Many modern email programs, such as Mozilla and Netscape, can display netnews.
The rapid increase of network communication speeds in recent years has encouraged the development of many new applications and services. The World Wide Web provides access to vast information stores on the Internet and makes extensive use of hypertext links to promote efficient searching through related documents. It adheres to the client/server model that is so pervasive in networking. Typically the WWW client is local to a site or is made available through an Internet service provider. WWW servers are responsible for providing the information requested by their many clients.
Mozilla/Firefox is a WWW client program that has enormous popular appeal. Firefox and other browsers use a GUI to give you access to text, picture, and audio information: Making extensive use of these hypermedia simplifies access to and enhances the presentation of information.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Basic networking tools allow Linux users to log in and run commands on remote systems (ssh, telnet) and copy files quickly from one system to another (scp, ftp/sftp). Many tools that were originally designed to support communication on a singlehost computer (for example, finger and talk) have since been extended to recognize network addresses, thus allowing users on different systems to interact with one another. Other features, such as the Network Filesystem (NFS), were created to extend the basic UNIX model and to simplify information sharing.
Concern is growing about our ability to protect the security and privacy of machines connected to networks and of data transmitted over networks. Toward this end, many new tools and protocols have been created: ssh, scp, HTTPS, IPv6, firewall hardware and software, VPN, and so on. Many of these tools take advantage of newer, more impenetrable encryption techniques. In addition, some weaker concepts (such as that of trusted hosts) and some tools (such as finger and rwho) are being discarded in the name of security.
Computer networks offer two major advantages of over other ways of connecting computers: They enable systems to communicate at high speeds and they require few physical interconnections (typically one per system, often on a shared cable). The Internet Protocol (IP), the universal language of the Internet, has made it possible for dissimilar computer systems around the world to readily communicate with one another. Technological advances continue to improve the performance of computer systems and the networks that link them.
One way to gather information on the Internet is via Usenet. Many Linux users routinely peruse Usenet news (netnews) to learn about the latest resources available for their systems. Usenet news is organized into newsgroups that cover a wide range of topics, computer-related and otherwise. To read Usenet news, you need to have access to a news server and the appropriate client software. Many modern email programs, such as Mozilla and Netscape, can display netnews.
The rapid increase of network communication speeds in recent years has encouraged the development of many new applications and services. The World Wide Web provides access to vast information stores on the Internet and makes extensive use of hypertext links to promote efficient searching through related documents. It adheres to the client/server model that is so pervasive in networking. Typically the WWW client is local to a site or is made available through an Internet service provider. WWW servers are responsible for providing the information requested by their many clients.
Mozilla/Firefox is a WWW client program that has enormous popular appeal. Firefox and other browsers use a GUI to give you access to text, picture, and audio information: Making extensive use of these hypermedia simplifies access to and enhances the presentation of information.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Friday, July 16, 2010
RPC Network Services
Much of the client/server interaction over a network is implemented using the RPC (Remote Procedure Call) protocol, which is implemented as a set of library calls that make network access transparent to the client and server. RPC specifies and interprets messages but does not concern itself with transport protocols; it runs on top of TCP/IP and UDP/IP. Services that use RPC include NFS and NIS. RPC was developed by Sun as ONC RPC (Open Network Computing Remote Procedure Calls) and differs from Microsoft RPC.
In the client/server model, a client contacts a server on a specific port to avoid any mixup between services, clients, and servers. To avoid maintaining a long list of port numbers and to enable new clients/servers to start up without registering a port number with a central registry, when a server that uses RPC starts, it specifies the port it expects to be contacted on. RPC servers typically use port numbers that have been defined by Sun. If a server does not use a predefined port number, it picks an arbitrary number.
The server then registers this port with the RPC portmapper (the rpcbind [FEDORA] or portmap [RHEL] daemon) on the local system. The server tells the daemon which port number it is listening on and which RPC program numbers it serves. Through these exchanges, the portmapper learns the location of every registered port on the host and the programs that are available on each port. The rpcbind/portmap daemon, which always listens on port 111 for both TCP and UDP, must be running to make RPC calls.
The /etc/rpc file maps RPC services to RPC numbers. The /etc/services file lists system services.
The sequence of events for communication between an RPC client and server occurs as follows:
1. The client program on the client system makes an RPC call to obtain data from a (remote) server system. (The client issues a “read record from a file” request.)
2. If RPC has not yet established a connection with the server system for the client program, it contacts rpcbind/portmap on port 111 of the server and asks which port the desired RPC server is listening on (for example, rpc.nfsd).
3. The rpcbind/portmap daemon on the remote server looks in its tables and returns a UDP/TCP port number to the local system, the client (typically 2049 for nfs).
4. The RPC libraries on the server system receive the call from the client and pass the request to the appropriate server program. The origin of the request is transparent to the server program. (The filesystem receives the “read record from file” request.)
5. The server responds to the request. (The filesystem reads the record.)
6. The RPC libraries on the remote server return the result over the network to the client program. (The read record is returned to the calling program.)
Because standard RPC servers are normally started by the xinetd daemon, the portmap daemon must be started before the xinetd daemon is invoked. The init scripts make sure portmap starts before xinetd. You can confirm this sequence by looking at the numbers associated with /etc/rc.d/*/S*portmap and /etc/rc.d/*/S*/xinetd. If the portmap daemon stops, you must restart all RPC servers on the local system.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
In the client/server model, a client contacts a server on a specific port to avoid any mixup between services, clients, and servers. To avoid maintaining a long list of port numbers and to enable new clients/servers to start up without registering a port number with a central registry, when a server that uses RPC starts, it specifies the port it expects to be contacted on. RPC servers typically use port numbers that have been defined by Sun. If a server does not use a predefined port number, it picks an arbitrary number.
The server then registers this port with the RPC portmapper (the rpcbind [FEDORA] or portmap [RHEL] daemon) on the local system. The server tells the daemon which port number it is listening on and which RPC program numbers it serves. Through these exchanges, the portmapper learns the location of every registered port on the host and the programs that are available on each port. The rpcbind/portmap daemon, which always listens on port 111 for both TCP and UDP, must be running to make RPC calls.
The /etc/rpc file maps RPC services to RPC numbers. The /etc/services file lists system services.
The sequence of events for communication between an RPC client and server occurs as follows:
1. The client program on the client system makes an RPC call to obtain data from a (remote) server system. (The client issues a “read record from a file” request.)
2. If RPC has not yet established a connection with the server system for the client program, it contacts rpcbind/portmap on port 111 of the server and asks which port the desired RPC server is listening on (for example, rpc.nfsd).
3. The rpcbind/portmap daemon on the remote server looks in its tables and returns a UDP/TCP port number to the local system, the client (typically 2049 for nfs).
4. The RPC libraries on the server system receive the call from the client and pass the request to the appropriate server program. The origin of the request is transparent to the server program. (The filesystem receives the “read record from file” request.)
5. The server responds to the request. (The filesystem reads the record.)
6. The RPC libraries on the remote server return the result over the network to the client program. (The read record is returned to the calling program.)
Because standard RPC servers are normally started by the xinetd daemon, the portmap daemon must be started before the xinetd daemon is invoked. The init scripts make sure portmap starts before xinetd. You can confirm this sequence by looking at the numbers associated with /etc/rc.d/*/S*portmap and /etc/rc.d/*/S*/xinetd. If the portmap daemon stops, you must restart all RPC servers on the local system.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Thursday, July 15, 2010
Proxy Servers
A proxy is a network service that is authorized to act for a system while not being part of that system. A proxy server or proxy gateway provides proxy services; it is a transparent intermediary, relaying communications back and forth between an application, such as a browser and a server, usually outside of a LAN and frequently on the Internet. When more than one process uses the proxy gateway/server, the proxy must keep track of which processes are connecting to which hosts/servers so that it can route the return messages to the proper process. The most commonly encountered proxies are email and Web proxies.
A proxy server/gateway insulates the local computer from all other computers or from specified domains by using at least two IP addresses: one to communicate with the local computer and one to communicate with a server. The proxy server/gateway examines and changes the header information on all packets it handles so that it can encode, route, and decode them properly. The difference between a proxy gateway and a proxy server is that the proxy server usually includes cache to store frequently used Web pages so that the next request for that page is available locally and quickly; a proxy gateway typically does not use cache. The terms “proxy server” and “proxy gateway” are frequently used interchangeably.
Proxy servers/gateways are available for such common Internet services as HTTP, HTTPS, FTP, SMTP, and SNMP. When an HTTP proxy sends queries from local systems, it presents a single organization wide IP address (the external IP address of the proxy server/gateway) to all servers. It funnels all user requests to the appropriate servers and keeps track of them. When the responses come back, the HTTP proxy fans them out to the appropriate applications using each machine’s unique IP address, thereby protecting local addresses from remote/specified servers.
Proxy servers/gateways are generally just one part of an overall firewall strategy to prevent intruders from stealing information or damaging an internal network. Other functions, which can be either combined with or kept separate from the proxy server/gateway, include packet filtering, which blocks traffic based on origin and type, and user activity reporting, which helps management learn how the Internet is being used.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
A proxy server/gateway insulates the local computer from all other computers or from specified domains by using at least two IP addresses: one to communicate with the local computer and one to communicate with a server. The proxy server/gateway examines and changes the header information on all packets it handles so that it can encode, route, and decode them properly. The difference between a proxy gateway and a proxy server is that the proxy server usually includes cache to store frequently used Web pages so that the next request for that page is available locally and quickly; a proxy gateway typically does not use cache. The terms “proxy server” and “proxy gateway” are frequently used interchangeably.
Proxy servers/gateways are available for such common Internet services as HTTP, HTTPS, FTP, SMTP, and SNMP. When an HTTP proxy sends queries from local systems, it presents a single organization wide IP address (the external IP address of the proxy server/gateway) to all servers. It funnels all user requests to the appropriate servers and keeps track of them. When the responses come back, the HTTP proxy fans them out to the appropriate applications using each machine’s unique IP address, thereby protecting local addresses from remote/specified servers.
Proxy servers/gateways are generally just one part of an overall firewall strategy to prevent intruders from stealing information or damaging an internal network. Other functions, which can be either combined with or kept separate from the proxy server/gateway, include packet filtering, which blocks traffic based on origin and type, and user activity reporting, which helps management learn how the Internet is being used.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Wednesday, July 14, 2010
Internet Services
Linux Internet services are provided by daemons that run continuously or by a daemon that is started automatically by the xinetd daemon when a service request comes in. The /etc/services file lists network services (for example, telnet, ftp, and ssh) and their associated numbers. Any service that uses TCP/IP or UDP/IP has an entry in this file. IANA (Internet Assigned Numbers Authority) maintains a database of all permanent, registered services. The /etc/services file usually lists a small, commonly used subset of services. Visit www.rfc.net/rfc1700.html for more information and a complete list of registered services.
Most of the daemons (the executable files) are stored in /usr/sbin. By convention the names of many daemons end with the letter d to distinguish them from utilities (one common daemon whose name does not end in d is sendmail). The prefix in. or rpc. is often used for daemon names. Look at /usr/sbin/*d to see a list of many of the daemon programs on the local system.
To see how a daemon works, consider what happens when you run ssh. The local system contacts the ssh daemon (sshd) on the remote system to establish a connection. The two systems negotiate the connection according to a fixed protocol. Each system identifies itself to the other, and then they take turns asking each other specific questions and waiting for valid replies. Each network service follows its own protocol.
In addition to the daemons that support the utilities described up to this point, many other daemons support system-level network services that you will not typically interact with.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Most of the daemons (the executable files) are stored in /usr/sbin. By convention the names of many daemons end with the letter d to distinguish them from utilities (one common daemon whose name does not end in d is sendmail). The prefix in. or rpc. is often used for daemon names. Look at /usr/sbin/*d to see a list of many of the daemon programs on the local system.
To see how a daemon works, consider what happens when you run ssh. The local system contacts the ssh daemon (sshd) on the remote system to establish a connection. The two systems negotiate the connection according to a fixed protocol. Each system identifies itself to the other, and then they take turns asking each other specific questions and waiting for valid replies. Each network service follows its own protocol.
In addition to the daemons that support the utilities described up to this point, many other daemons support system-level network services that you will not typically interact with.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Saturday, July 10, 2010
Shell
The shell is both a command interpreter and a programming language. As a command interpreter, the shell executes commands you enter in response to its prompt. As a programming language, the shell executes commands from files called shell scripts. When you start a shell, it typically runs one or more startup files.
Running a shell script
Assuming that the file holding a shell script is in the working directory, there are three basic ways to execute the shell script from the command line.
1. Type the simple filename of the file that holds the script.
2. Type a relative pathname, including the simple filename preceded by ./.
3. Type bash followed by the name of the file.
Technique 1 requires that the working directory be in the PATH variable. Techniques 1 and 2 require that you have execute and read permission for the file holding the script. Technique 3 requires that you have read permission for the file holding the script.
Job control
A job is one or more commands connected by pipes. You can bring a job running in the background into the foreground by using the fg builtin. You can put a foreground job into the background by using the bg builtin, provided that you first suspend the job by pressing the suspend key (typically CONTROL-Z). Use the jobs builtin to see which jobs are running or suspended.
Variables
The shell allows you to define variables. You can declare and initialize a variable by assigning a value to it; you can remove a variable declaration by using unset. Variables are local to a process unless they are exported using the export builtin to make them available to child processes. Variables you declare are called user-created variables. The shell also defines keyword variables. Within a shell script you can work with the command line (positional) parameters the script was called with.
Process
Each process has a unique identification (PID) number and is the execution of a single Linux command. When you give it a command, the shell forks a new (child) process to execute the command, unless the command is built into the shell. While the child process is running, the shell is in a state called sleep. By ending a command line with an ampersand (&), you can run a child process in the background and bypass the sleep state so that the shell prompt returns immediately after you press RETURN. Each command in a shell script forks a separate process, each of which may in turn fork other processes. When a process terminates, it returns its exit status to its parent process. An exit status of zero signifies success and nonzero signifies failure.
History
The history mechanism, a feature adapted from the C Shell, maintains a list of recently issued command lines, also called events, that provides a way to reexecute previous commands quickly. There are several ways to work with the history list; one of the easiest is to use a command-line editor.
Command-line editors
When using an interactive Bourne Again Shell, you can edit your command line and commands from the history file, using either of the Bourne Again Shell’s commandline editors (vi[m] or emacs). When you use the vi(m) command-line editor, you start in Input mode, unlike the way you normally enter vi(m). You can switch between Command and Input modes. The emacs editor is modeless and distinguishes commands from editor input by recognizing control characters as commands.
Aliases
An alias is a name that the shell translates into another name or (complex) command.
Aliases allow you to define new commands by substituting a string for the first token of a simple command.
Functions
A shell function is a series of commands that, unlike a shell script, are parsed prior to being stored in memory so that they run faster than shell scripts. Shell scripts are parsed at runtime and are stored on disk. A function can be defined on the command line or within a shell script. If you want the function definition to remain in effect across login sessions, you can define it in a startup file. Like the functions of a programming language, a shell function is called by giving its name followed by any arguments.
Shell features
There are several ways to customize the shell’s behavior. You can use options on the command line when you call bash and you can use the bash set and shopt builtins to turn features on and off.
Command-line expansion
When it processes a command line, the Bourne Again Shell may replace some words with expanded text. Most types of command-line expansion are invoked by the appearance of a special character within a word (for example, a leading dollar sign denotes a variable). See Table 9-6 on page 313 for a list of special characters. The expansions take place in a specific order. Following the history and alias expansions, the common expansions are parameter and variable expansion, command substitution, and pathname expansion. Surrounding a word with double quotation marks suppresses all types of expansion except parameter and variable expansion. Single quotation marks suppress all types of expansion, as does quoting (escaping) a special character by preceding it with a backslash.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Running a shell script
Assuming that the file holding a shell script is in the working directory, there are three basic ways to execute the shell script from the command line.
1. Type the simple filename of the file that holds the script.
2. Type a relative pathname, including the simple filename preceded by ./.
3. Type bash followed by the name of the file.
Technique 1 requires that the working directory be in the PATH variable. Techniques 1 and 2 require that you have execute and read permission for the file holding the script. Technique 3 requires that you have read permission for the file holding the script.
Job control
A job is one or more commands connected by pipes. You can bring a job running in the background into the foreground by using the fg builtin. You can put a foreground job into the background by using the bg builtin, provided that you first suspend the job by pressing the suspend key (typically CONTROL-Z). Use the jobs builtin to see which jobs are running or suspended.
Variables
The shell allows you to define variables. You can declare and initialize a variable by assigning a value to it; you can remove a variable declaration by using unset. Variables are local to a process unless they are exported using the export builtin to make them available to child processes. Variables you declare are called user-created variables. The shell also defines keyword variables. Within a shell script you can work with the command line (positional) parameters the script was called with.
Process
Each process has a unique identification (PID) number and is the execution of a single Linux command. When you give it a command, the shell forks a new (child) process to execute the command, unless the command is built into the shell. While the child process is running, the shell is in a state called sleep. By ending a command line with an ampersand (&), you can run a child process in the background and bypass the sleep state so that the shell prompt returns immediately after you press RETURN. Each command in a shell script forks a separate process, each of which may in turn fork other processes. When a process terminates, it returns its exit status to its parent process. An exit status of zero signifies success and nonzero signifies failure.
History
The history mechanism, a feature adapted from the C Shell, maintains a list of recently issued command lines, also called events, that provides a way to reexecute previous commands quickly. There are several ways to work with the history list; one of the easiest is to use a command-line editor.
Command-line editors
When using an interactive Bourne Again Shell, you can edit your command line and commands from the history file, using either of the Bourne Again Shell’s commandline editors (vi[m] or emacs). When you use the vi(m) command-line editor, you start in Input mode, unlike the way you normally enter vi(m). You can switch between Command and Input modes. The emacs editor is modeless and distinguishes commands from editor input by recognizing control characters as commands.
Aliases
An alias is a name that the shell translates into another name or (complex) command.
Aliases allow you to define new commands by substituting a string for the first token of a simple command.
Functions
A shell function is a series of commands that, unlike a shell script, are parsed prior to being stored in memory so that they run faster than shell scripts. Shell scripts are parsed at runtime and are stored on disk. A function can be defined on the command line or within a shell script. If you want the function definition to remain in effect across login sessions, you can define it in a startup file. Like the functions of a programming language, a shell function is called by giving its name followed by any arguments.
Shell features
There are several ways to customize the shell’s behavior. You can use options on the command line when you call bash and you can use the bash set and shopt builtins to turn features on and off.
Command-line expansion
When it processes a command line, the Bourne Again Shell may replace some words with expanded text. Most types of command-line expansion are invoked by the appearance of a special character within a word (for example, a leading dollar sign denotes a variable). See Table 9-6 on page 313 for a list of special characters. The expansions take place in a specific order. Following the history and alias expansions, the common expansions are parameter and variable expansion, command substitution, and pathname expansion. Surrounding a word with double quotation marks suppresses all types of expansion except parameter and variable expansion. Single quotation marks suppress all types of expansion, as does quoting (escaping) a special character by preceding it with a backslash.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Friday, July 9, 2010
The Bourne Again Shell
The Bourne Again Shell is based on the Bourne Shell which was written by Steve Bourne of AT&T’s Bell Laboratories. Over the years the original Bourne Shell has been expanded but it remains the basic shell provided with many commercial versions of UNIX.
sh Shell
Because of its long and successful history, the original Bourne Shell has been used to write many of the shell scripts that help manage UNIX systems. Some of these scripts appear in Linux as Bourne Again Shell scripts. Although the Bourne Again Shell includes many extensions and features not found in the original Bourne Shell, bash maintains compatibility with the original Bourne Shell so you can run Bourne Shell scripts under bash. On UNIX systems the original Bourne Shell is named sh. On Linux systems sh is a symbolic link to bash ensuring that scripts that require the presence of the Bourne Shell still run. When called as sh, bash does its best to emulate the original Bourne Shell.
Korn Shell
System V UNIX introduced the Korn Shell (ksh), written by David Korn. This shell extended many features of the original Bourne Shell and added many new features. Some features of the Bourne Again Shell, such as command aliases and commandline editing, are based on similar features from the Korn Shell.
POSIX standards
The POSIX (the Portable Operating System Interface) family of related standards is being developed by PASC (IEEE’s Portable Application Standards Committee, www.pasc.org). A comprehensive FAQ on POSIX, including many links, appears at www.opengroup.org/austin/papers/posix_faq.html.
POSIX standard 1003.2 describes shell functionality. The Bourne Again Shell provides the features that match the requirements of this POSIX standard. Efforts are under way to make the Bourne Again Shell fully comply with the POSIX standard. In the meantime, if you invoke bash with the ––posix option, the behavior of the Bourne Again Shell will more closely match the POSIX requirements.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
sh Shell
Because of its long and successful history, the original Bourne Shell has been used to write many of the shell scripts that help manage UNIX systems. Some of these scripts appear in Linux as Bourne Again Shell scripts. Although the Bourne Again Shell includes many extensions and features not found in the original Bourne Shell, bash maintains compatibility with the original Bourne Shell so you can run Bourne Shell scripts under bash. On UNIX systems the original Bourne Shell is named sh. On Linux systems sh is a symbolic link to bash ensuring that scripts that require the presence of the Bourne Shell still run. When called as sh, bash does its best to emulate the original Bourne Shell.
Korn Shell
System V UNIX introduced the Korn Shell (ksh), written by David Korn. This shell extended many features of the original Bourne Shell and added many new features. Some features of the Bourne Again Shell, such as command aliases and commandline editing, are based on similar features from the Korn Shell.
POSIX standards
The POSIX (the Portable Operating System Interface) family of related standards is being developed by PASC (IEEE’s Portable Application Standards Committee, www.pasc.org). A comprehensive FAQ on POSIX, including many links, appears at www.opengroup.org/austin/papers/posix_faq.html.
POSIX standard 1003.2 describes shell functionality. The Bourne Again Shell provides the features that match the requirements of this POSIX standard. Efforts are under way to make the Bourne Again Shell fully comply with the POSIX standard. In the meantime, if you invoke bash with the ––posix option, the behavior of the Bourne Again Shell will more closely match the POSIX requirements.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Thursday, July 8, 2010
The Nautilus Spatial View
Nautilus gives you two ways to work with files: the traditional File Browser view and the innovative. By default, Fedora/RHEL display the Spatial view.
The Nautilus Spatial (as in “having the nature of space”) view has many powerful features but may take some getting used to. It always provides one window per folder. By default, when you open a folder, Nautilus displays a new window.
To open a Spatial view of your home directory, double-click the Home icon on the desktop and experiment as you read this section. If you double-click the Desktop icon in the Spatial view, Nautilus opens a new window that displays the Desktop folder.
A Spatial view can display icons, a list of filenames, or a compact view. To select your preferred format, click View on the menubar and choose Icons, List, or Compact. To create files to experiment with, right-click in the window (not on an icon) to display the Nautilus context menu and select Create Folder or Create Document.
Use SHIFT to close the current window as you open another window
If you hold the SHIFT key down when you double-click to open a new window, Nautilus closes the current window as it opens the new one. This behavior may be more familiar and can help keep the desktop from becoming overly cluttered. If you do not want to use the keyboard, you can achieve the same result by double-clicking the middle mouse button.
Window memory
Move the window by dragging the titlebar. The Spatial view has window memory— that is, the next time you open that folder, Nautilus opens it at the same size and in the same location. Even the scrollbar will be in the same position.
Parent-folders button
The key to closing the current window and returning to the window of the parent directory is the Parent-folders button. Click this button to display the Parent-folders pop-up menu. Select the directory you want to open from this menu. Nautilus then displays in a Spatial view the directory you specified. From a Spatial view, you can open a folder in a traditional view by right-clicking the folder and selecting Browse Folder.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
The Nautilus Spatial (as in “having the nature of space”) view has many powerful features but may take some getting used to. It always provides one window per folder. By default, when you open a folder, Nautilus displays a new window.
To open a Spatial view of your home directory, double-click the Home icon on the desktop and experiment as you read this section. If you double-click the Desktop icon in the Spatial view, Nautilus opens a new window that displays the Desktop folder.
A Spatial view can display icons, a list of filenames, or a compact view. To select your preferred format, click View on the menubar and choose Icons, List, or Compact. To create files to experiment with, right-click in the window (not on an icon) to display the Nautilus context menu and select Create Folder or Create Document.
Use SHIFT to close the current window as you open another window
If you hold the SHIFT key down when you double-click to open a new window, Nautilus closes the current window as it opens the new one. This behavior may be more familiar and can help keep the desktop from becoming overly cluttered. If you do not want to use the keyboard, you can achieve the same result by double-clicking the middle mouse button.
Window memory
Move the window by dragging the titlebar. The Spatial view has window memory— that is, the next time you open that folder, Nautilus opens it at the same size and in the same location. Even the scrollbar will be in the same position.
Parent-folders button
The key to closing the current window and returning to the window of the parent directory is the Parent-folders button. Click this button to display the Parent-folders pop-up menu. Select the directory you want to open from this menu. Nautilus then displays in a Spatial view the directory you specified. From a Spatial view, you can open a folder in a traditional view by right-clicking the folder and selecting Browse Folder.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Wednesday, July 7, 2010
GNUStep
The GNUStep project (www.gnustep.org), which began before both the KDE and GNOME projects, is creating an open-source implementation of the OPENSTEP API and desktop environment. The result is a very clean and fast user interface. The default look of WindowMaker, the GNUStep window manager, is somewhat dated, but it supports themes so you can customize its appearance. The user interface is widely regarded as one of the most intuitive found on a UNIX platform. Because GNUStep has less overhead than GNOME and KDE, it runs better on older hardware. If you are running Linux on hardware that struggles with GNOME and KDE or if you would prefer a user interface that does not attempt to mimic Windows, try GNUStep. WindowMaker is provided in the WindowMaker package.
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition
Subscribe to:
Posts (Atom)