Re: [DISCUSS][VOTE] Release Apache Brooklyn 0.10.0 [rc3]

Aled Sage Wed, 21 Dec 2016 06:10:16 -0800

Thanks all - please reviewhttps://github.com/apache/brooklyn-server/pull/499 for this change.

---

I still need to look at the vagrant configuration (stripping out theusername:password, which is added to the config file).


Shout out if anyone else wants to pick that up.

---

I'll look at updating the docs as well, but that can be done after we'vekicked off the RC.


Aled


On 21/12/2016 13:39, Svetoslav Neykov wrote:

+1, agree with Aled's suggestion.

Svet.

On 21.12.2016 г., at 15:05, Alex Heneveld <[email protected]> 
wrote:

+1 ... default of password w/o https has always been a smell for me anyway.
unauth by default solves a lot of headaches.

the way the docker install sets up a pre-configured password is kinda nice

and/or w a switch to karaf we could look at being able to configure auth
etc in the product

--a


On 21 December 2016 at 12:50, Geoff Macartney <
[email protected]> wrote:

+1 to the proposal, as Aled says  I liked it during previous discussions.

Going forward to 0.11 I'd suggest we support just two modes of operation:
unauthenticated out-of-the-box for evaluation,  and authenticated with
https and jwt for production, with an easy process to get from the former
to the latter.


On Wed, 21 Dec 2016, 11:41 Richard Downer, <[email protected]> wrote:

Hi Aled,

+1 to your proposal. In the wider view, many popular software projects are
unauthenticated (or fixed credentials) on a default install, and specific
hardening steps need to be followed before running the software on a
server.

I think authentication needs a bigger discussion post 0.10.0 - I have
several valid use cases from customers that Brooklyn does not currently
support.

Thanks
Richard.


On 21 December 2016 at 10:59, Aled Sage <[email protected]> wrote:

Hi all,

I lean towards us changing the existing behaviour for 0.10.0 (i.e.
producing an rc4 that fixes it).

It seems risky/complicated to revert to the "pre-JAAS authentication code
path". If there is another acceptable way, then I'd much prefer that.

**Proposal**
We disable password authentication entirely, as the default

configuration.

We ensure steps to configure security are well documented.

As per the very long email thread in [1], this is "Alternative Proposal

2"

in my email dated 2016-09-13 15:32.

This got Geoff's agreement (on 2016-09-13 16:25) and also Martin's
agreement (2016-09-13 16:56). John McCabe pointed out by way of

comparison

that Jenkins deploys out-of-the-box with no auth (2016-09-08 22:05).

The major benefits I see are:

1. Solves the immediate problem (i.e. backwards compatibility for
   localhost login with no password).
2. Super-simple user experience, including for installing on a VM
   (which currently still requires the horrible step of digging out the
   auto-generated username:password, buried in the log).
3. Consistency for localhost + remote (getting-started instructions can
   be simpler, rather than different depending how/where you've
   installed it. This has not been stressed enough in the discussions
   so far.)
4. Passwords are a false sense of security when using http (which is
   still the default), given that it would be sent in plain text.

We should also ensure that the vagrant install is consistent (e.g. it no
longer needs to have an auto-populated username:password in the config
file, and can instead rely on the default being no password).

**Longer Term**
For the next release (i.e. 0.11.0), we can continue the discussion for
what the user experience should be long-term (e.g. on first login, it
prompts for a username+password to be created automatically). This

includes

discussion of RPM installs: on `yum install ...`, the user doesn't have a
chance to modify the defaults in the config file before Brooklyn is

started

for the first time.

For 0.11.0, we re-visit the default Karaf configuration (which I believe
will still require the auto-generated username + password (buried in the
log), both for localhost and remote).

Aled

[1] https://lists.apache.org/thread.html/cf6f467cc63afc9bb7bb75d
7396becbd4ea2ac273031d31073f546d2@%3Cdev.brooklyn.apache.org%3E



On 20/12/2016 16:05, Richard Downer wrote:

Ok, I can reproduce this behaviour when trying to connect to a Brooklyn
instance on localhost.

*But...*

I've started up a new instance on AWS and I'm connecting to it on port
8081. A username and password is printed to the console on startup, and

can use those credentials to access the web UI. If I give the wrong
password, I am forbidden to access.

