Re: Can't juju ssh to one of my units

2017-02-14 Thread Derek DeMoss 
Hey Sam,
Thank you for the help!

Sadly, the problem appears to be unrelated...

Ran the upgrades and then tried to manually ssh again, but I wound up on the 
wrong host.

It turns out that MAAS had stomped on the IP address with one of my Ceph 
Monitors' Auto Assigned addresses - ignoring the reserved range...  Gotta 
figure that out next.

MAAS Version 2.1.2+bzr-0ubuntu1

Derek DeMoss
Dark Horse Comics, Inc.
System Administrator I
"Truth...  Is where you seek it."-Lomar

> On Feb 13, 2017, at 3:15 PM, Samuel Cozannet  
> wrote:
> 
> Hi Derek,
> 
> You need to upgrade your Juju to 2.0.3 at least. This is a known issue (I am 
> all thumbs so can't find the LP ref right now but there are a bunch of 
> tickets about it)
> 
> To do so, first upgrade your controller:
> 
> sudo apt update && sudo apt upgrade
> juju switch controller
> juju upgrade-juju
> 
> Then upgrade units of the model
> 
> juju switch 
> juju upgrade-juju
> 
> If this doesn't work out for you, I had success with upgrading a controller 
> to 2.1-beta5 by adding the devel ppa, upgrading locally, upgrading the 
> controller, then the units.
> 
> 
> Let us know how it gets for you,
> Best
> Sam
> 
> On Feb 13, 2017 21:52, "Derek DeMoss"  > wrote:
> Hey All,
> I'm getting a host key verification failure when I try to juju ssh to one of 
> my units.
> 
> username@os-nuc-01:~/.ssh$ juju ssh  postgresql/14 -v
> OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug1: Connecting to  [] port 22.
> debug1: Connection established.
> debug1: identity file /home/username/.local/share/juju/ssh/juju_id_rsa type 1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/username/.local/share/juju/ssh/juju_id_rsa-cert 
> type -1
> debug1: identity file /home/username/.ssh/id_rsa type 1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/username/.ssh/id_rsa-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 
> Ubuntu-4ubuntu2.1
> debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x0400
> debug1: Authenticating to :22 as 'ubuntu'
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: curve25519-sha...@libssh.org 
> 
> debug1: kex: host key algorithm: ecdsa-sha2-nistp256
> debug1: kex: server->client cipher: chacha20-poly1...@openssh.com 
>  MAC:  compression: none
> debug1: kex: client->server cipher: chacha20-poly1...@openssh.com 
>  MAC:  compression: none
> debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
> debug1: Server host key: ecdsa-sha2-nistp256 
> SHA256:th86nMHQbr0RyuXXnsrBbeOs2JkchFl6gXVBY7p6S2k
> @@@
> @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> @@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
> It is also possible that a host key has just been changed.
> The fingerprint for the ECDSA key sent by the remote host is
> SHA256:th86nMHQbr0RyuXXnsrBbeOs2JkchFl6gXVBY7p6S2k.
> Please contact your system administrator.
> Add correct host key in /tmp/ssh_known_hosts736182584 to get rid of this 
> message.
> Offending RSA key in /tmp/ssh_known_hosts736182584:7
>   remove with:
>   ssh-keygen -f "/tmp/ssh_known_hosts736182584" -R 
> ECDSA host key for  has changed and you have requested strict 
> checking.
> Host key verification failed.
> 
> 
> If I just do: ssh ubuntu@ it connects just fine.
> 
> So my question is, where is Juju getting the original for 
> /tmp/ssh_known_hosts736182584:7
> 
> I've tried searching a bunch on my juju-controller machine, but I haven't 
> been able to find anything that looks like the problematic known_hosts file...
> 
> All the other machines/units are juju ssh-able, and I have no idea why this 
> one would be different [other than the drive filled up from postgresql, and I 
> had to clear some WAL files before things got running again].
> 
> Any insight or help would be appreciated!
> Derek DeMoss
> Dark Horse Comics, Inc.
> System Administrator I
> "Truth...  Is where you seek it."-Lomar
> 
> 
> --
> Juju mailing list
> Juju@lists.ubuntu.com 
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju 
> 
> 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:

Issue replacing the apache2 charm with the haproxy charm in a reverse proxy scenario.

2017-02-14 Thread Jay Wren 
Hello,

I have recently had the need to replace an apache2 ssl termination and
proxy/rewrite reverse proxy system with haproxy. I was hoping I'd be able
to configure the haproxy charm to do all the things that we were doing with
apache2 and its vhost_https_template config. All seemed to work well (huge
thanks to juju and charm authors) until the haproxy ssl termination and
proxy charm was also proxying another haproxy charm. I know this seems
strange, but its an interim config until we collapse our haproxy charms.

Moving from: apache2 -> haproxy-a -> service-a
 -> haproxy-b -> service-b
 -> service-c (direct, no haproxy)
 ... (10 different services)

To:   haproxy -> haproxy-a -> service-a
  -> haproxy-b -> service-b
  -> service-c (direct, no haproxy)
  ... (10 different services)

The issue seems to be that the apache2 charm expects a relation key named
"all_services" and haproxy provides that. haproxy expects a relation key
named "services" but does not provide that.

$ juju run --unit apache2/2 'relation-get -r balancer:93 -
blues-identity-haproxy/2 '
all_services: |
  - server_options:  [check inter 2000 rise 2 fall 5 maxconn 500]
servers:
- - blues-identity-2-8082
  - 10.142.0.16
  - '8082'
  - *id001
service_host: 0.0.0.0
service_name: blues-identity
service_options: [mode http, balance url_param waitid]
service_port: 83
hostname: juju-b4d3a0-41.c.jaas-001.internal
port: "80"
private-address: 10.142.0.15

I've filed a bug, https://bugs.launchpad.net/charm-haproxy/+bug/1664672 and
proposed a fix.
https://code.launchpad.net/~evarlast/charm-haproxy/alias-all_services-services/+merge/317254

Is this intended or is this an oversight or accident?

Thanks,
--
Jay
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

charms.reactive bi-weekly sync recap

2017-02-14 Thread Cory Johns 
Merlijn, Stuart, Alex, Tim, and I had our bi-weekly charms.reactive sync
today.

We have had some good exploration of ideas for the future of reactive over
the last two weeks in the form of Issues on the repo.  This seems to be
working well for us so far, and allows for anyone to join in the discussion
(go to https://github.com/juju-solutions/charms.reactive/issues to join
in), so we will continue with discussions there and in PRs on that repo.
One change that we will make is to create a PR with a consolidated "2.0 use
cases" documentation.  This will serve as both a more consolidated and
concrete set of examples of the ideas discussed in the "[discussion]"
issues, as well as becoming the documentation for reactive once those
features are implemented.

The sync also allowed us to clean up some outstanding PRs and, thanks to
Stuart and Tim, we resolved an upstream issue that was causing our Travis
builds to fail.  We now have passing CI on our PRs again.  :)

Our next sync will be two weeks hence, but collaboration will continue on
the repo, IRC, and here on this mailing list.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju