jlmt's questions

Am having some difficulties getting a few things working with cross-account data copies. Specifically, I'm trying to clone an S3 bucket from one AWS account (in eu-west-1) to another (in eu-west-2).

I've tried setting up bucket replication per this guide, adding a Replication Batch Operation to copy existing files, and have also tried a DataSync job per this guide.

Despite having followed the guides to the letter:

• Replication metrics show no activity and the destination bucket is still empty 24 hours later.

• The replication batch operation aborted with the reason Job failure rate 100% is above 50%.

• The CloudWatch log for the DataSync job provides only this detail: finished with status Unable to connect to S3 endpoint

I wonder if I'm missing some prerequisite that the guides assume will have already been set up; eg. Is there a need to establish some kind of trust relationship between two AWS accounts before cross-account permissions will work?

ie, where the intended destination S3 bucket in account 987654321098 has a permissions policy that includes this snippet to identify the actioning role in the source account:

        "Sid": "DataSyncCreateS3LocationAndTaskAccess",
        "Effect": "Allow",
        "Principal": { "AWS": "arn:aws:iam::123456789012:role/source-account-datasync-s3-copy-role" }

..is that all that should be needed for the destination account to trust the IAM role from the other account?

The build server is Ubuntu 16.04, patched recently with sudo apt update && sudo apt upgrade.

docker version says:

Version:           18.06.0-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        0ffa825
 Built:             Wed Jul 18 19:11:02 2018
 OS/Arch:           linux/amd64
 Experimental:      false

The Dockerfile looks like this:

FROM debian:12-slim

RUN apt-get update \
    && apt-get install -y wget \
    && apt-get install -y supervisor \
    && apt-get install -y apt-utils \
    && apt-get install -y nginx \
    && apt-get install -y libgdiplus

RUN apt-get autoremove -y \
    && apt-get clean -y \
    && apt-get autoclean -y \
    && rm -rf /var/lib/apt/lists/*

# .. other stuff cut ..

The apt-get update step fails with:

W: GPG error: http://deb.debian.org/debian bookworm InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY F8D2585B8783D481
E: The repository 'http://deb.debian.org/debian bookworm InRelease' is not signed.
W: GPG error: http://deb.debian.org/debian bookworm-updates InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131
E: The repository 'http://deb.debian.org/debian bookworm-updates InRelease' is not signed.
W: GPG error: http://deb.debian.org/debian-security bookworm-security InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 54404762BBB6E853 NO_PUBKEY BDE6D2B9216EC7A8
E: The repository 'http://deb.debian.org/debian-security bookworm-security InRelease' is not signed.

Presumably I need to first RUN something to update public keys.

I can find a lot of guides to solving this manually by copy-pasting the missing keys into the command line, but obviously I need the fix to be part of the Dockerfile (and ideally not fall over if the keys get changed, if possible?).

But perhaps the fact that apt-get isn't working for an official base image indicates a deeper problem?

Am I using the correct tag for a minimal Debian Docker image?

Is the problem related to using the slim distribution of Debian?

Could this be an issue with the build environment or old Docker version?

Any thoughts?

(Background: the intention is to build a .Net Core 2.1 runtime image for a legacy app, but the official Microsoft runtime image is no longer supported and has recently developed its own problems in which apt-get fails with many 404 errors. The choice of Debian slim here is because that image was based on an older version of the same.)

Edit: The comments seemed to suggest that it was probably the environment that was the problem; When building the same Dockerfile on Ubuntu 22.04.2 with Docker 24.0.4, everything was fine. Question answered as: Don't use an out of date build server!

I've been reading around this topic towards understanding whether there's some or no chance of downtime during an upcoming domain transfer for 15 live and very critical domains.

In our case there are three companies involved: CompanyA is the original registrar and DNS host, CompanyB is the new DNS host, and CompanyC is the new registrar.

I've already changed the nameservers for all domains to those of CompanyB. We suffered some downtime because CompanyA deleted their hosted DNS for our domains directly after the change, but the changes propagated and we're now able to configure our DNS with CompanyB.

From what I understand (please correct where wrong!):

1. There exists an SOA record that points oneofourdomains.com to ns.companyb.com. That record is maintained and authoritatively hosted by the ccTLD registry for the domain (eg. Verisign for .com). CompanyA currently has the ability to change the SOA record because they're the registrar.

2. There exist NS records for oneofourdomains.com, which are also related to the link from domain name to nameserver, are similarly hosted by the ccTLD, and which CompanyA are also able to change while acting as registrar.

3. Neither CompanyB nor CompanyC currently have any control over the SOA or NS records.

4. CompanyA are unable to cause us (DNS) problems during the transfer by dropping service early, because they are not the authoritative source for the SOA and NS records.

5. When we transfer the domains, it's administrative control of the SOA and NS records that will be transferred to CompanyC.

6. As long as we advise CompanyC that the SOA and NS records must not change (as regards pointing to CompanyB's nameservers), there's no need for any kind of DNS change, and therefore no possibility of downtime.

Is my understanding of this correct? My fear is that CompanyA will somehow cut us off again, and their support dept hasn't given me much confidence in their understanding of the topic.