Fedora Daily Package - Focus Weeks

Fedora 9 Week: Package Management from the Command Line

nospam@example.com (Chris Tyler) — Tue, 27 May 2008 00:01:00 -0400

This article is part of Fedora 9 Week.

In Fedora 9, the default package manager has changed from Yum to PackageKit. PackageKit is a system service that can queue package installation and removal requests. In Fedora 9 it works with a Yum-based backend (and can work with other backends on other systems).

To manage packages from the command line in Fedora 9, there are two options available: first, you could continue to use the yum command which is still present. The second option is to use the PackageKit command-line tool, pkcon, which works a lot like the yum command but which interfaces with the PackageKit service.

Like yum, pkcon accepts a subcommand and arguments. Here are some of the more common uses and the closest corresponding yum command:

pkcon command	yum command	description
pkcon search name pattern	yum list pattern	lists packages with names containing pattern (note: with yum it's necessary to specify wildcard astrisks if required.).
pkcon search details pattern	yum search pattern	lists packages with details (including description) containing pattern
pkcon install packageId	yum install packagename	installs the designated package
pkcon install-file filename	yum localinstall filename	installs the designated RPM file, resolving dependencies through yum repositories as required
pkcon update-system	yum update	update all packages on the system for which updates are available
pkcon update packageId	yum update packagename	update only the specified package
pkcon get description packageId	yum info packagename	get detailed information on the specified package
pkcon get depends packageId	yum deplist packagename	display dependency information for a package

Since pkcon queues requests with the PackageManager service, it does not ask for confirmation before proceeding with an installation or removal (which is the default behavior for yum). However, you do have the option of adding the -n option to the command line to enqueue a request without waiting for it to complete.

Fedora 9 Week: Installing Over an Existing System with LVM

nospam@example.com (Chris Tyler) — Mon, 26 May 2008 00:02:00 -0400

This article is part of Fedora 9 Week.

When installing Fedora 9 onto a system which already has a Fedora installation, it can be hard to decide whether to do an upgrade or a full reinstallation. Doing an update preserves virtually all of you data and settings, but doing a reinstallation gives a completely clean slate (at the expense of your data -- even if you use a separate /home filesystem, there are often system settings, web sites, and other data in /etc and /var).

Fortunately, when using logical volume management (the default storage scheme in Fedora), you can choose a middle ground: install the new version of Fedora onto a different logical volume without disturbing the existing LVs. The technique is simple:

1. Ensure that there is some space within your volume group which is not allocated to a logical volume. The easiest way to do this is by booting from the Fedora Live Disc image, and then using system-config-lvm.

2. Start the normal Fedora installer (from the install DVD) and select Instllation (not upgrade). When you reach the partitioning screen, select Create Custom Layout.

3. On the custom layout screen, double-click on your main volume group (named VolGroup00 if you used the default VG naming scheme during the previous Fedora instllation).

4. Select each of our previous filesystems and create a custom mountpoint for each (for example, if you had just one LV filesystem -- the root one, from Fedora 8 -- you may want to mount it as /f8root). Do not format these filesystems. If you have filesystems such as a home that you wish to use, specify the appropriate mountpoint for each (e.g., /home).

5. Create a new logical volume to hold the new root filesystem. Give it a descriptive name such as "f9root" and specify / as the mountpoint. 10 GB is a reasonable minimum size for this filesystem (you can go as small as 4 GB). If you don't already have a /home filesystem, consider creating one in a logical volume to make upgrading easier next time.

6. Click Ok in the Edit LVM Volume Group window to close it. Double-click on your old /boot partition and specify /boot as the mountpoint (consider formatting this partition).

7. Proceed with the installation as usual.

One the system has been fully installed, you can simply copy any needed file from your old system (/f8root) to your new system (/). Once you're certain that you don't need the old filesystem any more, you can remove it (and again, system-config-lvm provides a simple way to do this graphically).

System Recovery Week: Dealing with Disk Images

nospam@example.com (Chris Tyler) — Fri, 07 Dec 2007 00:01:00 -0500

This article is part of System Recovery Week, examining techniques used to perform maintenance or recovery on a Fedora system in special circumstances.

When performing system recovery, it is sometimes useful to capture the data from a disk drive into an image file which can then be manipulated on another system -- this is useful when hardware failure is imminent. You can copy a disk's contents over the network using a command such as:

# ssh -C user@remotehost "cat >disk1.img" </dev/sda

The -C option specifies compression, which may or may not be beneficial, depending on the speed of the network connection and the speed of the local and remote CPUs.

This resulting file (disk1.img in this example) is an exact copy of the data on the original disk. The same type of disk image is used for Xen and KVM virtualization.

The file command will report this type of file as an x86 boot sector:

# file disk1.img
disk1.img: x86 boot sector; partition 2: ID=0x83, starthead 0, startsector 208845, 1012095 sectors; partition 3: ID=0x83, starthead 0, startsector 1220940, 6972210 sectors

You can view the partition table of the disk image using fdisk -l. However, to access the individual partitions within the image, you must first use losetup to make the image accessible as a block device:

# losetup -f -v disk1.img
Loop device is /dev/loop0

This contents of the disk1.img file are now available through the block device /dev/loop0. (The -f option specifies that the first available /dev/loopN device should be used, and the -v enables verbose mode so that you will be told the name of the block device). You can now use kpartx to create a block device for each partition within the image:

# kpartx -a -v /dev/loop0
add map loop0p1 : 0 208782 linear /dev/loop0 63
add map loop0p2 : 0 1012095 linear /dev/loop0 208845
add map loop0p3 : 0 6972210 linear /dev/loop0 1220940

The partition block devices are found in /dev/mapper and are named with the original block device name (loop0) with the letter "p" and the partition number appended. The file -s command will analyze the contents of each partition:

# file -s /dev/mapper/loop0p*
/dev/mapper/loop0p1: Linux rev 1.0 ext3 filesystem data
/dev/mapper/loop0p2: Linux/i386 swap file (new style) 1 (4K pages) size 126510 pages
/dev/mapper/loop0p3: LVM2 (Linux Logical Volume Manager) , UUID: 5zG5aVBny87KnCdsicTz3RQbt3w37db

In this example, the first partition contains a filesystem which may be directly mounted (e.g., with mkdir /mnt/x1 ; mount /dev/mapper/loop0p1 /mnt/x1).

The second partition contains swap space, which is probably not of any interest. The third partition contains an LVM physical volume (PV), so you will need to use vgscan and vgchange to gain access to logical volumes contained therein:

# vgscan
Reading all physical volumes. This may take a while...
Found volume group "zephyr" using metadata type lvm2
Found volume group "main" using metadata type lvm2

# vgchange -ay
2 logical volume(s) in volume group "zephyr" now active
4 logical volume(s) in volume group "main" now active

# file -s /dev/mapper/zephyr-*
/dev/mapper/zephyr-home: Linux rev 1.0 ext3 filesystem data (large files)
/dev/mapper/zephyr-root: Linux rev 1.0 ext3 filesystem data (large files)

Note that in this case the discovered VG name is zephyr. Once these steps have been performed, the zephyr LVs can then be mounted in the usual way to provide access to their contents.

Note: If the volume group (VG) name on the disk image conflicts with the VG name on the host, it may be necessary to rename the VG on the host with the vgrename command in order to access the VG on the disk image. However, renaming the VG on the host can be a tricky task. For this reason, it's strongly recommended that VGs be given unique names when they are originally created -- naming each system's main VG after the hostname is a good practice.

When you are done using the disk image, reverse the procedure to take the disk image out of use:

# vgchange -an zephyr
0 logical volume(s) in volume group "zephyr" now active
# kpartx -d /dev/loop0
# losetup -d /dev/loop0

System Recovery Week: Recovering RAID Devices

nospam@example.com (Chris Tyler) — Thu, 06 Dec 2007 00:01:00 -0500

This article is part of System Recovery Week, examining techniques used to perform maintenance or recovery on a Fedora system in special circumstances.

When you boot from a Fedora installation disc and enter rescue mode, you have the option of having the filesystems from your Fedora installation mounted at /mnt/sysimage. If you do not select this option, or if it fails, RAID devices will not be configured for use (as is also the case with LVM, as discussed yesterday).

On a Fedora system, RAID arrays are managed by the mdadm utility. This program expects the RAID configuration to be available at /etc/mdadm.conf. In order to use mdadm without this configuration file, it is necessary to create a dummy configuration file. This is a multi-step process:

Create a dummy mdadm configuration file containing only the partitions to be scanned for possible RAID elements:

sh-3.2# echo "DEVICE /dev/[hs]d?[0-9]" >/tmp/mdadm.conf
Use mdadm's scanning capability to identify any RAID arrays and array members and append that information to the dummy configuration file:

sh-3.2# mdadm --examine --scan --config=/tmp/mdadm.conf >>/tmp/mdadm.conf
Start the detected arrays:

sh-3.2# mdadm --assemble --scan --config=/tmp/mdadm.con
mdadm: /dev/md0 has been started with 2 drives (out of 3).
You can now perform any RAID recovery tasks that are needed -- adding (or re-adding) elements to arrays, for example. To view the status of your arrays, cat /proc/mdstat.

If you have layered LVM on top of RAID, manually scan for and activate your volume groups as discussed yesterday.

System Recovery Week: Using LVM In Rescue Mode

nospam@example.com (Chris Tyler) — Wed, 05 Dec 2007 00:01:00 -0500

This article is part of System Recovery Week, examining techniques used to perform maintenance or recovery on a Fedora system in special circumstances.

Logical Volume Management (LVM) is a powerful storage system layer which abstracts the logical view of storage from the actual physical layout. It is automatically configured in the default Fedora storage configuration. LVM enables you to grow and shrink volumes, add storage from new devices to existing volumes, and migrate volumes between storage devices, all without taking the system offline. In fact, the system-config-lvm package provides a convenient way to perform all of these operations using a graphical interface.

However, you can't (yet) shrink a filesystem while it is mounted. This isn't a limitation of LVM itself, but of most filesystems, including ext3. To shrink a partition that is always mounted when the system is running -- such as the root filesystem -- it's necessary to boot from another medium, which is where rescue mode comes in (see yesterday's article). It may also be necessary to use rescue mode to recover from some particularly nasty corruption or misconfiguration issues.

