On 6 September 2012 19:53, Ian Lynagh
On Thu, Sep 06, 2012 at 07:14:53PM +0100, Ross Paterson wrote:
On Thu, Sep 06, 2012 at 06:49:36PM +0100, Matthew Gruen wrote:
To my knowledge, It's technically possible to import the old accounts.
Why is that? I think that's worth exploring, as you'd be losing associations between 1150 users and 24456 uploads of 4442 packages. (Not entirely, because the old names would be there as text, but they wouldn't be connected to user-ids.)
I think you misread "possible" as "impossible"?
FWIW, I assumed that there had been a decision that importing accounts is either impossible or unwanted, as the mirror script doesn't do it and there was no TODO item for it anywhere. But if that's not the case then I can look into importing them.
From the point of view of an existing user, they will go to the new site, go to a special page, enter their username and their old
There's two bits: there's the bulk import and then there's the mirroring bot. The bulk import can import the user accounts, given the htpasswd file from the existing server. Obviously the mirroring bot does not have access to that. The mirroring bot can do something with users however, it will try to set the owner of the new package on the destination server to be the same as the owner on the origin server, but I'd have to check the details. Here's the tricky part... (Matthew Gruen and I spent some time investigating this but I'm unsure how much of it is implemented...) The existing hackage server uses http basic authentication and an apache htpasswd file. The new server code uses http digest authentication as this is somewhat better (not as good as ssl but better than basic auth). The passwords from the htpasswd file cannot be converted into the storage format for the digest auth (not without cracking them!). Also, we cannot use either basic and digest depending on the user. So the solution is this... password and a new password (which can be the same if they like). This is a one off. After that they use the site as normal with their new password. What is really going on is that for the old users we keep a note that they have an old htpasswd-style password hash. When they go to the special password change page, we authenticate them using http basic auth using their old password. We set their new digest passwd and delete their old basic auth. This ought to be able to be done without affecting the core features, as a separate "hackage feature", storing the old htpasswd stuff separately. Duncan