Major outage caused by DDoS at Linode Atlanta
Resolved
The DDoS seems to be resolved for now, but we'll keep an eye on it.
Sep 3, 9:27 PMResolved Sep 7, 3:22 AMMajor
Status Provider
Home
/
Status
/
Service
Home
/
Status
/
Service
Community repository for open source Clojure libraries.
Source
statuspage.io
Category
Development
Adapter
STATUSPAGE IO
Verified
Pending review
Current state
Operational
Checked 6m ago
5
Components
0
Active incidents
0
Maintenance
100%
90d uptime
Major outage caused by DDoS at Linode Atlanta
Sep 3, 9:27 PM
Normalized official status-page data for incidents, maintenance, components, and history.
100%
Known uptime
1 known history days
5
Components tracked
0 outage, 0 degraded
8
Incidents indexed
0 active right now
10
Maintenance windows
0 active or scheduled
Components with the most recent status-page events.
API
Operational
Badges
Operational
DNSimple Name Servers
Operational
JAR repository
Operational
Site
Operational
Component changes, incidents, and maintenance windows grouped by day.
operational
degraded
outage
maintenance
unknown
1
operational days
0
degraded days
0
outage days
0
maintenance days
89
unknown days
Latest outages and degradations detected from the official status page.
The DDoS seems to be resolved for now, but we'll keep an eye on it.
Looks like we're all better now
## Summary There was approximately 25 minutes of server downtime from 2016-08-05 09:46 UTC to 2016-08-05 10:09 UTC while updating nginx. The root cause was a change in nginx default behaviour around IPv6 sockets which caused IPv4 connections to be ignored. ## Details The version of nginx installed on the server was quite old. Before upgrading, I looked through the release notes to look for changes. I copied them to a text file for easy reference if something went wrong. Nothing in the changelog looked like it would affect us (though crucially, I didn't fully understand all the mentioned changes...). I updated nginx while it was running (to prevent downtime being too long). Once the update had finished, I restarted nginx. It reloaded and everything seemed to be ok. I then realised that the old process was running, and the new version hadn't started. After killing the old process and starting the new one, clojars.org wasn't accessible. I searched for possible answers, and a change that was mentioned in the changelog came up: `ipv6only` was now set on by default for IPv6 sockets. This means that only IPv6 connections would be accepted and IPv4 would not connect. If you were connecting to Clojars over IPv6, you would have had no connectivity issues. I updated the nginx server config to turn off `ipv6only`, and service was restored. ## Learnings * When updating software, make sure that we understand all changes in the changelog, especially ones which change default behaviour. * If possible it would be good to test upgrades on a test server before applying it to the production server.
Linode issues appear to be resolved. Everything should be operational.
This incident has been resolved.
It seems like everything is back to normal.
Looks like it was just a temporary blip. Back to your regularly scheduled Clojure programming.
It seems like everything is stable and back to normal, but we'll keep monitoring the situation.
Scheduled and completed maintenance windows are separated from incidents.
The scheduled maintenance has been completed.
The scheduled maintenance has been completed.
The scheduled maintenance has been completed.
The migration has completed, all seems to be normal. Let us know if there are any issues.
Maintenance is complete.
Everything seems to have gone suspiciously well. Maintenance over, but monitoring.
The scheduled maintenance has been completed.
Maintenance is complete, site should be fully operational
Maintenance canceled - site is fully operational
The scheduled maintenance has been completed.
Uptimus tracks the official Clojars status page, normalizes upstream events, and separates incidents from scheduled maintenance.
Official source
https://clojars.statuspage.io
Adapter
STATUSPAGE IO
Alert streams
Incidents, component changes, and maintenance windows.
Public SEO page
Indexable status history for users searching outage information.
Regional reports can be layered on top of official provider status when user signals are available.
Showing 1 to 5 of 5 tracked components.
| Component | Status | Type | Last changed |
|---|---|---|---|
Site clojars.org user facing site | Operational | Component | Not recorded |
JAR repository | Operational | Component | Not recorded |
API | Operational | Component | Not recorded |
Badges | Operational | Component | Not recorded |
DNSimple Name Servers | Operational | Component | Not recorded |
Follow outages, degraded components, and maintenance updates in your Uptimus workspace with email, push, and webhook alerts.
Official provider components
Incident and maintenance separation
Workspace alerts and webhooks
Related status pages based on category, adapter type, and operational history.
Clojars is currently marked as Operational in Uptimus based on the latest official status page check.
Supported status page providers are checked continuously by our scraper scheduler. The public page is cached briefly for SEO and performance.
No. Uptimus stores incidents and maintenance windows separately when the upstream provider exposes enough detail.
Yes. Create an Uptimus workspace, follow this provider, and choose email, push, or webhook notifications.