To do LVM and filesystem-resizing work within the Fedora rescue mode, boot the rescue mode from disc as usual, but select Skip when the system offers to mount your hard-disk partitions. Unfortunately, this will mean that your volume groups will not be detected or activated, so you will need to do that manually.

The commands normally used for logical volume management such as vgdisplay, pvcreate, and lvreduce are actually symbolic links to a single executable named lvm. These symbolic links are not available in rescue mode, so you must explicitly use the lvm command followed by the operation you wish to perform: if you wish to do a vgscan, for example, enter the command lvm vgscan.

Therefore, to discover and activate all volume groups, you must execute these commands:

sh-3.2# lvm vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
sh-3.2# lvm vgchange -ay
2 logical volume(s) in volume group "VolGroup00" now active

You can display information about the logical volumes using lvm lvs (or lvm lvdisplay for a more verbose display):

sh-3.2# lvm lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
LogVol00 VolGroup00 -wi-a- 28.66G
LogVol01 VolGroup00 -wi-a- 992.00M

Note that the LV and VG names are not very descriptive -- which is why it's a good idea to override the default names during system installation. In this case, we know the approximate size of the LV containing the root filesystem, so we can determine that it is LogVol00 in VolGroup00.

Armed with this information, you can now check (fsck) the filesystem, shrink the filesystem within that logical volume, and then shrink the LV. Because of the potential for rounding errors, it's best to shrink the filesystem to a size slightly smaller than the new LV size, resize the LV, and then grow the filesystem to fully fill the LV:

sh-3.2# e2fsck -f /dev/VolGroup00/LogVol00
e2fsck 1.40.2 (12-Jul-2007)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking refernce counts
Pass 5: Checking group summary information
/dev/VolGroup00/LogVol00: 122967/7514560 files (0.9% non-contiguous), 1113272/7512064 blocks

sh-3.2# resize2fs /dev/VolGroup00/LogVol00 19G
resize2fs 1.40.2 (12-Jul-2007)
Resizing the filesystem on /dev/VolGroup00/LogVol00 to 4980736 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 4980736 blocks long.

sh-3.2# lvm lvresize VolGroup00/LogVol00 --size 20G
WARNING: Reducing active logical volume to 20.00 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce LogVol00? [y/n]: y
Reducing logical volume LogVol00 to 20.00 GB
Logical volume LogVol00 successfully resized

sh-3.2# resize2fs /dev/VolGroup00/LogVol00
resize2fs 1.40.2 (12-Jul-2007)
Resizing the filesystem on /dev/VolGroup00/LogVol00 to 5242880 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 5242880 blocks long.

Note that the operations following the first resize2fs do not need to be performed in rescue mode -- you can reboot the system at that point and continue after the system has booted normally. Earlier versions of the Fedora rescue mode may not set up the symbolic link /dev/VolumeGroup/LogicalVolume, so you may need to refer to /dev/mapper/VolumeGroup-LogicalVolume (e.g., use /dev/mapper/VolGroup00-LogVol00 in place of /dev/VolGroup00/LogVol00).

