Opened 7 years ago

Closed 7 years ago

#5455 closed Bug/Something is broken (fixed)

Issues for new virtual server kinoy

Reported by: Ross Owned by: Ross
Priority: Medium Component: Tech
Keywords: virtual-server kinoy.mayfirst.org x.509 Cc:
Sensitive: no

Description

Brandon and I created the new virtual server kinoy tonight. Most things went fine, but there were a couple of problems. First, keyringer failed for me again and I could not push the password. It is currently stored locally and needs someone to put it into keyringer.

Second, the following errors occurred when running freepuppet-helper gd:luisa/fannie. Both backup servers threw similar errors:

luisa

remote: info: /Stage[main]//M_backupninja::Server::Configure_node[kinoy]/Monkeysphere::Authorized_user_ids[kinoy-sync]/File[/home/members/mayfirst/backups/kinoy/.monkeysphere/authorized_user_ids]: Scheduling refresh of Exec[monkeysphere-authentication update-users kinoy-sync]
remote: err: /Stage[main]//M_backupninja::Server::Configure_node[kinoy]/Monkeysphere::Authorized_user_ids[kinoy-sync]/Exec[monkeysphere-authentication update-users kinoy-sync]: Failed to call refresh: monkeysphere-authentication update-users kinoy-sync returned 2 instead of one of [0] at /etc/puppet/modules/monkeysphere/manifests/init.pp:128
To root@luisa.mayfirst.org:/etc/puppet-bare
   8f2ecb3..6d0c2e1  master -> master

fannie

remote: notice: /Stage[main]/M_apt::Refresh/Exec[apt-refresh]/returns: executed successfully
remote: err: /Stage[main]//M_backupninja::Server::Configure_node[kinoy]/Monkeysphere::Authorized_user_ids[kinoy-sync]/Exec[monkeysphere-authentication update-users kinoy-sync]: Failed to call refresh: monkeysphere-authentication update-users kinoy-sync returned 2 instead of one of [0] at /etc/puppet/modules/monkeysphere/manifests/init.pp:128
remote: err: /Stage[main]/M_minimal/Monkeysphere::Add_id_certifier[nat]/Exec[monkeysphere-authentication add-id-certifier 0ADA1A85619A5D0E5A414F84FFD913B7CB2D0500 && monkeysphere-authentication update-users]/returns: change from notrun to 0 failed: monkeysphere-authentication add-id-certifier 0ADA1A85619A5D0E5A414F84FFD913B7CB2D0500 && monkeysphere-authentication update-users returned 255 instead of one of [0] at /etc/puppet/modules/monkeysphere/manifests/init.pp:96
remote: notice: /Stage[main]//Node[fannie.mayfirst.org]/Monkeysphere::Publish_server_keys[fannie]/Exec[monkeysphere-host publish-keys --all]/returns: executed successfully
remote: notice: /Stage[main]//Node[fannie.mayfirst.org]/Gpg::Publish_user_key[root]/Exec[gpg-send-key-root]/returns: executed successfully
To root@fannie.mayfirst.org:/etc/puppet-bare
   8f2ecb3..6d0c2e1  master -> master
ross@virilio:~/projects/puppet/helper$ 

Finally, the ssl certificate has not been purchased.

Change History (6)

comment:1 Changed 7 years ago by Ross

Owner: set to Jamie McClelland
Status: newassigned

Okay...I think I have gotten keyringer fixed. So others can get kinoy's root passphrase. The other two items need jamie's or dkg's attention.

comment:2 Changed 7 years ago by Jamie McClelland

Owner: changed from Jamie McClelland to Ross

Great work Ross!

The backup errors appear to be temporary errors with keys.mayfirst.org. I had hoped with #5438 we would not be seeing them any more :(. In any event, I manually ran:

monkeysphere-authentication update-users kinoy-sync

On both servers and the commands completed without errors.

I've also purchased and installed the cert (purchased via http://cheapssls.com/ using our login in keyringer and paying via our paypal account, also in keyringer).

The last thing... can you commit and push the puppet repo? I'm not seeing kinoy publicly published.

comment:3 Changed 7 years ago by Daniel Kahn Gillmor

Keywords: x.509 added

I'm afraid the puppet error logs above aren't descriptive enough to let me know what the failures were. When reporting these things in the future, could you try running the respective monkeysphere-authentication or monkeysphere-host commands by hand (possibly with MONKEYSPHERE_LOG_LEVEL=debug) and storing the report somewhere i can look at it?

One possibility is that you were running into cached results from the nginx frontend on keys.mayfirst.org, so data that you thought should have been immediately available was not available.

I'm going to try to reduce the cache duration to see if that sort of thing becomes less frequent.

comment:4 Changed 7 years ago by Ross

Resolution: fixed
Status: assignedclosed

comment:5 Changed 7 years ago by Ross

Resolution: fixed
Status: closedassigned

comment:6 Changed 7 years ago by Ross

Resolution: fixed
Status: assignedclosed

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.