Sean Reifschneider <[email protected]> writes: > I'm going to push some changes to the default config that open it up. > You should be able to get the new config, and then remove > `/var/cache/apt-cacher-ultra/ca/*` and restart apt-cacher-ultra. It > should then generate a new CA, and you will need to copy that > ca.crt to the client machine to continue testing. At that point it > should work for you.
OK, I've now tried again with 0.9.7. Initially I was in the same boat as before, only deb.debian.org could be accessed. I missed this advice or I guess I assumed removing the package would remove /var/cache/apt-cacher-ultra but it doesn't. Maybe something to consider for the postrm script, it seems at least /var/cache/apt-cacher-ultra/ca should be removed or cleaned. So, after managing a clean install I got the default unrestriced mitm config going, only changed the listen part in config.toml. And then the restricted mitm too. So for the machine running the cache at least, the cache works. I'll continue with some further testing later. But I'm still baffled as to when the cert needs regenerating? For example, after initial trials with deb.debian.org and security.debian.org I added mega.nz. The cert is still the same but things seem to be working. At least no errors from apt update. Your advice implies adding mega.nz should've needed a new certificate. > In my environment I started with things wide open and then looked at > the logs after a few days and used actual usage to create the allow > lists. However, I've since come to the mind that because of signing of > remote packages, the CA being limited to apt use only, and typical use > inside a trusted network that has public Internet access anyway, that > a more open default is probably better. Logging is another question, why does it look more like json in journalctl than traditional logging? Oh, it's the default. But why json by default? And also, not much point in putting a timestamp in the log when systemd (or journald) already puts a timestamp in there.
