Unsere primäre Infrastruktur inkl. des Shared Hostings und der vServer sowie einer der beiden Community-IX-Switches waren vom Ausfall nicht betroffen, da sie noch hinter einer anderen USV des Rechenzentrumsbetreibers hängen, die die ganze Zeit über Strom geliefert hat.

Sollte jemand noch Probleme mit seinem Server sehen, bitten wir um eine Info an den Support. Bitte prüft zunächst den Zugang über den Serviceprozessor oder die serielle Konsole, falls vorhanden. In den meisten Fällen können die Probleme dadurch gelöst werden.

Unsere primäre Infrastruktur inkl. des Shared Hostings und der vServer sowie die Community-IX-Switches waren vom Ausfall nicht betroffen.

Sollte jemand noch Probleme mit seinem Server sehen, bitten wir um eine Info an den Support. Bitte prüft zunächst den Zugang über den Serviceprozessor oder die serielle Konsole, falls vorhanden. In den meisten Fällen können die Probleme dadurch gelöst werden.

Ein Teil unserer Infrastruktur wurde teilweise aus einem anderen Raum von einer anderen USV versorgt. Diese Stromversorgung war die ganze Zeit über stabil, reicht aber nicht aus, um Server und Netzwerkgeräte zu versorgen. Daher haben beispielsweise vServer nicht neu gestartet, aber über Serverhousing untergestellte Server schon.

Der RZ-Betreiber plant, auch den Raum in dem wir uns befinden, mit einer komplett neuen Stromversorgung auszustatten. Es wird jedoch noch mehrere Monate dauern, bis die neue Infrastruktur komplett fertiggestellt ist und wir auf eine neue Stromversorgung umstecken können.

Die Geräte sind kurz nach dem Ausfall nach und nach wieder hochgefahren. In einem Rack musste nachgeholfen werden, da die Sicherungen rausgeflogen sind und gegen 12:53 Uhr erst wieder aktiviert werden mussten.

Sollte jemand noch Probleme mit seinem Server sehen, bitten wir um eine Info an den Support. Bitte prüft zunächst den Zugang über den Serviceprozessor oder die serielle Konsole, falls vorhanden. In den meisten Fällen können die Probleme dadurch gelöst werden.

Update: Alle Arbeiten am Server sind erfolgreich abgeschlossen und wir sind wieder up-to-date.

Unsere Hostingdienste werden in einem Rechenzentrum betrieben, an dem wir auch viele Server unserer Teilnehmer hosten. Das Rechenzentrum ist von dieser Wartung nicht betroffen, sondern lediglich der Vereinsraum.

Wir bitten den Ausfall zu entschuldigen.

Update: Der effektive Ausfall war zwischen 12:54 und 13:03 Uhr. Es ist nichts unerwartetes ausgefallen. Die Core-Infrastruktur des Vereinsraums ist durch eine USV gesichert und war die ganze Zeit über online.

Wir bitten den Ausfall zu entschuldigen.

Das Problem wurde gegen 18:30 Uhr behoben.

Heute haben wir die Bereitstellung der Webserverdaten per NFS als Ursache ausfindig machen können. Die Auslieferung der Webserverdaten erfolgt nun etwas anders und seit der Änderung verhalten sich die Webserver stabil. Ebenso hat sich die Performance auch verbessert, so dass sich die Änderung aus mehreren Gründen gelohnt hat.

Die Ursache wurde inzwischen behoben. Es werden wieder korrekte Zertifikate ausgeliefert.

Update 22:45 Uhr: Wir konnten durch Umrouting nun hoffentlich das Ausmaß des Problems reduzieren. Der angegriffene Teilnehmer ist leider nach wie vor down, der Rest des Netzwerkes sollte aber wieder erreichbar sein.

Sollten noch Fehler im Betrieb eurer Datenbanken auffallen, bitten wir um eine kurze Info an den Support. Wir bitten die in diesem Zusammenhang entstandenen Unannehmlichkeiten zu entschuldigen.

Wir sind dabei die Ursache zu analysieren und werden zur nachhaltigen Lösung des Problems gegebenenfalls zeitnah eine Wartung durchführen müssen, bei der ein weiterer, kurzer Wackler im Netzwerk erwartet wird.

An der Ursachenforschung arbeiten wir noch. Falls es auch jetzt noch anhaltende Probleme geben sollte, bitte kurz beim Support melden.

Der Ausfall wurde zunächst vom Rechenzentrumsbetreiber behoben, jedoch mussten wir dieses Mal danach manuell eingreifen, da einer unserer Stromkreise durch den Einschaltstrom der Server überlastet war und die Sicherung sich nicht einschalten ließ. Daher dauerte der Ausfall bis 13:37 Uhr.

Ausfälle von IN-Berlin-Diensten gab es nicht, da unsere Systeme mit redundanten Netzteilen ausgestattet sind.

Bei Problemen in diesem Zusammenhang bitte kurz beim Support melden.

Im Nachgang werden wir mit dem Rechenzentrumsbetreiber sprechen, ob diese Stromversorgung durch eine Versorgung von einem anderen Stromfeed ersetzt werden kann. Dadurch wird es in einem geplanten Wartungsfenster erneut zu einem Ausfall kommen, dann aber danach hoffentlich nicht mehr ungeplant. Wir werden uns dazu bei den betroffenen Teilnehmern melden, sobald wir mehr wissen.

Der Ausfall wurde um 12:36 Uhr vom Rechenzentrumsbetreiber behoben.

Ausfälle von IN-Berlin-Diensten gab es nicht, da unsere Systeme mit redundanten Netzteilen ausgestattet sind.

Bei Problemen in diesem Zusammenhang bitte kurz beim Support melden.

Der Stromausfall dauerte von 14:55 Uhr bis 14:59 Uhr. Das Routing hat sich von selbst wieder erholt, jedoch benötigt das im Internet genutzte Routingprotokoll BGP4 zur Neuberechnung der möglichen Pfade zu anderen Providern ein wenig Zeit. Da aber auch bei anderen Providern und Peeringpunkten in Berlin die Hardware kurzzeitig stromlos war, waren auch entsprechend viele Pfade neu zu berechnen.

Es war lediglich Routing im Netzwerk betroffen. Unsere Infrastruktur am Standort Alboinkontor war permanent mit Strom versorgt.

Für alle Domains die in unserem Zuständigkeitsbereich liegen und für die unsere E-Mail-Server zuständig sind haben wir nun diese SPF-Einträge automatisch gesetzt, damit E-Mails an Gmail wieder zugestellt werden können. Wenn jemand einen anderen Eintrag wünscht oder weitere Einträge hinzufügen möchte, kann der IN-Berlin Support weiterhelfen. Alle die ihre DNS-Server selbst betreiben können beispielsweise den folgenden Eintrag im DNS ergänzen:

@ IN TXT "v=spf1 include:\_spf.in-berlin.de ~all"

Hierbei sind wir noch relativ locker und erlauben derzeit all unsere IP-Netzbereich inklusive der VPNs und Server. Kommt eine E-Mail nicht aus unseren IP-Netzbereichen, könnte es sich um Spam handeln ("~all"), sollte aber dennoch an den Empfänger zugestellt werden. Möchte man strenger sein und allen Empfängern der eigenen E-Mails mitteilen, dass die eigenen E-Mails ausschließlich über IN-Berlin verschickt werden, kann das “~all” auch durch ein “-all” ersetzt werden.

Insbesondere liegen keine Daten von IN-Berlin-Teilnehmern auf Systemen dieses Rechenzentrumsbetreibers. Unsere Systeme sind komplett getrennt.

Wir warten aktuell auf eine Stellungnahme des Anbieters. Sobald uns neue Informationen bekannt werden informieren wir euch.

Update 16.11.2021 23:00 Uhr: Der Rechenzentrumsbetreiber hat den Zugriff Dritter auf seine internen Infrastruktursysteme bestätigt und nach eigenen Angaben ist eine Meldung an die Berliner Datenschutzbeauftragte erfolgt. Das genaue Ausmaß wird mit Hilfe von Logdateien derzeit noch ermittelt. Erste Gegenmaßnahmen wurden getroffen, weitere Maßnahmen sind in Arbeit.

Ein für uns relevantes Detail ist, dass die Technik für den Zutritt zum Rechenzentrum mit Hilfe des Datenbankzugriffes nicht manipuliert werden konnte, da das Produktivsystem nicht aus dieser Datenbank versorgt wird. Damit ist aller Wahrscheinlichkeit nach kein unberechtigter Zutritt erfolgt. Es sind durch den Vorfall aufgrund des bestehenden Geschäftsverhältnisses zwischen dem Rechenzentrumsbetreiber und dem IN-Berlin höchstens Vertragsdaten des IN-Berlin e.V. selbst bekannt geworden.

IN-Berlin nutzt komplett eigene Server. Diese sind in keiner Weise mit dem Netzwerk des Rechenzentrumsbetreibers verbunden. Der Rechenzentrumsbetreiber kann und konnte auch nie mehr/anders/direkter auf unsere Server zugreifen als jeder andere Internet-Nutzer. Darüberhinaus befinden sich die Vertragsdaten unserer Teilnehmer schon immer auf einem besonders gesicherten Server außerhalb dieses Rechenzentrums.

Daten von Teilnehmern des IN-Berlin waren zu keiner Zeit gefährdet.

IN-Berlin ist derzeit gemeinsam mit anderen in diesem Rechenzentrum befindlichen Communities - wie z. B. dem CCC - auf der Suche nach alternativen und ähnlich Community-kompatiblen Rechenzentrumsbetreibern wie diesem, auch um zukünftig die Dienste redundanter aufstellen zu können. Hierbei wählen wir einen oder mehrere Standorte nach verschiedenen Kriterien aus. Bitte habt Verständnis dafür, dass dies Zeit und Vorbereitung braucht. Wir konnten uns in den letzten 13 Jahren eine gute und kooperative Zusammenarbeit unter guten Vertragskonditionen mit Speedbone erarbeiten. Gute Kommunikation zwischen den Beteiligten fördert ebenfalls die Sicherheit, auch deswegen wäre uns eine Behebung der Speedbone-Schwächen lieber als ein überstürzter Umzug.

Sobald es weitere Neuigkeiten gibt, werden wir euch informieren.

An dieser Stelle vielen Dank an alle Mitglieder, die dem Verein in den letzten Jahren immer wieder mit Rat und Tat zur Seite gestanden haben und Glückwunsch an den neu gewählten Vorstand.

Wir sind aktuell an der genauen Analyse der Änderungen und werden euch auf dem laufenden halten.

Damit Ihr die IN-Berlin Infrastruktur auch für Videokonferenzen nutzen könnt, haben wir für euch einen Wiki-Artikel erstellt, in dem erklärt wird, wie das funktioniert und was dabei zu beachten ist.

Helft mit die Ausbreitung des Corona-Virus zu verlangsamen, bleibt zu Hause, nutzt alternative Wege Freunde, Bekannte und Gruppen zu treffen und bleibt gesund!

Anhand der Liste der betroffenen Zertifikate die Let’s Encrypt veröffentlicht hat haben wir unsere Zertifikate geprüft und keine betroffenen Zertifikate gefunden. Die Erreichbarkeit der TLS-gesicherten Dienste ist also für alle Teilnehmer weiter gewährleistet.

Aus dem inzwischen seit fast 30 Jahren (September 1990) bestehenden Zusammenschluss von Privatpersonen, welche die Basis für den Verein gelegt haben, ist heute vor 25 Jahren ein Verein geworden. Dies hat z. B. den Abschluss von Verträgen mit Firmen und Banken deutlich vereinfacht, sowie beispielsweise auch Haftungsfragen formell geklärt.

Wir bedanken uns bei allen Mitgliedern, Teilnehmern, Sponsoren und Partnern, die uns über all die Jahre die Treue gehalten haben, den Verein aufrecht erhalten und den Betrieb dieser nicht-kommerziellen Plattform ermöglichen!

Ursache waren neuere, sicherere Default-Einstellungen der libssl, welche Auswirkungen auf das Verhalten des Sendmail hatten. Im Rahmen des Updates haben wir zwar Tests durchgeführt, allerdings ist uns dieses Verhalten nicht aufgefallen. Es betraf auch nur einen kleinen Teil der E-Mails. Es sind keine E-Mails verloren gegangen, es kam lediglich zu Verzögerungen bei der Auslieferung. Wir bitten die Unannehmlichkeiten zu entschuldigen.

Um Datenverlust zu vermeiden, werden wir dafür leider Web-, Shell- und E-Mailserver herunterfahren müssen. Wir gehen davon aus, dass das am Sonntag morgen die wenigsten Leute stört und haben uns daher für diesen Zeitraum entschieden.

Die Webseiten der Teilnehmer sind im genannten Zeitraum nicht erreichbar. Ebenso ist kein SSH-Zugriff auf den Shellserver möglich. E-Mails werden in dem Zeitraum von unseren Servern weiterhin angenommen, werden aber erst nach Abschluss der Wartung zum E-Mailserver der sie per POP3 und IMAP4 bereitstellt ausgeliefert. Es gehen keine E-Mails verloren.

Wir bitten um euer Verständnis.

Update 21:00 Uhr: Der MySQL-Server steht wieder zur Verfügung.

Seit inzwischen 20 Jahren halten wir 30, zwischenzeitlich auch bis zu 60, Einwahlkanäle bereit, davor waren es nur einige wenige, die über mehrere Standorte verteilt waren. Anfangs stand die Einwahl primär für den Austausch von E-Mails und News per UUCP zur Verfügung, später auch für die Einwahl ins Internet.

Die letzte Einwahl eines Teilnehmers fand Ende 2016 statt, so dass wir diesen Dienst jetzt ruhigen Gewissens abschalten können. Der primäre Hintergrund ist, dass für die Bereitstellung des Anschlusses jetzt wieder höhere Kosten anfallen würden und wir diese nicht tragen wollen, wenn der Dienst eigentlich obsolet ist. Inzwischen haben wohl alle den Sprung auf DSL oder Internet via Kabel geschafft oder nutzen den Internetzugang mobil vom Smartphone aus. Nach unseren Informationen wird es ISDN-Anschlüsse in der breiten Fläche auch Ende 2018 beziehungsweise bei einigen Providern erst im Jahre 2022 nicht mehr geben. Neuanschlüsse werden oftmals schon heute als Voice-over-IP realisiert.

“Sag zum Abschied leise ATH” (den Modemkennern unter euch wird das sicherlich noch bekannt vorkommen ;-)

Frohe Ostern vom IN-Berlin!

Ein Klick auf den Link in der E-Mail zeigte auf einer fremden Domain exakt unser Webmail-Interface. Dort sollte man nun seine Zugangsdaten eingeben.

Wir hoffen, dass auf diese E-Mail niemand von euch hereingefallen ist. Falls doch, solltet ihr jetzt im Service-Interface euer E-Mail-Passwort ändern. Der Link befindet sich auf unserer Startseite.

Bitte versteht dies als allgemeine Warnung und klickt nicht auf Links in E-Mails, vor allem nicht, wenn diese euch zur Eingabe eurer Zugangsdaten auffordern. Die Links zu den regelmäßig besuchten Seiten sollte man entweder kennen oder seine Bookmarks verwenden.

Allgemein enthält jede E-Mail von uns die eine Aktion erfordert unsere E-Mail-Signaturzeilen, die Informationen zu unserem Verein, wichtige E-Mail-Adressen, unsere Rufnummern, Links zur Webseite, unsere Vereinsregisternummer und Umsatzsteuer-ID enthalten.

Wenn ihr unsicher seid, schaut auf unserer Startseite nach. Wir veröffentlichen i. d. R. sämtliche Informationen auch dort. Im Zweifelsfall fragt bitte bei unserem Support nach.

Die Server laufen weiter, sind aber nicht mehr erreichbar. Wir bitten den unerwarteten Ausfall zu entschuldigen.

Update: Seit 00:22 Uhr ist die Leitung wieder da.

Wir werden uns zunächst vor Ort einen Überblick verschaffen.

Update 14:55 Uhr: Der Betreiber der Colocationsfläche hat Probleme mit den USVs bestätigt. Da sich das Netz nicht mit dem Strom vom Diesel synchronisiert hat und es daher Phasenverschiebungen gab, kam es zu einer Spannungsschwankung, in Folge dessen etliche Sicherungen in den Unterverteilungen gekommen sind. Das fehlerhafte Bauteil wurde identifiziert und wird so schnell wie möglich vom Betreiber ausgetauscht.

Update 15:51 Uhr: Uns fehlt an einigen Servern noch der redundante Strom. Diese sind aber über das redundante Netzteil online.

Update 16.05.2017 09:55 Uhr: In der kommenden Nacht erfolgt der Austausch des defekten Schalters. Wir fahren daher unsere Server und auch die der Teilnehmer zum größten Teil herunter. Der Austausch wird ab 4 Uhr nachts erfolgen. Die Abschaltung erfolgt etwa 15 Minuten vorher. Sobald diese erfolgt ist, werden wir die Server wieder hochfahren. Wir bitten um Verständnis.

Update 17.05.2017 05:30 Uhr: Die Wartung wurde erfolgreich beendet. Alle Server laufen wieder.

Bitte stellt euren Benutzernamen auf sitename#in@profi-adsl.de oder sitename%in#turbo@dsl.net um. Das Passwort ändert sich dabei nicht. Die euch zugewiesenen IP-Adressen bleiben dabei auch erhalten.

Als Workaround haben wir bereits einen Dienst implementiert, der entweder zu lang laufende Skripts von Teilnehmern beendet oder im absoluten Problemfall den kompletten Apache Webserver neu startet. Beides ist sicherlich kein Dauerzustand, aber als Workaround durchaus erstmal brauchbar, um den Service weiter bereitstellen zu können. Parallel dazu sind wir natürlich weiter auf der Suche nach der Ursache.

Server von Teilnehmern die nur mit einem Netzteil ausgestattet sind werden vor der Wartung an dem entsprechenden Stromkreis heruntergefahren. Wir versuchen die betroffenen Server über die Tastatur beziehungsweise einen kurzen Druck auf den Stromschalter sauber herunterzufahren. Sofern beides deaktiviert sein sollte, werden wir den Server hart ausschalten müssen.

Da von der Wartung auch Netzwerkswitches betroffen sind, werden auch Server die nicht heruntergefahren werden müssen kurzzeitig ihre Netzwerkverbindung verlieren, sofern diese nicht redundant an das Netzwerk angebunden sind.

Wir versuchen wie immer die Ausfallzeiten zu minimieren und bitten die durch die Wartung entstandenen Unannehmlichkeiten zu entschuldigen.

Webseiten, die nur eine eigene Domain (also keine in-berlin.de-Domain) haben, werden sehr bald umgestellt. Webseiten, die auch einen in-berlin.de-Alias haben, werden nur langsam umgestellt. Leider gibt es bei Let’s Encrypt ein Limit von 20 Domains pro Woche, das auch nicht umgehbar ist. Diese 20 Domains werden wir nach und nach umstellen. Wer vorgezogen werden will, kann eine Mail an den Support schreiben.

Domains, die bereits SSL haben, werden nach Ablauf des Zertifikats automatisch auf ein Let’s Encrypt-Zertifikat umgestellt. Das heißt auch, dass ihr als User euch um keine Erneuerungen der Zertifikate mehr kümmern müsst, dies passiert nun automatisch.

Wir haben den Server repariert, mit einer neuen Festplatte ausgestattet und sämtliche darauf laufende Server rebootet.

Über den Standort Vereinsraum gibt es leider etwas unerfreuliches zu berichten.

In der Nacht auf Samstag sind um 02:18 Uhr unsere Richtfunkstrecke zum Gesundheitszentrum und die Rundstrahlantenne, über die sich unsere Nutzer im Kiez einbuchen, ausgefallen. Vermutlich vom Nachbarhaus kommend, haben Unbekannte die Netzwerkkabel und ein Antennenkabel von der Technik am Mast herausgerupft. Im Mai diesen Jahres ist das schon mal passiert: damals wurden die Kabel durchtrennt.

