Image of Beginning Google Maps API 3
Image of Modern Operating Systems (3rd Edition)
Image of Android Wireless Application Development
Image of RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302) (Certification Press)

Configure a Host ISO-based Package Repository on a CentOS 7.2 VM

In a recent blog post, I demonstrated how to set up a local RPM repository (repo) in a VMware CentOS 7.2 VM (AKA guest) running under VMware Workstation (AKA the host.) This made the CentOS VM independent of the need for network access w.r.t. RPM package installation. However, the trade off for the ability to install packages without Internet access is the 6 GB plus increase in the size of the VM necessitated for storing all the packages and metadata. Consider the following alternative scenario. You have downloaded the CentOS-7-x86_64-Everything-1511.iso from the CentOS Project or a mirror, used the ISO

Repair Damaged RPM Database

If you encounter any of the following messages: rpmdb: PANIC: fatal region error detected; run recovery error: db3 error(22) from dbenv->open: Invalid argument error: cannot open Packages index using db3 – Invalid argument (22) error: cannot open Packages database in /var/lib/rpm error: rpmdb: damaged header #1439 retrieved — skipping. or a similar RPM-related error message, it is probable that your RPM database is damaged. RPM uses a database to maintain the package dependency information. This database is normally located at /var/lib/rpm. # cd /var/lib/rpm # ls -al total 86420 drwxr-xr-x. 2 root root 4096 Nov 18 21:09 . drwxr-xr-x. 45

YUM Package Installation Updating and Removal Forensics

In previous posts I examined the internals of RPM packages and the RPM database itself. In this post, I explore how to trace RPM package installation, update and removal on Linux distributions which use YUM (YellowDog Update Modified). If you examine /var/log/yum.log, an example of which is shown below, you will note that the date component of each entry includes the day and month but not the year. Feb 15 10:00:44 Updated: ibus-1.5.5-1.fc20.x86_64 Feb 15 10:00:45 Updated: ibus-gtk2-1.5.5-1.fc20.x86_64 Feb 15 10:00:47 Updated: python-boto-2.23.0-1.fc20.noarch Feb 15 10:00:48 Installed: python-dropbox-1.6-4.fc20.noarch Feb 15 10:00:56 Installed: python-crypto-2.6.1-1.fc20.x86_64 Feb 15 10:00:57 Installed: python-paramiko-1.10.1-2.fc20.noarch Feb 15

Fedora 19, Simple-Scan and Canon LiDE Scanners

Recently I updated my Fedora 19 system and all appeared to be well until I wanted to quickly scan in a document to send to a colleague. The scanner I used is my old trustly Canon LiDE 30. Simple-scan refused to work because it claimed that no scanners were detected. Using lsusb, I quickly determined that the scanner was detected: # lsusb Bus 002 Device 004: ID 045e:076c Microsoft Corp. Comfort Mouse 4500 Bus 002 Device 003: ID 045e:0734 Microsoft Corp. Wireless Optical Desktop 700 Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device

Fedora FedUp Does Not Sync Distribution

Fedora FedUp is an excellent tool for upgrading your Fedora system. However you should be aware that it does not currently synchronize your system with the Fedora distribution that you upgraded to. To do that, you need to execute the following command after you finish FedUp-ing your system. # yum distro-sync From the yum man page: distribution-synchronization or distro-sync Synchronizes the installed package set with the latest packages available, this is done by either obsoleting, upgrading or downgrading as appropriate. This will “normally” do the same thing as the upgrade command however if you have the package FOO installed at