So it seems that this behaviour is unique to localhost. IMO this is
annoying but not a release blocker - but it would be nicer to our new
users
to have a fix.

The Brooklyn startup log says:
2016-12-20 15:54:32,668 INFO  Starting Brooklyn web-console with
passwordless access on localhost and protected access from any other
interfaces (no bind address specified)

So it seems that the "passwordless access on localhost" isn't quite

true.

In that case I'd go with Svet's suggestion to remove the localhost
exception.

Richard.

On 20 December 2016 at 15:08, Svetoslav Neykov <
[email protected]> wrote:

// Added DISCUSS tag

There's a long related [PROPOSAL] thread on the topic -
https://lists.apache.org/thread.html/cf6f467cc63afc9bb7bb75d7396bec
bd4ea2ac273031d31073f546d2@%3Cdev.brooklyn.apache.org%3E <
https://lists.apache.org/thread.html/cf6f467cc63afc9bb7bb75d7396bec
bd4ea2ac273031d31073f546d2@%3Cdev.brooklyn.apache.org%3E> which seems

to

have died off without consensus.

Anyone want to hazard a guess for how hard to fix BROOKLYN-417?
There are two possible fixes.
   * Require the autogenerated password - as simple as removing the
isRemoteAddressLocalhost[1] check.
   * Don't require a password. That's more complicated. It needs
reverting
to the pre-JAAS authentication code path, using a Filter to do the
authorization. Can't say right now whether we can just get some code

from

git history and plug it in or things have changed considerably,

assuming

JAAS under the hood.

Svet.

[1] https://github.com/apache/brooklyn-server/blob/master/
rest/rest-resources/src/main/java/org/apache/brooklyn/rest/
security/provider/BrooklynUserWithRandomPasswordSecurityProv
ider.java#L55

On 20.12.2016 г., at 16:48, Aled Sage <[email protected]> wrote:

Alex, all,

I've created https://issues.apache.org/jira/browse/BROOKLYN-417 to

track this - and have included details from my initial investigation.

I'm in two minds about whether it blocks the release. We expect people

to quickly move to supplying credentials (rather than Brooklyn
auto-generating a password). However, it does impact the initial user
experience (for those running on localhost, rather than vagrant etc) -
having to supply dummy username:password looks horrible. If we did ship
with this, we should probably update the docs to tell people to

configure

the credentials *before* starting brooklyn for the first time.

Anyone want to hazard a guess for how hard to fix BROOKLYN-417?

Aled


On 20/12/2016 14:06, Alex Heneveld wrote:

Hi Devs,

-0 ?  -1 ?

The "bin" build when run locally on a fresh system (no

brooklyn.properties)
requires that a username/password is supplied.  It doesn't do any

authentication of the local credentials but gives a 401 if not
supplied.
Specifically:

$ curl -v http://localhost:8081/ 2>&1 | grep "< HTTP"
< HTTP/1.1 401 Unauthorized

$ curl -u anyuser:passwordignored -v http://localhost:8081/ 2>&1 |

grep "<
HTTP"

< HTTP/1.1 200 OK

I'm inclined to think this should block a release as it will break

any

workflow that expects local http to work, and will irritate new users
without any security benefits, but I could be talked in to forgiving
it.

--A


On 20 December 2016 at 13:41, Andrea Turli

<andrea.turli@cloudsoftcorp.

com>
wrote:

+1 (binding)

Tested by running Svet's verify script.

Do a clean extract of source repo for next steps.

-------------------------------------------

Checks successfully completed:
[✓] Download links work.
[✓] Checksums and PGP signatures are valid.
[✓] Expanded source archive matches contents of RC tag.
[✓] Expanded source archive builds and passes tests.
[✓] LICENSE is present and correct.
[✓] NOTICE is present and correct, including copyright date.
[✓] No compiled archives bundled in source archive.

