Tag: software

in einem proxmox/ceph cluster mit insgesamt sieben nodes sind vier identische nodes nur für den ceph storage zustaendig. alles supermicro x8dtl-3f mit ssds und 10gbit nics.
irgendwann… ich weiss nicht genau wann… aber auf jeden fall nach dem update auf debian stretch und pve5 hatten diese vier server problemchen. erstmal sah es so aus, als ob es mehrere verschiedene probleme sind.

1. in einem zeitraum von 1 bis 7 tage booteten die server spontan und ohne erkenntlichen grund. keine eintraege im syslog und nichts im bios/ipmi eventlog zu sehen.

2. weniger haeufig kam es vor, dass ein node zwar noch “online” war, aber alle seine festplatten “verloren” hat. seh dann auf dem bildshirm so aus:

3. die onboard netzwerkkarten haben rumgezickt, was im logfile dann so aussah:

das hat sich dann im sekundentakt wiederholt

4. selten bekam ich meldungen wie diese auf den schirm:

wie sich aber rausstellte, war das genau das ausschlaggebende! falls noch was im syslog zu sehen war (eher garnicht ausser bei dem nic flapping), dann war auch immer so eine meldung unmittelbar davor zu sehen.

nach ein wenig googlen kam heraus, dass der “irqbalanced” fuer diese meldungen verantwortlich ist. der irqbalanced kann im laufenden betrieb irq’s bei bedarf auf eine andere cpu mappen. wenn man google nach diesem ding fragt, bekommt man viele aussagen. von “braucht man nicht, weil aktuelle kernels das von alleine koennen” bis “sehr wichtig bei hoher last fuer performanceoptimierungen”.

ich hab dann kurzerhand in der datei /etc/default/irqbalance den parameter “IRQBALANCE_ONESHOT=YES” gesetzt. in der beschreibung dazu steht: “after starting, wait for a minute, then look at the interrupt load and balance it once; after balancing exit and do not change it again.”

….und was soll ich sagen. seit vier wochen habe ich nun ruhe und die server lauifen durch 🙂

fuer eine genaua analyse und warum das seit wann auftritt… puh.. da fehlt mir die zeit. ich hab mich lange genug damit beschaeftigt und nun laufen die kisten wieder rund.

auf irgendeiner webseite wollte ich ein PDF runterladen. dann kam diese fehlermeldung:

und egal, welchen knopf man drueckt… man kam immer wieder zur downloadseite zurueck. warum macht man sowas?

eine alte owncloud installation habe ich “aus gruenden” endlich mal auf nextcloud aktualisiert. soweit war alles fein, aber in meinen sehr umfangreichen kalendern waren wohl ein paar syntaktische probleme enthalten. weil ich das bei der menge an eintraegen niemals einfach und schnell rausbekommen haette, waehlt ich eine holzhammer mehode. einmal exportieren, kalender loeschen, neu anlegen und wieder importieren.
bis dahin war der kalender mit dem namen “default” auch mein wirklicher default kalender und bei nutzung der webgui war dieser bei neu erstellten eintraegen auch vorausgewaehlt. nach meiner o.g. aktion war er es leider nicht mehr. jedes mal beim erstellen eines eintrages den passenden kalender auswaehlen war aber auch keine loesung. also gesucht und was gefunden. der beschrieben bug ist schon seit zwei jahren gemeldet… nur erledigt hats scheinbar noch niemand. da ich kein programmierer bin bin ich eher auf die workarounds angewiesen. diesen mag ich hier kurz beschreiben….

erstmal schauen, was da bei meinen kalendern so drin steht:

SELECT id, displayname, uri, calendarorder FROM oc_calendars WHERE principaluri LIKE '%MYUSERNAME;

da in dem feld “calendarorder” ueberall NULL drin steht, wirds erstmal gesetzt (auf wert “1”):

UPDATE oc_calendars SET calendarorder=1 WHERE principaluri LIKE '%MYUSERNAME%';

…um dann danach den richtigen kalender (“default” mit id 773) in der reihenfolge (calendarorder) eins hoeher (0 statt 1) zu setzen:

UPDATE oc_calendars SET calendarorder=0 WHERE principaluri LIKE '%MYUSERNAME%' AND id=773;

nach einem reload der webgui ist nun wieder alles paletti 🙂

irgendwann haben mal irgendwelche drecks bots einen uralten webserver lahm gelegt.
an die robots.txt haben sie sich nicht gehalten und eigentlich sollte die seite von keiner suchmaschine gecrawled werden. also aussperren nach diesem muster:

for i in `cat /var/log/apache/*.log | grep YandexBot|cut -d" " -f1|sort|uniq`; do iptables -A INPUT -s $i -j DROP; done 

das parst die apache logs, filtert nach dem entsprechenden bot, und sperrt die genutzten ips.
quick and dirty 😉