System Recovery Week: Rescue Mode and Reinstalling Grub

nospam@example.com (Chris Tyler) — Tue, 04 Dec 2007 00:01:00 -0500

This article is part of System Recovery Week, examining techniques used to perform maintenance or recovery on a Fedora system in special circumstances.

When a system is too damaged to permit booting from the hard disk drive, it's necessary to boot from another medium. The Fedora installation discs support a "Rescue mode" in which the system is booted from the CD and the hard disk partitions are optionally mounted for access.

To access this mode, boot from your Fedora install media and select "Rescue installed system" from the boot menu using the arrow keys and Enter or by pressing the R key (if you need to edit the boot options first -- to disable ACPI, for example -- navigate to the Rescue option with the arrow keys and press Tab).

The kerenel will boot from CD and the system will prompt you to select a keyboard style and language from scrollable lists of options. You will then be given the opportunity to enable the network interfaces on the system, either by entering the IP information or by using DHCP.

The system will then present a dialog stating that the rescue environment is about to find and mount the filesystems from your hard disk Fedora installation, and asks if you wish to continue. This is a critical question: if your filesystems are intact and you wish to access the data that is in them, you can select Continue, the default option. If you are concerned about the state of your filesystems and want to ensure that they will not be altered, but still want to access them, select Read-Only. If your filesystems are damaged, you have multiple Fedora installations, or you wish to perform an operation such as reducing the size of the root filesystem, choose Skip. After some additional messages, you will be presented with a root shell prompt.

If you have elected to continue with read/write mounting of your filesystems, all of the files from your Fedora installation should be available under /mnt/sysimage -- so the normal /etc/passwd file will be available at /mnt/sysimage/etc/passwd.

Although regular Fedora commands and utilities are available in rescue mode, most of them will not work because of the altered paths. You can work around this issue by temporarily changing the root directory using the chroot command:

chroot /mnt/sysimage