Der Individual Network Berlin e.V. hat Anzeige erstattet.

Über Hinweise, was sich am 12.09.2015 zwischen 2 und halb 3 auf unserem Dach in der Lehrter Str. 53 zugetragen hat, würden wir uns freuen.

Update 25.08.2015 21:17: Das Problem ist behoben. Entschuldigung für die lange Wartezeit.

Update 23:20 Uhr: Die umzuziehende Maschine ist vorbereitet, der Jabber Server wird jetzt heruntergefahren und auf die neue umgestellt.

Update 24.07.2015 00:47 Uhr: Der neue Jabber Server läuft, Kontakte auf jabber.ccc.de funktionieren wieder.

vor kurzem haben wir ein neues Storagesystem in Betrieb genommen, auf dem die Webseiten, Datenbanken und Shellverzeichnisse liegen. Da das neue deutlich mehr Speicherplatz hat, können wir die Inklusivvolumina für Web- und Shellspeicherplatz in den Tarifen IN-Berlin S, M und L erhöhen.

Ab dem 01.03.2015 gibt es daher für Web und Shell den gleichen Speicherplatz wie für E-Mails:

Der Preis für zusätzlichen Speicherplatz wird für E-Mail ebenso verringert, d. h. auch hier senken wir die Kosten.

Wer bisher mehr Speicherplatz für Web und Shell dazu gebucht hat (zu 0,50 € pro 512 MB), wird ab dem 01.03.2015 auf die neuen Preise umgestellt. Die Menge des Speicherplatzes wird bei der Umstellung beibehalten, lediglich der Preis wird reduziert. Falls der zusaätzlich gebuchte Speicherplatz nicht mehr benötigt wird, kann er per E-Mail an support@in-berlin.de abbestellt werden. Weitere Erläuterungen zum Speicherplatz finden sich auch in unserem Wiki.

Update 14:12 Uhr: Das Problem lag an einer der beiden USVs. Dort hing der Switch mit dem Uplink des Standorts. Wir haben das Kabel nun erstmal umgesteckt und beobachten die defekte USV. Die Server waren von dem Ausfall nicht betroffen, lediglich die Netzwerkanbindung.

Update 2014-10-18 19:09 Uhr: Es gibt wohl Probleme mit dem Mailclient Evolution. Aus dem Grund erlauben wir auf dem Mailserver derzeit wieder SSLv3. Sonst sind bisher keine Probleme an uns herangetragen worden, die mit der Abschaltung von SSLv3 zusammenhängen.

gerade erst heute kursieren wieder falsche E-Mails zum Thema Domainverlängerungen. Da es bereits mehrere Anfragen dazu in unserer Supportmailbox gab, möchte ich kurz dazu informieren.

Die E-Mails haben beispielsweise den Betreff Final Notice of Domain Listing und verlangen dann im Text eine Erklärung, dass man der Eigentümer der Domain ist und für die Verlängerung über ein oder mehrere Jahre einen hohen Dollarbetrag zahlen soll. Diese E-Mails werden auch verschickt, wenn die Domain nicht bald ausläuft. Da man eine Erklärung unterschreibt, kann die Domain dann möglicherweise auch ohne unsere Zustimmung vom IN-Berlin weggezogen werden und dann ist man viel Geld los.

Bitte ignoriert sämtliche E-Mails oder auch Briefe (per Post) zu Zahlungen im Zusammenhang mit Domains die beim IN-Berlin gehostet sind, wenn sie nicht von einer E-Mail-Adresse @in-berlin.de kommen. Wir werden nicht dazu auffordern ein Fax zurückzuschicken oder einen Betrag in US$ zu zahlen. Es handelt sich hier um Abzocke, die gegebenenfalls auch zum Verlust einer Domain führen kann. Die einzigen E-Mails die seit Ende 2013 ohne unseren Einfluss auf den Mailinhalt von unseren Domainregistraren automatisch an IN-Berlin Teilnehmer verschickt werden, haben wir auf unserer Webseite dokumentiert. Diese E-Mails informieren aber lediglich darüber, dass die Domain bald ausläuft und automatisch verlängert wird, wenn man nichts unternimmt. Hierbei wird niemals zu Zahlungen von Geld oder zur Rücksendung unterschriebener Erklärungen aufgefordert.

Bitte klärt im Zweifelsfall Fragen zu solchen E-Mails über uns ab und schickt auf keinen Fall irgendwelche unterschriebenen Erklärungen an jemanden zurück.

Update 00:46 Uhr: Nach etwa 20 Minuten Downtime der Leitung sind alle Server am Standort AM II wieder erreichbar.

Update 01:00 Uhr: Anscheinend sind auch die ADSL-Verbindung mit den Realms profi-adsl.de und city-adsl.de von dem Ausfall betroffen. Die Authentifizierung scheint nicht zu funktionieren. Wir haben unseren Technikpartner darüber informiert. Mit dem Usernamen sitename%in#turbo@dsl.net funktioniert der Zugriff mit dem selben Passwort und der selben IP-Konfiguration. Die Zuführung von dsl.net geschieht über einen anderen Technikpartner.

Update 01:30 Uhr: Die ADSL-Verbindungen über die beiden genannten Realms funktioniert wieder. Das Problem waren Paketverluste zwischen unserem Netz und dem unseres Technikpartners.

Update: Geht wieder, nachdem Debian ein weiteres Paket gefixt hat.

Update 22:51 Uhr: Fertig. Eventuell müsst ihr eure Artikelzähler zurücksetzen.

Thema ist “Werkzeuge für die Mitarbeit in Vereinen.”

Die Zeit rennt uns allen davon. Wir sind öfter mal etliche Kilometer von zu Hause entfernt. Familienleben soll auch erhalten bleiben. Und dazu die Arbeit im Verein? Wie soll das noch funktionieren?

Ich will am Beispiel der Piratenarbeit zeigen, welche Tools uns wie unterstützen können. Wie man auch aus der Ferne mitarbeiten und Konzepte schreiben kann, auch gemeinsam. Die digitale Arbeit mal nicht als Hemmnis, sondern als Unterstützung. Mit Mac und Windows und Linux, mit iPhone und Android-Smartphones.

Grundlegende Konzepte der Gruppenarbeit.

• Blatt und Stift: das Pad
• Beamer: der eigene Computer
• Telefonkonferenz: Mumble
• Dokumentation: Wiki
• Bekanntmachungen: blog
• Mitgliederversammlung und Präsentation: openslides
• Aufzeichnungen: Audio und Video
• Basics für Versammlungen: Protokollvorlagen

Unsere Produktivserver stehen in einem anderen Rechenzentrum. Betroffen waren lediglich das Backup und ein paar Server von Serverhousingteilnehmern. Andere Dienste des IN-Berlin waren hiervon nicht beeinträchtigt.

Update 20:30 Uhr: Alle Systeme die an der USV hingen sind jetzt direkt ohne USV am Stromnetz angeschlossen. Das ermöglicht uns jetzt ausführliche Tests mit der USV durchzuführen.

Die Registrierung ist jetzt nicht mehr freigegeben für Besucher. Wer etwas ändern will, kann das gerne tun, muss aber vorher beim Support nach einem Account fragen (dieser wird dann schnell eingerichtet).

Update 17:30 Uhr: Seit etwa 17:00 Uhr ist die Glasfaser wieder funktionsfähig und alle Dienste inklusive der xDSL-Zuführung funktionieren wieder.

Falls jemand wider Erwarten Probleme feststellen sollte, bitte möglichst detailliert an den Support melden und wir schauen uns das an. Falls ihr Fehlermeldungen von euren übertragenen cron jobs bekommt, schaut euch diese bitte vorher erst nochmal an.

Zum Überprüfen - Die Fingerprint unserer Zertifikate:

• jabber.in-berlin.de ist 13:F1:3D:33:1C:7F:A0:DA:AE:10:C5:AC:F1:E6:0C:F8:3F:F9:71:93
• imap.in-berlin.de ist C2:B6:76:02:1F:AF:AB:0E:BC:CE:DD:3D:4F:40:ED:E1:40:FF:90:9C
• pop3.in-berlin.de ist D9:F1:1E:1A:4B:35:E5:C9:A9:1F:8E:B1:6D:34:BC:BD:72:CF:92:3E
• mail.in-berlin.de ist 7B:2E:58:A3:4D:24:42:CA:BC:AE:FF:0B:A2:FC:5B:A7:D5:1C:8A:4C

Alle Zertifikate besitzen eine gültige Unterschrift von StartCom.

Inzwischen ist das Problem behoben und alle Dienste stehen wieder zur Verfügung. Der Virtualisierer der das Problem bereitet hat bleibt zunächst ausgeschaltet, aber das hat keinen Einfluss auf die Funktion der Dienste, da dieser nur in Redundanzfällen benötigt wird.

Update 4:00 Uhr: Es gibt noch Probleme mit dem mySQL-Server. 10 Minuten vor dem Crash wurde jedoch das Backup der meisten Datenbanken fertig, so dass es in den meisten Fällen kein Problem war, dieses wiederherzustellen, um wieder einen konsistenten Zustand zu bekommen. Der Restore läuft zum aktuellen Zeitpunkt noch!

Update 5:46 Uhr: Alle Datenbanken funktionieren wieder.

Sollte noch jemand Probleme im Zusammenhang mit dem gestrigen Absturz feststellen, bitten wir um eine Support-E-Mail mit einer konkreten Problembeschreibung.

Informationen und Updates geben wir übrigens immer auf https://in-berlin.de/ - das ist sinnvoll dort zu schauen, wenn man keine E-Mails mehr lesen oder schreiben kann. Eventuell ist dort schon ein wichtiger Hinweis zu finden, der einen weiterbringt.

Nochmal kurz was im Hintergrund passiert ist:

• Migration aller E-Mails, Flags (z. B. gelesen/ungelesen) und Sieve-Filter-Skripts auf einen neuen Server
• Konvertierung der Daten vom alten Cyrus-Mail-Format in das neue Dovecot-Mail-Format, da wir bei der Gelegenheit auch gleich den E-Mail-Dienst modernisiert haben.

Das klingt jetzt erstmal nicht so viel, aber unter der Haube hat sich sehr viel getan und wir sind froh, diesen Schritt nach viel Vorarbeit nun endlich gegangen zu sein. Wir sind noch nicht ganz fertig, aber der Zugriff auf die E-Mails funktioniert seit gestern nachmittag wieder.

Es gab leider bei der Migration ein paar Probleme:

Nachdem alle E-Mails kopiert und migriert waren, haben wir die Einlieferung neuer E-Mails von außen wieder zugelassen. Dabei kam es zu einem Maskierungsproblem mit einigen Adressen, das aber kurze Zeit später bereits behoben wurde.

Das Problem hat dafür gesorgt, dass teilweise bei Mails von außen username@einhorn.in-berlin.de als Empfänger in den E-Mails stand, die E-Mails aber trotzdem an den richtigen Empfänger gegangen sind. Das ist erstmal nicht schlimm, allerdings kann ein eventueller Mailfilter möglicherweise die Mail nicht richtig einsortieren und lässt sie im Posteingang. Wenn man aus dem Mailclient heraus einen sog. “Group Reply” macht (“Allen antworten”), taucht diese Adresse dann aber auf und führt natürlich ins Leere. Weiterhin sind ein paar wenige E-Mails zu der Zeit ebenfalls mit diesem falsch maskierten Absender herausgegangen.

Der IMAP-Namensraum (Namespace) hat sich geändert. Die Mailordner liegen jetzt nicht mehr unter “INBOX”, sondern unter “/” (“neben” INBOX). Für die meisten Clients ist das kein Problem, da der Namensraum vom IMAP-Server übergeben wird. Vorhandene Sieve-Skripts haben wir entsprechend angepasst. Beim Erstellen neuer Ordner auf dem IMAP-Server muss jetzt also nur noch “ordnername” und nicht mehr “INBOX.ordnername” angegeben werden.

Für Mutt ist folgende Änderung erforderlich:

• alt: set folder=imaps://imapusername@imap4.in-berlin.de/INBOX
• neu: set folder=imaps://imapusername@imap4.in-berlin.de/

Weiterhin hat sich der IMAP-Separator von “.” auf “/” geändert. Dies wird aber vom IMAP-Server ebenfalls an den Client übergeben. Vorhandene Sieve-Skripts haben wir auch hier entsprechend angepasst.

Für iOS-User: Falls das Mailabrufen mit dem iPhone oder iPad nicht mehr klappt, muss gegebenenfalls der Servername umgestellt werden, damit das Gerät es mit neuem Einstellungen probiert. Daher jetzt bitte benutzen:

pop3.in-berlin.de statt pop3.vr.in-berlin.de, beziehungsweise imap.in-berlin.de statt imap.vr.in-berlin.de

Falls der Abruf einzelner Mailboxen trotzdem nicht funktioniert, schaut bitte mal in die Sicherheitseinstellungen, ob da so komische Dinge wie APOP oder NTLM auftauchen. Falls ja, stellt dies bitte auf andere Methoden um und versucht es nochmal.

Aufgrund einer nicht abgefangenen Besonderheit ist die Migration bei 11 Postfächern leider abgebrochen. Die alten E-Mails aus diesen Postfächern haben wir aber bis heute früh wieder synchronisiert, so dass diese jetzt wieder zur Verfügung stehen.

Einige von euch nutzen servergespeicherte Filterregeln (Sieve), um E-Mails auszusortieren oder automatisch in andere Ordner zu verschieben. Dafür stand bisher “Websieve” zur Verfügung. Diese Software wird allerdings seit 2004 nicht mehr gepflegt und funktioniert nicht zusammen mit dem neuen Dovecot-Mailserver. Wir haben sie daher deaktiviert.

Die vorhandenen Sieve-Skripts funktionieren bis auf wenige Ausnahmen (nicht standardkonforme Filterregeln) weiter, jedoch können diese derzeit nicht per Web-Interface geändert werden. Hier sind wir gerade noch dabei zu überlegen, welche Zugriffsmethode zukünftig die Beste ist. ManageSieve direkt vom E-Mail-Client oder vom Shellserver kudu aus beziehungsweise die Konfiguration von Filterregeln über das neue Webmail-Interface das hoffentlich bis Januar fertig sein wird. Das neue Webmail-Interface wird auch die Smartphone-Synchronisation mitbringen und von Smartphones aus auch viel besser benutzbar sein, als das aktuelle Webmail-Interface.

Der Standard-Speicherplatz der E-Mail-Postfächer wurde von den alten 50 MB auf 256 MB erhöht. Hier werden wir uns demnächst aber nochmal zusammensetzen und entscheiden, wie wir das genau in Zukunft behandeln wollen und wie viel Speicherplatz jedes Postfach oder jeder Teilnehmer bekommen wird und euch erneut informieren.

Verwendet bitte möglichst Verschlüsselung beim Abrufen und Senden eurer Nachrichten. Wir planen, wie einige andere Provider auch, den E-Mail-Abruf und das Versenden von E-Mails ohne Verschlüsselung ab März 2014 komplett abzuschalten. Prüft daher bitte eure Sicherheitseinstellungen im Mailprogramm. Teilnehmer die nächstes Jahr noch unverschlüsselte Protokolle nutzen, werden wir aber nochmal anschreiben.

Unser neuer Mailserver beherrscht zeitgemäße Protokolle und starke Ciphers. Wir empfehlen TLSv1.2 mit TLS_DHE_RSA_WITH_AES_256_GCM_SHA384. oder DHE_RSA_WITH_CAMELLIA_256_CBC_SHA. Ciphers wie RSA_WITH_RC4_128_MD5, RSA_WITH_RC4_128_SHA oder TLS_RSA_WITH_SEED_CBC_SHA würden wir am liebsten nicht mehr anbieten. Die DHE_RSA_..-Familie ist der RSA_...-Familie vorzuziehen. Gebt TLSv1.2 oder TLSv1.1, notfalls TLSv1.0 den Vorzug vor SSLv3.

Falls noch jemand Probleme feststellt, lasst es uns bitte wissen!

Update 9:10 Uhr: Die Mailserver-Dienste sind angehalten. Die Synchronisation und Migration der Daten läuft und wird voraussichtlich etwa 4 Stunden dauern.

Update 13:13 Uhr: Das Skript für die Migration ist durchgelaufen. Wir prüfen nun das Ergebnis und stellen die IP-Adressen des neuen Servers auf die des alten Servers um.

Update 15:13 Uhr: Wir haben nun hoffentlich alle Probleme behoben. Der Zugriff auf den Mailserver ist nun wieder möglich.

Weitere Informationen haben wir in einen separaten Newsletter gepackt und aus diesem Newsartikel wieder entfernt.

Wenn der neue Mailserver in Betrieb ist, werden wir langfristig auch andere Änderungen anbieten können - grössere Mailboxen, zubuchbarer Mailspeicherplatz, neueres und viel moderneres Webmail-Interface mit Smartphone-Synchronisierung, und vieles mehr. Weitere Informationen dazu schicken wir in einem separaten Newsletter.

Update 18:45 Uhr: Der Umbau ist beendet, alle Dienste stehen wieder zur Verfügung.

Update 18:06 Uhr: Fertig, geht wieder. Gegebenenfalls sind die Artikelnummern anders, und ihr müsst die Gruppen neu laden lassen.

Update 20.08.2013 12:45 Uhr: DB wieder beschädigt. Wechsel zu buffindexed. Wird wieder viele Stunden dauern.

Update 21.08.2013 4:30 Uhr: buffindexed macht Fehler. Noch ein Rebuild, wieder mit ovdb.

Update 21.08.2013 18:20 Uhr: Geht wieder. Ich befürchte aber, das Problem kommt wieder.

Diese Programme sind überhaupt erst möglich durch die starke Zentralisierung und Abhängigkeit des Internets von wenigen Firmen. Würde man nicht Daten bei Facebook, Google und Co ablegen, dann wären sie nicht unter Kontrolle des US-Geheimdienstes.

Aber auch wenn diese Unternehmen europäisch wären, würde es wahrscheinlich früher oder später ein entsprechendes Abhörprogramm geben. Und dass es wieder Vorratsdatenspeicherung in Deutschland gibt, ist nur noch eine Zeitfrage - auf europäischer Ebene ist das schon längst Standard.

Beim IN-Berlin geht es uns auch darum, dass diese Möglichkeiten gar nicht erst entstehen. Wir halten ein autonomes, selbstgestaltetes Internet für notwendig. Die Infrastruktur muss nicht in den Händen der großen sein. Sie muss auch nicht in den USA oder in Frankfurt sein, sondern sie kann auch bei uns, in der Mitte von Berlin sein. Selbstgemacht, selbstverwaltet.

Auch wenn es in den letzten Jahren verloren gegangen ist, sollte man nicht vergessen: Das Internet ist kein Ort, an dem wir das fressen müssen, was Google und Facebook uns bereitstellen. Es ist ein Ort, den wir selber gestalten, der in unseren eigenen Händen ist. Und jeder kann daran mitwirken.

Deswegen gibt es den IN-Berlin. Wir geben uns nicht damit zufrieden, dass wir uns Mailaccounts bei Google, eine Webseite bei Myspace und Chats bei Skype zurechtklicken. Wir machen diese Dienste und noch viel mehr selber, und haben auch die Kontrolle darüber. PRISM ist uns egal, weil wir wissen, wer Zugriff auf unsere Server hat. Tempora auch, denn wer nicht Daten über den Atlantik sendet, der ist auch davor gefeit.

Sollten deutsche Behörden versuchen, auf Daten des IN-Berlin zuzugreifen - wir würden euch informieren, wie wir es einstmals schon bei der Vorratsdatenspeicherung taten.

Eure IN-Berlin-Aktiven

