Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 21 von 47)

Internet gefunden und weiterer Quatsch…

Man was war heute ein fauler Tag… und es war wunderbar. Es passiert mir einfach viel zu selten, dass ich mal so einen richtig faulen und sinnfreien Tag habe 🙂

Spät aufgestanden, Frühstück war vorbereitet, Internet von Level3 gefunden, die Katze mit einem Foto geweckt (er hasst das :-P), für Autohaus die Reifendaten eingesammelt, etwas vorm Schallplattenspieler herumgelegen, den Hund sowie mich bewegt, ein Upgrade am FreeNAS gefahren und noch rsync vom Ampache (über eine viel zu langsame Internetverbindung) angeworfen.

Tja Leute…. Jetzt gleich noch Tatort und Bier, dann schön schlafen. Morgen ist ja wieder arbeiten angesagt!

Vielleicht ist es ganz gut, dass man nicht SO viele faule Tage hat. Am Ende wird einem nur Langweilig!

Sabayon Linux – equo / Entropy Geschwindigkeit erhöhen

Die im Standard voreingestellten Optionen vom Entropy sind bei Sabayon nicht ganz optimal, zumindest wenn man hinter einem normalen Internetanschluss sitzt.

Um nun die Downloadgeschwindigkeit etwas zu erhöhen gibt es ein paar Dinge, die man tun kann.

Als erstes sollte man, den für seinen Standort, besten Spiegelserver herausfinden. Dieses erledigt folgender Aufruf:

$ sudo equo repo mirrorsort sabayon-weekly

Voreingestellt für den gleichzeitigen Download sollte 3 sein. Ab einem normalen A-DSL Anschluss darf man diese Zahl gerne auf 10 ändern.

$ sudo vi /etc/entropy/client.conf
multifetch = 10

Oft ist der eigentliche Unterschied zwischen zwei Paketen, bei einem Upgrade, eher gering. Daher macht es Sinn sich auch nur diesen Unterschied herunter zu laden:

$ sudo vi /etc/entropy/client.conf
packages-delta = enable

So, viel Spaß!

Temperaturmessung mit dem Raspberry Pi und DHT22-Sensor

Meine Wetterstation hat aufgegeben 🙁 OK, wirklich interessant war für mich immer nur Luftfeuchtigkeit und Temperatur draußen. Diese Aufgabe sollte doch von meinem Raspberry Pi erfüllt werden können, oder? Dann hätte ich die Daten zusätzlich direkt in meinem Cacti!

Ich setzte dabei auf den DHT22 / AM2302. Über Amazon war dieser für 2€ schnell bestellt. Ein 4,7kΩ Widerstand hatte ich selbstverständlich noch. Das eigentliche Schaltbild ist nicht weiter der Rede wert, ich habe da ein Bild für euch weiter unten…

Zur Software…

Nötig ist git für wiringPi und lol_dht22

Erstmal eine root Konsole auf dem Raspberry Pi öffnen:

$ sudo /bin/bash

Alle Tools für git installieren:

$ apt-get install git-core

Dann einen clone von wiringPi ziehen und kompilieren:

$ git clone git://git.drogon.net/wiringPi
$ cd wiringPi
$ ./build
$ cd ..

Jetzt noch schnell lol_dht22, dieses Programm liest den eigentlichen Sensor aus.

$ git clone https://github.com/technion/lol_dht22
$ cd lol_dht22
$ ./configure
$ make

Damit sollte sich bereits der Sensor auslesen lassen:

$ ./loldht 7
Raspberry Pi wiringPi DHT22 reader
www.lolware.net
Data not good, skip
Humidity = 73.90 % Temperature = 9.30 *C

Perfekt 😀 Nun benötige ich natürlich nur die beiden Zahlen. Daher habe ich den Code etwas angepasst. So bekomme ich jetzt nur noch die beiden Werte beim Aufruf:

$ /lol_dht22/loldht 7
73.90
9.30

Diese sammle ich nun per Bash-Script über einen Cron-Job ein und lege sie in zwei Files.

$ crontab -l
* * * * * /var/scripts/getsensor.sh

Hier das vom Cron aufgerufene Script:

$ cat /var/scripts/getsensor.sh
#!/bin/bash

/lol_dht22/loldht 7 > /home/pi/both.txt

 
while [ ! -s "/home/pi/both.txt" ]
do
        sleep 5
        /lol_dht22/loldht 7  > /home/pi/both.txt
 
