Kategorie: Kernel-Error-Blog (Seite 22 von 48)

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

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…

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!

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

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…

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…

Um zu verstehen was mit reverse map delegation von IPv4 und IPv6 Adressen nach RFC 2317 (http://tools.ietf.org/html/rfc2317) gemeint ist, hilft es zu verstehen warum man es überhaupt braucht. Daher versuche ich mit meiner kurzen Erklärung damit zu starten….

Wenn man in der „guten alten Zeit“ des Internets ein paar öffentliche IPv4 Adresse brauchte, ging man zu seiner RIR und bekam ein /24 in die Hand.

Als Beispiel: 1.2.3.0/24 also mit der Netzmaske 255.255.255.0

So hatte man ein Netz mit 256 Adressen. Wenn man nun in seinem DNS eine Zone für die PTR-Records anlegen wollte, war es kein Problem. Man konnte ja ohne große Probleme die Zone 3.2.1.in-addr.arpa. anlegen und die Zone konnte alle 256 Adressen beinhalten und beantworten.

Inzwischen sind die IPv4 Adresse aber knapp, oder sagen wir besser… verbraucht! Man bekommt, wenn überhaupt, nur noch so viele, wie man auch gut begründen kann 🙂

Als Beispiel: 1.2.3.0/29 also mit der Netzmaske 255.255.255.248

So hat man ein kleines Netz mit 8 Adressen. Will man nun in seinem DNS eine Zone für die PTR-Records anlegen gibt es ein Problem. Denn im DNS macht man die einzelnen Domains, Subdomains usw. am Punkt fest!

Als Beispiel: www.kernel-error.de.

de ist dabei die Subdomain von der Root-Domain (.)
kernel-error ist demnach die Subdomain der TLD (de)
www ist nun die Subdomain/Hostadresse von (kernel-error)

Möchte ich also eine Zone für ein IP Netz mit der Netzmaske /24 – 255.255.255.0 anlegen, ist ein kein Problem da ich ja einfach den letzten Punkt als Trenner für meine DNS-Zone nutzen kann. Alle 256 möglichen IPv4 Adressen würden dann von dieser Zone bedient werden können. Bei einem /29 habe ich aber keine Möglichkeit die Zone auf die 8 möglichen IP-Adressen zu beschränken…

Natürlich könnte ich nun denn noch eine Zone anlegen, wie auch bei einem /24 und halt nur meine 8 IP-Adressen (6 Hostadressen). Dann gibt es aber zwei Probleme! 1. Dieser DNS Server würde sich auch für die anderen Adressen zuständig fühlen und falsche Antworten liefern. 2. Wird ein Netz vergeben muss dort auch ein zuständiger DNS Server für das Netz eingetragen werden. Ihr seht schon… das wird nix!

Was macht man also? Ganz einfach und sicher vielen bereits bekannt… Der Provider/Hoster oder oder übernimmt die DNS-Zone für das Netz. Seine Kunden müssen also alle Wünsche über die zu setzenden RECORDS bei diesem anfragen oder über ein Webinterface eintragen. Dieses ist ein gangbarer Weg… Leider ist es hin und wieder etwas zu unflexibel und/oder zu zeitintensive. Ebenso gibt es ja Menschen die ihren DNS-Server gerne selbst unter Kontrolle haben, richtig?

Genau hier kommt dieses reverse map delegation ins Spiel. Zwar ist der im Netz eingetragene DNS Server noch immer der vom Provider… Dieser setzt aber keinen echten Hostename mehr zu den einzelnen IP Adressen, sondern einen CNAME zu einem in der DNS Domain des Kunden. So kann der Kunde die „PTR-RECORDS“ für seine IP Adressen über einen kleinen Umweg denn noch selbst setzten. Das ist schon die ganze Magie hinter diesem Begriff….

Wie sieht es nun in der Praxis aus? Ich bleibe bei meinem Beispiel des Netzes 1.2.3.0/29 und beschreibe wie ich es in er Regel einrichte….

Die Zone des /24 würde damit wie folgt aussehen:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@ 1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701      ; serial
              6H              ; refresh
              30M             ; retry
              2W              ; expiry
              1D )            ; minimum

            IN NS  ns1.kernel-error.de.
            IN NS  ns2.kernel-error.org.

0/29        IN NS    ns1.vandemeer.de.
0/29        IN NS    ns2.vandemeer.de.
0           IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1           IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2           IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3           IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4           IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5           IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6           IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7           IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Wie zu erkennen, ist die Zone zuständig für 1.2.3.0-255… Die DNS Server sind dabei (ns1.kernel-error.de und n2.kernle-error.org). Das erste /29 aus diesem /24 gehört dem Kunden hinter der Domain vandemeer.de. Es wird also eine „Subdomain“ angelegt mit dem Namen 0/29. Die 0 steht dabei für die Netzadresse des Netzes und die 29 für die CIDR Suffix. Diese „Subdomain“ wird von den DNS Servern ns1.vandemeer.de und ns2.vandemeer.de bedient. Damit nun alle angefragten PTR-RECORDS für dieses Netz auch an den DNS-Server des Kunden weiter gehen, muss für jede IP Adresse ein CNAME für eine Adresse in der neuen Zone des Kunden erstellt werden.

