nroi
commented
6 years ago Hi,
cpcache stands for central pacman cache, it's mainly targeted towards users who have some device running 24/7. If you don't have that, you might want to look into other pacman caching methods. I listed some of them in the README.md. I can't make cpcache into a one-size-fits-all solution and there are use cases where distributed pacman caches are more suitable than cpcache.
In case none of those options are suitable for your use case and you still want to use cpcache:
In my environment, a central server might not always be online, reachable or might have a lot of disk space for caching.
You could run cpcache on the device which is running most often. You will get a 404 error when using pacman while the device is not online, so pacman will just fetch the package from the next mirror in your mirrorlist. It's not elegant, but it works and you'll still have some packages shared in your LAN. Regarding disk space, if you use paccache as a cron job to regularly remove older versions of package, you won't need much disk space. I currently require ~ 15GB for two versions (paccache -k 2) of packages.
That is very advanced though and I doubt that there is anyone running such a big LAN, that this is required.
Exactly, I'm afraid it's not only time consuming for me to implement, but also for users of cpcache to configure. Generally speaking, cpcache's main priority is to be a time saver by making downloads faster and not requiring users to find suitable mirrors themselves. If cpcache were to require a personal PKI and use protocols such as mDNS, I'm afraid users will need to invest too much time configuring cpcache.
I have one other question: How does cpcache handle the repo database files?
cpcache does not cache database files, it always returns a 301 redirect response instead.
Hello,
In my environment, a central server might not always be online, reachable or might have a lot of disk space for caching. It would be great, if it were possible to distribute the cache over several machines in a LAN. The finding of other mirrors could be done via mDNS using a service type specific for cpcache. The servers could be load balanced client side depending on the network speed towards the client. If the network topology was to be detected using lldp, clients could be directed to the closest mirror in order to avoid bottlenecks. The cached files could be balanced or replicated among several caches. Authentication of mirrors could be done via TLS server certificates from a personal PKI.
That is very advanced though and I doubt that there is anyone running such a big LAN, that this is required.
What do you think?
I have one other question: How does cpcache handle the repo database files?