Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 24 von 47)

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.

Samsung Galaxy S2 Überhitzt hohe Akkuverbrauch / Mainboard defekt

Das ärgert mich aber jetzt… Es hat ja tatsächlich einige Zeit gedauert, bis ich mich überhaupt zu so einem SmartPhone habe hinreißen lassen. Zu dem Zeitpunkt habe ich mich für das Samsung Galaxy SII entschieden. Es läuft seit ein paar Jahren ganz tadellos, vor allem mit dem CM 11 CyanogenMod. Vor kurzem stellte ich dann fest, dass mein Akku nicht mehr den ganzen Tag (viel mehr war eh nie drin) gehalten hat. Warum die Batterie so schnell leer war habe ich aber nicht kontrolliert. Es ging so schleichend, dass ich es nicht direkt war genommen habe. Irgendwann war es dann so massiv, dass ich es nicht weiter ignorieren konnte. Zuerst dachte ich natürlich an den Akku selbst. Dieser hatte ja bereits zwei Jahre auf dem Rücken und das Handy wurde beim Laden besonders warm, um nicht zu sagen heiß. Ein originaler Samsung Akku (zumindest hoffe ich das er original ist), war über eBay schnell und günstig zu bekommen. Leider änderte sich mit diesem nichts.
Ich habe dann davon gelesen, dass Dreck an der USB-Buchse zu Kriechströmen führen kann und diese dann den Akku schnell leersaugen. Also die Buchse gereinigt, bracht ebenfalls nix. Netzteil getauscht => nix :-/
Ich habe also das Gerät einmal aufgeschraubt, was verdächtig einfach ging. Inzwischen verbrannte das Gerät nämlich selbst im abgeschalteten Zustand so viel Strom (in Wärme), dass es trotz angeschlossenem Ladegerät nicht mehr reichte den Akku zu laden. Ich wollte herausfinden welches Bauteil da wohl so viel Hitze erzeugt. Unter einer Schirmung mit der Aufschrift GT-I9100 #4 vermutete ich die Quelle zuerst, es zeigt sich später aber dass es der IC auf der anderen Seite des Mainboards war, mit der Aufschrift: SWB-B42. Das ist der IC für Wi-Fi, Bluetooth und FM Radio BCM4330.
Meine Hoffnung dass nur die nahe, auf dem Mainboard, verlötete CMOS Batterie ein Problem hatte, war also dahin. Was also tun? Den IC bekommt man für ca. 15$ + Porto zu kaufen. Sagen wir mal mit drei Wochen Zeit und 30€ Einsatz ist dieses machbar. Dann könnte man mit etwas Heißluft den alten IC lösen und den neuen auflöten. Viel Arbeit und gemacht haben sollte man es ebenfalls schon mal. Ich habe mich daher entschlossen einfach ein neues Mainboard zu kaufen. Neue… Nun, neu liege ich auch bei 150 bis 200€. Zu teuer! Ich habe (wieder auf eBay) ein Samsung Galaxy S2 gefunden, eines mit def. Display. Ist wohl jemand draufgetreten, oder so etwas 😛 Egal… Dieses Teil gab es für 50€. Ich habe es gekauft und einfach das Mainboard getauscht.
Tja, was soll ich sagen? Es funktioniert  😀 So bleibt mir mein Samsung Galaxy SII wohl doch noch etwas erhalten!

Aber ich habe doch nichts zu verbergen…

Da ist nun also das Ergebnis von eurem „Ich habe doch nichts zu verbergen“! Klasse, gut gemacht….

http://www.golem.de/news/data-mining-polizei-will-straftaten-mit-predictive-policing-verhindern-1407-107638.html

Jetzt muss du nicht mal was zu verbergen haben, jetzt reicht es, wenn man statistisch leider gerade „auffällig“ ist. Am Ende treten die Jungs euch die Türe ein, verhaften euch und führen euch in Handschellen ab. OK ok… Wird nicht passieren, Rechtsstaat usw…. Riiiiiiccchhhhtttiiiigggg

Glaubt ihr das wirklich?

Klar, wenn sich am Ende herausstellt das ihr nichts zu verbergen hattet, wird schon nichts passieren…. Dem Rest kann man ja auch später erklären das die Vorwürfe völlig haltlos waren und euch nichts nachgewiesen werden konnte. Das verstehen alle und es bleibt kein ~Nachgeschmack~… Ich übertreibe? Na warten wir mal ab, ich denke es wird noch genau so kommen. Genug Metadaten habe sie ja inzwischen.

