Creating a Trusted Local Repository from which Software Updates can be installed.

Printable View

Show 75 post(s) from this thread on one page

March 8th, 2009
luvr

1 Attachment(s)

Creating a Trusted Local Repository from which Software Updates can be installed.
Abstract.

If you manage multiple PCs running Ubuntu, you will likely want to keep them all updated. Thus, you will want to install the Ubuntu updates to each of them as they become available, and you will have each PC individually download all of the updates from the Ubuntu repositories on the internet. This may, however, be impractical to you—particularly if, e.g., you are on a rather slow internet connection, or if your monthly data transfer volume is severely limited, or if you simply prefer to save the bandwidth.

If you would like to download the updates just once, and further distribute the downloaded files locally, you can set up a Local Repository. Basically, a "repository" is a directory that contains a set of software packages (i.e., ".deb" files, in the case of Debian-based distributions—such as Ubuntu), plus an index file that lists the packages that are available in the directory. Such a repository, however, is considered "untrusted": the software installer (i.e., the "APT" system—which includes the "apt-get" command, the "Synaptic Package Manager," the "Update Manager," etc.) will ignore any package that is present in the repository whenever another copy of the package is available in another, trusted, repository—i.e., most likely, on the internet. To create a trusted repository, you need to take a few extra steps, in addition to creating the index file:
- Create a "release" file, which is a small text file that contains, among other details, a checksum for the index file;
- Generate a digital signature for the release file, to prevent tampering by unauthorised individuals.
Whenever the software installer attempts to use the trusted repository, it will verify if the digital signature for the release file is correct—i.e., if it corresponds to the current contents of the file. If the digital signature is correct, then the installer will trust the contents of the release file—which includes the checksum for the index file. If, subsequently, that checksum corresponds to the current contents of the index file, then the contents of that file can be trusted as well. Finally, the index file includes a checksum for each of the packages made available by the repository, so the packages themselves can be verified too.

Thus, before you can set up a trusted local repository, you will have to make sure that you can generate a digital signature for its release file. To that end, you will have to create a "GPG Key Pair" for yourself, and register it (or, more precisely, its public key part) as a trusted key for APT to use—so that APT can verify any digital signatures that are generated with this key pair (or, more precisely, with its private key part).

Step 1: Generating your GPG Key Pair.

To generate a GPG key pair, start the following command:

Code:

gpg --gen-key

After some introductory text, the program will ask you which type of key you want to create:

Code:

Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only)

Since you will be using your key only for generating digital signatures, you don't need option 1, "DSA and Elgamal," (although it will work fine), but you can get by with a "sign only" key—i.e., option 2, "DSA," or option 5, "RSA." Of these two, RSA is the more powerful, so I suggest you select that:

Code:

Your selection? 5

If you opt for an RSA key, the program will next ask you what size you want for the key; for maximum security, you will most likely want the longest possible key—i.e., 4096 bits (however, longer keys will require more computing resources, so you may prefer a shorter key if your computer is not all too powerful):

Code:

RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096

Next, the program will ask you if you want to attach an expiration date to the key; if you don't, then the key will remain valid indefinitely:

Code:

Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years

For a high-risk key (e.g., a key that you will use to digitally prove your identity), it may be critical to set an appropriate expiration date, but the type of key that you are currently generating doesn't really need an expiration date. The default option—i.e., a key that won't expire—is, therefore, perfectly acceptable. Alternatively, you may prefer the key to expire in, say, 5 years or so:

Code:

Key is valid for? (0) 5y

The program will show you the expiration date and time for the key, and ask you to confirm if that is what you want:

Code:

Key expires at Thu 06 Mar 2014 21:12:03 CET Is this correct? (y/N) Y

Now it's time to specify the "user id" for your new key:

Code:

You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and E-mail Address in this form: "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

The program will ask you for the following three items:
- Real name
  For a key that you will use to prove your identity, you should specify your own real name here.
  In this case, however, you should really avoid using your own name. Technically, you can give the key any name that you like—even something totally unrelated to the function of the key, like "Bart Bogus" or "Teri Hatcher is the Greatest!" or even "Who the Hell is Teri Hatcher, anyway?" will do.
  Since you will be using the key to sign your local Ubuntu repository, you should probably name it "Local Ubuntu Repository" or (if you want to mention the specific Ubuntu release for which you will be using the key) "Local Ubuntu Intrepid Ibex Repository" or some such.
