proxmox/ceph cluster in miniatur
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.
“haengende” ssh session abschiessen
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).
apache2 “Negotiation: discovered file(s) matching request: None could be negotiated”
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:
<IfModule mod_mime.c> 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.
das leid mit dem fritzbox netzteil
ich hatte seit wochen stoerungen an meinem DSL anschluss. immer wieder ist die verbindung abgebrochen. die fritzbox hat sich darauf hin wieder mit der gegenstelle synchronisiert und nach ca zwei minuten gings weiter als waere nix gewesen. wenn das mehrmals am tag auftritt und man dann auch noch von zuhause aus arbeiten muss, nervt das extrem. also stoerungsmeldung bei der telekom aufgemacht, die haben gemessen, port reset, alles gut. einen tag spaeter ging das spiel von vorne los. also wieder eine stoerungsmeldung aufgemacht… “es muss ein techniker vorbei kommen”. der naechste freie termin war fast zwei wochen spaeter. egal – irgendwie hats ja trotzdem funktioniert.
der techniker kam sogar an einem samstag. ein junger, pfiffiger bursche, den ich gleich am outdoor dslam abgefangen habe (ich kann den kasten aus dem fenster sehen 😉 )
der hat den port im dslam getauscht und zur sicherheit nochmal an meiner dose im keller nachgemessen… alles bestens!
pustekuchen… am gleichen tag ging der zirkus wieder los. also kanns ja nur noch an meiner fritzbox liegen 🙁
tage spaeter hat mir wer erzaehlt, dass die fritzboxen auch gerne mal probleme machen, wenn das mitgelieferte netzteil nicht mehr genau das tut, was es urspruenglich sollte. die fritzbox geht dann zwar noch, aber bei manchen sachen klemmts dann. also hab ich mir erstmal ein 0815 netzteil bestellt und rangestoepselt. ein versuch isses wert, bevor man ne ganze fritzbox kauft. und siehe da… seit nun zwei wochen laeuft die ganze kiste wieder stabil!
und einen positiven nebeneffekt hats trotz allem auch noch gehabt… seit der nette techniker mein kabel in einen anderen port gesteckt hat, steht mir nicht mehr nur 50/10 mbit, sondern 100/40 mbit zur verfuegung! 🙂
NMI watchdog bug soft lockup – CPU#1 stuck for 23s!
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.
IPMI sensor thresholds anpassen
eines meiner supermicro motherboards mit integriertem IPMI onboard moser seit wochen rum, dass die BIOS batterie leer sein sollte. ist sie nicht… ich hab sie schon zweimal getauscht und mich mit einem messgeraet von dem zustand der batterie (CR2032 knopfzelle) ueberzeugt. das bekloppte IPMI ding schickte mir zwischen einer handvoll und einhundert emails am tag, dass da was nicht stimmt. mit onkel google habe ich nichts vernuenftiges gefunden, was die ursache sein koennte. diverse resets aller art, initialisieren des ipmi moduls und ruecksetzen auf werkseinstellung hat nichts gebracht. das problem, welches da auftritt, ist eine quasi schwankende batteriespannung. und jedesmal, wenn ein gewisser grenzwert uunterschritten wird, gibts einen alarm.
normalerweise haben diese batterien um die 3,2 volt. dieses board misst aber immer irgendwas zwischen 2,1 und 3,2 volt. da sonst keine maengel feststellbar sind, habe ich kurzerhand die grenzwerte fuer die batterie (sensor VBAT) angepasst. damit ichs nicht wieder lange suchen muss, hier einfach mal verewigt. das tool der wahl heisst “ipmitool”. so werden die werte gesetzt:
root@node:~# ipmitool sensor thresh "VBAT" lnr "1.992" Locating sensor record 'VBAT'... Setting sensor "VBAT" Lower Non-Recoverable threshold to 1.992 root@node:~# ipmitool sensor thresh "VBAT" lcr "2.016" Locating sensor record 'VBAT'... Setting sensor "VBAT" Lower Critical threshold to 2.016 root@node:~# ipmitool sensor thresh "VBAT" lnc "2.016" Locating sensor record 'VBAT'... Setting sensor "VBAT" Lower Non-Critical threshold to 2.016 |
und so schaut man sich die eingestellten und gemessenen werte an:
root@node:~# ipmitool sensor get "VBAT" Locating sensor record... Sensor ID : VBAT (0x50) Entity ID : 7.1 (System Board) Sensor Type (Threshold) : Voltage (0x02) Sensor Reading : 2.640 (+/- 0) Volts Status : ok Nominal Reading : 3.312 Normal Minimum : 2.976 Normal Maximum : 3.648 Upper non-recoverable : 3.696 Upper critical : 3.672 Upper non-critical : 3.648 Lower non-recoverable : 1.992 Lower critical : 2.016 Lower non-critical : 2.016 Positive Hysteresis : 0.024 Negative Hysteresis : 0.024 Minimum sensor range : Unspecified Maximum sensor range : Unspecified Event Message Control : Per-threshold Readable Thresholds : lnr lcr lnc unc ucr unr Settable Thresholds : lnr lcr lnc unc ucr unr Threshold Read Mask : lnr lcr lnc unc ucr unr Assertion Events : Assertions Enabled : lnc- lcr- lnr- unc+ ucr+ unr+ Deassertions Enabled : lnc- lcr- lnr- unc+ ucr+ unr+ |
APC AP7920 + ssh: no matching key exchange method found
“professionelles” euqipment fuer betrieb in rechenzentren ist ja auch eine art IoT. und genauso schlecht wie bei billigen plaste gadgets ist auch die software darauf. (naja ok, vielleicht nicht ganz so schlecht und der fokus liegt auch auf nuetzlichen features als auf design, aber wenn so ein geraet ssh kann, sollte man auch bei einer firmware von 2016 eine vernuenftige ssh implementierung erwarten.)
auf jeden fall gehts hier um eine PDU von APC mit der modelnummer AP7920. da meckert mein ubuntu beim versuch mich damit ueber ssh zu verbinden:
no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 |
…dann muss man dem ssh client halt sagen:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 1.2.3.4 |
..damit das funktioniert
