Notes on Fedora

Notes on Fedora

Package Management

Fedora uses a software management system called RPM Package Manager, RPM rolls all of the programs, scripts, documentation, configuration files, and data used by a piece of software into a single file called a package. The package also contains metadata describing the package, license, maintainers, and the packages upon which the package depends.


What RPM doesn't provide is dependency resolution: the ability to automatically resolve dependency issues. However, the yum system builds on RPM to provide this capability, automatically searching external repositories to find needed

packages and install them automatically.

Querying the Package Management Database

The RPM package management database is an essential source of information about your system. The database is created when the system is installed and is updated whenever packages are added or removed. As RPM packages are installed on your system, the metadata for those packages is stored in a database that can be queried.

The -q option enables query mode: rpm -ql httpd

RPM query options for package selection

-a Selects all packages.

-f file Selects the package that installed file.

-g pkggroup Selects the packages that belong to pkggroup (such as Applications/Productivity).

--whatprovides capability

Selects packages that provide a certain capability, such as the ability to run perl scripts.

--whatrequires capability Selects packages that require a capability.

Packagename Selects a package with the given name.

to find out which package installed the file /usr/lib/libcdda_interface.so: rpm -qf /usr/lib/libcdda_interface.so

to find out which packages provide smtpdaemon (inbound mail server) capability: rpm -q --whatprovides smtpdaemon

Sometimes, though, you need more information than the name and version number of the packages selected.

--changelog Shows the package changelog, a list of changes to the various versions of the package

-c Shows the configuration files included in the package.

-d Shows the documentation files included in the package.

-l Lists files included in the package.

-i Provides detailed information about the package (description, license, group, origin...)

--provides Lists the capabilities provided by the package.

--requires Lists the capabilities required to successfully use the package.

--scripts Displays pre- and post-installation scripts, and pre- and post-uninstallation scripts.

--triggers Displays the trigger scripts in the package. Trigger scripts are invoked when another, related package is installed or removed.

to see the description of the package that installed /etc/mail/access: rpm -qif /etc/mail/access

To see all of the files installed by the package that installed /usr/lib/libcdda_interface.so:

$ rpm -qlf /usr/lib/libcdda_interface.so

To see all of the other capabilities provided by the package that provides the capability perl:

$ rpm -q --whatprovides perl --provides

If that RPM were on a remote web server or FTP server, you could substitute the URI for the filename:

$ rpm -qlp \ftp://ftp.ntua.gr/pub/video/videolan/testing/vlc-0.7.0-test1/rpm/rh9-fc1/rh9-fc1/vlc/a52dec-0.7.4-4.fr.i386.rpm

RPM packages are compressed archives of files with metadata. The archive is in cpio format, with gzip compression; the metadata is stored in a flexible, easily extensible format for forward- and (limited) backward-compatibility.

When a package is installed, the metadata is copied to the RPM database.

The RPM database is stored in several files in /var/lib/rpm. These databases are in the indexed DBM/GDBM format, which is also used for other configuration databases such as /etc/aliases.db; this indexed format permits high-speed searching.

Converting an RPM to a plain archive

The rpm2cpio command will convert an RPM package to a cpio archive:

$ rpm2cpio gnome-applet-gvid-0.3-1.i386.rpm > gnome-applet.cpio

If you want to extract a specific file from the archive, you can use the cpio command.

$ rpm2cpio gnome-applet-gvid-0.3-1.i386.rpm | cpio -idv

rpm2cpio - Extract cpio archive from RPM Package Manager (RPM) package.

rpm2cpio converts the .rpm file specified as a single argument to a cpio archive on standard out. If a ’-’ argument is given, an rpm stream is read from standard in.

rpm2cpio rpm-1.1-1.i386.rpm

rpm2cpio - < glint-1.0-1.i386.rpm

a damaged RPM database?

Use rpm with the -- rebuilddb option to recover from most forms of database corruption (this can take a while to run).

Installing and Removing Software Using RPM

As well as copying files to the correct locations (or deleting them), rpm checks file integrity, sets permissions, backs up

configuration files, and executes scripts within the affected package and other packages that have asked to be notified of changes (trigger scripts). These scripts can in turn start or stop services, modify configuration files, or perform other operations.

-i package_file Installs a package that is not currently installed.

-U package_file Upgrades an existing package version, or installs the package if it is not currently installed.

-F package_file Freshens an existing installation of the package by upgrading the version. If the package is not currently installed, it remains uninstalled.

-e package Erases the installed package. Unlike the other options, -e requires a package name (httpd), not a package filename (httpd-2.0.54-10.i386.rpm)

To perform a basic installation of a package, use the -i option and supply the name of a package file:

# rpm -ivh httpd-2.0.54-10.i386.rpm

To upgrade the package: # rpm -U httpd-2.0.62-3.i386.rpm

In this case, the upgrade would succeed even if httpd package weren't already present on the system; it would be installed.

To remove the package: # rpm -e httpd

Notice that Only the package name is given, not a package filename.

rpm options for installing and upgrading

--excludedocs Excludes documentation files. This will save some space and may be useful on a small system.

--force

Enables rpm to overwrite files that are part of other packages, reinstall packages already installed, and downgrade instead of upgrade packages.

--oldpackage Permits a downgrade instead of an upgrade.

--relocate olddir=newdir

Relocates files from one directory subtree to another. Useful if you want your binary files, datafiles, or documentation installed into an unusual location. Many Fedora packages are not relocatable.

--test Checks for conflicts and potential problems, but does not make any actual changes to the system.

rpm package-removal (erase) options

--allmatches Erases all packages matching the name given (useful if more than one version is installed).

--test

RPMs are named using the pattern: name-version-packagerelease.arch.rpm

packagerelease

The package version number; if one version of the software has been packaged a few times, this number is incremented while the software version number is left unchanged.

arch

The architecture for which the package is compiled (i386, x86-64, or PPC). For packages that are not compiled (such as Perl, PHP, or bash scripts) or packages that contain only data (such as a font set), noarch is used; for source packages, the architecture is set to src.

installing multiple versions of a package?

It's possible, but it can create a lot of problems. The --force option is required, and it's probably best to relocate the second installation to avoid file conflicts:

# rpm -q httpd

httpd-2.0.54-10.2

# rpm -i --force httpd-2.0.54-10.i386.rpm \ --relocate /=/var/compare/httpd-old

# rpm -q httpd

httpd-2.0.54-10.2

httpd-2.0.54-10

To remove the packages, you'll either need to specify the full package name including the software and package version numbers (e.g., httpd-2.0.54-10 instead of httpd) to delete one specific version, or

use the --allmatches option to remove all versions:

# rpm -e httpd

error: "httpd" specifies multiple packages

# rpm -e --allmatches httpd

Using Repositories

Fedora uses the yum repository system.

Using yum from the command line: yum install abe

To install a package file that is on the local computer, use yum's localinstall command: #yum localinstall /tmp/frodo-9.6.23-4-i386.rpm

Removing software: yum remove httpd

yum can also update software: yum update

For each of the currently installed packages, yum checks to see if a newer version exists in any of the repositories and queues the update of those packages plus the installation of any packages required for dependency resolution.

To update one specific package (and dependencies), list the package name as an argument: yum update httpd

Information and miscellaneous commands for yum

list Lists available packages.

check-update Verifies whether any updates are available. An exit code of 100 indicates that updates are ready for installation.

whatprovides capability | provides capability

Displays the name of any packages that provide the listed capability, which may be an RPM-style capability name or a

filename.

search keyword Searches for a package with keyword in the description, summary, packager name, or package name metadata. The search is case-insensitive.

info package Displays metadata about package (similar to rpm -qi).

deplist package Displays the dependencies of package, including the names of the packages that will resolve those dependencies.

localinstall rpm_file

localupdate rpm_file Installs or removes the package contained in the local rpm_file and, if necessary, resolves any dependencies using the

repositories.

-C Runs the specified command from cache.

Using yum with a GUI

To install the available updates, right-click on the update icon and select Apply Updates (or select Applications -> System Tools -> Software Updater, or enter the command pup).

Fedora Core also provides a tool for graphically installing and removing software, named Pirut. To start this program, select the menu option Applications Add/Remove Software;

Adding repositories

The repositories are configured by files in /etc/yum.repos.d. for example, you can install configuration files for these repositories with this command: # rpm -Uvh http://www.fedorafaq.org/yum

Installing From Source

tar xvzf xmorph_20040717.tar.gz

If the file is compressed with bzip2 (usually indicated by a filename that ends in .tar.bz, .tar.bz2, .tbz, .tb2, or .tbz2), use the j option instead of z to decompress:

tar xvjf xmorph_20040717.tar.bz2; cd xmorph-current

./configure; make; make install

Managing Processes

Monitoring process information graphically in GNOME

The menu item Applications -> System Tools -> System Monitor will run "gnome-system-monitor".

Managing users graphically