Ich denke: „It´s time for PANIC!“ Ich habe Angst 🙁

Wir müssen unbedingt alle etwas mehr auf unsere Daten achten und vor allem etwas „nervöser“ werden wenn es um die Überwachung von egal was geht. Nicht alles sinnfrei glauben, sondern mal mit Hirn hinterfragen! Das Thema: „Ich habe doch nichts zu verbergen“ ist damit wohl hoffentlich erschlagen, oder?

Google, IPv6 und geblockte E-Mails…

In der letzten Zeit stoße ich mich immer mal wieder an der, etwas eigensinnigen, Mailpolitik von Google. Dabei ist es egal ob man jetzt an eine gmail.com, googlemail.com Adresse oder an irgendeine „googelfremde“ aber dort gehostete Adresse etwas senden möchte.

Aus irgendeinem Grund ziert sich Google hin und wieder E-Mails anzunehmen, wenn sie per IPv6 eingeliefert werden. Man bekommt nur eine freundliche Meldung wie diese:

8:8001:107::2      12] Our system has detected that this 550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please visit 550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for 550 5.7.1 more information. a18si6099542wjs.121 - gsmtp (in reply to end of DATA command))

Folgt man nun also diesem lustigen Link zum Thema unsolicited mail / message blocked und geht die folgenden Infos komplett durch, stellt man fest, dass man sich an alle Vorgaben gehalten hat, Google es aber denn noch nicht einsieht die E-Mails anzunehmen. Ich muss natürlich dazu sagen, dass die Mailserver absolut korrekt konfiguriert sind und sogar Dinge wie DMARC, DANE mitbringen. Ebenfalls findet sich keines der Systeme auf Blacklisten oder sind in der Vergangenheit in irgendeiner Weise aufgefallen. Stellt das gleiche System die gleiche E-Mail über IPv4 ein, ist alles kein Problem. Warum zum Geier will Google also hin und wieder keine E-Mails per IPv6 bekommen?!?

Google ist natürlich in jedem Fall sehr freundlich, es gibt aber an keiner Stelle eine klare Aussage dazu. Egal an welcher Stelle man bei Google bohrt, am Ende steht immer die Info: „Warum genau eine E-Mail abgewiesen wird, können wir ihnen leider nicht mitteilen….“ !

Das bedeutet:

  • Man hält sich vollständig an jedes nur erdenkliche RFC.

  • Man hat einen perfekten Mailserver.

  • Man hält sich an alle Wünsche und Vorgaben von Google.

Und Google scheißt drauf sealed -=because we can=-

Nun kann man also versuchen Google zu boykottieren, tolle Idee! Nur ob die User da mitspielen, wage ich nun zu bezweifeln. Was tun? Nun ja, da Google ja die E-Mails ohne Probleme per IPv4 frisst, sorgt man wohl am besten dafür, dass E-Mails an Google nur per IPv4 zugestellt werden. Aus meiner Sicht ist dieses nicht nur Grütze, sondern es ist auch Sinn frei, dumm, unnötig, aufwendig und nervend.

Postfix bringt selbstverständlich alles nötige mit und lässt sich, wie folgt, zu diesem Blödsinn überzeugen.

Ich löse es über die transport map in Kombination mit einem weiteren smtp client service der nur IPv4 spricht. So kann ich schnell und einfach die gewünschten Domains diesem smtp client service zuweisen.

Dazu erstelle ich den Service in der /etc/postfix/master.cfg. Er bekommt den Namen smtp4, ist ein unix socket, ist vom Typ ein smtp service und bekommt die Option mitgegeben NUR IPv4.

smtp4     unix  -       -       -       -       -       smtp -o inet_protocols=ipv4

In der /etc/postfix/main.cfg aktiviere ich die transport maps und gebe als Ziel folgende Datei an: /etc/postfix/transport

transport_maps = hash:/etc/postfix/transport

Diese füttere ich nun mit den gewünschten Domains der Empfänger und gebe an dass diese bitte den neuen service smtp4 nutzen.

googlemail.com smtp4:
gmail.com smtp4:

Bitte nicht vergessen das „Datenbankfile“ zu erstellen und Postfix zum Neustart / einlesen der neuen Konfiguration zu übergeben.

$ postmap /etc/postfix/transport
$ /etc/init.d/postfix restart

Damit sollten nun alle E-Mails, wie angegeben, nur per IPv4 an den jeweiligen MX zugestellt werden. Ich will mich mit so einem IPv4/IPv6 Krims _nicht_ beschäftigen!!!!! Was da wieder los, hm?

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 AES 256 und JCE Unlimited Strength Jurisdiction Policy Files