done

sed '2d' /home/pi/both.txt > /home/pi/humid.txt
sed '1d' /home/pi/both.txt > /home/pi/temp.txt

Damit liegen nun immer die aktuellen Werte für Temperatur und Luftfeuchtigkeit in den beiden Textfiles unter /home/pi.

Jetzt sollen diesen Daten natürlich noch per snmp abgerufen werden können, damit ich sie in Cacti einbinden kann. Also zuerst snmp auf dem Raspberry Pi installieren:

$ apt-get install snmp snmpd

Unter „Pass-through“ MIB extension command lege ich nun zwei weitere an, für Temperatur und Luftfeuchtigkeit:

pass .1.3.6.1.2.1.25.1.8.2      /bin/sh         /usr/local/bin/temp
pass .1.3.6.1.2.1.25.1.8.1      /bin/sh         /usr/local/bin/humid

Wird nun per snmp diese OID abgefragt, wird das zugehörige Script ausgeführt:

$ cat /usr/local/bin/temp
#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.2
echo gauge
cat /home/pi/temp.txt
$ cat /usr/local/bin/humid
#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.1
echo gauge
cat /home/pi/humid.txt

Als kleiner Test:

$ snmpget -c public -v1 errorpi .1.3.6.1.2.1.25.1.8.1
iso.3.6.1.2.1.25.1.8.1 = Gauge32: 76

$ snmpget -c public -v1 errorpi .1.3.6.1.2.1.25.1.8.2
iso.3.6.1.2.1.25.1.8.2 = Gauge32: 9

Dieses lässt sich nun im Cacti einbinden und so aufzeichnen. Ok, etwas von hinten durch die Brust ins Auge… Sicher optimiere ich dieses noch 😀

Ach ja,  wer es braucht… Die Template-Exports für Cacti sind hier: cacti-temp.tar.gz


Und wohin mit dem Teil? Diese Frage hat mich etwas beschäftigt. Ich wollte es draußen haben, denn ich brauche ja die Daten von draußen 😀 Dafür muss es geschützt vor Wasser sein. Um die Luftfeuchtigkeit messen zu können darf es denn noch nicht komplett verschlossen sein. Ebenfalls sollte es an einer Stelle hängen, an welcher es nicht zu schlecht aussieht und vor allem, an welcher es nicht zerstört wird.

Ich habe einfach ein Rohr genommen, den Sensor dort mit etwas Silikon „eingeklebt“ und das Rohr an einer Seite mit einem Deckel verschlossen. So sollte kein Wasser an den Sensor laufen können. Angebracht habe ich dieses Rohr an meinem Pfosten der Satellitenschüssel. Dort oben „steht“ die Luft eher selten und es kommt niemand ran. Zusätzlich fällt es dort nicht weiter auf.

Mal abwarten wie es sich dort oben macht. Vielleicht hänge ich es später noch mal um! Sobald sich die eigentliche Position gefestigt hat, wird dann auch der Raspberry PI ordentlich verstaut ;-P


Jabber – 404 remote server not found – Openfire

Nachdem ich nun für die S2S-Verbindungen TLS erzwinge, sind ein paar Openfire User zu mir gekommen und beklagen sich darüber, dass ihre User im Client ein: „404 remote server not found“ bekommen.

Verbindungen/Nachrichten in die eine Richtung gehen durch und wenn die Unterhaltung einmal gestartet ist, „klappt“ es dann auch für eine gewisse Zeit. Ich muss zugeben, ein etwas spannender Effekt, welchen einen nicht direkt auf die Lösung des Problem bringt. Das Problem liegt nicht an meinem Jabber Server und nicht an meinen DNS Einstellungen. Es hängt tatsächlich am Openfire auf der Gegenseite. Java 6 fehlt im Keystore das Intermediate Zertifikat von StartSSL. Mein Server sendet es zwar mit, denn noch bekommt es Java 6 und einige Versionen 7 wohl nicht hin, die Kette korrekt zu bauen. Im Openfire warn.log finden sich dann Meldungen wie:

warn.log.1:2014.11.18 08:00:48 org.jivesoftware.openfire.server.ServerDialback - Error verifying key of remote server: jabber.kernel-error.de
warn.log.1:2014.11.18 08:00:48 org.jivesoftware.openfire.server.ServerDialback - ServerDialback: OS - Ignoring unexpected answer in validation from: kernel-error.de id: 1234567890 for domain: JABBERDOMAIN answer:<stream:features xmlns:stream="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></stream:features>

Erschlagen lässt sich dieses Problem, indem der Admin des Openfire-Systems einfach das Intermediate Zertifikat der CA in seinen Keystore packt. Wie? so…

Zuerst in den default Ordner des Openfire auf einem Debian System wandern und dann den Openfire zur Sicherheit beenden:

$ cd /etc/openfire/security/
$ /etc/init.d/openfire stop

Jetzt das Zertifikat von der Webseite der CA herunterladen und es importieren:

$ wget "http://www.startssl.com/certs/sub.class2.server.ca.crt"
$ keytool -import -keystore truststore -alias startcom.ca.sub2 -file sub.class2.server.ca.crt
Enter keystore password:  
Certificate was added to keystore

Default Kennwort ist: changeit

Wenn man schon dabei ist, kann man (sofern gewünscht) auch direkt die Zertifikate von CAcert.org importieren. Viele Systeme nutzen diese:

$ wget "http://www.cacert.org/certs/root.crt"
$ keytool -import -keystore truststore -alias CAcert.root.ca -file root.crt
Enter keystore password:  
Certificate already exists in keystore under alias <CAcert.root.ca>
Do you still want to add it? [no]:  no
Certificate was not added to keystore

$ wget "http://www.cacert.org/certs/class3.crt"
$ keytool -import -keystore truststore -alias CAcert.Class3.sub.ca -file class3.crt
Enter keystore password:  
Certificate was added to keystore

Ist eines der Zertifikate bereits vorhanden, macht es natürlich keinen Sinn dieses zu überschreiben, sofern es kein Problem mit diesem gibt.
Als letzten Schritt einfach Openfire wieder starten.

$ /etc/init.d/openfire start

Ab jetzt sollte es dann zu keinen hässlichen Logmeldungen mehr führen und alle können wieder schreiben 🙂

So long….


* U-P-D-A-T-E *

Da die Frage inzwischen schon vier mal bei mir angekommen ist… Wie testet man denn ob das Intermidiate Zertifikate überhaupt korrekt mit übergeben wird? Ganz einfach mit openssl 🙂

Spannend ist hier die Zeile: Verify return code: 0 (ok)

Steht hier etwas anderes, gibt es ein Problem.

