Datenhaufen zu IT und Elektronik.

Kategorie: Self-Hosting & Infrastruktur (Seite 6 von 10)

Apache 2.4 und Diffie-Hellman DHE mit 4096bit

Kaum geht mein Artikel zur erweiterten Sicherheit meiner Webseite online >>TLS Sicherheit weiter verschärft….<< schon kommen Fragen. Eine habe ich nun schon vier mal bekomme, daher hier direkt die Antwort. Ach ja, die Frage:

Wie habe ich meinen Apache dazu überredet DHE-Keys mit 4096bit zu benutzen?

Also… Der Apache beherrscht seit Version 2.4 Diffie Hellman mit mehr als 1024bit. Um dieses nutzen zu können, muss der Apache die passenden dh-params haben. Der Apache nutzt dabei automatisch die ihm gegebene Key stärke.

Ich generiere den DH Teil gerne direkt mit dem jeweiligen Zertifikat und verbinde dieses. Beschrieben habe ich es hier: >>Sicheres SSL / TLS Zertifikat<<

Wer gerne nachträglich generieren möchte macht es mir:

$ openssl gendh 4096 > dh_4096.pem

Dieses lässt sich nun einfach wie ein normales Zertifikat mit in die Konfiguration des Apachen einbinden. Im Grunde nichts besonders und nachdem man es gelesen und absolut einleuchtend, man sucht aber dann doch zuerst etwas.

Viele andere Dienste (Postfix usw…) bringen ja meist einen eigenen Konfigurationspunkt dafür mit. Im Apache liegt es ohne große Konfiguration in Zertifikatsnähe 🙂

easy

So long….

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

DNSSEC: KSK auf 4096-Bit aktualisieren und SHA-512 vorbereiten​

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/

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…

Citrix XenServer: Festplattenpriorität im Storage-Pool konfigurieren​

Hat man in seinem Citrix XenServer mehrere virtuelle Festplatte in einem Storage liegen, kann es vorkommen dass man einzelnen davon eine höhere Priorität zuweisen möchte als anderen.

Leider gibt es diese Option nicht klickbar im Citrix XenCenter, sondern man muss die Konsole (CLI) bemühen.

Das Einstellen dieser Prioritäten ist etwas komplexer, ich beschränke mich in meinem Beispiel auf die „schnell und einfach“ Version. Damit möchte ich sagen, bitte selbst damit beschäftigen.

Zum Thema… Es gibt verschiedene Algorithmen, welche man für sein QOS der virtuellen Festplatten wählen kann. Ich nehme gerne ionice, da es bei mehreren Systemen eher um IO-Probleme als reine Durchsatzprobleme geht. Diesem Algorithmus gebe ich die Information mit das es hier um realtime geht und die Klasse in welche die virtuelle Festplatte gesteckt werden soll. Bei der Klassifizierung ist zu beachten, dass es ein ganzzahliger Wert zwischen 0 und 7 sein muss. Die Klasse 0 hat dabei die höchste Priorität und die Klasse 7 die geringste.

Kleines Beispiel gefällig?

Wir sind auf der root Konsole des XenServers. Ich lasse mir die VMs mit ihren Platten anzeigen, in diesem Fall gibt es keine Snapshots. Würde es welche geben, gleiches Vorgehen, es sieht nur etwas „unübersichtlicher“ aus.

[root@fra.srv.ha.xen.05 ~]# xe vbd-list
uuid ( RO)             : 66a3903c-8eba-4d8a-92d9-c435d399d3ac
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): VM-Kennzeichnung
         vdi-uuid ( RO): <not in database>
            empty ( RO): true
           device ( RO):


uuid ( RO)             : 4e004302-c32e-4c90-b986-9efc0b1995a1
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): Laufwerkskennzeichnung
         vdi-uuid ( RO): 47e5ab14-9cf8-4e7f-88b8-fe20247efa85
            empty ( RO): false
           device ( RO): xvdb


uuid ( RO)             : 5b4f70ec-07cb-47a5-aa05-91647cf38b78
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): Laufwerkskennzeichnung
         vdi-uuid ( RO): e6796376-995f-4a99-8ba6-893c30aa6a14
            empty ( RO): false
           device ( RO): xvda