Möchte man unter seinem Java AES mit 256 Bit nutzen, muss man die JCE Unlimited Strength Jurisdiction Policy Files von Hand installieren.

Ja, man fühlt sich schnell einige Jahre zurück versetzt, als man noch aus den USA keine große Krypto exportieren durfte/darf. Daher war es ja lange nicht möglich große Krypto in Browsern einzusetzen. Das Java Thema ist sehr ähnlich!

Die Installation ist recht einfach.

Zuerst einmal die neuen Policy Files herunterladen (für Java 7):

http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html  

Im heruntergeladenen ZIP-File finden sich zwei jar Dateien. Diese müssen nun gegen die….  na, sagen wir mal beschränkten, ausgewechselt werden. Auf einem Debian finden sich diese hier:

/usr/lib/jvm/java-7-oracle/jre/lib/security
/usr/lib/jvm/jdk1.7.0_51/jre/lib/security

Nachdem beiden Dateien getauscht wurden, sind sie auch schon aktiv für jeden neuen Java Prozess. Ich will damit sagen, wenn es für den Openfire genutzt werden soll, diesen bitte einmal durchstarten.

Clientreport:

https://xmpp.net/result.php?id=42150

Serverreport:

https://xmpp.net/result.php?id=42151

Noch Fragen? Na dann fragen 🙂

Openfire und StartSSL Zertifikate

Etwas hilflos stand ich heute vor der Meldung von Openfire, welche mit mitteilte, dass mein Zertifikat von StartSSL nicht importiert werden konnte.

Über folgenden Weg habe ich es denn noch in meinen Openfire gießen können.

1. OpenFire beenden.

2. Das Root-Zertifikat von StartSSL sowie das Class1 Zertifikat für Server ist bereits im Java Truststore von Openfire enthalten. Da ich ein Class2 Zertifikat erstellt habe, muss ich das Intermedia Zertifikat noch aufnehmen. Sonst lässt sich ja kaum eine Kette bilden.

In meiner Installation liegt mein Openfire unter /etc/. Dort findet sich auch der Trust- sowie der Keystore. Die nächsten Schritte finden also am besten direkt dort statt. Damit ich am Ende direkt mein Zertifikat und das Intermediate Zertifikat in einem Rutsch importieren kann. Werfe ich direkt beide zusammen. Domain.tld.cert ist dabei der öffentliche Teil meines Zertifikates.

$ cd /etc/openfire/security
$ wget http://www.startssl.com/certs/sub.class2.server.ca.crt
$ cat sub.class2.server.ca.crt domain.tld.cert > domain.tld.cert.tmp

3. Das eigentliche Zertifikat muss ins pkcs12 Format konvertiert werden, domain.tld.key ist dabei der private Teil meines Zertifikates. Bei dieser Aktion muss ein Kennwort erstellt werden. Das Standardkennwort des Keystores ist: „changeit“. Ich nutze dieses hier ebenfalls.

$ openssl pkcs12 -export -in domain.tld.cert.tmp -inkey domain.tld.key -out domain.tld.pkcs12 -name domain.tld

4. Als letzten Schritt kann ich nun das Zertifikat in den Keystore meines Openfires aufnehmen:

$ keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore /etc/openfire/security/keystore -srckeystore domain.tld.pkcs12 -srcstoretype PKCS12 -srcstorepass changeit -alias domain.tld

5. Openfire wieder starten.

Nun lässt sich bereits im Webinterface das neue Zertifikat sehen und ist nutzbar.

Noch Fragen?

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…

DNSSEC fähiger Registrar

In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registart ist zusammenarbeite. Vor allem im Hinblick auf DNSSEC und dem KSK oder besser der DS-RECORDS.

Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Hier arbeite ich gerne mit dem Herrn Metz zusammen. Es ist immer jemand erreichbar, vor allem lassen sich schnell und einfach auch etwas ungewöhnliche Dinge umsetzten. Zwar ist das Webinterface (stand 06.2014) noch nicht so weit das man darüber DS-RECORDS einwerfen kann, der Weg per E-Mail funktioniert aber in der Regel binnen Minuten / Stunden.

Es kommt ja eher selten bis nie vor, das ich hier Werbung für ein Unternehmen mache, dieses hat es aber verdient.

So long…

Webseite: http://www.speedpartner.de/

E-Mail Adresse: info@speedpartner.de

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