Additional manual steps done (execute in source distribution folder
apache-brooklyn-0.10.0-src:
  * Check for files with invalid headers in source distribution.

There

are

already files excluded from RAT checks, do a sanity check.

  * Check for binary files in source distribution. Look for files
which

are

created/compiled based on other source files in the distribution.

"Primary"

binary files like images are acceptable.

Checks left to do manually with the help of above instructions:
[✓] All files have license headers where appropriate: I relied on

the

rat

check when running `mvn clean install` for checking that "all files

have

license headers where appropriate".

[-] All dependencies have compatible licenses.



On 19 December 2016 at 17:28, Svetoslav Neykov <
[email protected]> wrote:

Geoff,

I checked the checksums with the release verification script. Is

this

in
source control somewhere? I'll offer this to add to it:
See https://github.com/apache/brooklyn-dist/pull/65 <
https://github.com/apache/brooklyn-dist/pull/65> and in particular
https://github.com/neykov/brooklyn-dist/blob/
9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_broo
klyn_rc.sh

https://github.com/neykov/brooklyn-dist/blob/

9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_

brooklyn_rc.sh>

for an initial implementation of these kind of checks (obviously to be

expanded where possible).

Svet.


On 19.12.2016 г., at 18:17, Geoff Macartney <geoff.macartney@
cloudsoftcorp.com> wrote:

+1

[x] Download links work.
[x] Binaries work.
[x] Checksums and PGP signatures are valid.
[x] Expanded source archive matches contents of RC tag.
[x] Expanded source archive builds and passes tests.
[x] LICENSE is present and correct.
[x] NOTICE is present and correct, including copyright date.
[x] All files have license headers where appropriate.
[-] All dependencies have compatible licenses.
[x] No compiled archives bundled in source archive.
[x] I follow this project’s commits list.

I deployed the classic tarball and karaf versions to Ubuntu using

Java

and 7,

and the RPM to Centos 7, and was able to deploy sample

applications

to

AWS

and SL.

I checked the checksums with the release verification script. Is
this

in
source

control somewhere? I'll offer this to add to it:

    function licenses_and_notices () {
        local filename=$1
        local copyright='Copyright 2014-2016 The Apache Software

Foundation'

        for tarball in `ls *.tar.gz`; do
        container=$( tar tf $tarball | awk NR==1 )
        tar tf $tarball  | grep -q ${container}LICENSE
        tar tf $tarball  | grep -q ${container}NOTICE
        tar xOf $tarball ${container}NOTICE | grep -q

"${copyright}"

        done
    }

    licenses_and_notices

Notes:

I was able to deploy a WebServer + 3-node Riak demo app to

Softlayer

without problem,
and didn't see the "hostname is (none)" problem mentioned

previously

by

Svet.

I tested https access (with Karaf version) and access to it using

"br"

(from Mac) without

observing the crash Svet saw:

    ./br login https://10.10.10.102:8443 geoff password
    Get https://10.10.10.102:8443/v1/server/version: x509: cannot

validate

certificate for 10.10.10.102 because it doesn't contain any IP

SANs

    ./br  --skipSslChecks login https://10.10.10.102:8443 geoff

password
    Connected to Brooklyn version 0.10.0 at

https://10.10.10.102:8443

    ./br app
    Id   | Name   | Status   | Location


Tested the above on Linux and Mac.  I also tried 1000 consecutive

logins
and didn't see the

segfault as mentioned in the comment on BROOKLYN-416. I don't know

why

Svet

is seeing these
problems; my own tests would indicate that br is working ok.

Anyone

else
able to say what

they are seeing?

Caveat:

I did see the behaviour that Svet describes on the main.uri on the

sample
applications.

I thought hard about whether this should prevent us releasing. On
the

one
hand, there

is a possible risk of a poor impression on users trying Brooklyn

for

the
first time if

its own sample apps appear not to work well. On the other hand

it's

fairly

clear just from
looking at the URL what network it is on, so it shouldn't really

be

too

confusing.  In

the end what persuaded me was checking back to 0.9.0, and this

behaviour
was already

there, so this is not a regression. Not that that matters as such,

but

as

far as I recall

there was no feedback on the mailing list about this, so it does

not

seem
to have actually

caused a problem for anyone in practice. I'm therefore happy

enough

to

say

+1.
At the same time I think it is something that we should tidy up

for

the

future.

Geoff





On Mon, 19 Dec 2016 at 11:51 Svetoslav Neykov <
[email protected]> wrote:

+1 (binding)

Caveats:
  * hostname on Softlayer-provisioned machines is "(none)"
  * On Softlayer App Wizard examples "Template 2: Python Web
Server",
"Template 3: Bash Web Server and Riak Cluster" list the private

IP

for

"main.uri" (with no "xxx.public/private" alternatives). It's easy to

think
that it's not working. If public IP is used it's reachable. Some

of

the

items have the sensor propagated to top, but it's still the private

IP

  * "main.uri" is not propagated to root app  (for most examples),

need

to

drill down to first child to get the sensors

  * br - getting fatal error sometimes (
https://issues.apache.org/jira/browse/BROOKLYN-416 <
https://issues.apache.org/jira/browse/BROOKLYN-416>). Not a new

problem

it seems.

  * br - can't use --skipSslChecks, still getting "Get
https://localhost:8443/v1/server/version: x509: certificate is

valid

for

web-console, not localhost" from Karaf dist.

  * If I log in into two localhost ports at the same time I get
CSRF

Token
errors from the page that got loaded first. Using them one by one
works

fine.

Could be easily convinced that item 2 from above doesn't deserve

+1,

thoughts?


-------------------


Tested by running the verify script from
https://github.com/neykov/brooklyn-dist/blob/

9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_

brooklyn_rc.sh

https://github.com/neykov/brooklyn-dist/blob/

9e43edd4f7d65b0553ce41a0405e1be4c8abc364/release/verify_

brooklyn_rc.sh>

(https://github.com/apache/brooklyn-dist/pull/65 <

https://github.com/apache/brooklyn-dist/pull/65>).
Expanded the -bin & -karaf, running with local

brooklyn.properties.

Deployed the example apps to AWS & Softlayer (with preconfigured

locations).
Expanded the OS X br client and tried it against Classic (https) &
Karaf

(non-https);

[✓] Download links work.
[✓] Binaries work.
[✓] Checksums and PGP signatures are valid.
[✓] Expanded source archive matches contents of RC tag.
[✓] Expanded source archive builds and passes tests.
[✓] LICENSE is present and correct.
[✓] NOTICE is present and correct, including copyright date.
[✓] All files have license headers where appropriate.
[✓] All dependencies have compatible licenses.
[✓] No compiled archives bundled in source archive.
[-] I follow this project’s commits list.


Svet.


On 18.12.2016 г., at 19:14, Aled Sage <[email protected]>

wrote:

+1 (binding)

I downloaded the tar.gz, and ran it on OS X. I deployed

TomcatServer

to

AWS, Softlayer, Openstack (bluebox-london) and Google Compute

Engine.

I ran the verify_brooklyn_rc.sh script (see attachment in rc1

vote).

I relied on the rat check when running `mvn clean install` for

checking

that "all files have license headers where appropriate".

I checked that each tar.gz in [1] contained a top-level LICENSE
and

NOTICE file (including the text "Copyright 2014-2016 The Apache

Software

Foundation").

[-] Download links work.
[-] Binaries work.
[x] Checksums and PGP signatures are valid.
[-] Expanded source archive matches contents of RC tag.
[x] Expanded source archive builds and passes tests.
[x] LICENSE is present and correct.
[x] NOTICE is present and correct, including copyright date.
[x] All files have license headers where appropriate.
[-] All dependencies have compatible licenses.
[x] No compiled archives bundled in source archive.
[x] I follow this project’s commits list.

Aled

[1]

https://dist.apache.org/repos/dist/dev/brooklyn/apache-

brooklyn-0.10.0-rc3
On 16/12/2016 12:34, Svetoslav Neykov wrote:

This is to call for a vote for the release of Apache Brooklyn

0.10.0.

This release comprises of a source code distribution, and a

corresponding
binary distribution, and Maven artifacts.

The source and binary distributions, including signatures,

digests,

etc. can

be found at:


https://dist.apache.org/repos/dist/dev/brooklyn/apache-

brooklyn-0.10.0-rc3
The artifact SHA-256 checksums are as follows:

  9ae6ec9f6e2356264fd2032d224965d191e5eab5a5346f8a9de5b0527165
0157

*apache-brooklyn-0.10.0-rc3-1.noarch.rpm
  b43c1fc20409594d17151d68b550bb17d8ea5a5592e0b7fbdcf489a81ca2

118e

*apache-brooklyn-0.10.0-rc3-bin.tar.gz
  cb7df99f024e918c5517097d904a68d9976c5bf913c9dd64edebb6b5b6e5

a89e

*apache-brooklyn-0.10.0-rc3-bin.zip
  d65d2525507d40fa0b554b13a57190a724213610a7615082d53137b7bab4

b5d5

*apache-brooklyn-0.10.0-rc3-client-cli-linux.tar.gz
  4d13118fca8e02aaf5b4ab3b3f305d139450bcf64d290781609643c4622b

8cb5

*apache-brooklyn-0.10.0-rc3-client-cli-linux.zip
  375eb6a4944a7758dc790a75bd4a0abc782a4ba66af754b4162bbb66a339

02d8

*apache-brooklyn-0.10.0-rc3-client-cli-macosx.tar.gz
  9d95e0679e603a9184ada88b63b0c4e8f8503eb51677e04ae59f4aa05f45

*apache-brooklyn-0.10.0-rc3-client-cli-macosx.zip
  502e0999d3612f0eb4027d24312da67a67183fc127074ec815b3c72f5de4

1d87

*apache-brooklyn-0.10.0-rc3-client-cli-windows.tar.gz
  1e1ec0210e53faaf9ef1d8907275535a197b341df80e0832067967f4075d

b191

*apache-brooklyn-0.10.0-rc3-client-cli-windows.zip
  a32c65628bf897c66ed8bd820a2ce5268bba52815b46f805795e9b51ac83

*apache-brooklyn-0.10.0-rc3-karaf.tar.gz
  4b840de7ab986ba64ffba4b98748ca87818718ac3e386bb2d978533e4fa3

5f62

*apache-brooklyn-0.10.0-rc3-karaf.zip
  7906b3dba2278c9648f2b340a532d3030536a6a8f1c920311bdcd585a421

11e8

*apache-brooklyn-0.10.0-rc3-src.tar.gz
  4579e5e27c2751b5e8b57bab126ae683aa34aa42d6e13eb6c922951df694

7b4c

*apache-brooklyn-0.10.0-rc3-src.zip
  b361ada2d4cc1334e72b44986b96e6302aaa24464252c3782f7b679bfa5d

a858

*apache-brooklyn-0.10.0-rc3-vagrant.tar.gz
  393df963f6b952ec8c05c1aa0ab0d459037e0972798f17ba7d0221f7e357

*apache-brooklyn-0.10.0-rc3-vagrant.zip
The Nexus staging repository for the Maven artifacts is located
at:

https://repository.apache.org/content/repositories/

orgapachebrooklyn-1034
All release artifacts are signed with the following key:

    https://people.apache.org/keys/committer/svet.asc

KEYS file available here:

    https://dist.apache.org/repos/dist/release/brooklyn/KEYS


The artifacts were built from git commit IDs:

brooklyn: 1d7ab19ffba2c87e9ad1b037fb217dc7d39506c9
brooklyn-client: 0e870fa15714c5a050bb67d6fa0429ff90a8fa4c
brooklyn-dist: dda655c45abab34601a5e62250431ea93fdf1755
brooklyn-docs: d75752725ef6683a0f52e3059ed475dc69872f9e
brooklyn-library: 9fbc78cb4a9d1dccdbdbb70a1ee48f2afddfe067
brooklyn-server: 41561635e3bbb0524dbeaae516a26c793174fd93
brooklyn-ui: a6e2e8bccfdd98b4f7155b5be86f5b85149e0f33
All of the above have been tagged as

"apache-brooklyn-0.10.0-rc3"

Please vote on releasing this package as Apache Brooklyn

0.10.0.

The vote will be open for at least 72 hours.
[ ] +1 Release this package as Apache Brooklyn 0.10.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...


Thanks!
Svet.


CHECKLIST for reference

[ ] Download links work.
[ ] Binaries work.
[ ] Checksums and PGP signatures are valid.
[ ] Expanded source archive matches contents of RC tag.
[ ] Expanded source archive builds and passes tests.
[ ] LICENSE is present and correct.
[ ] NOTICE is present and correct, including copyright date.
[ ] All files have license headers where appropriate.
[ ] All dependencies have compatible licenses.
[ ] No compiled archives bundled in source archive.
[ ] I follow this project’s commits list.

Re: [DISCUSS][VOTE] Release Apache Brooklyn 0.10.0 [rc3]

Reply via email to