Zu erkennen ist ein System (577e39d4-e771-477b-8829-8648b05b682b) mit zwei virtuellen Festplatten (4e004302-c32e-4c90-b986-9efc0b1995a1 / 5b4f70ec-07cb-47a5-aa05-91647cf38b78).

Versorgt mit diesen Informationen kann ich nun direkt die beiden Platten mit neuer Priorität versehen.

$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_type=ionice
$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_paramsched=rt
$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_params:class=5

$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_type=ionice
$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_paramsched=rt
$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_params:class=5

Als Test lasse ich mir nun noch einmal die gesetzten Einstellungen auf der Konsole ausgeben. Einmal den gewählten QOS-Algorithmus und dann dessen gesetzte Optionen.

$ xe vbd-param-get uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 param-name=qos_algorithm_type
ionice
$ xe vbd-param-get uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 param-name=qos_algorithm_params
class: 5; sched: rt

Noch Fragen? Dann fragen…

 

Der eingeschlafene Hintern im DataCenter

Da hocke ich heute mal wieder im DataCenter und arbeite an den Systemen. Wie immer, im Schneidersitz auf dem Boden und mit den Notebook auf den Beinen. Nach einiger Zeit merke ich, dass mein Hintern aufgehört hat sich über die Temperatur zu beschweren. Dieses ist in der Regel ein untrügerisches Zeichen dafür, dass er eingeschlafen ist. Was nun Vor- und Nachteile hat. Vorteil, ich kann noch länger so sitzen ohne das es fühlbar unbequem wird; Nachteil, wenn ich später versuche aufzustehen, wird es lustig!

Das muss doch irgendwie besser gehen, oder? OK, ok… Es gibt in der Regel einen hässlichen Hocker, der ist aber so hässlich das man doch besser auf dem Boden sitzt, weil es dann doch bequemer ist. Dann könnte ich mir noch ein Kissen mitbringen und es unterlegen. O_o ne, doch nicht! Wenn ich so überlege dann finden sich in meiner Erinnerung nur Bilder, von auf dem Boden hockenden Technikern vor einem Schrank. Alle mit kaltem Hintern und jedem schläft dieser früher oder später ein. Da sollte mal jemand was erfinden *AUFRUF*.

Wie auch immer, wenn ich mir schon über solche Dinge Gedanken mache… Dann kann es mir nicht so schlecht gehen, oder vielleicht genau aus diesem Grund doch? Na dann werde ich wohl nun mal jemanden aufwecken, wünscht mir Glück.

ownCloud Sync Client Sabayon

Auf meinem Sabayon System findet mein Rigo leider keinen owncloud-client. Glücklicherweise baut sich dieser fast von alleine 😀

Ich lade mir also einfach die beiden Quellpakete qtkeychain-master.zip und mirall-1.6.1rc1.tar.bz2 herunter. Entpacke sie qtkeychain-master in qtkeychain-master und mirall-1.6.1rc1 in mirall. Dann beginne ich mit dem bauen, dabei lege ich den späteren Installationsprefix auf /usr fest damit es am Ende nicht alles unter /usr/local… liegt. Dieses aber, wie so oft, selbst denkend nachmachen, es wird schnell unordentlich.

$ mkdir qtkeychain-build
$ cd qtkeychain-build
$ cmake -DCMAKE_BUILD_TYPE="Debug" cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../qtkeychain-master
$ make
$ sudo make install

Jetzt noch der eigentliche owncloud-client.

$ mkdir mirall-build
$ cd mirall-build
$ cmake -DCMAKE_BUILD_TYPE="Debug" cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../mirall
$ make
$ sudo make install

Schon lässt sich alles aufrufen und wie gewünscht nutzen. Ach ja, sollten noch Abhängigkeiten fehlen, finden sich diese aktuell alle mit Rigo! Sauberer wäre es ebenfalls direkt Pakete zu erstellen, dann könnte man sie sauberer ersetzten, löschen usw.. Ist mir gerade für diese Nummer zu aufwendig.

Viel Spaß!

Openfire: IPv6 Authentifizierung mit Remote-Server für Domain einrichten