$ openssl s_client -showcerts -connect jabber.kernel-error.de:5222 -starttls xmpp
CONNECTED(00000003)
depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 2 Primary Intermediate Server CA
verify return:1
depth=0 description = pViXGk1aRdP23kII, C = DE, ST = Nordrhein-Westfalen, L = Hattingen, O = Sebastian Van De Meer, CN = jabber.kernel-error.de, emailAddress = postmaster@kernel-error.de
verify return:1
---
Certificate chain
 0 s:/description=pViXGk1aRdP23kII/C=DE/ST=Nordrhein-Westfalen/L=Hattingen/O=Sebastian Van De Meer/CN=jabber.kernel-error.de/emailAddress=postmaster@kernel-error.de
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
-----BEGIN CERTIFICATE-----
MIIG4zCCBcugAwIBAgIDAjIFMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg
MiBQcmltYXJ5IEludGVybWVkaWF0ZSBTZXJ2ZXIgQ0EwHhcNMTQwNTE4MTU0NTU2
WhcNMTYwNTE4MTgwOTMwWjCBxjEZMBcGA1UEDRMQcFZpWEdrMWFSZFAyM2tJSTEL
MAkGA1UEBhMCREUxHDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xEjAQBgNV
BAcTCUhhdHRpbmdlbjEeMBwGA1UEChMVU2ViYXN0aWFuIFZhbiBEZSBNZWVyMR8w
HQYDVQQDExZqYWJiZXIua2VybmVsLWVycm9yLmRlMSkwJwYJKoZIhvcNAQkBFhpw
b3N0bWFzdGVyQGtlcm5lbC1lcnJvci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAKJmXUJxwqipigjZf5cdLCMLcyThMO0Jtl7liZbh5Mxklho/NONN
PFdOT4thBG63SDol7XJm3ke1MJLZJeaaYXXXUo5aEQ8U1DGImSerfs8cexLFAczo
qc8c6Jm5x2wXhDIxpU7zaL9duX1gaJ8mbNiX+xoNUdx9QIENlXz/xdtVu0l95McK
Esrk3OZ11wyF1GSnFJtAQNC9Bn7fPV4kArZdh/OV+0tTUpM+EMG8PR2iQg6uVvhN
TNwzRKrxTVClmBRLyeT10Nhjt3rkB+bhGCWbXVtwitS3mlMEL7QoNPj7iRbIOUfF
TheJJ3x3PjxfmAubpfo/ndsGjV2c/jw2OmMCAwEAAaOCAxAwggMMMAkGA1UdEwQC
MAAwCwYDVR0PBAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAd
BgNVHQ4EFgQU/3ZeNF1M/zhTpWBrad0YI7q3BGAwHwYDVR0jBBgwFoAUEdsjRf1U
zGpxb4SKA9e+9wEvJoYwTAYDVR0RBEUwQ4IWamFiYmVyLmtlcm5lbC1lcnJvci5k
ZYIPa2VybmVsLWVycm9yLmRlghgqLmphYmJlci5rZXJuZWwtZXJyb3IuZGUwggFW
BgNVHSAEggFNMIIBSTAIBgZngQwBAgIwggE7BgsrBgEEAYG1NwECAzCCASowLgYI
KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcG
CCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5
MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRv
IHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy
dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw
dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdh
dGlvbnMuMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t
L2NydDItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0
cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvc2VydmVyL2NhMEIGCCsG
AQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3My
LnNlcnZlci5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5j
b20vMA0GCSqGSIb3DQEBBQUAA4IBAQBcMcSJxbr52s1gzaH7zjh0FfveuiTvPIZY
enV1UxoPZLeFMAIUsZf2h/hGTXDNhH48bcF8eRcbMnPhS8xQPEXSNd7yFtPnpE6c
3jdjE6+Fm3Rd6MZ8BIruB98T8cc74LK3NoWxdnJNLs3+D2W2lMUjpCUgggHSNoOt
d73lXFYSxbu7+lOIE/w0oQeYKD6/aGGgZFaUdM2B1OHEz2z9skhQgFJkM6aAFK03
sH4KaYnwdnyNpuS8XpPhmrQ6KMZBQMi43TcH3mQtgTUXjZOC7i8ZSLzAtg0mdqSy
CJqfAKS6X/7ARyMHNNlZWDWXRuScs2k7x58afIx60MTp50SFSB4F
-----END CERTIFICATE-----
 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
MIIGNDCCBBygAwIBAgIBGjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjA1NzA5WhcNMTcxMDI0MjA1NzA5WjCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4k85L6GMmoWtCA4IPlfyiAEh
G5SpbOK426oZGEY6UqH1D/RujOqWjJaHeRNAUS8i8gyLhw9l33F0NENVsTUJm9m8
H/rrQtCXQHK3Q5Y9upadXVACHJuRjZzArNe7LxfXyz6CnXPrB0KSss1ks3RVG7RL
hiEs93iHMuAW5Nq9TJXqpAp+tgoNLorPVavD5d1Bik7mb2VsskDPF125w2oLJxGE
d2H2wnztwI14FBiZgZl1Y7foU9O6YekO+qIw80aiuckfbIBaQKwn7UhHM7BUxkYa
8zVhwQIpkFR+ZE3EMFICgtffziFuGJHXuKuMJxe18KMBL47SLoc6PbQpZ4rEAwID
AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYD
VR0OBBYEFBHbI0X9VMxqcW+EigPXvvcBLyaGMB8GA1UdIwQYMBaAFE4L7xqkQFul
F2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDov
L29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0
c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0
BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl
LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEAnQfh7pB2MWcWRXCMy4SLS1doRKWJwfJ+
yyiL9edwd9W29AshYKWhdHMkIoDW2LqNomJdCTVCKfs5Y0ULpLA4Gmj0lRPM4EOU
7Os5GuxXKdmZbfWEzY5zrsncavqenRZkkwjHHMKJVJ53gJD2uSl26xNnSFn4Ljox
uMnTiOVfTtIZPUOO15L/zzi24VuKUx3OrLR2L9j3QGPV7mnzRX2gYsFhw3XtsntN
rCEnME5ZRmqTF8rIOS0Bc2Vb6UGbERecyMhK76F2YC2uk/8M1TMTn08Tzt2G8fz4
NVQVqFvnhX76Nwn/i7gxSZ4Nbt600hItuO3Iw/G2QqBMl3nf/sOjn6H0bSyEd6Si
BeEX/zHdmvO4esNSwhERt1Axin/M51qJzPeGmmGSTy+UtpjHeOBiS0N9PN7WmrQQ
oUCcSyrcuNDUnv3xhHgbDlePaVRCaHvqoO91DweijHOZq1X1BwnSrzgDapADDC+P
4uhDwjHpb62H5Y29TiyJS1HmnExUdsASgVOb7KD8LJzaGJVuHjgmQid4YAjff20y
6NjAbx/rJnWfk/x7G/41kNxTowemP4NVCitOYoIlzmYwXSzg+RkbdbmdmFamgyd6
0Y+NWZP8P3PXLrQsldiL98l+x/ydrHIEH9LMF/TtNGCbnkqXBP7dcg5XVFEGcE3v
qhykguAzx/Q=
-----END CERTIFICATE-----
---
Server certificate
subject=/description=pViXGk1aRdP23kII/C=DE/ST=Nordrhein-Westfalen/L=Hattingen/O=Sebastian Van De Meer/CN=jabber.kernel-error.de/emailAddress=postmaster@kernel-error.de
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 4537 bytes and written 612 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 98D942E7D6BD132AE7E19F13AFBE5C0C7A2F4CA651B9679B98E200A841572ABE78BB43B5572C1929B2423EC61008BBDD
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1416399042
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=0