zu dem beitrag mit dem proxmox/ceph cluster gibts noch ein schickes video:

und das im dunkeln anzusehen… hach… das kann jeden nerd dazu bringen, ewigkeiten davor zu stehen und einfach nur stur auf das geblinke zu starren. so wie bei einem lagerfeuer.

hab ichs schonmal gesagt? ich liebe ceph. und bei solchen datenraten beim recovery … boah…

(nein, das ist nicht von meinem “spiel cluster” auf intel NUC basis mit usb3 platten 😉 )

ich lehne mich jetzt mal aus dem fenster uns behaupte, dass ich eines der “kleinsten” proxmox/ceph cluster habe, die je so gebaut wurden. klein im sinne von physischen abmessungen. die hardware ausstattung ist zwar nicht so der high performance kram, aber fuer die groesse recht ansehnlich.

3x intel NUC mit 9x 2,5 zoll usb 3.0 platten und ein synology slim nas. da eckdaten:

10 CPU cores
70 GB ram
6 TB ceph storage (brutto)
4 TB nfs storage (synology)

fuer das, was man so zuhause rumexperimentieren muss, langt mir das (fuers erste) 😀

das ganze sieht dann so aus: (erste ausbaustufe)

der hdd platz im ceph war mir bald zu klein, so dass ich noch drei weitere platten dran gehaengt hab:

da aber die platten nun dicht an dicht gepackt waren, musste ich mir was einfallen lassen, da die einfach zu warm wurden. dazu hab ich baumarkt ein paar alu profile gekauft, zersaegt und mit sekundenkleber zusammengebastelt.

was dann am ende so aussieht:

so ist dann etwas luft zwischen den platten und das alu kann vielleicht ein bischen waerme ableiten. wenns nicht reicht, kann ich noch ein oder zwei luefter dahinter haengen.

immer wieder kommts mal vor, dass eine ssh session “haengt”, weil z.b. gerade die internetverbindung abgekackt ist oder sowas. um die zu beenden, muss man “enter”, gefolgt von “~.” (tilde+punkt) druecken. die tilde ist der escape character und der punkt steht fuer disconnect.

hier noch ein paar andere von diesen sehr nuetzlichen kombinationen:

• ~.: Disconnect.
• ~^Z: Background ssh.
• ~#: List forwarded connections.
• ~&: Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate.
• ~?: Display a list of escape characters.
• ~B: Send a BREAK to the remote system (only useful for SSH protocol version 2 and if the peer supports it).
• ~C: Open command line. Currently this allows the addition of port forwardings using the -L, -R and -D options (see above). It also allows the cancellation of existing remote port-forwardings using -KR[bind_address:]port. !command allows the user to execute a local command if the PermitLocalCommand option is enabled in ssh_config(5). Basic help is available, using the -h option.
• ~R: Request rekeying of the connection (only useful for SSH protocol version 2 and if the peer supports it).

neulich… beim umzug einer fotogalerie auf einem anderen webserver kam neben der entsprechenden fehlermeldung im browser (file not found) diese fehlermeldung im error.log:

AH00687: Negotiation: discovered file(s) matching request: /var/www/htdocs/domain.tld/index (None could be negotiated)., referer: http://domain.tld/

nach etwas googlen war mir klar, dass das mit der option “MultiViews” zusammenhaengt.

die apache webseite weiss dazu:

The effect of MultiViews is as follows: if the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client’s requirements.

heisst also… beim aufruf von “http://domain.tld/index” schaut der webserver, ob er eine datei “index” mit einer irgendeiner dateiendung findet. er haette eigentlich in diesem falle die vorhanden index.php finden und nehmen sollen…. hat er aber nicht. grund dafuer war, dass der webserver nicht wusste, was er mit der dateianedung “php” anfangen soll.

bei einem debian stretch wird der umgang mit den mimetypes mit dem apache modul “mime” geregelt. am anfang der datei /etc/apache2/mods-available/mime.conf steht geschrieben:

   TypesConfig points to the file containing the list of mappings from
   filename extension to MIME-type.
   #
   TypesConfig /etc/mime.types

also husch in der /etc/mime.types geschaut und gesehen, dass diese zeile auskommentiert ist:

# application/x-httpd-php      phtml pht php

kommentarzeichen davor weg, speichern, apache neu starten und gut.

eine meiner auf kvm basierten virtuellen maschinen auf basis ubuntu (16.04) mit virtio netzwerkkarte und openvpn hat unter belastung immer wieder diese meldungen geschmissen:

mit dem ergebnis, dass die cpu last ganz oben hing und die vm nicht mehr nutzbar war. ursache war der virtio treiber fuer die netzwerkkarte. (oder eher die kombination kernel und virtio nic.) nachdem ich das in proxmox auf eine e1000 umgestellt habe, flutscht das nur noch so. die cpu last ist zwar geringfuegig mehr, aber dafuer schmiert die kiste nicht mehr ab.