Für die IPv4-Adresse 1.2.3.4 wäre es also:

4           IN CNAME 4.0/29.3.2.1.in-addr.arpa.

Eine Abfrage mit dig würde jetzt bereits folgende Antwort liefern:

$ dig -x 1.2.3.4

; <<>> DiG 9.10.1 <<>> -x 1.2.3.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47287
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;4.3.2.1.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
4.3.2.1.in-addr.arpa. 10799 IN    CNAME   4.0/29.3.2.1.in-addr.arpa.

;; Query time: 103 msec
;; SERVER: 192.168.10.1#53(192.168.10.1)
;; WHEN: Fr Okt 17 10:59:19 CEST 2014
;; MSG SIZE  rcvd: 106

Jetzt kann der Kunde auf seinem DNS Server die folgende PTR-Zone einrichten:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@ 1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701      ; serial
              6H              ; refresh
              30M             ; retry
              2W              ; expiry
              1D )            ; minimum

            IN NS  ns1.vandemeer.de.
            IN NS  ns2.vandemeer.de.

0           IN PTR netzadresse.vandemeer.de.
1           IN PTR router.vandemeer.de.
2           IN PTR mailin.vandemeer.de.
3           IN PTR imap.vandemeer.de.
4           IN PTR webserver.vandemeer.de.
5           IN PTR frei.vandemeer.de.
6           IN PTR frei.vandemeer.de.
7           IN PTR broadcastadresse.vandemeer.de.

Startet man nun die gleiche dig Abfrage, bekommt man die vollständige und gewünschte Antwort:

$ dig -x 1.2.3.4

; <<>> DiG 9.10.1 <<>> -x 1.2.3.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47287
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;4.3.2.1.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
4.3.2.1.in-addr.arpa. 10799 IN    CNAME   4.0/29.3.2.1.in-addr.arpa.
4.0/29.3.2.1.in-addr.arpa. 14399 IN PTR  webserver.vandemeer.de.

;; Query time: 103 msec
;; SERVER: 192.168.10.1#53(192.168.10.1)
;; WHEN: Fr Okt 17 10:59:19 CEST 2014
;; MSG SIZE  rcvd: 106

Es klingt und sieht also mal wieder komplizierter aus als es ist!

Probleme?

Ja es gibt auch Probleme! Wäre ja zu schön, wenn nicht 😀

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein. Nur halt für diesen speziellen Fall! Das RFC ist nun von 1998… Denn noch scheint es sich nicht sonderlich „herumgesprochen“ zu haben. Ich möchte damit sagen, dass es immer mal wieder bei Problemen dazu kommen kann, dass man seinem Gegenüber zuerst das RFC 2317 erklären muss, bevor es weiter geht 🙂

Ebenfalls macht Postfix ärger, wenn man folgende smtpd restrictions gesetzt hat: reject_unknown_client

Denn diese prüft ob helo / PTR und A/AAAA zueinander passen. Nutzt man reverse map delegation, werden diese nicht zueinander passen!

Oct  17 10:00:00 mx30 postfix/smtp[54786]: FFCC569824: host mx.example.org[4.5.6.7] said: 450 4.1.7 <super@maildomain.de>: Sender address rejected: unverified address: host mail.rennboot.de[3.4.5.6] said: 450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7] (in reply to RCPT TO command) (in reply to RCPT TO command)

Betreibt man also einen größeren Mailserver, vermeidet es Arbeit und Ärger, wenn man auf dieser IPv4 Adresse kein reverse map delegation einsetzt.

Tja… Fragen? Dann wie immer: fragen! 😀

Kaum schreibe ich etwas zur Datensicherung meines FreeBSD Notebooks, schon kommt die Frage, wie ich einen/meinen Linux Desktop sichern würde….

Um es kurz zu machen, ich nutze dazu seit langem bereits das Programm backintime. Es arbeitet mit rsync und hardlinks ebenfalls bietet es die Möglichkeit seine Sicherungen auf alle möglichen Ziele zu schieben, so auch per SSH nach irgendwo.

Wer rsnapshot für Unix Server kennt… Es ist so ähnlich nur bei Bedarf mit GUI. Zusätzlich lässt sich noch schnell und einfach etwas Krypto ins Spiel bringen. Die Datensicherungen lassen sich so sehr schnell und vor allem einfach erstellen und wiederherstellen. Probiert es einfach mal!

Fragen? Dann fragen 🙂