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 <[email protected]> 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 thisinsource 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_brooklyn_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 Java8and 7, and the RPM to Centos 7, and was able to deploy sample applications toAWSand SL. I checked the checksums with the release verification script. Is thisinsource control somewhere? I'll offer this to add to it: function licenses_and_notices () { local filename=$1 local copyright='Copyright 2014-2016 The Apache SoftwareFoundation'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: cannotvalidatecertificate for 10.10.10.102 because it doesn't contain any IP SANs ./br --skipSslChecks login https://10.10.10.102:8443 geoffpasswordConnected 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 consecutiveloginsand didn't see the segfault as mentioned in the comment on BROOKLYN-416. I don't know whySvetis seeing these problems; my own tests would indicate that br is working ok. Anyoneelseable to say what they are seeing? Caveat: I did see the behaviour that Svet describes on the main.uri on thesampleapplications. I thought hard about whether this should prevent us releasing. On theonehand, there is a possible risk of a poor impression on users trying Brooklyn forthefirst time if its own sample apps appear not to work well. On the other hand it'sfairlyclear 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 thisbehaviourwas already there, so this is not a regression. Not that that matters as such, butasfar as I recall there was no feedback on the mailing list about this, so it does notseemto have actually caused a problem for anyone in practice. I'm therefore happy enough tosay+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 tothinkthat it's not working. If public IP is used it's reachable. Some oftheitems have the sensor propagated to top, but it's still the private IP * "main.uri" is not propagated to root app (for most examples), needtodrill 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 newproblemit seems. * br - can't use --skipSslChecks, still getting "Get https://localhost:8443/v1/server/version: x509: certificate is validforweb-console, not localhost" from Karaf dist. * If I log in into two localhost ports at the same time I get CSRFTokenerrors from the page that got loaded first. Using them one by oneworksfine. Could be easily convinced that item 2 from above doesn't deserve a +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 preconfiguredlocations).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 TomcatServertoAWS, 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` forcheckingthat "all files have license headers where appropriate".I checked that each tar.gz in [1] contained a top-level LICENSE andNOTICE file (including the text "Copyright 2014-2016 The ApacheSoftwareFoundation").[-] 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-rc3On 16/12/2016 12:34, Svetoslav Neykov wrote:This is to call for a vote for the release of Apache Brooklyn0.10.0.This release comprises of a source code distribution, and acorrespondingbinary distribution, and Maven artifacts. The source and binary distributions, including signatures, digests,etc. canbe found at:https://dist.apache.org/repos/dist/dev/brooklyn/apache-brooklyn-0.10.0-rc3The artifact SHA-256 checksums are as follows: 9ae6ec9f6e2356264fd2032d224965d191e5eab5a5346f8a9de5b05271650157*apache-brooklyn-0.10.0-rc3-1.noarch.rpmb43c1fc20409594d17151d68b550bb17d8ea5a5592e0b7fbdcf489a81ca2118e*apache-brooklyn-0.10.0-rc3-bin.tar.gzcb7df99f024e918c5517097d904a68d9976c5bf913c9dd64edebb6b5b6e5a89e*apache-brooklyn-0.10.0-rc3-bin.zipd65d2525507d40fa0b554b13a57190a724213610a7615082d53137b7bab4b5d5*apache-brooklyn-0.10.0-rc3-client-cli-linux.tar.gz4d13118fca8e02aaf5b4ab3b3f305d139450bcf64d290781609643c4622b8cb5*apache-brooklyn-0.10.0-rc3-client-cli-linux.zip375eb6a4944a7758dc790a75bd4a0abc782a4ba66af754b4162bbb66a33902d8*apache-brooklyn-0.10.0-rc3-client-cli-macosx.tar.gz9d95e0679e603a9184ada88b63b0c4e8f8503eb51677e04ae59f4aa05f454860*apache-brooklyn-0.10.0-rc3-client-cli-macosx.zip502e0999d3612f0eb4027d24312da67a67183fc127074ec815b3c72f5de41d87*apache-brooklyn-0.10.0-rc3-client-cli-windows.tar.gz1e1ec0210e53faaf9ef1d8907275535a197b341df80e0832067967f4075db191*apache-brooklyn-0.10.0-rc3-client-cli-windows.zipa32c65628bf897c66ed8bd820a2ce5268bba52815b46f805795e9b51ac836912*apache-brooklyn-0.10.0-rc3-karaf.tar.gz4b840de7ab986ba64ffba4b98748ca87818718ac3e386bb2d978533e4fa35f62*apache-brooklyn-0.10.0-rc3-karaf.zip7906b3dba2278c9648f2b340a532d3030536a6a8f1c920311bdcd585a42111e8*apache-brooklyn-0.10.0-rc3-src.tar.gz4579e5e27c2751b5e8b57bab126ae683aa34aa42d6e13eb6c922951df6947b4c*apache-brooklyn-0.10.0-rc3-src.zipb361ada2d4cc1334e72b44986b96e6302aaa24464252c3782f7b679bfa5da858*apache-brooklyn-0.10.0-rc3-vagrant.tar.gz393df963f6b952ec8c05c1aa0ab0d459037e0972798f17ba7d0221f7e3570440*apache-brooklyn-0.10.0-rc3-vagrant.zipThe Nexus staging repository for the Maven artifacts is located at:https://repository.apache.org/content/repositories/orgapachebrooklyn-1034All 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.
