[arch-general] How to download .sigs into CacheDir with pacman
Greetings everyone! I am constructing a local, common repository of packages aggregated from core, extra and community, named 'default' for discussion's sake. This local repository shall be a "frozen" state of a (virtual) machine's package installation, to ensure a common package status across all machines which are using this local repository to upgrade. The idea behind this is to setup an internally tested "baseline" or "stable release" repository for certain clients. Basically, I want to shove 'pacman -Q' output into my magic bash script on my personal testing machine where all necessary updates are installed, and have a shiny repository ready for use fall out at the end. This is working nicely already, except for one thing that bothers me greatly: I haven't found a way to reliably download the official package signature files along with the packages themselves through creative use of pacman. I do not REALLY want to fetch the .sig files in another step from the mirror I am using, as that'd require me to construct package FILE names myself instead of just throwing pacman a "core/filesystem=2012.2-2" and let pacman figure out my architecture and download location. I DO want to have package signing available for my local copy, though. Is there a way to grab the .sig files along with the package files with pacman, and place them somewhere neat as the CacheDir, for instance? Any help or ideas are appreciated! Best regards, Dennis
On Thu, Mar 22, 2012 at 2:05 PM, Dennis 'Gyroplast' Herbrich
Greetings everyone!
I am constructing a local, common repository of packages aggregated from core, extra and community, named 'default' for discussion's sake. This local repository shall be a "frozen" state of a (virtual) machine's package installation, to ensure a common package status across all machines which are using this local repository to upgrade. The idea behind this is to setup an internally tested "baseline" or "stable release" repository for certain clients.
Basically, I want to shove 'pacman -Q' output into my magic bash script on my personal testing machine where all necessary updates are installed, and have a shiny repository ready for use fall out at the end. This is working nicely already, except for one thing that bothers me greatly:
I haven't found a way to reliably download the official package signature files along with the packages themselves through creative use of pacman. I do not REALLY want to fetch the .sig files in another step from the mirror I am using, as that'd require me to construct package FILE names myself instead of just throwing pacman a "core/filesystem=2012.2-2" and let pacman figure out my architecture and download location. I DO want to have package signing available for my local copy, though.
Is there a way to grab the .sig files along with the package files with pacman, and place them somewhere neat as the CacheDir, for instance?
That's an interesting situation. If I understood you correctly, you have something like: repository box: Downloads some updates that you'll test and approve. After that, you'll publush a new version of your repository database. other boxes: Updates from your private repository. Do they update only from your repository or can they eventually get updates from Arch? I presume they update only from your repository. What you maybe don't know is that pacman don't use those .sig files to really check the packages. The signatures come with each repository database, in the metadata for each signed package. So, you shouldn't really have to download them again, you already got them with Arch's database repositories, in your repository box. I would do the following: 1. Create a gpg key on the repository box 2. Sign the database you create with repo-add (you can choose the key to use) 3. On the other boxes, use pacman-key to import and trust your repository public key 4. Update your other boxes 5. Be happy :) For future updates of your repository, you'll have to re-sign it. What you really get is a two level trust system. Your repository box trusts Arch's keys and your other boxes trust your repository key. Hope that helps. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On Thu, Mar 22, 2012 at 02:28:43PM -0300, Denis A. Altoé Falqueto wrote:
That's an interesting situation. If I understood you correctly, you have something like:
repository box: Downloads some updates that you'll test and approve. After that, you'll publush a new version of your repository database.
other boxes: Updates from your private repository. Do they update only from your repository or can they eventually get updates from Arch? I presume they update only from your repository.
This is entirely correct and the intended setup. I want/need to switch from rolling release to a tested "stable" repository for my clients, to ensure a smooth update experience. Basically the kind of setup that's advertised to those who bemoaned the lack of a stable repository in Arch in the past. ;)
What you maybe don't know is that pacman don't use those .sig files to really check the packages. The signatures come with each repository database, in the metadata for each signed package. So, you shouldn't really have to download them again, you already got them with Arch's database repositories, in your repository box.
Indeed, I didn't know that, thank you (and Thomas!) very much. That'll do just nicely!
I would do the following:
1. Create a gpg key on the repository box 2. Sign the database you create with repo-add (you can choose the key to use) 3. On the other boxes, use pacman-key to import and trust your repository public key 4. Update your other boxes 5. Be happy :)
That's precisely what I did. :) I just didn't realize until now that the trust chain is kept intact by simply signing my local repo database with my internally trusted key created on the repository box, but it all makes sense now. In fact that's even better than I hoped, as this procedure allows the clients to ONLY trust my repository box key and won't have to bother with importing any other keys and a complex web of trust, even when AUR or homebrewn packages need to be integrated.
For future updates of your repository, you'll have to re-sign it. What you really get is a two level trust system. Your repository box trusts Arch's keys and your other boxes trust your repository key.
That's perfect for my purposes. I might switch to having multiple, internal repository keys with crossover revocation similar to the Arch master key concept, but so far I enjoy the RAW, UNLIMITED POWER of being fully trusted. ;)
Hope that helps.
Absolutely. Thanks to Thomas and Allan as well! It's great to see how far Arch has come during the last 10 years. It hasn't let my down since. I'll make sure to document my procedure of "snapshotting" the package state of a system along with my bash magic in the wiki. It's a bit more involved than what is already described in "Pacman Tips". Best regards, and keep up the great work! Dennis
Am 22.03.2012 18:05, schrieb Dennis 'Gyroplast' Herbrich:
I haven't found a way to reliably download the official package signature files along with the packages themselves through creative use of pacman. I do not REALLY want to fetch the .sig files in another step from the mirror I am using, as that'd require me to construct package FILE names myself instead of just throwing pacman a "core/filesystem=2012.2-2" and let pacman figure out my architecture and download location. I DO want to have package signing available for my local copy, though.
Is there a way to grab the .sig files along with the package files with pacman, and place them somewhere neat as the CacheDir, for instance?
pacman -S uses the signature files from the database file, it does not download them as single files. They are contained in the $pkgname-$pkgver-$pkgrel/desc file inside the .db tarball.
On 23/03/12 03:05, Dennis 'Gyroplast' Herbrich wrote:
Greetings everyone!
I am constructing a local, common repository of packages aggregated from core, extra and community, named 'default' for discussion's sake. This local repository shall be a "frozen" state of a (virtual) machine's package installation, to ensure a common package status across all machines which are using this local repository to upgrade. The idea behind this is to setup an internally tested "baseline" or "stable release" repository for certain clients.
Basically, I want to shove 'pacman -Q' output into my magic bash script on my personal testing machine where all necessary updates are installed, and have a shiny repository ready for use fall out at the end. This is working nicely already, except for one thing that bothers me greatly:
I haven't found a way to reliably download the official package signature files along with the packages themselves through creative use of pacman. I do not REALLY want to fetch the .sig files in another step from the mirror I am using, as that'd require me to construct package FILE names myself instead of just throwing pacman a "core/filesystem=2012.2-2" and let pacman figure out my architecture and download location. I DO want to have package signing available for my local copy, though.
Is there a way to grab the .sig files along with the package files with pacman, and place them somewhere neat as the CacheDir, for instance?
Any help or ideas are appreciated!
pacman -U http://.... downloads signature files automatically if present. Allan
participants (4)
-
Allan McRae
-
Denis A. Altoé Falqueto
-
Dennis 'Gyroplast' Herbrich
-
Thomas Bächler