The Fedora GUI tool for managing users and groups is "system-config-users", which is accessed through the menu under System -> Administration -> "Users and Groups."

Using Runlevels

Fedora can be booted into different runlevels, each of which starts a specific collection of software for a particular purpose. The most commonly used are runlevel 3, which starts the system with a character-based user interface, and runlevel 5, which starts the system with a graphical user interface.

s (or S) Single-user maintenance mode Emergency system recovery work

0 Halt Stops the system

1 Single-user mode System administration

2(Multiuser without networking) (Not normally used)

3 Multiuser, character-mode Normal system operation without graphical login; useful for servers

5 Graphical Normal system operation with graphical login.

6 Reboot Restarts the system

Changing the runlevel after booting

Use the init command to change to the runlevel of your choice:init 3

Changing the default runlevel

The default runlevel is controlled by a line in the file /etc/inittab: id:5:initdefault:

Creating entries for different runlevels on the boot menu

The boot menu is configured using the file /boot/grub/grub.conf. You can edit this file so that options for various runlevels appear on the boot menu.

Find a Fedora Core entry, the one with the latest kernel. Make an identical copy of it immediately after the original location in the file:

Change the description of the copied section to indicate the runlevel that will be used.

On the kernel line, append the runlevel that you wish to use (this will override the default runlevel in /etc/inittab):

title Fedora(2.6.27.5-117.fc10.i686) - Runlevel 3 - Character mode

root (hd0,0)

kernel /vmlinuz-2.6.27.5-117.fc10.i686 ro root=UUID=f9a1eb61-c1ca-4d27-98d9-05d336ed9065 rhgb quiet 3

initrd /initrd-2.6.27.5-117.fc10.i686.img

Optionally, change the default, timeout, or hiddenmenu options to suit your tastes. hiddenmenu hides the menu until the user presses a key; remove the hiddenmenu line to automatically reveal the menu every time the system is booted.

Once the kernel has fully started up, it runs just one program: init. All other software is started directly or indirectly by init.

If a runlevel is specified in the kernel boot options, init uses that value for the runlevel; otherwise, it obtains a runlevel from the initdefault line in /etc/inittab.

booting without an /etc/inittab file

If the file /etc/inittab doesn't exist, init cannot start the system normally. Runlevel S was created specifically for this purpose; it's the only runlevel that doesn't require /etc/inittab, In fact, init doesn't even ask for a password in runlevel S; it takes you directly to a root command prompt.

To protect against the unauthorized use of runlevel S, it's a good idea to add a password entry to the boot menu.

Generate an encrypted password with the grub-md5-crypt command:

Next, edit the /boot/grub/grub.conf file and add this line at the top, substituting the password generated in step 1:

password --md5 $1$f1z061$j/UEYyBn0e0996w0gjq4k/

using the GUI in runlevel 3

If you log in on a character-mode display, you can start the GUI with this command: startx

To have the GUI start each time you log in, add this command to your ~/.bash_profile: exec startx

Managing and Configuring Services

Fedora starts a number of programs automatically when the system is booted.

Select the menu option System -> Administration -> Services to start the system-config-services tool

Configuring services

ntsysv is a character-mode program similar to system-config-services:

This will configure the current runlevel. To configure a different runlevel, use the --level option: # ntsysv --level 4

Configuring services from the command line

The chkconfig command provides an easy way to enable and disable services. The --list option displays the current service configuration:$ chkconfig --list

If you specify a service name, then only the configuration for that service is shown: $ chkconfig --list httpd

To enable a service in a runlevel, use the --level option to specify the runlevel along with the on argument:

# chkconfig --level 4 httpd on

To disable it, use the off argument: # chkconfig --level 4 httpd off

To reset a service to its default configuration, use the reset argument. The configuration will be reset for the runlevel you specify, or for all runlevels if you don't include a --level option:

# chkconfig --level 4 httpd reset

# chkconfig httpd reset

Managing services from the command line

The service command is used to manage running services, the most common actions are: start, stop, restart,

reload Reload the configuration files for the service after they have been edited.

status Display the current status of the service. This will indicate if the service is stopped or running; depending on the service, additional information may be displayed.

service httpd start|status

Services are managed by scripts in the /etc/rc.d/init.d directory; the name of each script corresponds to the name of the service. Each runlevel has its own directory named /etc/rc.d/rc<X> .d, where <X> is the runlevel.

If you examine a runlevel directory, you'll see names beginning with K or S, followed by a 2-digit number, followed by a service name. All of these files are actually symbolic links to service scripts in /etc/rc.d/init.d.

