When all required charm configurations are set, the reprepro config should be generated.

Spec: https://docs.google.com/document/d/1Gzb5iaWzPvZ0M2HtqFH3ksTsW1arb57R4mM6Pic4y60/edit#

If you look at https://esm.ubuntu.com/ubuntu/dists/trusty-updates/Release.gpg, you see binary data. It should be ASCII armored like the file in the main archive: http://archive.ubuntu.com/ubuntu/dists/trusty-updates/Release.gpg

This applies to all series. APT in precise can fetch non-armored files, and trusty might too (but uses the InRelease anyway), but apt stopped supporting that recently.

Got this in our staging environment:

upstream auth_backend {
    server x.x.x.19:8080;
    server x.x.x.20:8080;
    server x.x.x.19:8080;
    server x.x.x.20:8080;
}

These addresses need to be a set or something, so that only unique ones are listed.

Keys specified in the service config should be imported in the reprepro tree

Spec doc: https://docs.google.com/document/d/1Gzb5iaWzPvZ0M2HtqFH3ksTsW1arb57R4mM6Pic4y60/edit#

We should add a "Version: 12.04" config to the release file, so that the ubuntu esm archive matches the other precise repositories.

ESM:

500 https://extended.security.staging.ubuntu.com/ubuntu/ precise/main i386 Packages
     release o=UbuntuESM,a=precise,n=precise,l=UbuntuESM,c=main
     origin extended.security.staging.ubuntu.com

Standard precise:

 500 http://br.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
     release v=12.04,o=Ubuntu,a=precise,n=precise,l=Ubuntu,c=main

Discussion in #ubuntu-release:

<infinity> ahasenack: It's missing a v=12.04, if you want behaviour to match the primary archive.
<infinity> ahasenack: I mean, we wanted it distinguishable from the primary archive (hence o=UbuntuESM), but the same fields should be present in both.
<ahasenack> ok
<ahasenack> and for v=12.04, what we need is "Version: 12.04", right? In the release file
<infinity> ahasenack: Yup.

Hi,

Can the charm please be updated to be able to use Juju storage ? (for /srv/archive-auth-mirror/static/ubuntu/ at least, or all of /srv if you prefer)
https://jujucharms.com/docs/stable/developer-storage

Thanks

Hi,

This charm can handle nagios-external-monitor relations, but doesn't create any check when the relation is created.

Please add a check (presumably, check_http) when the relation is added.

Thanks

unattended-upgrades by default matches on the release and security pockets of only the official Ubuntu release. This relies on the following fields in the archive Release file for a correct match:

Origin: Ubuntu
Suite: precise-security

According to STS, these are not present in the Release file for the ESM archive. Please add them.

Hi,

In a situation where archive-auth-mirror is fronted by an haproxy, adding a unit can lead to clients getting 404s. Since there is no initial sync before the new unit fully starts, and since by default the haproxy check is a simple L4 check, the unit will be added in the haproxy pool before an initial sync completes.

I believe nginx should be started only after an initial sync completed.

Thanks

I deployed archive-auth-mirror and related it to basic-auth-service. I didn't check /etc/nginx/sites-enabled/archive-auth-mirror's auth_backend at that point so I can't say what it looked like.

I then added another basic-auth-service unit, and then I checked /etc/nginx/sites-enabled/archive-auth-mirror and it was pointing at just the new unit, instead of both:

upstream auth_backend {
    server 10.0.100.51:8080;
}

I then destroyed the new unit (ran into basic-auth-service issue #1) and after cleaning up the error the auth_backend section was still not modified. Maybe related to the bug, so let's not fret yet.

So I added another unit, which gave me basic-auth-service/2. Now the auth_backend section reads like this:

upstream auth_backend {
    server 10.0.100.18:8080;
}

That is the IP of the new unit. Looks like it's only considering the last unit. I was expecting to see two IPs in there: one for each unit of basic-auth-service.

It looks like the mirroring process doesn't remove packages that were deleted from the backend PPPA.

In this case, the https://launchpad.net/~ubuntu-esm/+archive/ubuntu/esm/ PPPA is empty, and adding it to a precise machine and running apt-get update confirms it. But if I add the ESM sources.list, I still see the two test packages we had in the PPPA before:

keyutils:
  Installed: 1.5.2-2
  Candidate: 1.5.2-2ubuntu0.1~esmtest1
  Version table:
     1.5.2-2ubuntu0.1~esmtest1 0
        500 https://esm.ubuntu.com/ubuntu/ precise/main amd64 Packages
 *** 1.5.2-2 0
        500 http://br.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status
ecryptfs-utils:
  Installed: 96-0ubuntu3.5
  Candidate: 96-0ubuntu3.6~esmtest1
  Version table:
     96-0ubuntu3.6~esmtest1 0
        500 https://esm.ubuntu.com/ubuntu/ precise/main amd64 Packages
 *** 96-0ubuntu3.5 0
        500 http://br.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages
        100 /var/lib/dpkg/status
     96-0ubuntu3 0
        500 http://br.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

The apt-cache policy output above is with both the ESM and the backend PPPA enabled. You can see there is no mention of the backend PPA.

The cron job seems to be running, as the timestamp of files such as https://esm.ubuntu.com/ubuntu/dists/precise/Release is recent and confirms the */15 frequency of the cron job

This might be temporary, as we know PPPAs don't immediately delete packages, and might even keep one older version around, just not referenced in the Packages file so they are essentially invisible to apt. But I was under the impression that reprepro took that into account.

The tests require htpasswd:

======================================================================
ERROR: test_remove_user (test_manage_user.ManageUserTest)
test_manage_user.ManageUserTest.test_remove_user
----------------------------------------------------------------------
testtools.testresult.real._StringException: Traceback (most recent call last):
  File "/home/andreas/git/canonical/archive-auth-mirror/unit_tests/test_manage_user.py", line 39, in test_remove_user
    add_user(self.auth_file, 'user1', 'pass1')
  File "/home/andreas/git/canonical/archive-auth-mirror/lib/archive_auth_mirror/scripts/manage_user.py", line 14, in add_user
    check=True)
  File "/usr/lib/python3.5/subprocess.py", line 693, in run
    with Popen(*popenargs, **kwargs) as process:
  File "/home/andreas/git/canonical/archive-auth-mirror/.tox/py35/lib/python3.5/site-packages/systemfixtures/processes/fixture.py", line 27, in __call__
    return self._real_Popen(*args, **kwargs)
  File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'htpasswd'

This should be a dep somewhere.