We have updated the SSL certificate and intermediate CAs again today.
- SHA256: 39:B8:E5:9B:F1:39:92:33:99:EF:32:5A:9C:8E:14:58:42:63:83:F2:A2:2E:36:FE:33:E7:91:16:21:A8:F6:81
- SHA1: B0:53:47:AB:EE:9F:A0:67:F8:9C:4A:CF:81:72:A2:A2:46:47:1F:32
The *.coderesort.com SSL certificate has been renewed.
- SHA1: 1D:4A:4D:BD:07:E6:B0:7B:90:40:FA:1C:FE:D1:A1:12:9B:31:3E:08
- MD5: DB:82:8A:4D:3D:FC:8A:CF:D0:65:E9:AD:A3:88:25:1D
We are scheduling OS upgrades and maintenance across our infrastructure this weekend.
Services will be unavailable from 23:30 CET Friday night, but we expect most things completed in 2-3 hours. However, we are keeping the maintenance window open across the weekend in case follow-up issues require reboots or service restarts.
Follow @CodeResort on Twitter for further status updates.
Update: Upgrades completed in 6 hours. All services fully operational again.
We are moving with the times, and are now introducing Git as a supplement to our Subversion support. This post is not about the relative merits of each system, only to provide an overview of the new features we have added for Git.
- Git is optional. Each project still gets one Subversion project like before, but can now add additional Git repositories.
- Git repositories are not yet browsable via the web interface. The source, changesets and timeline of events are not yet enabled due to (lack of) performance. We don't quote get the performance we require with so many projects and repositories, and no size or content restrictions. However, we have made a small 'Browse Source' helper that lists Git repositories for each project with URLs to use with Git clients. We will enable the full source browsing functionality as soon as it is ready.
- Git clients can connect both through SSH and HTTPS. HTTPS being the most common and easy to get started with, but SSH adding both additional security and usefulness in certain situations by providing certificate-based access.
- To support SSH certificate-based access, we have made an administration interface for adding your public keys. The interface is available through your personal profile project, reachable via your name in the menu at the very top. If this still says "Create profile..." you need to click and create a profile first. Once accessed, the administration interface should be self-explanatory: It allows you to paste and add keys, or mark existing keys and delete them.
- All projects now have a Git/Repositories menu item under "Admin". However, like anything else this is restricted by permissions, so make sure users are assigned permissions REPOSITORY_CREATE, REPOSITORY_DELETE or VERSIONCONTROL_ADMIN as needed. With required permissions, just enter a name and create your first Git repository in seconds. And, you can even fork an existing repository as an identical copy of the original (a.k.a server-side clones). Permissions are managed through this same interface, as is the ability to delete projects.
Questions? Missing features? Bugs? Please let us know!
Our ISP is making some infrastructure changes, and have warned that we can expect something like ~20 minutes of downtime on Monday September 19th after 16:00.
Our Internet link broke twice this weekend (all times are CET):
- On Saturday August 27th at 11:42 the link went down. We called for emergency help and the ISP arranged for someone to come in and check cables. Unplugging and replugging cables, and as if by magic the link became active again at 16:36. 4h54m downtime.
- On Sunday August 28th in the evening the link started to become unreliable. Lots of packets not making it through the link, effectively slowing the service to a crawl. At 23:45 the link died completely. Contacted ISP emergency help again, but as it was now nighttime there was no real hope of immediate help. We scheduled a new visit first thing Monday morning. They arrived as promised, changed various cables and plugs, and measured all cabling for control. Link reconnected at 09:57, logging 10h12m of downtime.
We are quite confident the problem was related to cabling, and our ISP is quite confident that current cabling is OK. We sincerely hope the issue is resolved for good.
Note: When the service becomes unavailable, our Twitter account is the only reliable source of information. Do follow us if you want reliable status messages when issues arise.
Provider of our domain and DNS services, NetworkSolutions.com, is experiencing repeated distributed denial-of-service attacks. The DNS servers that map www.coderesort.com to address 188.8.131.52 has at times not been available. We are sorry about this and any problems you may be experiencing, but it seems that the worst is now passed as the servers have started responding again.
If you are not already following us on Twitter, please follow us now:
Any issues will be reported and tracked on Twitter as they happen. If our service is unavailable for any reason, @CodeResort will be our only reliable channel for reaching you with the latest status.
You may at any time make a full local backup of your Subversion repository using the svnsync tool that is part of Subversion.
Much information about this tool is published on the interwebs, but we've made a how-to that is as simple as it can possibly get. As always this information is available in the 'Help' section of all projects, and of course by direct link:
Together with web project backups, this lets you keep local copies of ALL your CodeResort project information.
We have just deployed a new SSL certificate as our old certificate was set to expire in the next month.
As Subversion clients often come without any pre-defined certificate authorities, each new certificate must be explicitly accepted. For our new certificate, the approval should contain information similar to this - particularly verify the fingerprint:
Error validating server certificate for 'https://www.coderesort.com:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: *.coderesort.com - Valid: from Mon, 06 Jun 2011 06:30:33 GMT until Wed, 06 Aug 2014 18:06:16 GMT - Issuer: GeoTrust, Inc., US - Fingerprint: 45:f4:c0:4b:e8:e6:1e:21:21:a5:68:c3:d7:18:c6:63:d6:26:62:3e (R)eject, accept (t)emporarily or accept (p)ermanently?
Please accept it (p)ermanently to make Subversion client work as before.
We will do a major refresh of the server OS tonight, so expect up to 1 hour of downtime as we upgrade and verify.
UPDATE: Recorded downtime from 23:51 CET to 00:18 CET for a total of 27 minutes. All systems operational again.
We are fortunate to enjoy a steady rise in users, projects and activity. Our most recent landmark is passing 100.000 Subversion commits!
There is room for more, so keep them coming :-)
We've made some very useful additions to our Talk feature - available to all projects.
Offline support with notification
As a user, you can now mark your membership in the room as permanent. If you are not presently available in the room, you will still be listed in a new 'Offline' users list.
The really useful extension of this is that we will notify you by email if someone speaks to you in the room when you are offline. That way others can bring you into the discussion, and you can bring in others as needed.
The format for addressing users is to start the line with an explicit reference to the user:
steve: Got an opinion on this new suggestion from john?
User 'steve' would be notified if not online.
View-only access to talks
It is now possible to assign read-only permission to users, and TALK_VIEW allows viewing full transcript and follow ongoing discussions. With the exception of posting new messages or uploading files.
As an extension of this feature, the view-only policy has also been enforced for rooms marked as 'closed'. Only TALK_ADMIN permission will allow posting in closed rooms.
Why not create a Talk to host your next project meeting?
At CodeResort we provide various features and services to our users, based on various tools and technologies. It is our intention to present this largely as a unified whole, but sometimes that is hard to do - and sometimes it just makes no sense to do it.
For logins we made a very early decision to base it on email address. That allowed us to only require 2 pieces of information from our users; email + password. It was the lowest common denominator for all the tools and clients needed to work with CodeResort, and it provided the lowest level of entry for users to get started.
This makes email address the key for a dimension of our users infrastructure, and as such it cannot be changed. As any key, we could of course change it if we really, really wanted to. However, that would mean rewriting all parts of project history and would be both incorrect and dangerous to do. If we change person@companyA.com to person@companyB.com for all commits and all wiki and ticket history, would that really be correct? If person leaves Company A to take on a job at competing business Company B, would that make a new natural location for sending ticket notifications for old Company A issues that gets updated? Would it be right to reassign credit for thousands of hours of changes paid for by Company A onto Company B? Should the person retain access to all Company A projects in new role? We don't think so.
Any user that changes email needs to create a new login, and re-apply for access to the projects that now makes sense to participate in.
A natural consequence of the simple email-based key is of course that many decide to use a 'personal' email when registering, so that trivial things like changing workplace need not be an administrative burden. That's fine with us of course, you are free to use any valid email you want.
For project owners, however, this is somewhat less ideal. Being presented with a email@example.com address makes it harder to determine who this may be, a challenge that usually only becomes harder over time as people come and go in projects.
So, we came up with the concept of an optional "Profile". 'Optional' in so far that we do not require that you make one, but 'optional' in the sense that project owners may require it and only accept applications for access if you have such a profile that details your full name, place of work and basic contact details.
Your login is linked to this profile, and in fact the profile is a separate project just for you and your login where you may store your own information in the Wiki or use the Blog to publish facts and trivia. Through the personal project we also provide a 'My Tickets' overview page, and we hope to further extend personal projects with useful features soon.
Link several logins to one profile
A recent change we made is to add the ability to link more than one login to a profile. That means you can keep your profile ('person') and share it and access it from any of the logins you create. Moving from Company A to Company B does not mean you shouldn't be allowed to keep your own information. The details of this is available in the Admin->Logins page in your profile project.
Questions and Answers
Q: Why no Forms login? Why no descriptive forms? Why not use state-of-the-art web technologies such as OpenID / OAuth to perform authentication, instead of plain authentication requests? The simple answer is that the tools support just isn't there. There is no way to make a Subversion client perform a redirect or have it impersonate by accepting tokens and cookies. All it knows is the Basic and Digest authentication protocols. Same with the WebDAV support that allows you to connect file shares and map them as local disks. And the API that allows you to use simple tools to pull and push information. Whatever else we provided for our web-frontend we would still need to make a duplicate system that would work with all possible tools. So we have ended up sticking to the one simple way of doing it.
Q: Why can't I login using my 'handle' / shortname? We could have done that, but with profiles supporting more than one login this is not really feasible. Should we test password against any of the logins? Do we pick the first login that matches? The last? Or just make it random? What if you forgot your password, do we reset all logins or just pick one again?
Q: What if my company change name? So, what if the change from Company A to Company B is not about you changing but your employer changing? What if you get sold or merged into some new entity - or your employer just decides on a corporate name change? That is the one real-world scenario that complicates our simple rule, but we still do not have any tools to make such pervasive changes. Sorry.
Q: What's next? From the perspective of users and logins? Not much really. We'll keep using our simple scheme for logins and profiles, but keep enhancing the user experience as we did by introducing the option to link several logins to same profile.
We will perform OS upgrades tonight, starting at 23:45 CET. Expect site to be unavailable for +/- 30 minutes while we upgrade packages, reboot and verify.
UPDATE: All upgrades completed. 10 minutes of downtime recorded.
Ever been hard at work at something in your Subversion working copy when you realize that this really, really should have been done in a branch instead...? Whatever the reason, this situation always tends to add a level of anxiety as it really should be done without loosing hours worth of changes...
Here is our tried & tested how-to guide: HowTo/Subversion/DevelopBranchMerge
As our other documentation and guides it can always be found in the 'Help' section of your project.