The scripts that start with S are used to start services, and the scripts that start with K are used to kill (stop) services. K scripts are only used when switching between runlevels after the system has been booted.

The digits in the filename are used to control the sequence in which the scripts are executed. This is essential because some services rely on others; for example, the web server relies on the network being up and running, so the network script must be run first.

When you examine the top of a service script, you will find a comment line containing the keyword chkconfig: followed by three arguments:

$ head /etc/rc.d/rc5.d/S90xfs

chkconfig: 2345 90 10

The first argument (2345) is a list of the runlevels in which this service will run by default; this information is used to initially set up the system and to handle chkconfig's reset argument. If the default for this service is to have it turned off in all runlevels, the value - is used. The second argument is the sequence number (00 through 99) for the start link;

the value 90 shown here means that the name of the start link will be S90xfs. The third argument is the sequence number for the kill link, which in this case yields a kill-link name of K10xfs.

When service scripts are called, they are passed a keyword such as start, stop, restart, or reload, indicating the action the script must take.

creating my own service

Create a service script in /etc/rc.d/init.d. Include a chkconfig line as described in the previous section.

Run the command chkconfig --add service to set up the default service links.

You can then configure your service in the same way as any of the other services, using system-config-services, service, and chkconfig.


Resources:

Fedora Linux: A Complete Guide to Red Hat's Community Distribution


Post a Comment

Labels

Java (159) Lucene-Solr (110) All (60) Interview (59) J2SE (53) Algorithm (37) Eclipse (35) Soft Skills (35) Code Example (31) Linux (26) JavaScript (23) Spring (22) Windows (22) Web Development (20) Tools (19) Nutch2 (18) Bugs (17) Debug (15) Defects (14) Text Mining (14) J2EE (13) Network (13) PowerShell (11) Chrome (9) Continuous Integration (9) How to (9) Learning code (9) Performance (9) UIMA (9) html (9) Design (8) Dynamic Languages (8) Http Client (8) Maven (8) Security (8) Trouble Shooting (8) bat (8) blogger (8) Big Data (7) Google (7) Guava (7) JSON (7) Problem Solving (7) ANT (6) Coding Skills (6) Database (6) Scala (6) Shell (6) css (6) Algorithm Series (5) Cache (5) IDE (5) Lesson Learned (5) Miscs (5) Programmer Skills (5) System Design (5) Tips (5) adsense (5) xml (5) AIX (4) Code Quality (4) GAE (4) Git (4) Good Programming Practices (4) Jackson (4) Memory Usage (4) OpenNLP (4) Project Managment (4) Python (4) Spark (4) Testing (4) ads (4) regular-expression (4) Android (3) Apache Spark (3) Become a Better You (3) Concurrency (3) Eclipse RCP (3) English (3) Firefox (3) Happy Hacking (3) IBM (3) J2SE Knowledge Series (3) JAX-RS (3) Jetty (3) Restful Web Service (3) Script (3) regex (3) seo (3) .Net (2) Android Studio (2) Apache (2) Apache Procrun (2) Architecture (2) Batch (2) Build (2) Building Scalable Web Sites (2) C# (2) C/C++ (2) CSV (2) Career (2) Cassandra (2) Distributed (2) Fiddler (2) Google Drive (2) Gson (2) Html Parser (2) Http (2) Image Tools (2) JQuery (2) Jersey (2) LDAP (2) Life (2) Logging (2) Software Issues (2) Storage (2) Text Search (2) xml parser (2) AOP (1) Application Design (1) AspectJ (1) Bit Operation (1) Chrome DevTools (1) Cloud (1) Codility (1) Data Mining (1) Data Structure (1) ExceptionUtils (1) Exif (1) Feature Request (1) FindBugs (1) Greasemonkey (1) HTML5 (1) Httpd (1) I18N (1) IBM Java Thread Dump Analyzer (1) JDK Source Code (1) JDK8 (1) JMX (1) Lazy Developer (1) Mac (1) Machine Learning (1) Mobile (1) My Plan for 2010 (1) Netbeans (1) Notes (1) Operating System (1) Perl (1) Problems (1) Product Architecture (1) Programming Life (1) Quality (1) Redhat (1) Redis (1) Review (1) RxJava (1) Solutions logs (1) Team Management (1) Thread Dump Analyzer (1) Troubleshooting (1) Visualization (1) boilerpipe (1) htm (1) ongoing (1) procrun (1) rss (1)

Popular Posts