Da fummle ich gerade mit dem Jabber / XMPP Server Openfire herum und stoße auf einen etwas nervigen Bug. Das Teil hat nämlich ein kleines Problem, wenn man als Nameserver in seinem System den localhost als IPv6 Adresse eingetragen hat.

Zur besseren Identifikation, im ErrorLog (/var/log/openfire/error.log)von Openfire finden sich dann Meldungen wie diese:

2014.06.15 22:48:35 org.jivesoftware.openfire.session.LocalOutgoingServerSession - Error authenticating domain with remote server: jabber.ccc.de
java.lang.NumberFormatException: For input string: ":1"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:492)
        at java.lang.Integer.parseInt(Integer.java:527)
        at com.sun.jndi.dns.DnsClient.<init>(DnsClient.java:125)
        at com.sun.jndi.dns.Resolver.<init>(Resolver.java:61)
        at com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:570)
        at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:430)
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:127)
        at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
        at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:192)
        at org.jivesoftware.openfire.net.DNSUtil.resolveXMPPDomain(DNSUtil.java:124)
        at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSession(LocalOutgoingServerSession.java:270)
        at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain(LocalOutgoingServerSession.java:167)
        at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPacket(OutgoingSessionPromise.java:261)
        at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(OutgoingSessionPromise.java:238)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

Zum lösen muss also nur in die /etc/resolf.conf der Nameserver von ::1 auf 127.0.0.1 umgestellt werden.

Immer diese Kackbugs hinsichtlich IPv6. Hoffentlich arbeiten so langsam mal mehr mit IPv6, damit die Fehler schneller gefunden und gefixt werden. Ich hasse es an so etwas hängen zu bleiben, da ich es so unnötig finde!

Fertig…

Exchange Online, Lync Online und Office 365: DNS-Einträge für eine BIND-Zone einrichten

Bei mir ist gerade die Frage aufgeschlagen was man denn bitte in seine DNS Zone vom Bind schreiben muss, wenn man eines oder mehrere dieser wunderbaren Microsoft Lync, Office 365 oder Exchange benutzen möchte.
Während des Registrierungsprozesses kommt man an die Stelle an welcher man einen TXT RECORD in der Zone veröffentlichen soll um den besitzt der Domain/Zone zu bestätigen. Etwas später müssen dann für die einzelnen Dienste ebenfalls Records gesetzt werden, damit am Ende das Outlook Autodiscover, Lyncdiscover sowie die  Lync Federation funktionieren. Nutzt man Exchange Online muss natürlich noch der MX RECORD geändert werden, damit die E-Mails alle bei Microsoft „einlaufen“.

Nun ist es für ungeübte nicht immer direkt zu durchschauen was gemacht werden muss, daher hier ein kleines Beispiel an der Domain: kernel-error.com
Die zu setzenden RECORDS werden einem dann auf der Webseite von Microsoft wie im Beispiel unten Angezeigt.

Exchange Online

TypPrioritätHostnameVerweist auf die AdresseGültigkeitsdauer
MX 0 @ kernel-error-com0i.mail.protection.outlook.com 1 Stunde 
CNAME – autodiscover autodiscover.outlook.com 1 Stunde 
     
TypTXT-NameTXT-WertGültigkeitsdauer 
 TXT @ v=spf1 include:spf.protection.outlook.com -all 1 Stunde 
     
 Alias oder Hostname  Ziel Gültigkeitsdauer   
 kernel-error.com MS=ms12345678  1 Stunde
  

Lync Online

TypDienstProtokollPortStärkePrioritätGültigkeitsdauerNameZiel
SRV _sip _tls44311001 Stundekernel-error.comsipdir.online.lync.com
SRV _sipfederationtls _tcp506111001 Stundekernel-error.comsipfed.online.lync.com
         
 Typ Hostname Verweist auf die Adresse Gültigkeitsdauer     
 CNAME sip.kernel-error.com sipdir.online.lync.com 1 Stunde     
 CNAME lyncdiscover.kernel-error.com webdir.online.lync.com 1 Stunde     

Zusätzliche Office 365-Einträge

TypHostnameVerweist auf die AdresseGültigkeitsdauer
CNAMEmsoid.kernel-error.comclientconfig.microsoftonline-p.net1 Stunde