Neue dnssec KSKs

Ich habe nach längerem dann mal meinen KSK für´s dnssec getauscht. Bzw. ich bin gerade dabei 🙂

Der alte war noch ein 1024bit NSEC3RSASHA1. Jetzt ist auch klar warum er getauscht werden musste 😛 Der neue ist nun ein NSEC3RSASHA1 mit 4096bit. Als zweiten neuen Key habe ich einen RSASHA512 mit ebenfalls 4096bit erstellt. So habe ich für den Fall der Fälle auch direkt einen ohne SHA1 im „Anschlag“.

Dieser neue Key ersetzt in Kürze den alten 1024bit KSK Schlüssel. Bereits jetzt sollte es aber für jeden nur noch über den 4096bit NSEC3RSASHA1 Schlüssel laufen.

Inzwischen sollte wohl jede halbwegs aktuelle Software mit dnssec Support mit diesen Schlüsseln umgehen können. Wenn nicht, wird es Zeit für ein Update 😀

In diesem Sinne!


* U-P-D-A-T-E *

Inzwischen ist auch der andere Schlüssel oben und sollte sich so langsam durch die Welt sprechen….

http://dnsviz.net/d/kernel-error.de/dnssec/

http://dnsviz.net/d/kernel-error.org/dnssec/

http://dnsviz.net/d/kernel-error.com/dnssec/

Strom mit dem Raspberry Pi und dem Eltako DSZ12E-3x80A. Aber bitte mit Cacti Graphen.

In meinem Keller werkelt noch einer von den ganz alten Stromzählern mit Scheibe 🙂 Dieser zählt zwar ganz brav für meinen Stormversorger den Stromverbrauch in meinem Haus, hat aber leider keine Möglichkeit mir das Gezählte digital zur Verfügung zu stellen. Jetzt würde mich dieses aber interessieren. Denn ich könnte mir so einige Auswertungen im Cacti vorstellen 😉

Es musste also ein neuer Stromzähler her am besten direkt mit S0 Ausgang. Also habe ich bei meinem Energieversorger angerufen und gefragt, was da geht. Der Mensch am anderen Ende machte zuerst einige komische Geräusche um im Anschluss mit Zahlen um sich zu werfen, bei denen selbst mir die Ohren schlackerten. Die Lösung viel also raus… Also selbst einen Stromzähler kaufen, nur welchen? Ich habe mich für den Eltako DSZ12E-3x80A entschieden und ihn direkt bei http://www.elektro4000.de bestellt (klappt bei den Leuten wunderbar). Er lag bei ca. 75€, was schon eine ganz andere Hausnummer ist, als was mein Energieversorger da vom Stapel gelassen hat.

