#musicbrainz-devel

How's this? http://navap.mbsandbox.org/

looks nice

two lines feels like the max for a footer though, so as long as it doesn't creep beyond that :)

the open licenses note is new, yeah?

Yes

however, yeah, that looks better, it doesn't do a gross wrap thing at the narrowest it can get. +1 :)

that schwag link is sorta terrible too

in that it only has terrible cafepress crap :P

I added the data license link to balance the two sides out, but I'm thinking what if we just had that as the left side?

The only important link that we'd miss is the donate link. Everything else is already on the page or..schwag..

hm

I like the links to wiki/forums/tracker/etc. being not buried in menus

I hate using the menus

I would expect someone like you to skip the links and just type the urls in :p

well, yes, that's also true

I like having the links not buried in menus because menus suck, not because I use *either* :P

hm. the wiki link should also be scheme-independent

I should see about getting https on our other subdomains too

solve the "the default goes to the wrong place omg!" ticket with "okay fine, now you can't get to the default because everything's https" :P

cool, thanks

Are we putting the blog, jira, and forums on https as well?

they aren't yet

however, that's the intention

we have a *.musicbrainz.org cert, we should use it :P

Yeah

I haven't for those because blog/forums are apache and jira's it's own weirdness -- so I don't know the incantations already :)

meh, its*

twitter can also be scheme-independent FWIW

obviously the donation stuff is through other sites, so that much isn't an issue, but

A single domain cert isn't too expensive I think

no, indeed not, I just don't know if that's something that's wanted :)

we'll probably want one for caa.org at some point, to silence warnings about insecure content

but we also need to pester the IA, because at present their https stuff is set up wrong

e.g. https://ia701207.s3dns.us.archive.org/mbid-189d... works, but there's a cert warning because it's for *.us.archive.org, not *.s3dns.us.archive.org

Shouldn't *.us.archive.org encompass *.s3dns.us.archive.org?

no

SSL wildcards only support one level

I see

yeah

it's somewhat annoying :/ but that's how it is

Is there a good reason for not using https as default or even forcing https via an nginx redirect?

not forcing people into it immediately

especially because userscripts are by and large not updated to account for https yet

navap: temporarily limiting exposure for testing purposes

also that :)

but yes; I do think that all logged-in access should be going through https; maybe even all website access.

on the other hand, doing non-authenticated webservice access unencrypted might be a good idea.

the webservice is the other thing, we don't have a way to guarantee our clients have stuff

we don't even redirect www.musicbrainz.org to musicbrainz.org for the webservice

which incidentally means it works better over HTTPS than the rest of the site, since our www -> non-www redirect is currently broken, but :P

that shouldn't be hard to fix in the nginx config tho

no, there's already a codereview up for it :)

yep, that looks about right :)

the nginx config for musicbrainz is rather complicated :/

the rewrites file is the biggest pain

because legacy URLs :?

the frontend configs aren't even public, that's another layer of complexity

something went wrong in my libvirt, so my musicbrainz vm has decided to disappear without a trace

I need to rebuild it now :/

onlything left is the frontend config in my nginx :)

haha

well, the *rest* is all in the git repository

it's just the frontend stuff that's in a separate private repo

admittedly, my frontend nginx config looks like this: https://raw.github.com/gist/3856052

very impressive ;)

looks about right, yeah

(that address is on a split dns setup, and can only be seen in my house)

if you want https, set X-MB-https to on/off accordingly :)

where are you terminating the https?

frontend

and then passing X-MB-https so the server instances know how to format links

and then you pass a header to the backend to indicate whether or not https was used?

yup :)

makes sense.

This http vs https link business is a bit complicated. e.g. links in emails

links in emails should be always https, imo.

since you only get an email if you've logged in at some point, and logged in users should always be using ssl :)

But what about non-musicbrainz.org servers?

fun.

I guess you'll have to add another parameter to DBDefs.pm :/

Shhh don't let ocharles hear you

I think I'll just leave this scheme-independant link fixing for later

although the sandbox ones are a special case, i guess.

there we go, finally fixed my automounting authentication issues properly

ooh, fun. just set up my mail client with a startssl certificate, so I can now send signed emails :)

it's just a class 1 cert tho, so all it does is show that the person sending the email has control of the email address being sent from... which is still something.

btw, if anyone uses HTTPS-Everywhere, rules file for musicbrainz: https://gist.github.com/3856165

kepstin-work: the rule for beta has been 50% completion or better -- you're probably right but you do need to go through and check them :)

yay, the picard-daily ppa is finally building again

yay :D

hobbes is so sloooow

I wonder if test's database should be on rika and just the server code on hobbes

or something

warp: if musicbrainz_db_warp on hobbes can be dropped, either do it or tell me; test is now using a different DB

(specifically: musicbrainz_db_20121008)

warp, ijabz: related, if the test search server needs updating, someone should make that happen :) either by doing it yourselves or informing me how to do that

ianmcorvidae: I am not personally using musicbrainz_db_warp , was it being used by test?

(also, goodmorning! :)

yes, it's what test was using until a bit more than an hour ago

warp: also, are the "Show all pending edits" changes in the schema change branch?

warp: I don't see the script in upgrade.sh

which understandably worries me, given I thought testing for schema change stuff had already started

ianmcorvidae: could be

ianmcorvidae: I didn't merge it in, and if it's not in there apparently ocharles didn't either :)

(I have a shippit from you, not from oliver)

yeah

I had expected that the upgrade script, if nothing else, would be there

the RG coverart schema change scripts are in there

anyway

I guess it should at least be on test

hm, lots of warnings in t::MusicBrainz::Server::Controller::Statistics

yeah

a lot of those are the result of it making sure the pages don't crash horribly when there are no statistics

ocharles has a patch up that silences lots of warnings, IIRC

I'm validating the html

but it looks like I'm going to have to silence another error

(silence as in ignore it, instead of fixing the generated html)

oh no, this is an error, not a warning. grmbl.