Update 00:55 Uhr: Alle Systeme außer die Webserver sind wieder online. Derzeit weigert sich der Webserver die Datenpartition zu mounten. Der Grund ist derzeit noch unklar. Bevor jetzt durch vorschnelle Aktionen Dinge schiefgehen, schauen lieber im Laufe des Tages noch ein paar mehr Leute drauf. Bis dahin muss der Webserver leider offline bleiben :-(

Update 09:00 Uhr: Der PHP 5.2 Webserver ist wieder online und konnte die Datenpartition jetzt wieder mounten. Das Problem war eine Caching-Option in der KVM-Virtualisierung. Der PHP 5.3 Webserver hat noch ein Problem und ist derzeit noch offline.

Update 09:55 Uhr: Der PHP 5.3 Webserver ist auch wieder online!

Update 21:30 Uhr: Es ist wieder das gleiche Problem wie gestern abend aufgetreten :-( Wird sind dran.

Update 22:15 Uhr: Alle Systeme sind wieder online. Wir haben inzwischen einen konkreteren Verdacht woran es liegen könnte und beobachten das nun.

Update 23:15 Uhr: Das mySQL-Upgrade war erfolgreich. Alle Datenbanken sind wieder online. Das Wiedereinspielen der Datenbanken hat leider doch ein wenig länger gedauert als vermutet.

Update 19.01.2013 12:41 Uhr: Es muss leider mit einem weiteren Reboot nochmal nachgebessert werden, da kudu jetzt sporadische Probleme meldet.

Update 24.01.2013 18:45 Uhr: Leider müssen wir den Shellserver kudu erneut rebooten, da sich herausgestellt hat, dass der neue Kernel des Basis-Systems den Geschwindigkeitsvorteil anderer, aktualisierter Pakete wieder zunichte macht. Wir bitten die Unannehmlichkeiten im Zusammenhang mit den Reboots zu entschuldigen.

Es gehen keine Mails verloren, man kann nur nicht auf sie zugreifen und die Auslieferung der Mails in diesem Zeitraum wird um wenige Minuten verzögert.

Update 03:43 Uhr: Eine Unterverteilung ist stromlos. Wir haben alles so weit umgesteckt und die Systeme wieder hochgefahren. Aus Gründen der besseren Redundanz muss der Strom in den nächsten Tagen nochmal zurückgesteckt werden.

Update 9:36 Uhr: geht wieder.

Bei Mailinglisten bei denen konfiguriert war, dass im To: oder Cc: der Name der Mailingliste explizit eingetragen sein muss wurden alle Nachrichten mit “Message has implicit destination” zurückgehalten, auch wenn das Kriterium erfüllt war. Die Nachrichten wurden für den Listowner zurückgehalten und mussten manuell freigegeben werden. Ich habe gerade den Patch erweitert und das Problem behoben.

Wir bitten um eine kurze Information, falls weitere Probleme im Zusammenhang mit Mailman auftreten sollten.

Update: Geht wieder.

1. weitere ADSL-Zuführung - schneller für Nicht-Berliner Bisher gab es die Möglichkeit, sich über sitename#in@city-adsl.de und sitename#in@profi-adsl.de einzuwählen. city-adsl.de ist besonders für Teilnehmer in und rund um Berlin interessant, da wir die Daten direkt in Berlin übergeben bekommen und somit die Latenzen vergleichsweise gering sind. profi-adsl.de läuft erst zentral nach Frankfurt am Main und wird dann von dort zu uns nach Berlin transportiert. Für Teilnehmer die nicht in der Umgebung von Berlin wohnen gab es daher i. d. R. keine Unterschiede zwischen den beiden Zugängen, für die Berliner aufgrund der Latenz sehr wohl.

Beide Benutzernamen konnten bisher als Redundanz zueinander verwendet werden, daher wenn der eine ausfällt, konnte man einfach den anderen benutzen. profi-adsl.de steht derzeit nur noch einigen wenigen Teilnehmern zur Verfügung, die city-adsl.de aufgrund von Limitierungen ihres DSL-Anschlusses nicht nutzen können. Für alle anderen Teilnehmern haben wir profi-adsl.de wie angekündigt gesperrt.

Als neue Redundanz steht jetzt sitename%in#turbo@dsl.net zur Verfügung. Das Passwort ist identisch mit den anderen Zugängen. dsl.net, welches auch wie profi-adsl.de in Frankfurt am Main übergeben wird, kann im Falle eines Ausfalls jederzeit als Redundanz zu city-adsl.de genutzt werden. Wir werden voraussichtlich im November in Frankfurt am Main einen lokalen Router aufstellen, der dsl.net direkt terminiert und von dort aus eine Internetanbindung bereitstellt. Gerade Teilnehmer die nicht im Berliner Umland wohnen werden davon profitieren und bessere Latenzen haben. Wir raten daher diesen Teilnehmern den Usernamen auf sitename%in#turbo@dsl.net umzustellen, um von den kommenden Vorteilen zu profitieren. Natürlich ist auch die Nutzung von city-adsl.de weiterhin möglich, aber warum sollte man auf die Vorteile verzichten? ;-)

2. optimiertes Accounting Wir mussten feststellen, dass einige Teilnehmer seit Ende September anscheinend keine Zwangstrennung mehr von der Deutschen Telekom haben. Dies hat Teilnehmer die regelmässig in unser ADSL-Accounting, mit dem wir die übertragenen GBytes zählen, schauen etwas verwirrt, da es so aussieht, als wären dort keine neuen Verbindungen aufgezeichnet. Eine fehlende Zwangstrennung bedeutet auch, dass wir am Monatsende den entstandenen Traffic nicht einem Monat zuordnen können, da das immer pro laufender Verbindung gemessen wird.

Aus diesem Grund haben wir im Oktober bisher nicht den Traffic vom September berechnet, da wir zunächst eine neue Berechnung der Trafficdaten bauen mussten. Die Trafficdaten liegen uns für die letzte Abrechnungsperiode in 5-Minuten-Abständen vor, so dass es im Nachhinein kein Problem war, die genauen Trafficdaten neu zu berechnen. Wir werden den Traffic aus dem September im Novemberkontoauszug ausweisen und bei Überschreitung des Inklusivvolumens nachberechnen.

Update 14:35 Uhr: Das akute Problem sollte nach Erstmaßnahmen behoben sein. Die E-Mails werden nach und nach wieder reinkommen.

Update 14:10 Uhr: city-adsl.de funktioniert wieder

Für 10 € (Strom und Traffic inklusive) im Monat kann man die kleinen Rechner bei uns im Vereinsraum unterstellen. Mehr Details sind in unseren Serverhousingtarifen zu finden.

Update 20:55 Uhr: Laut Info vom RIPE ist das Problem behoben und innerhalb der nächsten Stunden sollte sich alles normalisieren.

Update 22:25 Uhr: Unsere Netze haben inzwischen wieder funktionierendes reverse DNS.

Wir wurden darüber in Kenntnis gesetzt, dass am kommenden Dienstag den 2012-05-08 zwischen 5 und 7 Uhr morgens ein Techniker der Vattenfall den Stromzähler in der Colocationsfläche austauschen muss, da die Art der Stromabrechnung geändert wird. Die Arbeiten sollen etwa 15 Minuten dauern.

Ich werde vor Ort sein, falls es Probleme mit einem Server gibt und dieser nicht automatisch wieder hochfährt. Die Server die an der USV angeschlossen sind sollten die Wartung überleben, sofern sie nicht zu lange dauert. Teilnehmer deren Server nicht hinter der USV hängen können diese entweder vorher herunterfahren, sicherstellen dass der Server durch Drücken von Ctrl-Alt-Del herunterfährt oder es auf einen harten Ausfall ankommen lassen. Wenn der Strom wieder da ist werde ich prüfen, ob alle Server wieder Strom haben. Falls es nach der Wartung Probleme geben sollte, meldet euch bitte bei uns.

Update 23:30 Uhr: Der Fehler auf dem Shellserver ist behoben.

Update 19:00 Uhr: Außer dem Shell- und Upload-Server kudu (shell.in-berlin.de) sind alle Dienste wieder verfügbar.

Update: Wir haben eine Lösung gefunden die erstmal funktioniert. Diese muss aber in den nächsten Tagen noch einmal geändert werden.

Update 08:31 Uhr: Aktuell ist die Verbindung wieder stabil, es kann aber noch einige Wackler geben. Die Ursache war komplex, ein Teil war eine übergelaufene Tabelle auf einem Core-Router.

Update: Seit 08:55 Uhr ist die Routing-Einstellung, die das Problem ausgelöst hat, geändert. Mit weiteren Wacklern ist aus diesem Grund also nicht zu rechnen.

Der NNTP-Server “news.in-berlin.de” / “news.vr.in-berlin.de” muss ab sofort seine Newsartikel von einer anderen Quelle beziehen. Das heißt leider, dass sich alle Artikelnummer der Newsartikel ändern. Bitte resetten euren NNTP-Client. Teilweise ist dies nur durch Löschen und neu Abbonieren der Newsgroups möglich. Dies hat auch leider zur Folge, dass der Status der gelesenen und ungelesenen Newsartikel zurückgesetzt wird. Wir haben die Umstellung bereits seit längerem vorbereitet, so dass die neue Quelle die Artikel mit einer ausreichenden Haltezeit vorhalten sollte. Falls es in einigen Newsgroups oder Newshierarchien jetzt Probleme (keine Artikel oder zu kurze Haltezeit) geben sollte, lasst es uns bitte wissen, damit wir das prüfen und gegebenenfalls korrigieren können.

Die Server für das Service-Interface, E-Mail per POP3/IMAP4/SMTP, E-Mail und News per UUCP, der alte Shell-Server antilope sowie der serielle Konsolenserver, den auch einige Serverhousingteilnehmer nutzen, müssen heruntergefahren werden, da sie derzeit mit nur einem Netzteil ausgestattet sind. Ebenfalls betroffen sind wenige Serverhousingteilnehmer an dem Standort, die aber nochmal per separater E-Mail informiert werden. Es müssen ebenfalls 3 Netzwerkswitches ausgeschaltet werden, so dass es auch zu einer Nicht-Erreichbarkeit von Diensten und Servern (auch von Serverhousingteilnehmern) kommen kann, die nicht heruntergefahren werden müssen.

Wir bitten die Unannehmlichkeiten zu entschuldigen. Sollte jemand nach 17 Uhr noch umstellungsbedingte Probleme feststellen, die wir noch nicht bemerkt haben, freuen wir uns über jeden Hinweis.

Mail ohne Webmail und Mysql-Datenbanken sind nicht betroffen.

Update 21:52 Uhr: Bei der Aktualisierung gab es Probleme mit dem Kalender von Horde, daher haben wir die Aktion zurückgestellt - vorläufig bleibt alles beim Alten. Horde/Webmail ist wieder verfügbar.

Update 13:46 Uhr: Alle Dienste laufen wieder.

Mittlerweile ist wieder alles in Betrieb.

Andere Dienste (Teilnehmer-Webseiten, service.in-berlin.de, Shellserver) sind nicht betroffen.

Wir bitten um Verständnis für die kurzen Ausfälle. Selbstverständlich bemühen wir uns, die Ausfallzeiten so kurz wie möglich zu halten.

Update: Seit 21:29 Uhr sind alle Dienste wieder erreichbar. Es gab eine Downtime von 6 Minuten.

Update 18:20 Uhr: Die Wartungsarbeiten sind ausgefallen, das Service-Webinterface war ununterbrochen erreichbar.

Update 10.07.2011 23:20 Uhr: Seit heute um etwa 13:30 Uhr ist das Userbackup wieder erreichbar.

Update 22:05 Uhr: Die virtuellen Maschinen sind wieder online. Wir haben die Ursache für den Ausfall eingekreist.

Laut Nachfrage beim Stromanbieter führte ein defektes Kabel zum Ausfall. Im o. g. Zeitraum wurde auf ein Ersatzkabel geschwenkt. Danach war die Versorgung wieder gegeben.

Update: Die Ausfallzeit betrug etwa 20 Minuten. Alle Dienste sind wieder up.

Weitere Informationen zu unserer CA, dem root-Zertifikat und dem Fingerprint findet ihr auf der Webseite unserer CA.

Wir bemühen uns, die Downtime auf das notwendige Minimum zu beschränken und bitten alle Teilnehmer um Verständnis.

Die Dienste Mail, Teilnehmer-Webseiten, Shellzugang, Teilnehmer-Mailinglisten, Jabber sind nicht betroffen.

Update: Um 16:00 Uhr war das Problem gelöst. Wir haben dann nochmal etwas umgesteckt auf eine andere USV, so dass gegen 16:25 Uhr nochmal ein kurzer Ausfall erzeugt wurde. Seit 16:30 Uhr funktioniert aber alles wieder. Eine USV ist gestorben und hat einen Switch und einen Router mitgenommen. Warum bei diesem Ausfallszenario die Uplink-Redundanz nicht wie geplant funktioniert hat, muss nun mit dem Uplink-Provider geklärt werden.

Update 14:10 Uhr: Das Problem ist nach einem Reboot des Mailservers behoben.

Update 17:10 Uhr: Die 030-Einwahl funktioniert wieder. Die Versatel hatte eine sehr kurze Reaktionszeit.

Update 21:00 Uhr: antilope wurde in neue Hardware verfrachtet und ist wieder online.

Update 00:06 Uhr: Der Server ist wieder up. Alle Dienste sollten wie gewohnt wieder zur Verfügung stehen.

Update: Seit 15:10 Uhr lassen sich die meisten Domains wieder auflösen. Allerdings kann sog. Negativ-Caching noch ein paar Stunden Probleme beim Zugriff auf Domains bereiten.

Update 16:10 Uhr: Die ADSL- und SDSL-Neueinwahl funktioniert wieder. Die Leitung ist noch nicht wiederhergestellt.

Update: Um 22:42 Uhr ist das Update abgeschlossen, alle Dienste sollten wieder laufen.

Update: Seit dem Abend des 27.04.2010 funktioniert der Access Point wieder. Leider haben diverse Faktoren für eine Verzögerung der Reparatur gesorgt.

Sorry für die Unannehmlichkeiten.

Update: Seit 17:35 Uhr ist das Problem gelöst, die Einwahl über profi-adsl.de funktioniert wieder.

Update: Seit 20:20 Uhr ist das Problem gelöst, die Einwahl über city-adsl.de funktioniert wieder.

Update 12:03 Uhr: Das Problem bei unserem Technikpartner ist behoben, die ADSL-Neueinwahl funktioniert wieder.

Update 09:07 Uhr: Das Problem scheint gelöst zu sein. Es wurde verursacht durch einen planmäßigen Austausch des Peering-Switches am ECIX, über den der ADSL-Traffic zugeführt wird.

Update 17.11.2009 21:10 Uhr: Der Angriff auf das IN-Berlin-Netz wurde erkannt und isoliert. Das Netz läuft jetzt wieder problemlos.

Da der Betreiber der von uns genutzten Rechenzentrumsfläche im Alboinkontor am kommenden Dienstag zwischen 8:00 und 13:00 Uhr eine Stromwartung beziehungsweise einen Redundanztest plant, müssen wir dringend am 2009-11-14 zwischen etwa 11:30 und 15:00 Uhr einzelne Systeme umstecken und demzufolge auch rebooten.

Es sind 2 Server von Teilnehmern von dem Umbau betroffen, der Rest sind Server des IN-Berlin (Mailserver, Service-Interface, UUCP, einer der VPN-Tunnel-Gateways). Die betroffenen Teilnehmer wurden bereits informiert. Die Shell-, Web-, Applikations- und Datenbankserver müssen nicht rebootet werden, da sie mit redundanten Netzteilen versorgt sind. Betroffen ist aber auch einer unserer Router und einer der Haupt-Switches. Es kann daher im Wartungszeitraum für alle Teilnehmer zu Wacklern im Netzwerk kommen.

Seit dem Stromausfall am 07.09.2009 haben wir noch ein paar Rechner (für den Regelbetrieb) ungünstig auf die Stromleisten verteilt, da wir die Ausfallzeit in der Nacht möglichst gering halten und schnell wieder alle Systeme online haben wollten. Teilweise werden die gegeneinander redundanten Rechner und Switches nun aber nicht mehr von unterschiedlichen Stromkreisen versorgt. Diesen Zustand gilt es nun zu korrigieren, wo bestätigt ist, dass das Problem mit der USV vom RZ-Betreiber gelöst wurde.

Wir bitten um Verständnis für diese vorbereitende Aktion und hoffen, dass am kommenden Dienstag keine Ausfälle durch die Arbeiten des RZ-Betreibers entstehen.

Update: Nach einigen Startschwierigkeiten beim Betreten des Rechenzentrums konnten wir dann verspätet mit der Wartung beginnen und haben alles so weit erledigt wie geplant. Alle Dienste stehen wieder zur Verfügung.

Update 19:49 Uhr: Das Kabel ist auf eine andere Netzwerkkarte umgesteckt und nun funktioniert antilope wieder. Da die antilope eigentlich abgeschaltet werden soll und wir an der Hardware daher nichts mehr umbauen, gibt es hier keine redundante Netzwerkkonfiguration, wie z. B. auf den virtualisierten Servern.

Update: Um 00:34 Uhr war kurzzeitig eine Einwahl möglich und viele User sind und bleiben auch wieder online, aber die Neueinwahl selbst scheint noch nicht wieder permanent möglich zu sein.

Update: Es handelte sich um ein Stromproblem bei Level3, wodurch auch unser Vorlieferant ausgefallen ist. Inzwischen funktioniert aber alles wieder.

Der Stromausfall ist inzwischen behoben, allerdings hat unser Festplattenarray ein Problem, es coredumped beim Booten. Daher stehen derzeit die virtualisierten Systeme wie Shell- und Web-Server nicht zur Verfügung. Wir arbeiten nun mit dem Hersteller des Festplattenarrays an einer Lösung und halten euch hier auf dem Laufenden.

Update 08.09.2009 10:34 Uhr: Das Festplattenarray ist wieder up, aber derzeit ohne eine Cache-Batterie. Wir werden mit dem Hersteller die weitere Vorgehensweise klären. Es ist nicht auszuschließen, dass wir beim Einbau der neuen Batterie in den nächsten Tagen nochmal im Rahmen einer angekündigten Wartung die Systeme kontrolliert herunterfahren müssen. Diese Wartung wird aber dann nicht tagsüber stattfinden.

Update 23:50 Uhr: alle Server sind migriert und aktualisiert

Update: Der User-Webserver wurde bereits beim letzten Ausfall gestern abend speichermäßig aufgerüstet, wodurch das akute Problem erstmal behoben ist. Wir ziehen den User-Webserver zu einem späteren Zeitpunkt zusammen mit anderen Servern auf einen anderen Hardwarenode um.

Update: Die Netzwerkprobleme sind gelöst. Ursache war ein Defekt auf einem Switch eines Berliner Peeringpunkts.

Update 17:00 Uhr: Der Zugriff auf den POP/IMAP-Server ist komplett wiederhergestellt.

Update 11:20 Uhr: Das Problem ist gelöst, die profi-adsl.de-Teilnehmer sind wieder online.

Update : Seit dem 06.01.2009 etwa 09:30 Uhr funktioniert die Einwahl auf unseren Berliner Ortsnetznummern wieder.

Update 13:30 Uhr: hirsch ist wieder up and running. Der News-Spool liegt jetzt testweise auf einer SSD.

Update: Seit etwa 14:40 Uhr ist das Problem laut Telefonica behoben. Es musste mehrfach Hardware getauscht werden. Leider stellen wir nach vor Probleme fest und haben das erneut weitergegeben und warten nun auf Rückmeldung.

Update: Seit etwa 16:30 Uhr ist das Problem bei Telefonica größtenteils behoben, so dass city-adsl.de wieder stabil sein sollte.

Update: Das Problem ist anscheinend noch immer nicht gelöst. Wir haben die Störung erneut weitergegeben.

Update: Seit etwa 18:30 Uhr sind die city-adsl.de Sessions wieder stabil. Leider haben wir noch kein Feedback, dass das Problem behoben ist.

Update: Seit etwa 5:30 Uhr ist auch das letzte Problem behoben. Bitte stellt, falls ihr auf profi-adsl.de gewechselt habt, möglichst wieder auf city-adsl.de zurück. Danke.

Update: Seit etwa 16:00 Uhr ist der Strom wieder da.

Update 20:00 Uhr: Seit 19:10 arbeiten alle Server bis auf den alten Webserver antilope wieder normal. Seit 19:55 steht auch antilope wieder zur Verfügung.

Update 14:20 Uhr: Das Problem beim Leitungsprovider ist behoben, die 030-Einwahl funktioniert wieder.

Am Zielort stellte sich heraus, dass das Netzteil von antilope (auch bekannt als me.in-berlin.de) gestorben war. Wir haben kurzfristig Ersatz beschafft und auch diese Maschine wieder in Betrieb genommen. Weiterhin waren in verschiedenen Servern noch diverse defekte Lüfter auszutauschen, die wir auch gleich mit ersetzt haben.

Insgesamt haben wir in der vorgesehenen Zeit mehr geschafft, als ursprünglich vorgesehen, ein Großteil der Server ist bereits umgezogen. Vom alten Standort müssen noch vier Server umgezogen werden, u. a. der POP3/IMAP4/SMTP-Server einhorn. Während des Umzugs werden die Dienste POP3/IMAP4/SMTP-Relay temporär nicht zur Verfügung stehen.

Der Umzug der letzten Server wird morgen, am 30.09.2008, zwischen 16:30 und 19 Uhr stattfinden. Die Vorbereitungen am neuen Standort sind bereits getroffen, so dass der Server schnell eingebaut werden kann. Wir werden selbstverständlich versuchen, die Downtime so gering wie möglich zu halten.

Nach dem Umzug der letzten Server werden wir das Netzwerk noch etwas optimieren und dadurch die Paketlaufzeiten geringfügig verringern. Derzeit laufen die Pakete noch über den alten Standort, nach dem endgültigen Umzug wird ein Großteil des Traffics direkt am neuen Standort in die Welt transportiert. Nach und nach werden wir dann noch kleinere Optimierungen vornehmen, ein wenig Altlasten aufräumen und uns wieder neuen Projekten widmen.

An dieser Stelle nochmals vielen Dank an alle Umzugshelfer!

• es steht mehr Platz zur Verfügung, so dass wir weiter ausbauen können
• das Klima ist deutlich besser
• es gibt eine direkte USV- und Diesel-Notstromversorgung, um die wir uns nicht mehr selbst kümmern müssen
• mehr Netzwerkredundanz, da mehrere Carrier in dem Rechenzentrum sind

Am kommenden Samstag den 27.09.2008 werden wir im Zeitraum zwischen 11 und 20 Uhr damit beginnen, die ersten Server in das neue Rechenzentrum umzuziehen. Es werden noch nicht alle Server umgezogen. Da wir die Server innerhalb Berlins transportieren müssen, wird es unweigerlich zu Ausfällen von Diensten kommen. Es wird kein Dienst über den kompletten Zeitraum ausfallen, aber gegebenenfalls mehrfach im angegebenen Zeitraum.

IN-DSL sollte während des Umzugs weiter funktionieren, da wir hier zunächst nur einen Terminierungsrouter umziehen. Serverhousing im Vereinsraum ist vom Umzug nicht betroffen.

Ursache ist partieller Ausfall der Klimaanlage im Serverraum. An einer Lösung des Problems wird gearbeitet.

Update: Seit etwa 18 Uhr sollten alle Dienste wieder zur Verfügung stehen.

Die initialen Passwörter wurden im Dezember verschickt, alle Nutzer, die keins erhalten haben, wenden sich bitte per E-Mail an den Support. E-Mail- und Einwahlpasswörter sind nicht betroffen.

Update: Die Probleme sind seit etwa 13:30 Uhr gelöst und wurden durch über einen Peeringpunkt eingeschleuste Multicastpakete verursacht. Damit das nicht wieder auftritt, werden zeitnah entsprechende Maßnahmen im Netz unseres xDSL-Technikpartners ergriffen.

Update: Seit 02:45 Uhr ist das Problem behoben. Wir werden in den nächsten Tagen noch weitere Entlastung schaffen, haben aber jetzt erstmal wieder funktionierende Dienste.

Informationen zur neuen Verzeichnisstruktur (“wo liegen jetzt die Dateien auf welchen Servern?”) und zu den neuen Servern haben wir im Wiki hinterlegt. Dort gibt es auch Informationen zum SSH-Zugang zum Shellserver.

Update: Die Migration der Daten ist abgeschlossen. In den nächsten Tagen werden dann die Passwortbriefe verschickt und einzelne Sites auf den Apache2 migriert.

Update: Das Problem wurde wenige Minuten später behoben.

Update 01:55 Uhr: Das Problem wurde durch unseren Technikpartner behoben. Die Downtime betrug etwa 25 Minuten.

Update 18:52 Uhr: Die Mailinglisten arbeiten wieder. Die HTML-Archive der Mailinglisten werden im Hintergrund neu generiert, das wird einige Zeit dauern. Wenn noch jemand von einer Mailinglisten-URL hierher umgeleitet wird, liegt das möglicherweise daran, dass sich die Änderung der IP-Adresse noch nicht weltweit im DNS herumgesprochen hat, oder die Umleitung noch im Cache des Browsers oder eines Proxys steht.

Update 22:00 Uhr: HTML der Listenarchive ist generiert.

Update 22:55 Uhr: Der Umzug weiterer Mailinglisten hat begonnen.

Update 23:12 Uhr: Mailinglisten arbeiten wieder normal, HTML der Listenarchive wird generiert.

Update 23:33 Uhr: HTML der Listenarchive ist generiert, der Umzug damit abgeschlossen.

Update: IN-DSL ist nach 30-minütiger Downtime wieder halbwegs online, allerdings sind erst die Hälfte der Sessions wieder da. Die andere Hälfte kam nach dem Reset eines Routers bei unserem Technikpartner ebenfalls wieder online. Wir haben noch keine offiziellen Informationen zur Ursache des Ausfalls erhalten, nur die Info, dass die Last auf den Routern zur Ausfallzeit ungewöhnlich hoch war, was auf einen DoS-Angriff schließen lässt.

Update 16:51 Uhr: Die umgezogenen Listen und deren Webinterfaces auf dem neuen Server sind wieder funktionsfähig.

Update 17:50 Uhr: Die Regenerierung der HTML-Archive ist jetzt auch abgeschlossen.

Update: Die Probleme sind geklärt. Es handelte sich um einen Angriff mit vielen kleinen Paketen, der dafür gesorgt hat, dass der Router über den IN-DSL läuft instabil wurde.

Update: seit 16:10 Uhr funktioniert die 030-Einwahl wieder.

Update 18:40 Uhr: erste Phase beendet, alle Mailinglisten im Normalzustand

Update 22:45 Uhr: Das Problem ist behoben, der Server ist wieder online.

Update: Leider gibt es Probleme bei der Umstellung, die entweder bei der DTAG oder beim neuen Technikpartner zu suchen sind. Neueinwahlen mit city-adsl.de sind daher momentan leider nicht möglich. Der Technikpartner sucht aber bereits nach der Ursache. So lange ist die Einwahl über profi-adsl.de möglich, da das über einen anderen Technikpartner läuft.

Update 14:30 Uhr: Der Technikpartner hat das Problem gegen 14:00 Uhr gelöst, Neueinwahlen über city-adsl.de sind wieder möglich. Das Problem wurde ausgelöst durch die “#” in unseren Benutzernamen…

Update 01:03 Uhr: Die Einwahl über city-adsl.de funktioniert wieder. Wir haben allerdings noch keine Information zur Störungsursache.

Update: Uns wurde zuerst eine Entstörung am heutigen Samstag zugesagt, jetzt gerade habe ich auf Anfrage von der Versatel-Hotline erfahren, dass die zuständige Abteilung am Wochenende überhaupt nicht arbeitet und nicht vor Montag mit einer Entstörung zu rechnen ist.

Update 23.07.2007 07:45 Uhr: Das Problem ist behoben, die Einwahl ist wieder möglich. Wir werden mit Versatel aber noch die Ursache des Ausfalls klären müssen.

Update: Seit 13:09 Uhr sind alle E-Mail-Dienste wieder erreichbar.

Rechnet daher bitte ab 9 Uhr mit einer Downtime des UUCP Dienstes für voraussichtlich 2 Stunden. Gernot hat zwar alles sehr weit vorbereitet, so dass die Downtime vermütlich kürzer sein wird, aber man weiß nie, was noch unvorgesehenes passiert. Mails die während der Downtime für eure Sites reinkommen, werden auf anderen Mailservern so lange zwischengespeichert, bis der UUCP-Server wieder verfügbar ist.

Übermorgen, am 17.03.2007, planen wir in der Zeit von 12-14 Uhr Kernelupdates der neuen User-Server und ein Firmware-Upgrade unseres Storage-Systems. Während dieser Zeit werden die Zope 2.8 Instanzen kurzzeitig während der Reboots der Systeme nicht erreichbar sein.

Weitere Informationen über die neuen User-Server (Features, Möglichkeiten), geplante Migrationsschritte, einen neuen Spamfilter sowie sinkende Domainpreise werden wir demnächst in einem weiteren Newsletter bekanntgeben.

Wir werden natürlich versuchen, die Downtimes so gering wie möglich zu halten und hoffen auf euer Verständnis.

Update: Seit dem Abend des 23.01. ist auch der bisherige Newsserver wieder in Ordnung. Wir haben jetzt wieder eine Redundanz mit 2 Newsservern.

Update: Die Probleme wurden am selben nachmittag von unserem Technikpartner beseitigt. Es handelte sich um ein Hardwareproblem auf einer sekundären Routerengine, während die primäre Routerengine ein Softwareproblem hatte. Aus diesem Grund haben Redundanzen leider nicht wie geplant gegriffen ;-/ Unser Technikpartner wird zur Vermeidung derartiger Probleme Anfang 2007 nochmal einen Redundanztest durchführen.

Update: Seit 18:56 Uhr funktioniert der Dienst wieder.

Update 14:55 Uhr: Der Newsserver ist wieder erreichbar.

Update: Der Mailserver funktioniert mittlerweile wieder. Die von unseren anderen Mailservern zwischengespeicherten E-Mails werden nun nach und nach in die POP3/IMAP4-Mailboxen ausgeliefert.

Update 17:42 Uhr: IMAP/POP3 steht wieder zur Verfügung.

Update 20.09.2006 00:00 Uhr: Die Dienste von mirror.vr.in-berlin.de stehen wieder zur Verfügung.

Update 20.09.2006 13:20 Uhr: Die Umorganisation der Festplatten und die Wiederherstellung der CD/DVD-Images läuft noch (Zugriff möglich), es steht jetzt mehr Platz zur Verfügung. Am Ende des Umbaus wird es noch einmal einen kurzen (maximal 10 Minuten) Ausfall geben.

Der Server ist grundsätzlich nur aus unseren Netzen (also bei Zugang über IN-Berlin) erreichbar.

Update: Die Störung ist inzwischen behoben.

X-Spam-Score: ** (2.5) BAYES_99,HTML_MESSAGE

Außerdem hatte die Bayes-Datenbank auf methan bis 26.7. etwa 12 Uhr keine antrainierten Daten. Die Bayes-Datenbanken sind jetzt auf beiden Mailservern wieder auf aktuellem Stand und werden weiter von uns mit Spam und “Ham” trainiert.

Wir bitten für die entstandenen Unannehmlichkeiten um Entschuldigung.

Details zur Nutzung des Spam-Tagging finden sich im Wiki.

Update 10:30 Uhr: Die Ursache des Problems ist beseitigt.

Update 11:26 Uhr: Allerdings kann es beim Abarbeiten der aufgelaufenen Mails kurzzeitig (etwa 5 min) noch zu Nichterreichbarkeit beim Versenden von Mails kommen.

Update 13:30 Uhr: Die Dienste stehen wieder zur Verfügung.

Update 18:15 Uhr: Die neue Platte ist eingebaut und hirsch läuft wieder.

Beim Austausch hat sich aus organisatorischen Gründen auch die IP-Adresse des Servers geändert. Teilnehmer die sich von uns ihre Mails direkt per SMTP ausliefern lassen, müssen ihre Firewall für SMTP anpassen. Bitte lasst das Netz 192.109.42.0/27 und die IP-Adressen 130.133.8.34 und 130.133.8.35 zu.

Update: Das Problem wurde am selben Abend noch gelöst.

Während der Arbeiten kann es zu kurzfristigen Ausfällen einzelner Dienste kommen, wir bemühen uns, diese so kurz wie möglich zu halten.

Alle Nutzer, die Prozesse auf me.in-berlin.de laufen lassen, werden gebeten, diese nach Abschluß der Arbeiten neu zu starten, da auch die von allen verwendete libc6 aktualisiert wird.

Update 01:42 Uhr: Die Arbeiten sind abgeschlossen.

Update 17:00 Uhr: Die Störung ist behoben.

Update 12:35 Uhr: Die Modem/ISDN-Einwahl funktioniert wieder.

Update 22:15 Uhr: Die Versatel hat die Leitung durchgemessen und resettet. Sie haben Fehler in der Lehrter Straße festgestellt. Morgen früh geht eine Störung an die Telekom raus.

Update 26.07. 7:00 Uhr: Die Leitung wurde heute Nacht nochmal resettet und von der Versatel überwacht. Seitdem sind keine Probleme mehr aufgetreten. Die Leitung wird heute erstmal weiter beobachtet.

Update 18:15 Uhr: einhorn läuft jetzt wieder mit allen Lüftern.

Update 17:00 Uhr: Der Server ist wiederhergestellt und alle Dienste sollten wieder funktionieren.

Update: Seit etwa 16 Uhr funktioniert IN-DSL wieder. Das Problem war ein Stromausfall in Frankfurt.

diese Nachricht betrifft nur diejenigen Teilnehmer, die Kunde der Berlikomm sind und sich per Modem und/oder ISDN bei uns unter den Rufnummern 030/454871 und 454872 einwählen. Kunden anderer Telefongesellschaften (z. B. Telekom, Arcor), IN-DSL- oder IN-Berlin Light Teilnehmer sind nicht betroffen.

Mit Erstaunen mussten wir am 20.10.2004 feststellen, dass die Berlikomm die Verbindungen zu unseren Einwahlrufnummern seit dem 01.09.2004 als Stadtgespräch abgerechnet hat. Dies hat zur Folge, dass eure Telefonrechnungen aufgrund eines Abrechnungsfehlers der Berlikomm vermutlich ungewöhnlich hoch sein werden.

Die betroffenen Teilnehmer müssen in jedem Fall ihre Telefonrechnung bei der Berlikomm reklamieren. Weitere Informationen sind per E-Mail an alle Teilnehmer verschickt worden. Wer seine Mailbox bei uns nicht abfragt, kann diese Information per Anfrage an support@in-berlin.de noch einmal von uns bekommen.

Update: Es handelt sich um ein Hardwareproblem. Wir haben den Router erstmal durch ein Ersatzgerät ausgetauscht. Seit etwa 7:30 Uhr ist die Einwahl per ISDN/Modem wieder möglich.

Update 11:35 Uhr: Der Strom ist wieder da, alle Systeme sind problemlos wieder hochgefahren.

Update 21.05.2004: Seit kurz nach mittag liefert Freenet uns wieder Binary-News.

Update 14:00 Uhr: Die Umbauarbeiten und Updates sind abgeschlossen.

Ab sofort ist die maximale Mailbox Größe 50 MB, statt bisher 20 MB.

Wir versuchen natürlich wie immer die Ausfallzeit so gering wie möglich zu halten und bitten um euer Verständnis.

Neuer Hostkey Sites, die per UUCP über SSH pollen, müssen den neuen Hostkey bestätigen (also einmal “von Hand” verbinden). Leider konnten wir das nicht mehr vorher per Mail ankündigen - siehe eine Meldung tiefer.

Update: Es läuft so weit alles wieder. Wir haben den Ausfall gleich dazu genutzt, die Server hirsch (UUCP und News) und einhorn (POP3, IMAP4, SMTP) wieder physisch zu trennen. Daher hat der Ausfall etwas länger gedauert, aber es gibt dann durch die Trennung, die ohnehin geplant war, keine zusätzliche Downtime mehr.

Durch den Umbau kann es für einige UUCPler erforderlich sein, aufgrund des neuen SSH-Hostkeys von hirsch.in-berlin.de als User UUCP nochmal eine SSH-Verbindung per Hand zum hirsch aufzubauen. Sollte jetzt noch jemand Probleme mit E-Mail oder UUCP haben, schreibt uns bitte eine E-Mail an support@in-berlin.de.

Update: Das Update war erfolgreich und ist so gut wie abgeschlossen.

Update 19:00 Uhr: Umbau beendet - der E-Mail- und UUCP-Server ging schnell, aber mit den Routern gab es Probleme, daher immer mal kurzzeitige Aussetzer. Jetzt geht wieder alles.

Update: Die Wartungsarbeiten sind abgeschlossen. Es sollte nun alles wieder wie gewohnt, nur mit mehr Redundanz, laufen.

Update 17:15 Uhr: Die Anbindung ist jetzt abgeschaltet und es wird über eine andere Anbindung geroutet. Die Probleme sollten jetzt erstmal nicht mehr auftreten.

Update 14:00 Uhr: Auf einer Festplatte befindet sich ein fehlerhafter Sektor. Wir sind gerade dabei, das Dateisystem zu prüfen. Der Newsserver steht daher kurzzeitig nicht zur Verfügung.

Update 15:45 Uhr: Eine Festplatte ist teilweise physisch defekt. Wir haben diese aus dem RAID-System genommen und werden sie möglichst schnell austauschen.

Update: E-Mail per Pop/Imap sollte wieder gehen, am Webmail wird noch gearbeitet.

In alle Mails bei denen ein Attachment entfernt wurde, wird die Headerzeile X-INBEV: unsafe attachment removed eingefügt. Danach kann man die Mails z. B. zusätzlich filtern. Alle aktuellen Filterregeln für E-Mails und die Erweiterungen der geblockten Anhänge haben wir auf einer Seite zusammengestellt.

Das Problem war, dass der Newsserver unseres primären Binary-Feeds aufgrund des Swen-Wurms massiv überlastet wurde. Jetzt wurde er für IN-Berlin wieder freigeschaltet, so dass ihr wieder Binary-News abrufen könnt.

Update: Der Server läuft nach einem Restore des root-Filesystems wieder.

Informationen über den Wurm und die möglichen Betreffzeilen, die von diesem Wurm generiert werden, findet man z. B. auf den Internetseiten des BSI.

Der Newsserver ist gerade mit dem Einsortieren mehrerer tausend Binary-Artikel beschäftigt. NNTP-Zugriff war daher temporär deaktiviert. Jetzt füllen sich die Gruppen langsam wieder.

Gegen 10:30 Uhr werden wir mit den Arbeiten beginnen. Temporär steht dann das Abholen von E-Mails über POP3/IMAP4 und das Senden von E-Mails sowie UUCP nicht zur Verfügung.

Außerdem werden wir in den Proxy- und Newsserver “elch” eine zusätzliche Festplatte einbauen, die etwas Performance bringen wird. Während der Einbauzeit steht der Server ebenfalls temporär nicht zur Verfügung.

Wir versuchen natürlich die Umbauzeiten möglichst gering zu halten.

Sorry, aber in der Hardware steckt man leider nicht drin…

Jetzt sollte sich alles wieder normalisiert haben. Es kommen zwar immer noch Bounces bei uns rein, aber diese sollten den Regelbetrieb nicht mehr stark beeinflussen können.