Ich LIEBE es ja, immer wenn Microsoft solche Dinge ins Deutsche übersetzten tongue-out Im Folgenden nun als kleines Beispiel das Zonenfile vom Bind für kernel-error.com mit den gesetzten Records.

$ORIGIN .
$TTL 86400      ; 1 day
kernel-error.com             IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                                2014010101 ; serial
                                15000      ; refresh
                                1800       ; retry (30 minutes)
                                604800     ; expire (4 weeks)
                                86400      ; minimum (1 day)
                                )
                        NS      ns1.kernel-error.de.
                        NS      ns2.kernel-error.org.

$TTL 1H
						IN TXT "MS=ms12345678"
						IN TXT "v=spf1 include:spf.protection.outlook.com -all"
						
						IN MX	0 kernel-error-com0i.mail.protection.outlook.com.
						
_sip._tls.kernel-error.com.			IN SRV   1 100 443	sipdir.online.lync.com.
_sipfederationtls._tcp.kernel-error.com.	IN SRV   1 100 5061	sipfed.online.lync.com.


$ORIGIN kernel-error.com

$TTL 1H
autodiscover		IN CNAME	autodiscover.outlook.com.
sip			IN CNAME	sipdir.online.lync.com.
lyncdiscover		IN CNAME	webdir.online.lync.com.
msoid			IN CNAME	clientconfig.microsoftonline-p.net.

Prüfen lassen sich alle gesetzten DNS-RECORDS natürlich wie immer schnell mit dig!

TXT     @     v=spf1 include:spf.protection.outlook.com -all     1 Stunde

$ dig +nocmd +noall +answer kernel-error.com IN TXT @ns1.kernel-error.de
kernel-error.com.            3600    IN      TXT     "MS=ms12345678"
kernel-error.com.            3600    IN      TXT     "v=spf1 include:spf.protection.outlook.com -all"

MX     0     @     kernel-error-com01.mail.protection.outlook.com     1 Stunde

$ dig +nocmd +noall +answer kernel-error.com IN MX @ns1.kernel-error.de
kernel-error.com.            3600    IN      MX      0 kernel-error-com0i.mail.protection.outlook.com.

SRV     _sip     _tls     443     1     100     1 Stunde     kernel-error.com     sipdir.online.lync.com

$ dig +nocmd +noall +answer _sip._tls.kernel-error.com. IN SRV @ns1.kernel-error.de
_sip._tls.kernel-error.com.  3600    IN      SRV     1 100 443 sipdir.online.lync.com.

SRV     _sipfederationtls     _tcp     5061     1     100     1 Stunde     kernel-error.com     sipfed.online.lync.com

$ dig +nocmd +noall +answer _sipfederationtls._tcp.kernel-error.com. IN SRV @ns1.kernel-error.de
_sipfederationtls._tcp.kernel-error.com. 3600 IN SRV 1 100 5061 sipfed.online.lync.com.

CNAME     –     autodiscover     autodiscover.outlook.com     1 Stunde

$ dig +nocmd +noall +answer autodiscover.kernel-error.com IN A @ns1.kernel-error.de
autodiscover.kernel-error.com. 3600  IN      CNAME   autodiscover.outlook.com.

CNAME     sip.kernel-error.com     sipdir.online.lync.com     1 Stunde

$ dig +nocmd +noall +answer sip.kernel-error.com IN A @ns1.kernel-error.de
sip.kernel-error.com.        3600    IN      CNAME   sipdir.online.lync.com.

CNAME     lyncdiscover.kernel-error.com     webdir.online.lync.com     1 Stunde

$ dig +nocmd +noall +answer lyncdiscover.kernel-error.com IN A @ns1.kernel-error.de
lyncdiscover.kernel-error.com. 3600  IN      CNAME   webdir.online.lync.com.

CNAME     msoid.kernel-error.com     clientconfig.microsoftonline-p.net     1 Stunde

$ dig +nocmd +noall +answer msoid.kernel-error.com IN A @ns1.kernel-error.de
msoid.kernel-error.com.      3600    IN      CNAME   clientconfig.microsoftonline-p.net.

Noch Fragen? Dann fragen 🙂 Sonst wünsche ich noch „viel Spaß“ mit dem neuen Microsoft Online Produkten….

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