However, you need to be aware that files within the mounted Fedora filesystems will not have been updated during the rescue mode boot process, including /etc/mtab and /var/log/messages. You can compensate for this by some degree by getting the information from other places (such as dmesg for kernel messages and /proc/mounts for mount information).

If you have been forced to use rescue mode because your system's Grub bootloader code has become damaged or has been overwritten by another bootloader, you can reinstall the Grub bootloader in rescue mode:

Start the Grub shell with the grub command:

# grub
Probing devices to guess BIOS drives. This may take a long time.

GNU GRUB version 0.97 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename.]
grub>
Use the find command to locate the partition containing the boot files by searching for /grub/grub.conf (or /boot/grub/grub.conf if that fails). Grub will report the partition using its own syntax:

grub> find /grub/grub.conf
(hd0,0)
Use the root command to configure the partition from which the boot files are to be loaded (use the partition ID from step 2):

grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
The partition ID from step 2 can be converted to a drive ID by removiing the comma and partition number -- for example, the partition (hd0,0) is on the drive (hd0). Use the setup command with this drive ID to install the Grub bootloader code:

grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... no
Checking if "/grub/stage1" exists... yes
Checking if "/grub/stage2" exists... yes
Checking if "/grub/e2fs_stage1_5" exists... yes
Running "embed /grub/e2fs_stage1_5 (hd0)"... 16 sectors are embedded.
succeeded
Running "install /grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.
Exit the Grub shell with quit:

grub> quit
#

You can also use rescue mode to set the root password, create alternate superuser accounts, or change or remove a boot password. Whether these are important recovery operations or a type of attack depends only on the context in which they are performed. You can slow down such an attack by configuring the system BIOS to boot only from the hard disk and installing a BIOS password, but that can be reset using a motherboard jumper in most cases. The moral of the story: if you don't have physical security, you don't have system security.

When you are finished using rescue mode, type exit or press Ctrl-D twice. The system will then reboot.

System Recovery Week: Single-user mode

nospam@example.com (Chris Tyler) — Mon, 03 Dec 2007 00:02:00 -0500

This article is part of System Recovery Week, examining techniques used to perform maintenance or recovery on a Fedora system in special circumstances.

Figure 1 - Appending single-user mode ("s") to the system boot options.

There are times when a Fedora system will not boot normally, due to the state of the filesystem, the absence of startup files, or incorrect configuration. Most users will never encounter these circumstances, but it's important to know what to do if they arise.

The simplest recovery mode available is "single user" or "maintainence mode". This is a special runlevel which will take you directly into a superuser (root) shell prompt without executing most of the normal system startup scripts. Because this mode boots from the normal filesystems, it will only work when the kernel, initrd (initial ramdisk), and basic filesystem are intact; however, it does not require a valid /etc/inittab, /etc/passwd, or /etc/shadow file or a working set of boot scripts, so it can be used in many situations where a normal boot would fail.

To enter single user mode, interrupt the normal grub boot display (which usually shows a message counting down the seconds until Fedora is booted, or which may show a menu of available operating systems if you have altered the default grub boot configuration) by pressing the spacebar. If you have a boot password, press P and enter the password now.

Press the A key to append boot options to the default kernel, and type a space and the letter s to indicate that you want to enter single-user mode, as shown in Figure 1. Press Enter to continue booting.

Figure 2 - Root shell prompt in single-user mode.

The system will boot and then go directly to a root shell prompt (Figure 2). You can perform any normal administrative functions at this prompt - but since the normal system startup has not taken place, you will not be able to use networking, printing, or other services. If your init scripts are intact, you can start specific services, such as network or cups, using the service command: service nameOfService start

Operations commonly performed in single user mode include:

Selecting a new root password: passwd
Replacing or repairing the /etc/inittab, /etc/passwd, or /etc/shadow files by copying or editing the files
Checking a filesystem which will not start up cleanly during normal boot, using a command such as this (Caution! the command as written here will proceed with all repair operations without asking further questions. This will likely result in a clean filesystem which can be mounted but may in rare cases result in some data loss): fsck -f -y /dev/filesystemDevice