3 x 80A sollte für den normalen Hausgebrauch locker reichen 🙂 Dieser Zähler darf/kann natürlich den Zähler meines Energieversorgers nicht ersetzten. Er muss also hinter dem offiziellen Zähler eingebaut werden. Dieses darf und sollte nicht jeder machen. Wenn du nicht weißt ob du es darfst, darfst du es auch nicht! Ein Elektriker benötigt dafür ca. 0,5 bis 1h. Mit Anfahrt und Stift sollte sich der Einbau (unabhängig vom Gerät) so um die 100 – 150€ belaufen.

Ich musste für meinen Einbau den Neozed-Sicherungssockel etwas versetzen um Platz zu schaffen. Was soll ich sage? Das Teil war noch aus Keramik und zerbröselte schon beim Anschauen. Sah etwas so aus, als wenn der „Einbauende“ die Leitungen am Sockel gebogen hat :-/ Für mich war also noch ein neuer Sicherungssockel mit allen Einzelteilen nötig. Zugegeben in dem Zuge habe ich kurz über einen Laststrennschalter nachgedacht, nur SO oft fummel ich ja nicht rum.

Lange Rede kurzer Sinn, verbaut ist das Teil schnell und einfach gewesen. Verheiratet mir dem Raspberry ist er auch recht flott, da ich auf folgendes zurückgreifen konnte: http://blog.webernetz.net/2014/10/13/stromzahler-mit-s0-schnittstelle-vom-raspberry-pi-auswerten/

So blieb etwas mehr Zeit am Cati zu pfeilen und noch ein paar mehr SNMP Abfragen zu erstellen, welche mir den Tagesgesamtverbrauch, Wochenverbrauch usw. liefern. Cacti soll ja nicht rechnen müssen 🙂

So long…

FreeBSD ZFS Datensicherung / Backup

Ich muss sicher keinem mehr erzählen, dass ich ein absoluter ZFS Fan bin…. Wie sich Snapshots erstellen und per ssh einfach über das Netzwerk übertragen lassen, habe ich ja bereits vor einigen Jahren beschrieben. In einem Gespräch sind wir vor kurzem auf FlexClone von NetApp gekommen (von wegen Enterprise Storage 😉 ). In diesem Zusammenhang auch irgendwann auf die Art wie ich die Datensicherung auf meinem FreeBSD Notebook machen 🙂

Ich habe einen kleinen Solaris basierten Storageserver. Auf diesen pumpe ich inkrementell das ZFS Home Volume von diesem Notebook. Um euch nicht im Dunkeln zu lassen, beschreibe ich es hier kurz.

Der Ablauf ist im Grunde so:
– Snapshot auf dem Client anlegen.
– Volume auf dem Ziel anlegen.
– Snapshot vom Client per SSH in das Ziel schieben.
– Weitere Snapshots auf dem Client anlegen.
– Die Differenz der Snapshots auf das Volume ins Ziel schieben.

Los gehts!

Erstellen eines Snapshots auf dem Notebook. Dieses definiert damit auch den zu sichernden Stand:

$ zfs snapshot -r tank/usr/home/kernel@-12-10-2014

Nun sollte dieser Snapshot bei einem zfs list aufgelistet werden:

$ zfs list
NAME                                         USED  AVAIL  REFER  MOUNTPOINT
tank                                         107G   109G   144K  none
tank/ROOT                                   8,76G   109G   144K  none
tank/ROOT/beforeUpdate-2014-10-10_20-18-44     8K   109G  5,04G  /mnt
tank/ROOT/beforeUpdate-2014-10-10_21-02-41     8K   109G  5,06G  /mnt
tank/ROOT/beforeUpdate-2014-10-12_17-38-35   136K   109G  8,05G  /mnt
tank/ROOT/default                           8,76G   109G  8,28G  /mnt
tank/ROOT/default@2014-10-10-20:18:44       56,6M      -  5,04G  -
tank/ROOT/default@2014-10-10-21:02:41       31,3M      -  5,06G  -
tank/ROOT/default@2014-10-12-17:38:35        323M      -  8,05G  -
tank/tmp                                     392K   109G   392K  /tmp
tank/usr                                    98,4G   109G   144K  /mnt/usr
tank/usr/home                               97,0G   109G   152K  /usr/home
tank/usr/home/kernel                        97,0G   109G  96,9G 
/usr/home/kernel
tank/usr/home/kernel@-12-10-2014            20,0M      -  96,9G  -
tank/usr/jails                               144K   109G   144K  /usr/jails
tank/usr/obj                                 144K   109G   144K  /usr/obj
tank/usr/pbi                                 144K   109G   144K  /usr/pbi
tank/usr/ports                              1,41G   109G   856M  /usr/ports
tank/usr/ports/distfiles                     582M   109G   582M 
/usr/ports/distfiles
tank/usr/src                                 144K   109G   144K  /usr/src
tank/var                                    9,32M   109G   144K  /mnt/var
tank/var/audit                               160K   109G   160K  /var/audit
tank/var/log                                 356K   109G   356K  /var/log
tank/var/tmp                                8,67M   109G  8,67M  /var/tmp

