Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 39

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

  1. #21
    Join Date
    Jan 2006
    Location
    Boom, Belgium
    Beans
    222
    Distro
    Ubuntu 10.04 Lucid Lynx

    ADDENDUM: Transferring your GPG Key Pair to Another Computer.

    Abstract.

    You generated a GPG key pair that you use to maintain a trusted local repository. Since the private (or “secret”) key part is available only on the computer on which you generated the key pair, you can create the digital signature for the repository only on that one computer.

    Even though, generally, you should not distribute the secret key to multiple computers, you may occasionally want to transfer it, e.g., when you replace your current computer with a new one.

    Step 1: Exporting your GPG Key Pair.

    To export your GPG key pair, you will have to export both the public and the private key parts. You have already exported the public key, in Step 2 of the initial post of this thread. If you still have the export file available, you may reuse it now; otherwise, just rerun the following command to export the public key to a text file again:
    Code:
    gpg --output pubkey-export-file --armor --export xxxxxxxx
    Again, replace the pubkey-export-file parameter string with an appropriate name for the output file, and replace the xxxxxxxx parameter with the key id.

    Note:

    Remember that 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

    Next, execute the following command to export the private key to a text file:
    Code:
    gpg --output seckey-export-file --armor --export-secret-key xxxxxxxx
    Warning:

    Keep in mind that the private key should be kept secret. Therefore, you should delete any copies of the export file as soon as you no longer need them—or, at least, keep them in a very, very safe place indeed.

    After you exported both the public and the private key parts, you can transfer the resulting text files to your new computer, where you can subsequently import them—as described next.

    Step 2: Importing your GPG Key Pair on Your New Computer.

    Once the pubkey-export-file and the seckey-export-file are available on your new computer, you are ready to import them into its keyring.

    To import the public key part, run the following command:
    Code:
    gpg --import pubkey-export-file
    Then, to import the private key part, run the following command:
    Code:
    gpg --allow-secret-key-import --import seckey-export-file
    Your key pair is now available on your new computer; you may want to list your keys, as documented above, to verify this.

    Remember that, to be safe, you should now delete the seckey-export-file (to which you exported the private key part).

    Appendix A: Changing the Passphrase of the Secret Key.

    You can change the passphrase of the private key part, as documented next.

    Note:

    Even though you will be working at the command line to complete this procedure (as well as the one documented in Appendix B, below), the system may at times pop up a dialog box to ask for your passphrase. If, like me, you find this behaviour rather annoying and potentially confusing or distracting, you can prevent this dialog box from appearing, as follows:
    • Start the “Encryption and Keyrings” utility (“System”“Preferences”“Encryption and Keyrings”);
    • Select the “PGP Passphrases” tab;
    • Either select “Never remember passphrases” (the safe, paranoid, option), or deselect “Ask me before using a cached passphrases” (the relaxed option).

    From then on, you can complete all of your work involving your secret key and your passphrase exclusively from the command line shell, without ever having to divert your attention to the graphical desktop environment.

    Run the following command, to start a session to edit your key:
    Code:
    gpg --edit-key xxxxxxxx
    At the “command>” prompt displayed by the gpg program, type the “passwd” command:
    Code:
    passwd
    The program will prompt you for the current passphrase:
    Code:
    Enter passphrase:
    Next, it will ask you to enter a new passphrase:
    Code:
    Enter the new passphrase for this secret key.
    
    Enter passphrase:
    To ensure that you correctly typed the new passphrase, you will have to repeat it:
    Code:
    Repeat passphrase:
    When the program redisplays its “command>” prompt, enter the “save” command, to make your changes permanent and to exit the program:
    Code:
    save
    Note:

    If you change your mind, and decide that you want to keep the old passphrase after all, then simply enter the “quit” command instead, and answer the confirmation questions appropriately.

    Appendix B: Changing the Userid of the Key.

    If you set the userid of the key to, say, “Local Ubuntu Intrepid Ibex Repository,” and you subsequently transfer the key to a Jaunty Jackalope system, you will likely want to update the userid, to make it correspond to the new Ubuntu release.

    Changing the userid will happen in two steps:
    • Add the new userid;
    • Delete the old userid.

    Just as in Appendix A, above, you will have to run the following command to edit your key:
    Code:
    gpg --edit-key xxxxxxxx
    To add the new userid to the key, type the “adduid” command:
    Code:
    adduid
    The program will prompt you for the new real name, e-mail address, and comment—e.g.:
    Code:
    Real name: Local Ubuntu Jaunty Jackalope Repository
    E-mail address:
    Comment:
    You selected this USER-ID:
        "Local Ubuntu Jaunty Jackalope Repository"
    
    Change (N)ame, (C)omment, (E)-mail or (O)kay/(Q)uit?
    If you then type O to confirm your changes, then you will have to enter your passphrase, and the program will display your key with both the old and the new userids:
    Code:
    pub  4096R/xxxxxxxx  created: 2009-03-07  expires: 2014-03-06  usage: SC  
                         trust: unknown       validity: unknown
    [ unknown] (1)  Local Ubuntu Intrepid Ibex Repository
    [ unknown] (2). Local Ubuntu Jaunty Jackalope Repository
    Next, you will have to select the userid that you want to delete—i.e., userid 1. To that end, type the following command:
    Code:
    uid 1
    The program will display an asterisk (i.e., “*”) next to the selected userid:
    Code:
    pub  4096R/xxxxxxxx  created: 2009-03-07  expires: 2014-03-06  usage: SC  
                         trust: unknown       validity: unknown
    [ unknown] (1)* Local Ubuntu Intrepid Ibex Repository
    [ unknown] (2). Local Ubuntu Jaunty Jackalope Repository
    Type the “deluid” command to delete the selected userid:
    Code:
    deluid
    Confirm the operation, and the selected userid will be removed:
    Code:
    pub  4096R/xxxxxxxx  created: 2009-03-07  expires: 2014-03-06  usage: SC
                         trust: unknown       validity: unknown
    [ unknown] (1). Local Ubuntu Jaunty Jackalope Repository
    Finally, enter the “save” command to make your changes permanent and to exit the program:
    Code:
    save

  2. #22
    Join Date
    Nov 2008
    Beans
    46
    Distro
    Ubuntu

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

    Hello Luvr i LAN network on my hostel and here internet connection is so slow and i keep my system up-to-date so i want to do that all students can update their ubuntu software from my repository so can u tell me in deatail what i have to do for this??

  3. #23
    Join Date
    Jan 2006
    Location
    Boom, Belgium
    Beans
    222
    Distro
    Ubuntu 10.04 Lucid Lynx

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

    Quote Originally Posted by mihir786 View Post
    Hello Luvr i LAN network on my hostel and here internet connection is so slow and i keep my system up-to-date so i want to do that all students can update their ubuntu software from my repository so can u tell me in deatail what i have to do for this??
    If I understand you correctly, you want to install updates (and perhaps also new software packages) to one machine from the online repositories, and store the downloaded packages into a local repository, from where the other machines can pick them up. That way, you will have to download the packages only once, instead of having each computer download them separately.

    Obviously, you will have to start by setting up a local repository on your "Master" machine (that is, the machine on which you will download the updates and new installs). If you haven't already done so, I suggest you follow the procedure as I described it in the first post of this thread. If you know how to work with a command-line console, then I believe the procedure is explained quite clearly (but please do let me know if there's anything that confuses you about it).

    Once you have the local repository correctly set up on your "Master" machine, it's time to allow your "Satellite" systems to access it as their primary source location for software updates (and, possibly, any new software that you decide to install on the "Master" machine).

    I guess that you will want to access your local repository through your local network, right? If that is the case, then file sharing through SAMBA is by far the most convenient option. (SAMBA started life as a Free Software implementation of the Windows networking protocols, to allow Linux--and BSD and Unix--systems to share files with Windows systems; these days, however, it is getting more and more popular as a networking option among Linux systems as well.) Your "Master" machine will have to be set up as a SAMBA Server, to which your "Satellites" can then connect as Clients.

    I must admit, though, that I have never set up a SAMBA server, so I cannot give you much advice about it; I believe, though, that you can easily set it up from the Ubuntu desktop. On your "Master" machine, just locate the folder that you want to share with the "Satellites" (i.e., your local repository folder), right-click on its icon, and select "Sharing Options"; the options that will be presented to you, should be fairly simple.

    On your "Satellite" machines, you will have to select "Connect to Server..." (from the "Places" menu). For Service type, select "Windows share"; type in the Server name (i.e., the name of your "Master" machine) and the Share name (which you defined when you created the share on the server), plus, possibly the user name and password for the connection.

    Once your client and server setup works, you will have to figure out how to "mount" the shared folder to a specific location on your client machines. I guess you should be able to define the network connection in your "/etc/fstab" file (or some such), but I'm afraid I won't be able to help you with this aspect at this time.

    Finally, to make your "Satellite" machines pick up updated and new packages from your (now shared) local repository, you will have to
    • Export the "Public Key" that you created for your local repository (see Step 2 of the procedure as documented in the first post of this thread);
    • Import the Public Key to all of your "Satellite" computers (see Step 3 of said procedure);
    • Add your local repository as an APT source on all of your "Satellite" computers (see Step 9 of the procedure).

    Note:
    While this may all seem awfully long-winded and complex, I'm sure it's not really that hard.

    In fact, I'm using a local repository myself, even though I don't share it on a network. Instead, I copy it to a USB disk (using the "Unison" file synchronisation tool), and from the USB disk onto each computer on which I want to use it (again using "Unison"). Thus, each of these computers gets its own local copy of my local repository.

    Again, please do keep in mind that I have never set up a SAMBA server, and I would have to search for more information on how to define an appropriate "mount point" for a shared folder on the cleint machines myself.

  4. #24
    Join Date
    Oct 2007
    Location
    Australia
    Beans
    1,715
    Distro
    Ubuntu Development Release

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

    Hi Luvr, and mihir786, if I may make a suggestion I wouldn't use SAMBA for this. What I would do instead is set up a Repository folder (making sure to give it an appropriate name that is easily recognisable) on the "Master Machine" then enable that folder to be shared (but very importantly not written to by) with "Client Machines". I would do this by NFS. It is all explained in the Ubuntu Server Guide.

    The client machines will then need to be pointed using NFS to the "Repository" in Software Sources. The next step would be to make sure the "Check for updates" is set to an appropriate time frame. It would be no use setting it to everyday when the Repository server is only updated once a week . After that you could test it by using Update Manager and clicking "Check".
    Ubuntu User 23142 | Wiki | Laptop | HowTo:Create a background slideshow and Screensaver | Reconditioning pre-loved PCs and installing Ubuntu to give away to good homes.

  5. #25
    Join Date
    Jan 2006
    Location
    Boom, Belgium
    Beans
    222
    Distro
    Ubuntu 10.04 Lucid Lynx

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

    Quote Originally Posted by k3lt01 View Post
    I would do this by NFS.
    I must say, I did think about NFS before I posted my reply, but when I wondered how the client machines would have to address the server, I realised that most local networks use DHCP. In other words, most computers will not have a fixed IP address.

    In addition (at least to the best of my knowledge) addressing the local computers by workstation name won't work, because host names aren't resolved on the local network--at least, not without additional setup.

    That's why I suggested SAMBA--which should make workstation names visible on the local network.

    For instance, I'm running a small peer-to-peer local network, with an ADSL router as my gateway to the internet. The router, of course, has a fixed IP address on my network, but hands out dynamic IP addresses to my workstations; none of my workstations have fixed IP addresses, since I don't perform any explicit configuration on any of them. Under these conditions, SAMBA seems like the most convenient option to me. (In fact, in the past, when I was still running a Windows machine on this network, I remember playing with a Linux box as a SAMBA client that connected to the Windows machine, and that worked fine.)

    Now, I have just bought a new ADSL router, which, incidentally, allows me to associate fixed IP addresses with any client machines (identified by MAC address) that I choose to define to the router; these client machines won't need any additional setup, and will continue to receive their network configuration through DHCP, but they will be assigned fixed IP addresses from the router. That should make traditional Unix networking options far more practical. In addition, if I understand the documentation correctly, the router may even provide name resolution on the local network--though, admittedly, I may have misinterpreted the docs.

    Anyway, I'm not really a networking guru, so my understanding may be wrong, but that is how I believe these things work. If I'm mistaken, though, by all means, please don't hesitate to correct me; I'm always interested in learning more about the subject!

  6. #26
    Join Date
    Oct 2007
    Location
    Australia
    Beans
    1,715
    Distro
    Ubuntu Development Release

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

    Ah I get your thinking now, I thought SAMBA was more for Windows Networking thats why I suggested NFS. I can see your point.
    Ubuntu User 23142 | Wiki | Laptop | HowTo:Create a background slideshow and Screensaver | Reconditioning pre-loved PCs and installing Ubuntu to give away to good homes.

  7. #27
    Join Date
    Jan 2006
    Location
    Boom, Belgium
    Beans
    222
    Distro
    Ubuntu 10.04 Lucid Lynx

    ADDENDUM: Installing the Flash Player Plugin without Internet Access.

    The Problem.

    You successfully installed the “Adobe Flash Player Plugin” software package (i.e., “flashplugin-installer”) on one computer that has full internet access, and you are making the package available locally—e.g., through a local software repository.

    You are now trying to install the package on another computer, but this time with limited or no internet access, e.g., with the following command:
    Code:
    sudo apt-get install flashplugin-installer
    When the command starts up, it produces the following output:
    Code:
    Reading package lists... Done 
    Building dependency tree       
    Reading state information... Done 
    The following extra packages will be installed: 
      ia32-libs lib32asound2 lib32bz2-1.0 lib32gcc1 lib32ncurses5 lib32stdc++6 lib32v4l-0 lib32z1 libc6-i386 nspluginwrapper 
    Suggested packages: 
      xulrunner-1.9 konqueror-nsplugins ttf-bitstream-vera ttf-dejavu ttf-xfree86-nonfree xfs lib32asound2-plugins 
    The following NEW packages will be installed 
      flashplugin-installer ia32-libs lib32asound2 lib32bz2-1.0 lib32gcc1 lib32ncurses5 lib32stdc++6 lib32v4l-0 lib32z1 libc6-i386 nspluginwrapper 
    0 upgraded, 11 newly installed, 0 to remove and 0 not upgraded. 
    Need to get 0B/34.2MB of archives. 
    After this operation, 145MB of additional disk space will be used. 
    Do you want to continue [Y/n]?
    You notice, specifically, the line that reads “Need to get 0B/34.2MB of archives.” From this output line, you draw the conclusion that the software packages will not be downloaded from the internet, but that the files that you want to install, will be taken from your local repository instead.

    However, when you continue the operation, you discover that the installer still attempts to download a “.tar.gz” archive file; this download will, obviously, fail if the computer does not have an active internet connection—e.g.:
    Code:
    --2010-04-18 16:22:17--  http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_10.0.45.2.orig.tar.gz 
    Resolving archive.canonical.com... failed: Name or service not known. 
    wget: unable to resolve host address `archive.canonical.com' 
    download failed 
    The Flash plugin is NOT installed.
    In this post, I will explain how you can examine the “flashplugin-installer” package, and find a way to avoid having the package download the archive file during installation.

    Step 1: Getting a Copy of the “flashplugin-installer” Package.

    As I mentioned in the introduction above, I’m assuming that you have already installed the “flashplugin-installer” package on one computer, and that you are making it available in your local software repository. You can, then, easily copy it from there to, e.g., your home directory, as follows:
    Code:
    cd
    cp LocalRepository/flashplugin-installer_*.deb .
    A copy of the “flashplugin-installer” package should now be present in your current working directory—as the following command will demonstrate:
    Code:
    ls -l flashplugin-installer_*.deb
    The output from this command should look similar to the following:
    Code:
    -rw-r--r-- 1 luvr luvr 19574 2010-05-13 15:40 flashplugin-installer_10.0.45.2ubuntu0.9.10.1_amd64.deb
    
    Note:

    If you did install the “flashplugin-installer” package, but you do not maintain a local repository, then you should be able to copy it from the APT package cache—i.e., the “/var/cache/apt/archives” directory—instead:
    Code:
    cd
    cp /var/cache/apt/archives/flashplugin-installer_*.deb .
    Step 2: Extracting the Control Information from the Package.

    If you want to take a look at what a software package actually does when you install it, you will have to extract its control information—which includes configuration settings and script files to guide the installation process (as well as the uninstallation process).

    To extract the control information from a Debian package file, you can use the “dpkg-deb” command, and pass it the “--control” option—the following command, for instance, will extract the control information from your copy of the “flashplugin-installer” package file:
    Code:
    dpkg-deb --control flashplugin-installer_10.0.45.2ubuntu0.9.10.1_amd64.deb
    This command will not produce any visible output, but it will create a “DEBIAN” directory, in which it will copy the control information from the package file. You can run the following command to obtain a list of the extracted control files:
    Code:
    ls -l DEBIAN
    The output will look something like this:
    Code:
    total 36
    -rwxr-xr-x 1 luvr luvr 1548 2010-02-15 14:37 config
    -rw-r--r-- 1 luvr luvr 1941 2010-02-15 14:37 control
    -rw-r--r-- 1 luvr luvr  334 2010-02-15 14:37 md5sums
    -rwxr-xr-x 1 luvr luvr 5126 2010-02-15 14:37 postinst
    -rwxr-xr-x 1 luvr luvr  206 2010-02-15 14:37 postrm
    -rwxr-xr-x 1 luvr luvr 2505 2010-02-15 14:37 prerm
    -rw-r--r-- 1 luvr luvr 5438 2010-02-15 14:37 templates
    Two of these files will be of particular interest to you, if you are trying to figure out what exactly will happen when you attempt to install the package:
    • config
      This is the script that will drive the configuration of the installation process.
      In the case of the “flashplugin-installer” package, for example, it will decide if the supporting files will have to be downloaded, or have been made available locally.
    • postinst
      This is the script that will take any post-installation steps required to make the installed software fully functional.

    These two script files can help you determine which files you will have to pre-download, and where you have to copy them, in order to keep the installer from attempting to download any further files during the installation process.

    Step 3: Examining the “config” File.

    If you open the “config” file in any text editor, then you will see the following code fragment near the top of the file:
    Code:
    db_get flashplugin-installer/local
    echo "423ac7830c8a55ac931acb9e07a51f2aa981aedb63b45745460b4556a10e157b  $RET/install_flash_player_10_linux.tar.gz" \
    | sha256sum -c > /dev/null 2>&1 \
    || db_set flashplugin-installer/local /var/cache/flashplugin-installer
    While these lines will likely appear confusing to you (they surely do to me!)—they do reveal a few potentially interesting items:
    • 423ac7830c8a55ac931acb9e07a51f2aa981aedb63b4574546 0b4556a10e157b
      This strangely looking string appears to consist of a sequence of 64 hexadecimal digits.
      Since it seems to get passed on to the “sha256sum” command, it must be a SHA-256 checksum value of some file.
    • install_flash_player_10_linux.tar.gz
      This string appears to be the name of a file.
      Since it apparently gets passed on to the “sha256sum” command, together with the SHA-256 checksum value, it must be the name of the file to which the checksum applies.
    • /var/cache/flashplugin-installer
      This string certainly looks like some sort of a path name.
      Since you have already identified a file name, it doesn’t seem all that far-fetched to assume that this is the name of the directory where the file should be located.

      Note:

      The path name occurs as a parameter to a “db_set” command (whatever that may mean). The first parameter of the command is “flashplugin-installer/local”; thus, the command appears to “set” a data item named “flashplugin-installer/local” equal to the path name.

      If you want to obtain a little more information on what the “flashplugin-installer/local” item is supposed to mean, then you may want to look for its description in the “templates” file (which is one of the files that make up the control information that got extracted from the package):
      Code:
      Template: flashplugin-installer/local
      Type: string
      Default:
      Description: Location to the local file:
       Have you already downloaded the .tar.gz
       package from the Internet? If so, please enter the directory you downloaded
       it into. Do not include the filename here. If you
       have not already downloaded it, leave this blank and the package will be
       downloaded automatically.
      This description certainly confirms your suspicions about the meanings of the file and path name strings.

    Conclusion:
    The “config” script looks for a file named “install_flash_player_10_linux.tar.gz” in the “/var/cache/flashplugin-installer” directory, and will calculate the checksum of the file in order to verify its integrity. If it doesn’t find the file, or if the checksum doesn’t match, then the script will force a download from the internet during the installation process.
    Note:
    Newer versions of the Flash Player Plugin installer no longer look for the “install_flash_player_10_linux.tar.gz” file. For reference, however, I will not update this post for such newer releases. My later, similar, post on Installing the Flash Player Plugin from a Local Mirror, without Internet Access, on the other hand, does work with such a newer version.
    Step 4: Examining the “postinst” File.

    Next, if you open the “postinst” file in any text editor, then you will find the following code near the top of the file:
    Code:
    FLASH_VERSION=10.0.45.2
    FILENAME=adobe-flashplugin_${FLASH_VERSION}.orig.tar.gz
    SHA256SUM_TGZ="30be012f0a680ef54fd6bca50c6bdb4addf29368b3d105496daf480abd8ac97b"
    PARTNER_URL=http://archive.canonical.com/pool/partner/a/adobe-flashplugin/$FILENAME
    These statements apparently refer to a file named “adobe-flashplugin_10.0.45.2.orig.tar.gz”; they specify the expected SHA-256 checksum of the file, and the location from which it should be downloaded.

    Step 5: Building the “SHA256” File.

    It should be clear by now, that you will have to pre-download two files:
    • install_flash_player_10_linux.tar.gz
    • adobe-flashplugin_10.0.45.2.orig.tar.gz

    Also, the installer will verify their checksums, and it will consider them valid only if the checksums are correct. After you download the files, it may, therefore, be a good idea to manually verify their checksums before actually installing the package—to ensure that the files were downloaded without error.

    You may, therefore, want to create a checksum verification file first—i.e., a text file that lists each file that you want to verify, together with its expected checksum value. Each line of the verification file should have the following format:
    • The checksum value—which should be a 64-character string of hexadecimal digits;
    • A single blank space;
    • A single asterisk (i.e., “*”);
    • The name of the file.

    To determine the actual contents of the checksum verification file, you should refer back to the “config” and “postinst” scripts discussed above. The result should look like this:
    Code:
    423ac7830c8a55ac931acb9e07a51f2aa981aedb63b45745460b4556a10e157b *install_flash_player_10_linux.tar.gz
    30be012f0a680ef54fd6bca50c6bdb4addf29368b3d105496daf480abd8ac97b *adobe-flashplugin_10.0.45.2.orig.tar.gz
    Save this text under any appropriate name—e.g., “SHA256.”

    Step 6: Downloading the “install_flash_player_10_linux.tar.gz” File.

    To download the “install_flash_player_10_linux.tar.gz” file, you will have to use your browser to navigate to the following URL:
    Code:
    http://get.adobe.com/flashplayer
    For the “version to download,” select “.tar.gz for Linux,” and then click “Agree and install now.” You should save the file to the same directory where you created the “SHA256” file, above.

    Step 7: Downloading the “adobe-flashplugin_10.0.45.2.orig.tar.gz” File.

    To download the “adobe-flashplugin_10.0.45.2.orig.tar.gz” file, you can use the “wget” utility. The location from which to download the file, is given by the “PARTNER_URL” value in the “postinst” script, as documented above. Run the following command to get the file, and save it into your current working directory:
    Code:
    wget http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_10.0.45.2.orig.tar.gz
    Step 8: Verifying the Downloaded Files.

    You should make sure that your current working directory now contains the following three files:
    • SHA256
    • install_flash_player_10_linux.tar.gz
    • adobe-flashplugin_10.0.45.2.orig.tar.gz

    To verify the integrity of the downloaded files, you can now run the following command:
    Code:
    sha256sum -c SHA256
    The output from this command should tell you that the files are OK:
    Code:
    install_flash_player_10_linux.tar.gz: OK
    adobe-flashplugin_10.0.45.2.orig.tar.gz: OK
    Step 9: Installing the Flash Player Plugin, Using the Downloaded Files.

    From now on, whenever you want to install the Flash Player plugin on another computer, you can first copy the two downloaded files into its “/var/cache/flashplugin-installer” directory, as follows:
    Code:
    sudo mkdir /var/cache/flashplugin-installer
    sudo cp install_flash_player_10_linux.tar.gz /var/cache/flashplugin-installer
    sudo cp adobe-flashplugin_10.0.45.2.orig.tar.gz /var/cache/flashplugin-installer
    If you subsequently install the “flashplugin-installer” package on the computer, then the local copies of these files will be used, so the installer won’t have to download them again.

    Important:

    The required versions of the downloaded files depend both on the Ubuntu release, and on the current Flash Player version. You will have to download new versions of the files (as identified in the “config” and “postinst” scripts documented above) when you need to install them under a different Ubuntu release, or when the Flash Player gets updated.
    Last edited by luvr; September 24th, 2010 at 07:58 PM.

  8. #28
    Join Date
    Aug 2010
    Beans
    5
    Distro
    Ubuntu 10.04 Lucid Lynx

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

    Hi luvr,
    I used your HowTo, and it actually solved my problem (like having to burn CD with APTonCD). So first of all thanks a lot. But there's is still one problem which i can't figure it out by myself.
    When I load my repository in Synaptic, it doesn't show all packages I stored locally which are available in "Packages" file. Where this problem may come from? I know they're there, and I redid the tutorial twice. Also there are no older versions of packages.

  9. #29
    Join Date
    Jan 2006
    Location
    Boom, Belgium
    Beans
    222
    Distro
    Ubuntu 10.04 Lucid Lynx

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

    Quote Originally Posted by sineau View Post
    When I load my repository in Synaptic, it doesn't show all packages I stored locally which are available in "Packages" file. Where this problem may come from?
    Without any further information, the only reason I can think of would be the package architecture that they apply to. For instance, you may be running a 32-bit ("i386") system, while the packages are targeted at the 64-bit ("amd64") architecture (or vice versa).

    Could that be the case here?

  10. #30
    Join Date
    Oct 2010
    Beans
    4

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

    Have followed the howto provided at the beginning of the thread to add a Release file to my local repository of inhouse packages, however when I try to install the package, I am getting:

    WARNING: The following packages cannot be authenticated!
    <package-name>

    How can I overcome this issue as we want to automate the process and this will stop it from installing automatically.

    The local repository has been added to the target system's sources.list file.

Page 3 of 4 FirstFirst 1234 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •