My thoughts Just do it!

CentOS 6 auffrischen

CentOS 6.10 hatte sein End-of-Life November 30th, 2020. Doch damit ist die Software ja nicht tot. Wir können ihr helfen, noch ein wenig weiter zu leben. Es werden dazu ein Base-Repository für Installation etwaiger fehlender Pakete sowie Repositories aus ähnlichen oder regänzenden Distributionen benötigt.

1. Einrichtung des neuen Base-Repositories

Hierzu verweise ich auf ein anderes Dokument, was ich auch dafür verwendet habe. Bitte lasst einen Coffee dort, es ist Gold wert!

-> https://www.getpagespeed.com/server-setup/how-to-fix-yum-after-centos-6-went-eol

 

2. Installation weiterer Packages um die Toolchain zu erneuern

Mit dem Compiler GCC 4.4 aus dem Jahre 2009 können diverse neue Packages nicht mehr gebaut werden. Glücklicherweise gibt es Standard-Lösungen für dieses Problem.

Scientific Linux ist genau wie CentOS ein Rebuild der Redhat Enterprise Distribution und somit hochgradig kompatibel mit zweiterem. Nutzen wir die Distribution als Ergänzung für unser Basis-System.

2a) Aktivierung des GPG-Keys

rpm import http://ftp.scientificlinux.org/linux/scientific/obsolete/5x/x86_64/RPM-GPG-KEYs/RPM-GPG-KEY-cern

2b) Hinterlegen der Repository-Configuration für yum

wget -O /etc/yum.repos.d/slc6-devtoolset.repo http://linuxsoft.cern.ch/cern/devtoolset/slc6-devtoolset.repo

2c) Installation einer aktuelleren Entwickler-Toolchain

yum install devtoolset-2

3. Nutzung der neuen Toolchain

Jetzt prüfen wir zunächst die alte Toolchain um den Unterschied feststellen zu können:

gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Der folgende Command aktiviert die neue Toolchain und muss bei jeder Sitzung neu ausgeführt werden:

scl enable devtoolset-2 bash

Damit wird eine neue Shell geladen, in der die Pfade bereits so konfiguriert sind, dass die neue Toolchain standard ist:

gcc --version
gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Viel Spaß!

Gültiges selbstsigniertes Zertifikat erstellen

Ein gültiges Zertifikat zu erstellen ist keine Zauberei. Chrome (und ggf. auch andere Browser) prüfen die Zertifikate auf signifikante Attribute um eine größtmögliche Sicherheit zu gewährleisten.

In den neuen Versionen von Chrome werden Zertifikate mit einem Common-Name als ungültig betrachtet, wenn das Attribute subjectAltName nicht gesetzt ist (siehe auch https://support.google.com/chrome/a/answer/7391219?hl=de) und ein Aufruf wird mit der Meldung NET::ERR_CERT_COMMON_NAME_INVALID quitiert.

Damit dieses Problem nicht auftritt gibt es die Möglichkeit, ein Zertifikat mit diesem Attribut zu versehen, während man es via openssl erstellt. Unter anderem kann man eine recht komplexe Kommandoabfolge verwenden (Rezept):

openssl req \
-x509 \
-newkey rsa:4096 \
-reqexts SAN \
-config <(cat /etc/pki/tls/openssl.cnf \
<(printf "\n[SAN]\nsubjectAltName=DNS:domain.tld,DNS:site.domain.tld")) \
-keyout /etc/ssl/certs/site-key.pem \
-out /etc/ssl/certs/site-cert.pem \
-days 365 \
-nodes \
-subj "/C=DE/CN=site/O=site.domain.tld"

Dieses Kommando erstellt ein Zertifikat für die Domain site.domain.tld sowie dem Alternativnamen domain.tld via einer temporären Erweiterung. Der Parameter bereitet openssl darauf vor, die Erweiterung SAN aus der Konfiguration anzufordern. Da in der Datei /etc/pki/tls/openssl.conf (der Pfad ist für CentOS 6 gültig, andere Distributionen können variieren) eine solche Erweiterung bestimmt nicht konfiguriert ist, wird der Rest via Parameter -config eingefügt.

Die Schlüsselbittiefe ist ebenso an die eigenen Bedürfnisse anzupassen, wie die Domainnamen und Pfade.

Ich übernehme keine Verantwortung für etwaige Probleme mit der SSL-Konfiguration. Bitte kontrolliert auf jeden Fall eure Einstellung, bevor ihr diese Kommandos ausführen wollt.

 

Das erstellte Zertifikat kann beispielsweise in den Apache oder nginx eingebaut werden. Anschließend kann man das Zertifikat natürlich auch mit dem Browser herunterladen und in den eigenen CA-Storage hinzufügen, um ihm endgültig zu vertrauen.

Android Platform-Tools und Build-Tools auf CentOS 6.x

Der User Juloor hat im Post Einfach mal die Android-Build-Tools auf CentOS 6 fixen den Kommentar veröffentlicht, das die aktuellen Build- und Platform-Tools mit der originalen Anleitung nicht mehr zum Laufen zu bringen sind.

Ich hab das mal als sportliche Herausforderung angenommen, das Problem zu beheben.

Hier mein Vorgehen:

1. Installieren einer neueren Version der glibc

Ich hab nach einem kurzen Test festgestellt, dass die neueste Version 2.26 mit meinem aktuellen Platform-Compiler Gcc 4.4.7 nicht bauen wird.

Mit der mindest-angeforderten Version 2.15 hagelt es Segmentation Faults.

Daher bin ich zunächst auf die 2.20 geschwenkt und habe diese nach der o.g. Anleitung in /opt/glibc-2.20 installiert. Entpacken - ins neue Verzeichnis wechseln und einen Unterordner "build" erstellen, wieder hinein wechseln.

$ ../configure --prefix=/opt/glibc-2.20 && make && make install

2. Danach habe ich die Platform-Tools auf die aktuellste Version (rev 26) upgedated

$ cd /opt/android/tools
$ ./android update sdk --all --no-ui --filter 1,2,3 

Dabei wurden auch die Android SDK Tools auf Version 25.2.5 und die Android SDK Build-tools auf Version 26.0.1 angehoben.

3. Anschließend habe ich den "Patch" aus https://www.nkey.de/post/einfach-mal-die-android-build-tools-auf-centos-6-fixen/ wieder auf /opt/android/build-tools/26.0.1/aapt und zusätzlich auf /opt/android/platform-tools/adb angewendet, diesmal aber etwas am Shell-Script modifiziert

#!/bin/bash
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
/opt/glibc-2.20/lib/ld-linux-x86-64.so.2 --library-path /opt/glibc-2.20/lib:$LD_LIBRARY_PATH:/lib64 ${DIR}/adb.bin $*

Ausgaben:

$ /opt/android/platform-tools/adb version
Android Debug Bridge version 1.0.39 Revision 3db08f2c6889-android
Installed as /opt/glib-2.20/lib/ld-2.20.so
$ /opt/android/build-tools/26.0.1/aapt version
Android Asset Packaging Tool, v0.2-4187382

Caribu ORM

Ein weiteres Projekt von mir ist der Caribu ORM, ein Object-Relational-Mapper für PHP. Das Hauptaugenmerk liegt darin, dem Anwender so viel Arbeit wie möglich abzunehmen. So ist es möglich, allein durch Erstellen einer Value-Object-Klasse, in welcher die Eigenschaften annotiert werden, als Datenbank-Accessor zu verwenden.

An der Verbesserung und Erweiterung des Wiki auf Github muss noch gearbeitet werden. Zudem muss noch eine Roadmap erstellt werden. Wer das Projekt dennoch verwenden will, kann es in der Version 1.0 mittels Composer einbinden:

{
"require" : {
"nkey/caribu" : "~1.0"
}
}


Der Source des Projektes ist auf Github zu finden: https://github.com/maikgreubel/caribu-orm

PHPGenerics

Mit PHPGenerics unternehme ich den Versuch, generische Komponenten in einer einfach zu verwendenten Bibliothek unterzubringen und Unit-Tests dafür zu Verfügung zu stellen.. Der Sourcecode wird auf Github gehostet.

Derzeit umfasst die Library Klassen für den Zugriff auf

  • Logging
  • Sockets
  • Http (Client & Server)
  • Streams (File, Memory, Socket)
  • Utilities

Es existieren Basis-Schnittstellen und deren Implentierungen, so dass einfache Operationen nicht immer wieder neu programmiert werden müssen.

Einige meiner weiteren Projekte profitieren von den PHPGenerics und sind als Abhängigkeit dort eingetragen.

Home ← Ältere Posts