Sollte ein zfs list keine Snapshots anzeigen, ist dieses sicher beim Pool deaktiviert. In diesem Fall hilft ein:

$ zpool set listsnapshots=on tank

Auf dem Sicherungsziel erstelle ich nun ein neues ZFS Volume, in welches die Sicherung gehen soll:

$ zfs create DatenPool01/Datensicherung/errorlap
$ zfs list DatenPool01/Datensicherung/errorlap
NAME                                  USED  AVAIL  REFER  MOUNTPOINT
DatenPool01/Datensicherung/errorlap   209K  2.56T   209K  /mnt/DatenPool01/Datensicherung/errorlap

Nun kann ich bereits den erstellten Snapshot in dieses neue Volume schieben:

$ zfs send -R tank/usr/home/kernel@-12-10-2014 | ssh
root@solaris-storage.kernel-error.de zfs receive -Fduv DatenPool01/Datensicherung/errorlap
The authenticity of host 'solaris-storage.kernel-error.de (192.168.10.10' can't be
established.
ECDSA key fingerprint is ec:c0:e6:ed:81:b4:16:35:e9:c6:22:f0:a7:f7:ed:d6.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'solaris-storage.kernel-error.de' (ECDSA) to the list of known
hosts.
root@solaris-storage.kernel-error.de's password:
receiving full stream of tank/usr/home/kernel@-12-10-2014 into
DatenPool01/Datensicherung/errorlap/usr/home/kernel@-12-10-2014
received 98.4GB stream in 5298 seconds (19.0MB/sec)

Ist dieses durch, sollte man dieses natürlich am Ziel auch erkennen können:

$ zfs list DatenPool01/Datensicherung/errorlap
NAME                                  USED  AVAIL  REFER  MOUNTPOINT
DatenPool01/Datensicherung/errorlap  97.0G  2.47T   221K  /mnt/DatenPool01/Datensicherung/errorlap

Jetzt ist also bereits eine Vollsicherung im Ziel angekommen. Die weiteren Sicherungen sollen/können nun inkrementell erfolgen. Dazu erstelle ich einen weiteren Snapshot:

$ zfs snapshot -r tank/usr/home/kernel@-12-10-2014-02

Nun kann ich die Differenz dieser beiden Snapshots ins Ziel schieben:

$ zfs send -R -i tank/usr/home/kernel@-12-10-2014
tank/usr/home/kernel@-12-10-2014-02 | ssh root@solaris-storage.kernel-error.de zfs
receive -Fduv DatenPool01/Datensicherung/errorlap
root@solaris-storage.kernel-error.de's password:
Permission denied, please try again.
root@solaris-storage.kernel-error.de's password:
receiving incremental stream of tank/usr/home/kernel@-12-10-2014-02 into
DatenPool01/Datensicherung/errorlap/usr/home/kernel@-12-10-2014-02
received 991MB stream in 59 seconds (16.8MB/sec)

Somit liegt im Ziel nun eine aktuelle Datensicherung. Dieses lässt sich nun natürlich per Script automatisieren und vor allem alle 15 Minuten erstellen, sofern gewünscht! So lassen sich natürlich auch Vollsicherungen des kompletten Notebooks erstellen 🙂

B.t.w.1: NetApp stelle ich hiermit sicher nicht in Frage. Spitzen Produkte, gut durchdacht und toller Service.

