How To Set Up Your Own RPM Repository (repo)

Even if you have more than one system, the benefits of having your own local mirror of RPMs are substantial: faster updates, better synchronization of system packages, etc. It’s also pretty easy to do.

  1. Install createrepo via yum: yum -y install createrepo
    1. You might as well install “repoview”, too:
    2. yum -y install repoview
  2. Install rsync via yum if you don’t have it installed already: yum -y install rsync
  3. Pick a file system and directory to contain your copy of the repository. Remember, this repository will only grow over time, so take that in to consideration. You don’t want to pick a volume that will cripple your entire system if it fills up. In this example, let’s use /export/repos, and create the following directories:
    1. /export/repos/6/x86_64
    2. /export/repos/6/i386
  4. Edit /etc/exports to contain:
    • /export/repos *(ro,sync)
  5. Start the NFS server process:
    • /etc/init.d/nfs start
    • chkconfig –level 345 nfs on
  6. Mount the file system on all of your hosts. I personally use automounter, but it is not required:
    • mount myserver:/export/repos /home/repos
  7. Put together a small script (I have a sample one attached to this post) which will rsync the repository from a known good mirror source to the directory you created in step 3. (rsync_repos.pl)
    • #!/bin/sh
      # rsync (mirror) the latest updates locally.
      # Rich West
      #CREATEREPO=0RSYNC_OPTIONS=” \
      –verbose –progress –stats \
      –delete \
      –archive \
      –exclude debug \
      –exclude repodata”if [ “$1” != “-d” ] || [ “X$2” = “X” ]; then
      echo “Usage: $0 -d <32bit | 64bit | all> [-r]”
      echo
      exit;
      fi
      MIRROR1=/export/repos/6/i386/updates
      MIRROR2=/export/repos/6/x86_64/updates
      RSYNC_HOST=distro.ibiblio.org::distros/fedora/linux/core/updates/6
      rm -rf $MIRROR1/.olddata $MIRROR2/.olddata
      OUTFILE=/tmp/rsync.output

      if [ “$2” = “32bit” ] || [ “$2” = “all” ]; then
      ##
      # Sync up the ‘updates’ tree for the 32bit distribution.
      ##
      /bin/nice /usr/bin/rsync $RSYNC_OPTIONS \
      $RSYNC_HOST/i386/ $MIRROR1 \
      >> $OUTFILE
      ##
      # Build the repo data
      ##
      if [ “$CREATEREPO” = “1” ]; then
      /usr/bin/createrepo -q $MIRROR1
      cd $MIRROR1
      /usr/bin/repoview -q .
      cd /
      fi
      fi

      if [ “$2” = “64bit” ] || [ “$2” = “all” ]; then
      ##
      # Sync up the ‘updates’ tree for the 64 bit distribution
      ##
      /bin/nice /usr/bin/rsync $RSYNC_OPTIONS \
      $RSYNC_HOST/x86_64/ $MIRROR2 \
      >> $OUTFILE
      ##
      # Build the repo data
      ##
      if [ “$CREATEREPO” = “1” ]; then
      /usr/bin/createrepo -q $MIRROR2
      cd $MIRROR2
      /usr/bin/repoview -q .
      cd /
      fi
      fi

  8. Update your yum repo files to point to your local copy of the repository and disable the external ones:
      • Create /etc/yum.repos.d/my.repo:
        • [My-updates]
          name=My Repo Mirror – $releasever – $basearch
          baseurl=file:///home/repos/$releasever/$basearch/updates/
          enabled=1
          gpgcheck=0
      • Disable the Fedora “updates” repo /etc/yum.repos.d/fedora-updates.repo:
        • Change all of the entries to contain “enabled=0”
  9. Create a cronjob to sync your repo and the known-good repo mirror nightly:
    • crontab -e
    • 00 04 * * * /home/root/bin/rsync_repos.pl -d all -r

In my case, I figured the one to keep sync’ed was the one that changed the most: the updates repository. However, your mileage may vary, and you can apply the above to sync’ing just about any repository. I also chose one that used ‘rsync’ versus having to script a bit “wget” or another web mirroring tool.

ext3 journaling: check forced

You get the general feeling that the force is against you. You’re running EXT3, an extension to the old and stable ext2, for that extra buffer: journaling. In the simplest of terms, ext3 prevents those enormous boot-up delays when the volume needs checking due to a crash or other circumstances. EXT3 has the ability to recover the state of the volume from the journal, and, viola! Your boot up is very quick.

However, you’ve now found you’ve been running that server of yours for half a year (180 days) or more and you are happy. You now have the itch to change something which requires a reboot. It pains you to lose that uptime, but the gains are better than holding out for greater up time. You do the necessary work, boot up the machine, and are greeted with a message stating that the volume has gone unchecked for greater than 180 days followed by the dreaded words check forced. This now makes you sit there as it falls back to using the old ext2 file system check that takes forever on large drives.

Unless you formatted these drives by hand, you would never have seen the warning message:

This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Most GUI’s and OS installers hide this information.

So, the trick is to nip this one in the bud by disabling the check. You don’t need it anyhow. Really.

tune2fs -i 0 /dev/hdb1

And your system will never force a check of the volume unless you tell it to.

Foreign Dynamic Disk problems: Give ’em a GreenCard already!

Getting the error that you cannot import a foreign disk? Looked in the Event Viewer’s System Log to find: “A disk group with the specified name already exists”? Not to worry! There is a solution, it just isn’t obvious.

This requires some general comfort with regedt32.exe, and I have only done this under Windows XP Pro.

  1. Fire Up regedt32.exe.
  2. Navigate to : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dmio\Boot Info
  3. Right-mouse click on “Primary Disk Group” and select “delete” to remove it.
  4. Quit the registry editor.
  5. Reboot the machine.

Once the machine comes back up, you can go in to “Disk management” and successfully import the foreign disk.