I can update the rpm easily enough (although prod I would think we should wait until after freeze).

note that the auotsign hosts are currently rhel7 instances.

If you can get a epel7 (or epel7-infra) build done I can update stg anytime...

Ah cool, yeah I'll make epel7-infra RPMs. I need to get in a fix for the CoreOS signing thing that I'll work on today, but I'll make the RPM afterwards.

I've built the new package and since it now uses Fedora Messaging, I need a few things:
- a TLS certificate & key to connect to the broker
- a UID and GID for the robosignatory user it's going to run as (I think we have fixed UID/GID in infra ?)

Thanks

What sort of messages does it send now? The signing messages (should be if they were working) be emited by koji...

currently it runs as the 'fedmsg' user. I guess we need to make up a new one...

Yeah we need a new user, that's why I was asking for a UID/GID, if that's how we do things.

It sends messages after having signed coreos artifacts to notify them when it's done. It's a new thing. It still consumes the same sort of messages as before (plus some coreos messages). I'll set all that in the new config file anyway, I just need the TLS key & cert.
When I'm done with the ansible I'll ask you to update / run the playbook, if that's OK with you.

Thanks!

ok. It's a bit sad because we in the past I think deliberately wanted robosign to be a 'listen only' service, but I guess if we need to we need to. :(

ok, I have made both prod and stg certs.

For user, we could use 'releng' user? or make a robosignatory one? I don't care much...

Oh, could you explain to me why you wanted robosign to be listen-only?

I didn't find the creation of the releng user in ansible. To create the robosignatory user, can I let the system choose the UID/GID or should they be predefined? If so, where is the reference database? Thanks!

I think it was was meant as a security layer where by simplifying what is assumed and done means that it can't be too hard to attack or debug later.

The robosignatory system does not allow logins or have many users to cut down any avenue of secondary attack. Having it communicate outwards also means other things have to trust that this is robosignatory saying it versus something else. While it sounds silly when this is all in a closed environment.. if we have to move this into a cloud shared environment, it becomes a different problem.

Yeah, as smooge says it was just to reduce possible attack surface.

UID/GID shouldn't matter. We do need to add the user to the fas blacklist (also in ansible) though, so some user doesn't come and make that username a fas user.

OK perfect, I'll just create a "robosignatory" user then. Thanks.

I need one last thing to be able to update robosignatory: an AWS access_key and access_secret that it can use to download artifacts from CoreOS's S3 bucket and upload back signature files.

I think we can re-use the releng ones here. They are in ansible-private already as:

fcos_builds_releng_aws_access_id and fcos_builds_releng_aws_secret_key

Alright, I've pushed the changes in Ansible for the robosig update, could someone with the correct privileges deploy it to staging please? Maybe @kevin ? Thanks.

There was a issue with it trying to use the group before it was added, so I fixed that.

However, now it's hitting a template error...

fatal: [autosign01.stg.phx2.fedoraproject.org]: FAILED! => {"changed": false, "msg": "AnsibleError:
template error while templating string: expected token ',', got 'fedora'. String: amqp_url = \"amq
ps://robosignatory{{ env_suffix }}:@rabbitmq{{ env_suffix }}.fedoraproject.org/%2Fpubsub\"\n\npubli
sh_exchange = \"amq.topic\"\npassive_declares = true\n...therest of the template...

Not sure where...

Ah, my bad, it's a typo. I just fixed it. Please run the playbook again :-)

Robosignatory is now running in staging, and it seems to be signing packages correctly. @kevin , what about deploying to prod on Monday? Does that sound good?

A little close to freeze, but sure. ;) Any particular time better or worse for you? Is after 17UTC possible? (I have meetings 16 and 15). If not, I could try 14, but would have to head to my meeting if we don't finish in an hour.

Yeah I could have tried yesterday, but deploying such a critical piece to prod on a Friday seemed like a... an idea that left room for improvement.
If you can do 14 it would be great for me, if we're not done in an hour we'll rollback. I can't do post-17UTC this Monday. Does that sound OK?

I'll shoot for 14UTC. ;) See you on #fedora-admin?

Yes, see you in a few hours :-)

This is completed.