B.t.w.2: PC-BSD bietet ein Stück Software mit dem Namen Life Preserver. Mit dessen Hilfe kann man die Snapshots auf seinem kompletten Pool managen und diesen recht einfach per SSH mit einem anderen ZFS System syncen. So zum Beispiel auch mit FreeNAS. Alles lässt sich damit komplett automatisieren. So kann man alle 15 Minuten per SSH seinen kompletten Pool auf sein ZFS Backup schieben. Mit passenden Internetanbindung von überall auf der Welt transparent. Stirbt das System, kann man mit einer Boot CD und einer neuen Platte ganz flott alles wiederherstellen, egal wo man gerade ist 😀 

Fragen? Dann fragen!

Alternative SPF-RECORDS im DNS

Da ich es gerade mal wieder auf dem Tisch habe…. Ja, „früher“ konnte man verschiedene RECORDS im DNS setzten um SPF-RECORDS zu veröffentlichen. So auch einen Record Type mit dem direkten Namen SPF. Seit 2014 ist dem aber nicht mehr so! Denn ab jetzt soll man seine SPF-Records nur noch als TXT-Record (RFC1035 Typ 16) veröffentlichen. Dieses steht im fertigen RFC7208 Abschnitt 3.1.

Damit also bitte die ganzen anderen RECORDS zu SPF aus dem DNS entfernen und nur noch TXT-RECORDS einsetzten. Ich freue mich darüber, denn bisher musste man sonst eine Vielzahl verschiedener Records pflegen, da man sich nicht sicher sein konnte, welchen jetzt bitte die Implementierung des Empfängers nutzt. Zugegeben, die Basis TXT war die am meisten verbreitete Version. Denn noch gab es da hin und wieder ein Problem 🙂 Nun steht das RFC bereits einige Zeit fest, und ich habe alle anderen „SPF-RECORDS“ aus dem DNS entfernt. Nun also nur noch TXT bei mir 😀

So long

Notebook Akku def.

Das ist doch nicht zu glauben 🙁 Mein Notebook Akku ist im Eimer!

Für einen passenden neuen muss ich knapp 100/120€ auf den Tisch legen. Klar, irgendwann gibt ein Akku halt mal auf… Nur dieser hat besonders schnell aufgegeben. Nach knapp 2,5 Jahren ist er nun tot. Die letzten haben im Schnitt 3 – 4 Jahre bei mir gehalten. Meine Art mit den Notebook zu arbeiten ist dabei fast unverändert. Na ja, der Stromverbrauch ist denn noch nicht ohne, daher mache ich dem Akku mal keinen Vorwurf. Große CPU, viel Speicher, zwei Festplatten, 17″ (ja, ich renne mit so einem riesigen Schläptop herum).

 

[kernel@errorlap:~]$ acpiconf -i 0
Design capacity:        5200 mWh
Last full capacity:     2093 mWh
Technology:             primary (non-rechargeable)
Design voltage:         14800 mV
Capacity (warn):        0 mWh
Capacity (low):         0 mWh
Low/warn granularity:   100 mWh
Warn/full granularity:  0 mWh
Model number:           BAT0
Serial number:          123456789
Type:                   LiON
OEM info:               PTL
State:                  high 
Remaining capacity:     97%
Remaining time:         unknown
Present rate:           0 mW
Present voltage:        16403 mV

 

In diesem Sinne… Werde ich wohl mal einen Ersatzakku bestellen, oder gleich ein neues Notebook? Ach ich bin da noch etwas unschlüssig. Das Gerät selbst ist noch ganz gut, hat aber schon einiges geleistet…

Kein Jabber/XMPP mehr ohne Transportverschlüsselung

Hallo zusammen,

wie ja bereits vor einiger Zeit angekündigt, habe ich heute TLS als Transportverschlüsselung zwischen den Server to Server Verbindungen erzwungen. Für die Clients s2c besteht dieser Zwang bereits seit langem, nun also auch für die Verbindungen zwischen der Server.

Ich habe mir natürlich vorher die Mühe gemacht, andere Serverbetreiber anzuschreiben, wenn ich zu ihnen keine verschlüsselte s2s Verbindung aufbauen konnte. Ein paar sind aktiv geworden, ein paar nicht. Die Anzahl der nicht verschlüsselten s2s Verbindungen ist denn noch verschwindend gering! Ich habe diese Verbindungen also hiermit bewusst „abgehängt“.

Sollte ihr also aktuell Probleme mit der Verbindung zu oder von meinem System haben, bitte einfach melden!

So long…

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