SSH host key maintenance, local provider
Hi. Has anyone got a simple mechanism for keeping their ~/.ssh/known_hosts and ~root/.ssh/known_hosts files clear of ephemeral juju machines? I did have a script that cleared it out on bootstrap, but it has stopped working and I thought I'd ask here for current best practice before debugging it. -- Stuart Bishop stuart.bis...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: SSH host key maintenance, local provider
This is what I have: Host 10.0.3.* StrictHostKeyChecking no UserKnownHostsFile /dev/null ForwardAgent yes LogLevel ERROR ControlMaster auto ControlPath /tmp/ssh_mux_%h_%p_%r ControlPersist 8h LogLevel ERROR is nice, means you don't get any key warnings. HTH -- Simon On 3 October 2014 12:13, Stuart Bishop stuart.bis...@canonical.com wrote: Hi. Has anyone got a simple mechanism for keeping their ~/.ssh/known_hosts and ~root/.ssh/known_hosts files clear of ephemeral juju machines? I did have a script that cleared it out on bootstrap, but it has stopped working and I thought I'd ask here for current best practice before debugging it. -- Stuart Bishop stuart.bis...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: SSH host key maintenance, local provider
On 3 October 2014 13:21, Simon Davy bloodearn...@gmail.com wrote: This is what I have: Host 10.0.3.* StrictHostKeyChecking no UserKnownHostsFile /dev/null ForwardAgent yes LogLevel ERROR ControlMaster auto ControlPath /tmp/ssh_mux_%h_%p_%r ControlPersist 8h Sorry, for clarity, this is in my .ssh/config file. I also have similar rule for canonistack ip ranges. -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: SSH host key maintenance, local provider
On 3 October 2014 20:23, Curtis Hovey-Canonical cur...@canonical.com wrote: On Fri, Oct 3, 2014 at 8:30 AM, Simon Davy bloodearn...@gmail.com wrote: On 3 October 2014 13:21, Simon Davy bloodearn...@gmail.com wrote: This is what I have: Host 10.0.3.* StrictHostKeyChecking no UserKnownHostsFile /dev/null ForwardAgent yes LogLevel ERROR Juju-CI is in several clouds. We treat the 10.* and 172.* networks as ephemeral for our tests. Hp's machines on the 15.125.* are ephemeral. I haven't seen enough azure and joyent IP to also ignore them. Host 10.*.*.* 172.*.*.* ec2-*.compute-*.amazonaws.com 15.125.*.* StrictHostKeyChecking no UserKnownHostsFile /dev/null Alas StrictHostKeyChecking seems the norm, which I can't use as it turns off port forwarding. But that UserKnownHostsFile looks promising... -- Stuart Bishop stuart.bis...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Reminder: Getting Started with Charm Testing
Hi everyone, Charm Testing is a hot topic right now, so in order to help people spin up on testing this first charm school is about charm testing today at 3pm EDT/ 7pm UTC. We'll be on #juju and ubuntuonair.com As always we'll toss the videos up on youtube and send the link to the list. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Multiple Juju Relationships to a Single Charm
not quite clear why you think it doesn't work, could you outline what you'd like to do and where the difficulty arises. a picture is worth a thousand words, but some words as context are useful to frame it. -k On Fri, Oct 3, 2014 at 1:15 PM, Michael Schwartz m...@gluu.org wrote: Juju'ers: If you consider virtual hosting on a web server, each web folder may be a different client, who may have their own OpenID Provider. I made a quick diagram: http://www.gluu.org/blog/wp-content/uploads/2014/10/juju_ apache_charm.png As far as I can tell, there is no really good way to do this in Juju. Any ideas? thx, Mike - Michael Schwartz Gluu Founder / CEO @gluufederation -- 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: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Landing job uses pre-push script
On Thu, Oct 2, 2014 at 1:35 PM, Martin Packman martin.pack...@canonical.com wrote: The landing job for juju now uses the pre-push script from the juju branch before running tests. This means it's running go vet over the source, and I've fixed a couple of errors on master. Great, thanks Martin. What it doesn't do currently is fail the landing if vet reports issues, as the script doesn't fail in this case. If we want to make go vet issues gate the landing of code, we can just land that change to the pre-push script. IIRC, go tool vet will only set an error return code when invoked on a package or files, rather than on a directory. I think it's a matter of checking whether go tool vet prints any warnings, rather than relying on the return code. Or xargs and get the RC. Martin -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: API Versioning for compatible changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Just to let you all know, the Uniter API facade is now versioned: - V0 - all existing methods except GetOwnerTag - V1 - a few new methods related to port ranges support added (AssignedMachine, AllMachinePorts, and ServiceOwner to replace the deprecated GetOwnerTag). At the apiserver side, each version is in its own file (e.g. uniter_v0.go, uniter_v1.go, with uniter_base.go containing common code for both versions), and the same is true for the unit tests (e.g. uniter_v0_test.go, uniter_v1_test.go, and uniter_base_test.go with common tests shared between versions). At the api (client) side, a BestAPIVersion method was added and used internally to check if a method is available and returning an errors.NotImplemented otherwise. So please, from now on add new methods in V1. If something needs to be removed or changed, and you're unsure how to implement it or test it properly, ask me, Frank, or John, and we'll be glad to help. I hope in the future more facades will get refactored like that, and we can make the code and tests maintenance easier, as well as design APIs with versioning and backwards-compatibility in mind. Cheers, Dimiter On 30.09.2014 14:16, John Meinel wrote: This came up recently in a discussion about the Uniter API, but I think it is a broader discussion that we should be having. If you are only adding a new method, it is possible to consider that this is a compatible change, and not bother to do the extra work to create a new version for that Facade and deal with multiple version compatibility. I would argue, however, that this is actually only half of the compatibility statement, and we actually make it harder for clients that want to use our API to do so properly. Consider if we have Client V1, and then we add a new method DoMagic(). If we create a V2 for it, then clients that want to use DoMagic can just do a do you have Client v2? and then decide right after Login what code path they want to use. Otherwise, they have to first check do you have V1 because that is the first version that might have DoMagic, and then do the DoMagic call, and check if they get an IsCodeNotImplemented error, and then fallback to compatibility code. I do realize that there is overhead in doing this work. Especially given our current code base (with no versioning) most of our tests are not easy to apply to 2 versions of a Facade. However, as soon as we have 2 versions, we'll need the code refactored and then the third version should be much easier to create. So I think it is just a cost that we need to just do. The other axis for discussion is whether we go through this effort for all of our API, for only Client apis (and leave Agent APIs to really only have 1 supported version). We did 1 supported version for Firewaller, because the new one can't get its job done with the old API. Thoughts? John =:- - -- Dimiter Naydenov dimiter.nayde...@canonical.com juju-core team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJULogSAAoJENzxV2TbLzHw8UYIALoqCSKAeDi/ticuMnMGfcwv SYLRs6noCNGh/5Z2sGN1/Da9/4uQXPd6d99vEypZvWIl97J5aCtiHD8NKFYqrkwX qTApprs0MEB9Ep1JJW6IZ7kGYL/3+HK7Bizv0CNmrkgvGSTnib2WC6RF4qduP+p3 2CiqBxBEwZ9bnCi21tX4Mbc4UFcbWHrILdE7KMOOQgpkjh/3TXHxfez968ZDuit1 JZ1lnudGwte6qqrPzJgyK4Mvc/MfpL9qxFJrwYzo5UNOwI9hg62EJMimHFmyUb0x lTJ0/9MLYZD7iS5xsB/RovSV6FNp7oC/C34nMjUIVgxcbXRVMYWMKe25POXbkLI= =f6gF -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
