On Mon, 16 Apr 2007, John Summerfield wrote: > Date: Mon, 16 Apr 2007 07:15:49 +0800 > From: John Summerfield <debian at herakles.homelinux.org> > Reply-To: CentOS mailing list <centos at centos.org> > To: CentOS mailing list <centos at centos.org> > Subject: Re: [CentOS] Scripts to generate exact copy of > CentOS-5.0-i386-bin-DVD.iso from CD images > > Wojtek.Pilorz wrote: > > On Sun, 15 Apr 2007, Akemi Yagi wrote: > > > >> Date: Sun, 15 Apr 2007 06:37:18 -0700 > >> From: Akemi Yagi <amyagi at gmail.com> > >> Reply-To: CentOS mailing list <centos at centos.org> > >> To: CentOS mailing list <centos at centos.org> > >> Subject: Re: [CentOS] Scripts to generate exact copy of > >> CentOS-5.0-i386-bin-DVD.iso from CD images > >> > >> On 4/14/07, Wojtek.Pilorz <wpilorz at bdk.pl> wrote: > >>> I am enclosing scripts and config files to generate exact copy > >>> of CentOS 5.0 i386 installation DVD image, that is > >>> CentOS-5.0-i386-bin-DVD.iso > >>> if you have CD images for i386. > >> I have 2 questions: > >> > >> (1) There is one thing that is puzzling to me. You present an > >> alternative method that makes use of the existing > >> CentOS-5.0-i386-bin-DVD.iso file. In this case (if you already have > >> it), what is the purpose of running the scripts? > > > > You prepare a DVD containing CD images and include scripts to generate DVD > > image - so on one media you have, in a sense, both. Other than that, perhaps > > not much reason. > > > >> (2) The scripts are specific for CentOS 5.0 as you described. What > > The method I use is general. The scripts should be made more general, > > indeed. That would require a bit of planning. > > > >> would it take to make them more generic? > >> Is there any way to achieve > >> the same without having to extract info from the original DVD? > > Actually I did not have DVD image file. I had CD images on local fast mirror > > which I could easily download. > > I downloaded header of DVD image (part containing all directories definition) > > and compared file length and timestamps. > > With CentOS 5.0 it was easy - there were less than 50 files differing, most > > of them needed to be downloaded (specific parts of DVD image). > > > > The file resulting from the tree had SHA1 and MD5 checksums as advertised on > > CentOS mirrors, so I could use it further in the process. > > > > [ > > In case it did not match, I would use sha1 values for image segments from > > bittorrent definition file to find out, where are the differences. > > > > I have scripts that help me with that, but the process is not easy, unless > > one is fluent with perl or similar tool. > > ] > > > > Once I have destination DVD image, the process is quite straighforward, it > > amounts to finding what files should be placed where in the image. To find out > > I run the script which compares SHA1 values for 2K-aligned 2K chunks of > > destination image with SHA1 values of 2K chunks for files supposed to be in the > > image. > > > > If anyone is interested in the tools I use, I can post then (all mine, all GPL). > > > > > >> Akemi > > Best regards, > > > > Wojtek > > Wojtek > > Debian's been using a similar system for years. Their current tool is > called Jigdo-file, and requires special action by the CD/DVD authors. So Yes, I was aware of jigdo. > far as I know, Debian is the only project using Jigdo, though I do know Recently fedora was asking opinions about jigdo. I voted for jigdo. > at least one Linux magazine has used it. > > The Debian special action is to create two files, a .jigdo file and a > .template. Together, they provide a similar function to the .bittorrent > files so many authors do create. > > Jigdo uses the two files and some input from the user to download the > files from one or more (hopefully, local) sites and reconstruct the images. > > It doesn't directly use an existing ISO image, but it can use its > contents if it's mounted. > > Jigdo has some advantages: > 1. I can choose a local download site, my side of the Internet > connexion, where components of the required image can be found. > 2. I can choose more, friendly to my IAP, download sites to get further > packages to fill in for where the most local falls short. > > In contrast, bittorrent chooses its own download sites, and my IAP pays > over and over for the same downloads, even if he has a local copy. > > 3. It uses standard download protocols, http and ftp, that uses ports > most commonly open in firewalls and is practical for everyone. > > In contrast, bittorrent requires special firewall rules and one can't > (and shouldn't) give everyone bittorrent access, even if they have http > and ftp access to the Internet. > > Your use of the so-popular bittorrent images is a big advantage for your Actually I use only bittorent definitionf file *.torrent; I extract SHA1 values for regions of images - this allows me to find out where the differences are. This is needed only if I do not have the image I want to create. Perhaps I would have never tried that If had faster network access. > idea. Whether your use of existing ISO images is an advantage depends, > but it's valuable that you can. > > Do you think you could discuss the matter with Richard Atterer, the > Jigdo guru at Debian? Find whether Would it be possible to combine the Sure, > approaches, so that jigdo-lite (the downloader part) could use the > bittorrent image? If the two approaches could be combined into the one I tried jigdo a few years ago to recreate CD images I needed from files, but at that time it was quite slow and size of files was non-optimal on my data, so I created my own tool, which is not as ambitious as jigdo (just one function - creating ISO 9660 images from files), but works quite fast and reliably for me over last two years or so. I have not tried jigdo since then. > tool, it would be wonderful. Good idea. I am open for discussion, sending code and what is needed to achieve that goal. > > It would also ensure your new tool doesn't get lost. > > > You can find jigdo-file from here: > http://packages.debian.org/stable/utils/jigdo-file > > Thank you, Wojtek