- E-mail address
  You needn't specify an e-mail address for this key.
- Comment
  You needn't specify a comment either.
So, for example:

Code:

Real name: Local Ubuntu Intrepid Ibex Repository E-mail address: Comment: You selected this USER-ID: "Local Ubuntu Intrepid Ibex Repository"

You will get a chance to modify the user id; if you're satisfied with what you entered, then select Okay to continue:

Code:

Change (N)ame, (C)omment, (E)-mail or (O)kay/(Q)uit? O

At this point, the program has all the data that it needs to generate your new key. The key will actually consist of two parts:
- A private (or secret) key—which (as the name suggests) you should keep secret, to prevent "digital identity theft."
  In this case, you don't really reveal your identity, but anyone who gains access to your secret key will be able to create falsely "trusted" software repositories that could be installed on any computer that knows about your key.
- A public key—which you are supposed to distribute to anyone who should be able to verify your identity.
  In this particular case, you will add this public key to the list of trusted keys on any computer on which you want to install the packages from your local repository.
It should be obvious that the secret key should really be kept secret. Therefore, the program will ask you for a "passphrase" (or "password"), which will protect your secret key:

Code:

You need a Passphrase to protect your secret key. Enter passphrase:

Select a sufficiently complex passphrase, but one that you can remember—if you ever forget it, then you will lose access to your secret key, and you will no longer be able to generate any digital signatures with it.

You will have to repeat your passphrase:

Code:

Repeat passphrase:

Finally, the program will begin to compute your new key pair:

Code:

We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, use the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.

You should really follow the advice that the program gives you, and keep your system busy. If you don't, then the program will complain that it cannot generate enough random bytes for your key—and it will make you wait until it can:

Code:

...+++++ Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 182 more bytes) .....................................+++++

Once your new key pair is ready, the program will produce the following output:

Code:

gpg: /home/luvr/.gnupg/trustdb.gpg: trustdb created gpg: key xxxxxxxx marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: next trustdb check due at 2014-03-06 pub 4096R/xxxxxxxx 2009-03-07 [expires: 2014-03-06] Key fingerprint = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx uid Local Ubuntu Intrepid Ibex Repository Note that this key cannot be used for encryption. You may want to use the command "--edit-key" to generate a subkey for this purpose.

The bold, underlined and coloured text, xxxxxxxx, represents the "key id"—which you will have to specify when you export the (public) key, next.

Note:

You can list your keys at any time, with the following command:

Code:

gpg --list-keys

The output will include the key id, as shown below:

Code:

/home/luvr/.gnupg/pubring.gpg ----------------------------- pub 4096R/xxxxxxxx 2009-03-07 [expires: 2014-03-06] uid Local Ubuntu Intrepid Ibex Repository

Step 2: Exporting your newly generated Public Key.

Now that your GPG key pair is ready, you will have to export the public key to a text file, using the following command:

Code:

gpg --output pubkey-export-file --armor --export xxxxxxxx

You should, obviously, replace the pubkey-export-file parameter string with an appropriate name for the output file. Furthermore, the xxxxxxxx parameter represents the key id, as discussed above.

Step 3: Importing your Public Key into the APT List of Trusted Keys.

Note:

You will have to perform this step on every computer on which you want to install software packages from your (yet to be created) local software repository.
You can perform this step at any time, and on as many computers as you deem appropriate.

Make sure that you have the pubkey-export-file (which you created in Step 2, above) available, and execute the following command to import it into the list of keys that will be trusted by APT:

Code:

sudo apt-key add pubkey-export-file

Note:

To verify if the key was successfully imported into APT, you can run the following command:

Code:

sudo apt-key list

Alternatively, you could start the "Software Sources" utility (from the "System" → "Administration" menu) and display its "Authentication" tab page.
Moreover, you can also start the "Software Sources" utility from within the "Synaptic Package Manager," through its "Settings" → "Repositories" menu.

Step 4: Installing the Debian Package Development Tools.

Return to the computer on which you generated your key pair (i.e., where you ran steps 1 and 2 above).

Execute the following command to install the Debian Package Development Tools:

Code:

sudo apt-get install dpkg-dev

Once this package is installed, you will be able to create software package repositories on this system.

Step 5: Creating the Directory Structure for your Local Repository.

You will be setting up a simple repository—i.e., one that consists of just one directory. Complex repositories, consisting of a deeper directory hierarchy, are out of the scope of this document.

As an example, the following commands will create a "LocalRepository" subdirectory under your personal home directory,

Code:

cd mkdir LocalRepository cd LocalRepository

(The first "cd" command will set your current directory to your home location, after which the second command will create the "LocalRepository" subdirectory, and the third command will enter the newly created directory.)

To kickstart your new local repository, you can load it with the software packages that you have recently installed. Whenever you install new software or updates through APT, the required packages will be loaded into the APT cache—i.e., the "/var/cache/apt/archives" directory on your system. You can now copy these packages to your local repository:

Code:

cp /var/cache/apt/archives/*.deb .

(Notice the lone dot (".") at the end of this command—it is required, and is a placeholder for the "current directory." The command effectively copies all Debian packages from the APT cache into your current directory—i.e., into your local repository.)

Note:
If your APT cache does not contain any packages, then be sure to verify the "Temporary Files" setting in the "Synaptic Package Manager," as follows:
- Open "Synaptic Package Manager" ("System" → "Administration" → "Synaptic Package Manager");
- Display its "Preferences" dialogue ("Settings" → "Preferences");
- Display the "Files" tab page;
- Under the "Temporary Files" header, ensure that either "Leave all downloaded packages in the cache" or "Only delete packages which are no longer available" is selected.
Step 6: Creating the Index File for your Local Repository.

Once your local repository contains all the packages that you want to make available through it, you are ready to create the index file for the repository. To that end, run the following command:

Code:

dpkg-scanpackages . /dev/null > Packages

This will create a text file, "Packages," which is the plain-text, uncompressed version of the index file. You should also create a compressed version of the index file, using the following command:

Code:

gzip -9c Packages > Packages.gz

This will create the compressed version, "Packages.gz," of the index file, without deleting the original, uncompressed file.

Step 7: Creating the Release File for your Local Repository.

The release file is a small text file that should contain:
- A header.
  A detailed description of the format of this section is out of the scope of this document, but the following is a simple example of a perfectly valid header:
  
  Code:
  
  Archive: intrepid Origin: Ubuntu Label: Local Ubuntu Intrepid Repository Architecture: i386 MD5Sum:
- Two detail lines—one for the uncompressed "Packages" file, and one for the compressed "Packages.gz" file. The detail lines should be formatted as follows:
  - One blank space;
  - The MD5 checksum for the file, as calculated by the "md5sum" command;
  - One blank space;
  - The size, in bytes, of the file, right-aligned and padded to the left with blanks, in a 16-character field;
  - One blank space;
  - The name of the file.
  The following example shows two valid detail lines:
  
  Code:
  
  d8cd948e0371a338025d3d99f5f9f304 454617 Packages 7e43f7e45a7f49dbb01e659c25997446 109619 Packages.gz
Obviously, it would be an awfully error-prone process if you were to try and manually type in these lines. Hence, an automated process is highly desirable—and, fortunately, not too hard to develop. For example, you can construct the command to generate the detail line for the "Packages" file as follows:
- To calculate the MD5 checksum, run the "md5sum" command:
  
  Code:
  
  $ md5sum Packages d8cd948e0371a338025d3d99f5f9f304 Packages
- You should keep only the checksum value, and drop the file name from the output of the "md5sum" command. To that end, pipe the output through the "cut" command, keeping only the first blank-delimited field:
  
  Code:
  
  $ md5sum Packages | cut --delimiter=' ' --fields=1 d8cd948e0371a338025d3d99f5f9f304
- To obtain the size of the file, you can use the "wc" command with the "--bytes" option:
  
  Code:
  
  $ wc --bytes Packages 454617 Packages
- Again, you need keep only the first blank-delimited field of the output:
  
  Code:
  
  $ wc --bytes Packages | cut --delimiter=' ' --fields=1 454617
- To generate the properly formatted output line, you can use the "printf" command.
  The checksum can be inserted directly into the format string thanks to the "$(...command...)" construct supported by the shell; for the file size, the format string can specify a 16-character decimal number field, and the value can be given as an argument to be substituted into the format string:
  
  Code:
  
  $ printf ' '$(md5sum Packages | cut --delimiter=' ' --fields=1)' %16d Packages\n' \ > $(wc --bytes Packages | cut --delimiter=' ' --fields=1) d8cd948e0371a338025d3d99f5f9f304 454617 Packages
Based on the above description, the following is a command sequence to fully automate the creation of the release file. To generate the header, a so-called "here" document is used--i.e., the input text is copied directly into the command sequence, with a specified marker string (in this case, "EOF") used to mark the end of the document.

Code:

cat > Release <<EOF Archive: intrepid Origin: Ubuntu Label: Local Ubuntu Intrepid Repository Architecture: i386 MD5Sum: EOF printf ' '$(md5sum Packages | cut --delimiter=' ' --fields=1)' %16d Packages\n' \ $(wc --bytes Packages | cut --delimiter=' ' --fields=1) >> Release printf ' '$(md5sum Packages.gz | cut --delimiter=' ' --fields=1)' %16d Packages.gz' \ $(wc --bytes Packages.gz | cut --delimiter=' ' --fields=1) >> Release

Step 8: Generating the Digital Signature for the Release File.

The digital signature for the release file should be written to a file named "Release.gpg," using the following command:

Code:

gpg --armor --detach-sign --output Release.gpg Release

With this step, your local repository is ready for use.

Step 9: Adding your Local Repository as an APT Source.

Now that your local repository is fully set up, you can copy it to any computer on which you want to use it, and add it to its APT source configuration file, "/etc/apt/sources.list."

You will need root privileges to edit the "/etc/apt/sources.list." file—therefore, if you want to start up your text editor (e.g., "gedit") from a terminal, you should run the command as follows:

Code:

sudo gedit /etc/apt/sources.list

Alternatively, you can start the text editor from the GNOME desktop environment by pressing <Alt>-<F2> to display the "Run Application" dialog, and typing the following command:

Code:

gksudo gedit /etc/apt/sources.list

At the top of the file, add a definition for the local repository, as follows:

Code:

deb file:///home/luvr/LocalRepository /

(Note that you should, of course, specify the correct path to your repository on the "file://" protocol.)

Finally, you should let APT update its internal package index:

Code:

sudo apt-get update

(Alternatively, you can execute the "Reload" function in "Synaptic Package Manager.")

Epilogue: Keeping your Local Repository Up-To-Date.

From now on, whenever you perform any further software installations through APT, you should perform the following steps to keep your local repository updated:
- Copy the downloaded packages from the APT cache to your local repository;
- Recreate the repository index and release files, and generate a new digital signature.
To fully automate this process, you can execute the "update-repository" script file, which you can find attached as a zip archive file to this post.

References.
- How to create a "it really works!" local repository of packages.
- Debian Repository HOWTO.
- For a different approach to creating a local repository, see BobSongs' tutorial on How to make your own Ubuntu Repository DVDs.
  For my two cents' worth on how the two methods compare, see Post #204 of that thread.
  Furthermore:
  - In Post #236 of that thread, I explain how to use "debmirror" to create a trusted local Ubuntu mirror.
  - In Post #243 of that thread, I explain how to create a trusted local Ubuntu mirror from a set of Ubuntu Repository DVDs.
- ADDENDUM: Removing Old Package Versions from your Local Repository. (This is a link to post #12 in this thread.)
- ADDENDUM: Installing the "msttcorefonts" Package without Internet Access. (This is a link to post #17 in this thread.)
- ADDENDUM: Transferring your GPG Key Pair to Another Computer. (This is a link to post #21 in this thread.)
- ADDENDUM: Installing the Flash Player Plugin without Internet Access. (This is a link to post #27 in this thread.)
March 22nd, 2009
Mark1959

Re: Creating a Trusted Local Repository from which Software Updates can be installed.

Thank you for putting together such a clear HOW TO.

It is so helpful for us noobs to be able to learn by following such instruction.

Would you be able to clarify the process where one is trying to share the repository on a network ?

I have three computers sharing using SAMBA both are Ubuntu 8.10 OS and whilst I can easily manually copy the repository to both machines that seems a bit agricultural.

Should I set up some kind of synchronisation or mirroring of the file systems - this would be good since I could also keep things like books marks consistent between machines.

Would the better approach be to have the main computer as the central library and address as per step 9;

"At the top of the file, add a definition for the local repository, as follows:
Code:

deb file:///home/luvr/LocalRepository /

with an appropriate network address.

I do realize this is a very elementary level of query. It is possible I am attempting this in totally the wrong way. I would be great full for just a pointer in the right direction.

Thank You in Anticipation.
March 22nd, 2009
luvr

Re: Creating a Trusted Local Repository from which Software Updates can be installed.

Quote:

Originally Posted by Mark1959

Would you be able to clarify the process where one is trying to share the repository on a network ?

I have three computers sharing using SAMBA both are Ubuntu 8.10 OS and whilst I can easily manually copy the repository to both machines that seems a bit agricultural.

To be honest, I haven't given SAMBA much thought so far. In my case, the local repository is particularly useful because I'm trying to keep multiple Ubuntu systems updated that are on different locations, and some of them have rather slow internet connections (I once attempted an update that included a new kernel on one of these, and it took over two hours to download the new package versions!). I'm using a USB disk to transport the contents of my local repository between systems; I do, however, keep local copies of the repository on each machine, and I use the Unison file synchronisation tool to ensure that only new and changed files will be copied over whenever I update either the USB disk or the local copies on each of the computers.

Having said that (and assuming that you have a SAMBA share available that you can access from all of your computers), you can create your local repository somewhere on the shared directory tree, and specify the path to it in your sources.list file--in the very same way that you would specify a repository on a local disk.

For example, if your SAMBA share is mounted at "/server/samba/share" and your repository is in directory "LocalRepository" within the share, you could simply write:

Code:

deb file:///server/samba/share/LocalRepository /

If you want to ensure that the SAMBA share will get automatically mounted whenever you boot up, then you will have to become familiar with the /etc/fstab file, in which you will have to specify that the share be automounted. (Obviously, you will have to ensure that the machine that serves the SAMBA share is up and running, too, since otherwise, the share will not be accessible.)

Quote:

Should I set up some kind of synchronisation or mirroring of the file systems - this would be good since I could also keep things like books marks consistent between machines.

I'm afraid I cannot offer much detailed advice on this, but I believe it should be possible to set up your "/home" directory on, e.g., a SAMBA share, and have all of your computers point there for their "/home" locations. Then, whichever computer you log on to, you will get the exact same personal settings (from the shared directory). Note that the "/home" location will have to be automounted when the system boots, so it will have to be specified in the /etc/fstab file (which I hinted at above).

Quote:

Would the better approach be to have the main computer as the central library and address as per step 9;

"At the top of the file, add a definition for the local repository, as follows:

Code:

deb file:///home/luvr/LocalRepository /

with an appropriate network address.

Whether you set up your local repository on a separate server (e.g., the one that serves your SAMBA share), or on whichever machine that you designate as your "main" computer, doesn't really matter--both solutions will work equally well. You could set up a SAMBA share on your "main" computer as well, and work from there.

There's also the option of setting up an HTTP or FTP repository on your local network, but I haven't looked into these features yet, and I cannot really tell you much more about them.

I hope this answers at least some of your questions, or that it offers you the right pointers to get you started.
March 25th, 2009
Geochelone

Re: Creating a Trusted Local Repository from which Software Updates can be installed.

How to make apt prefer this trusted local repositories instead of Internet? When I disable my network, apt will get the packages from local repo, which is ultra snappy.

However, when I enable my network, apt will get the packages from Internet, instead of local repo.

For example, I want to install restricted extras. When network is disabled, installation is blazing fast, however without flash player and ms core fonts. When network is enabled, installation is slow (as apt downloads the packages from Internet).

Thus, how to make apt to fetch packages from local repo, unless the packages aren't available locally?
March 25th, 2009
luvr

Re: Creating a Trusted Local Repository from which Software Updates can be installed.

Quote:

Originally Posted by Geochelone

How to make apt prefer this trusted local repositories instead of Internet?

First, you will have to ensure that your public key was successfully imported into the APT list of public keys on the computer where you want to use the repository. (If it wasn't, then you will get some warning to the effect that the digital signature could not be verified.)

Next, ensure that the local repository was added to the /etc/apt/sources.list file on the computer. Also make sure, however, that the local repository is specified first; if the system finds the same package in multiple places (e.g., once in your local repository, and once in a repository on the internet), it will load it from the first location in the sources.list file where it finds the package. In other words, if the internet repository is specified before the local repository in sources.list, then the internet repository will be preferred; the local repository will be used only if the system cannot access the internet repository.
March 28th, 2009
luvr

Re: Creating a Trusted Local Repository from which Software Updates can be installed.

Quote:

Originally Posted by Geochelone

flash player and ms core fonts.

This is a little detail that I missed upon first reading of your reply.

I'm not sure about Flash Player, but the msttcorefonts package will download its font files from the internet when you install it; these files are not integrated into the package itself. That's why, even if the package itself gets installed from a local repository, it will still download a bunch of files from the internet. I'm sure there must be a way to install the fonts from local copies of the font files, but I haven't looked into this issue deeply enough to understand how exactly it would be done.
March 29th, 2009
BobSongs

Re: Creating a Trusted Local Repository from which Software Updates can be installed.

luvr: I've added your tutorial as a cross reference on my tutorial. I like the topic (closely related) and particularly the patience in your layout and writing. I hope we can point to each other's tutorials as long as they continue here.

Bob
March 29th, 2009
luvr

Re: Creating a Trusted Local Repository from which Software Updates can be installed.

I found more information on:

Quote:

Originally Posted by Geochelone

flash player and ms core fonts.

Specifically, how to install the Microsoft TrueType Core Fonts on a computer that has no access to the internet: msttcorefonts on standalone machine.
April 11th, 2009
Geochelone

Re: Creating a Trusted Local Repository from which Software Updates can be installed.

Oh hay!

I'm trying to make the bash script run-able from anywhere in my laptop. So I mod it here and there. And I hit some bumps.

Here is the modded script.

Code:

#!/bin/sh # DECLARE L1=/media/Tortoise/Repositories/Jaunty/Canonical #******************************************************************************************************************************* #* * #* Generate the "Packages" index file. * #* * #******************************************************************************************************************************* dpkg-scanpackages $L1 /dev/null > $L1/Packages #******************************************************************************************************************************* #* * #* Create the "Packages.gz" compressed index file. * #* * #******************************************************************************************************************************* gzip -9c $L1/Packages > $L1/Packages.gz #******************************************************************************************************************************* #* * #* Create the "Release" file. * #* * #******************************************************************************************************************************* cat > Release <<EOF Archive: Intrepid Origin: Ubuntu Label: Official Architecture: i386 MD5Sum: EOF printf ' '$(md5sum $L1/Packages | cut --delimiter=' ' --fields=1)' %16d /media/Tortoise/Repositories/Jaunty/Canonical/Packages\n' $(wc --bytes $L1/Packages | cut --delimiter=' ' --fields=1) >> $L1/Release printf ' '$(md5sum $L1/Packages.gz | cut --delimiter=' ' --fields=1)' %16d /media/Tortoise/Repositories/Jaunty/Canonical/Packages.gz' $(wc --bytes $L1/Packages.gz | cut --delimiter=' ' --fields=1) >> $L1/Release

The resultant Release file is different from the original script. It misses the MD5Sum part.

Could you please show me where is wrong and why?

PS: /media/Tortoise/ is my portable hard disk. I intend to run the script from my home folder.
April 14th, 2009
luvr

Re: Creating a Trusted Local Repository from which Software Updates can be installed.

Quote:

Originally Posted by Geochelone

The resultant Release file is different from the original script. It misses the MD5Sum part.

Could you please show me where is wrong and why?

Looks to me like you're writing the header lines (i.e., the output of the "cat" command) into a different file from the detail lines (i.e., the output of the "printf" commands). Indeed, your "cat" command specifies just "Release" as its output file:

Code:

cat > Release <<EOF

On the "printf" commands, on the other hand, you specify "$L1/Release" for the output file:

Code:

printf ...dadododah... >> $L1/Release

Your problem will likely get solved if you change the output file name on the "cat" command to $L1/Release--the same as on the "printf" commands.

Show 75 post(s) from this thread on one page