When you are finished using single user mode, exiting the shell with the exit command or Ctrl-D will start a normal system boot. It's usually a better idea to perform a full reboot, using the reboot command.

Note that single user mode presents an extreme security risk: any person who has physical access to your system can use single user mode to gain root (unrestricted) access to your system. A boot password will make it slightly more difficult to execute this type of attack. If you did not create a boot password at installation, you can add one at any time:

Use the grub-md5-crypt command to generate an encrypted version of your selected password:
# grub-md5-crypt
Password: hello
Retype password: hello
$1$gNc9G$BppzXI37ogNVc2aJ8tjSe0
Enter the encrypted password into the top of your Grub configuration file, /boot/grub/grub.conf:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/concord3/f8root
# initrd /initrd-version.img
#boot=/dev/md0
password --md5 $1$gNc9G$BppzXI37ogNVc2aJ8tjSe0
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.23.1-49.fc8)
root (hd0,0)
kernel /vmlinuz-2.6.23.1-49.fc8 ro root=/dev/concord3/f8root rhgb quiet
initrd /initrd-2.6.23.1-49.fc8.img
title Fedora (2.6.23.1-42.fc8)
root (hd0,0)
kernel /vmlinuz-2.6.23.1-42.fc8 ro root=/dev/concord3/f8root rhgb quiet
initrd /initrd-2.6.23.1-42.fc8.img

However, a user with physical access to your machine can circumvent the boot password by booting from another device, as we will see later this week.

Focus Week: System Recovery Week

nospam@example.com (Chris Tyler) — Mon, 03 Dec 2007 00:01:00 -0500

This week is a special Focus Week where we'll be examining the techniques used by experienced system administrators to recover a system or perform special maintainence in unusual circumstances. This will include the use of single-user mode, rescue mode (booted from optical disc), LVM and RAID recovery, and dealing with disk images from other computers.

Fedora 7: Custom Spins with Revisor

nospam@example.com (Chris Tyler) — Wed, 06 Jun 2007 00:01:00 -0400

This week we are diverging from the usual daily themes to present a Focus Week on Fedora 7.

This site, the Fedora Daily Package, is all about the software packages included in Fedora. The latest release of Fedora -- Fedora 7 -- introduces some significant improvements in packaging, including the merge of the Fedora Core and Fedora Extras repositories and the introduction of tools for creating custom distribution spins and live discs.

One of the biggest improvements that Fedora 7 brings is a change in the package repository structure. Previous releases of Fedora had separate Core and Extras repositories:

Core included packages that were 'on-disc' -- distributed on the ISO images -- and almost all of the packages were maintained by Red Hat employees.
Extras packages were not on the main ISO images. They were maintained by a mix of Red Hat and non-Red Hat community members.

Erasing the distinction between these two group of packages opened up the way for any community member to maintain any type of package. It also meant that the package set became too large to fit on a single-sided DVD. Rather than arbitrarily select a group of packages to go on disc, a set of tools was created which can take any set of packages -- including ones from third-party repositories -- and build a custom installation image or a live environment which can be booted and run entirely from optical or USB media.

Continue reading "Fedora 7: Custom Spins with Revisor"

Fedora 7: Installation

nospam@example.com (Chris Tyler) — Mon, 04 Jun 2007 05:10:43 -0400

This week we are diverging from the usual daily themes to present a Focus Week on Fedora 7.

Fedora 7 offers more distribution and installation options than any previous version of Fedora.

The Fedora torrents and mirrors offer seven different Fedora DVD and CD images:

Name	Size	Description
Fedora 7 i386	2.8G	DVD image for installation on 32-bit PCs
Fedora 7 x86_64	3.4G	DVD image for installation on 64-bit PCs
Fedora 7 ppc	3.5G	DVD image for installation on POWER-based systems, including non-Intel Macs
Fedora 7 Live i686	701M	Live CD/DVD with Gnome for 32-bit PCs
Fedora 7 KDE Live i686	688M	Live CD/DVD with KDE for 32-bit PCs
Fedora 7 Live x86_64	781M	Live DVD with Gnome for 64-bit PCs
Fedora 7 KDE Live x86_64	833M	Live DVD with KDE for 64-bit PCs

The Live discs may be used to directly run Fedora without installing it, but they may also be used to perform a minimal installation to hard disk. This minimal installation will not include most server software or large desktop applications such as OpenOffice.org.

The actual Fedora 7 installation process is very similar to the Fedora 6 installation process. If you haven't performed a Fedora installation before, get the free Chapter 1 from my book Fedora Linux: A Complete Guide to Red Hat's Community Distribution on the O'Reilly web site (click the Sample Chapter link).

Network Installation

Many people would like to install Fedora 7 on a system without a working DVD drive. This is easily done using a network installation if you have another Linux system available on the network, as I wrote on the fedora-list yesterday:

Continue reading "Fedora 7: Installation"

Package Management Week: Tips & Tricks

nospam@example.com (Chris Tyler) — Fri, 20 Apr 2007 00:01:00 -0400

This week we are diverging from the usual daily themes to present a Focus Week on Package Management.
This site, the Fedora Daily Package, is all about the software packages included in Fedora Core and Fedora Extras. Fedora includes a number of powerful tools for managing packages, and this week will focus on those tools so that you can get the most out of your system.

Let's wrap up this Focus Week with a some tips and tricks in a Q&A format:

Q: I have an RPM file that did not come from a yum repository. I can install it with rpm -i packagefile, but then I have to solve the dependencies myself. Is there a way to install a package which is not from a repository, but use the yum repository system to resolve dependencies?

A: Yes -- use the yum command localinstall:

# yum localinstall packagefile.rpm

Q: Fedora provides an icon in the notification area/taskbar that shows when packages are available for upgrade. But I run a server, and there's usually no one logged into the GUI. How can I get my system to automatically install the latest updates, so that it is not left vulnerable to known security risks?

A: Configure yum-updatesd to automatically install available updates (click!).

Q: Yum seems dazed and confused, and I think it's due to some bad repository data being cached. How do I fix this?

A: Tell yum to erase cached data:

# yum clean all

Continue reading "Package Management Week: Tips & Tricks"

Package Management Week: Yum Repositories & Plugins

nospam@example.com (Chris Tyler) — Thu, 19 Apr 2007 00:01:00 -0400

Yum resolves dependencies and downloads packages from repositories -- online package libraries. Fedora Core 6 ships with three repositories enabled:

Fedora Core -- the software packages included in Fedora Core 6. These are the packages included on the distribution media (for example, the DVD or CD-ROMs)
Fedora Updates -- updates to the packages in Fedora Core 6
Fedora Extras -- additional software that works with Fedora Core but which is not included on the distribution media

(In Fedora 7, Core and Extras are being merged).

Repository configuration files are stored in in /etc/yum.repos.d. By editing these files, it is possible to change the server(s) used for each repository, use a repository on DVD or hard disk, and enable or disable repositories.

Continue reading "Package Management Week: Yum Repositories & Plugins"

Package Management Week: Using Yum

nospam@example.com (Chris Tyler) — Wed, 18 Apr 2007 00:01:00 -0400

The Yum repository system is layered on top of RPM to facilitate automatic package downloading and dependency resolution. There are seven ways to access Yum repositories in Fedora 6:

the yum command
the pirut graphical installation/removal tool, located on the menus at Applications > Add/Remove Software
the pup package updater, located on the menus at Applications > System Tools > Software Updater
the yum-updatesd service, which normally signals the puplet applet in the notification area to inform the user of the availability of updates, but which can also be configured to automatically update packages or download available updates.
the yum-updateonboot service, which is not installed by default; it automatically updates the system at boot time
the optional kyum graphical interface for yum (a KDE alternative to Pirut)
the yumex graphical tool, which is available in Fedora Extras -- this is a very powerful GUI tool, providing access to some yum features that are not accessible through other GUI tools such as pirut and pup

In today's article I will focus on the first three programs: yum, pirut, and pup.
Continue reading "Package Management Week: Using Yum"

Package Management Week: RPM Queries

nospam@example.com (Chris Tyler) — Tue, 17 Apr 2007 00:01:00 -0400

The venerable rpm utility provides command-line access to the RPM system. With the development of the Fedora repository system, rpm is rarely used for package installation, update, or removal -- yum serves that role -- but rpm is still the best tool for directly querying the local database of installed software.

The rpm query option (-q) provides access to the RPM database. It is used along with options that fall into two distinct categories: those which select the packages for which information is displayed, and those which select the information to be displayed about each of those packages. Here are the most common options:

Options to select files:

Option	Selects...
packagename	The installed package packagename
-a	All installed packages
-f filename	The instaled package that provided filename
--whatprovides capabilityname	The installed package that provides the capability capabilityname
--whatrequires capabilityname	The installed package that depends on the capability capabilityname
--triggeredby packagename	All installed packages that include a trigger script which is triggered by the installation or removal of packagename
-p filename	The uninstalled package file filename

Options to control the information displayed:

Option	Displays...
(nothing)	The package name and version
-l	List of all files in the package
-c	List of config files in the package
-d	List of documentation files in the package
--provides	List of capabilities provided by the package
--requires	List of capabilities required by the package (dependencies)
-i	Detailed metadata about the packages
--scripts	Installation/uninstallation scripts included in the package
--triggers	Trigger scripts included in the package

These arguments can be combined in many different ways. Here are some examples:

Continue reading "Package Management Week: RPM Queries"

Package Management Week: RPM Basics

nospam@example.com (Chris Tyler) — Mon, 16 Apr 2007 00:01:00 -0400

The Fedora linux distribution is comprised of thousands of RPM packages. RPM stands for RPM Package Manager and refers to the package format, the tool used to manage packages, and the overall package system. RPM is important not only to Fedora but to the entire Linux community, because it is the package format specified in ISO 23360, the Linux Standard Base.

An RPM package is a single file containing all of the components necessary to install one feature, such as a software application, a group of related utilities, a driver, or a set or fonts or artwork files. The components contained in an RPM package may include:

software (binaries or scripts)
configuration files
documentation, including manpages, info files, on-line help files, and text files
data such as fonts, artwork, sound files, game levels, and XML stylesheets
sample data files to aid the user in learning how to use an application
scripts which are executed before or after the package is installed, and before or after the package is removed
triggers: scripts which are executed when another package is installed or removed
metadata, or data about the package, including the package name, summary, and description, software version, package revision, build date, packager name, build host, license, source URL (upstream website), and more
a list of the capabilities provided by the package
a list of the package's dependencies -- capabilities required in order to successfully install and use the package

The RPM system tracks installed packages in a local database, which is invaluable to a system administrator -- the database makes it easy to find out what is installed, identify the source of mystery files, determine if files have changed, and check which license applies to a package.

When installing a package, the RPM system can determine when other packages are needed to meet dependencies, but RPM itself cannot determine which packages will solve those dependencies. The yum repository system builds on RPM, permitting dependencies to be solved automatically by searching repositories of packages.

In the next few days we'll examine the Fedora package tools in detail:

Tuesday - Using the rpm command to query the package database as well as install, update, and remove packages.
Wednesday - Using yum repository tools, including yum, pirut, pup, yum-updatesd, and yumex.
Thursday - Enabling and disabling repositories and using yum plugins.
Friday - Package management tips and tricks.