[Berlin-wireless] Wer kümmert sich eigentlich um die VPN03 VMs?

[Philipp Borgers]

Von welchen VMs sprechen wir denn jetzt?

Upgradepfad für VPN03a sieht wie folgt aus:

* VM mit funktionierendem DNS für Mails aufsetzen und Zertifikat-Generierung
dorthin migrieren (Wunsch-DNS: ca.berlin.freifunk.net)
* neue VM für VPN03a aufsetzen
* alte VM löschen

An der alten VM sollten wir einfach nicht weiter "rumfrickeln".

Tut mir leid, dass ich die VMs etwas vernachlässigt habe.

Gruß Philipp

On Sat, Aug 29, 2015 at 01:14:38AM +0200, Bastian wrote:
> Hallo Liste,
> 
> ja, VPN03 zu optimieren ist wirklich nicht trivial, weil das echt viel
> tiefgehendes Verständnis vom OSI-Stack und Netzwerk und so voraussetzt,
> aber ein bisschen einfache Admintätigkeiten sollten doch das mindeste sein:
> 
> Eigentlich wollte ich mich gerade nur um das Sammeln von Metriken für
> eine Baseline kümmern, aber mir ist gerade echt die Lust vergangen:
> 
> * 5 Jahre alter Kernel 2.6.32-5, unter Squeeze (unsupported, EOL)
> * platte Voll, deswegen funktionieren unattended upgrades nicht
> * Meldungen die besagen wie kaputt voll die conntrack_table ist
> nf_conntrack: table full, dropping packet
> net_ratelimit: 60 callbacks suppressed
> 
> Ein einfaches googlen dazu bringt folgendes zutage:
> The common reason for that is a heavy traffic passing by the server or
> very often a DoS or DDoS (Distributed Denial of Service) attack.
> Sometimes encountering the err is a result of a bad server planning
> (incorrect data about expected traffic load by a company/companeis) or
> simply a sys admin error[1]
> 
> Leute, wenn ihr die Meldung seht und nicht versteht, dann fragt doch
> einfach auf der Liste. Aber ich muss momentan annehmen, dass ich der
> erste bin der die Meldung sieht, und somit sich einfach niemand um die
> Maschinen kümmert.
> 
> Solange sich niemand für die VPN03 VMs verantwortlich fühlt, sehe ich
> keinen Grund warum wir überhaupt eine Diskussion über weitere VPN03 VMs
> führen.
> 
> [1]:
> http://pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/
> 
> Best,
> Bastian
> 



> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein öffentlich einsehbares Archiv

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20150829/37f0c190/attachment.pgp>