Falls man mal einen Wikipedia-Artikel im Text-Format benötigt (bspw. um ein neuronales Netz zu testen oder zu trainieren), kann diesen im JSon-Format exportieren. Dazu einfach einen Link im Browser mit diesen GET-Query-String eingeben:

https://de.wikipedia.org/w/api.php?action=query&format=json&titles=Berlin&prop=extracts&exintro&explaintext

 

Ausgabe:

{
    "batchcomplete": "",
    "query": {
        "pages": {
            "2552494": {
                "pageid": 2552494,
                "ns": 0,
                "title": "Berlin",
                "extract": "Berlin [b\u025br'li:n] ist die Hauptstadt und ein Land der Bundesrepublik Deutschland. Die Gro\u00dfstadt ist mit rund 3,8 Millionen Einwohnern die ...."
            }
        }
    }
}

Es nervt immer, dass maillog zu voll gemüllt zu sehen mit Anmeldungsversuchen, die nur ein Ziel haben: Identitätsdiebstahl für Spamming und anderen Shit, den kein Mensch braucht.

Hier mal ein paar Rules für iptables, um die Barriere für Spammer und Scriptkiddies höher zu setzen:

-A INPUT -s 87.246.7.0/24 -j DROP
-A INPUT -s 103.151.122.0/24 -j DROP
-A INPUT -s 103.151.123.0/24 -j DROP
-A INPUT -s 103.151.149.0/24 -j DROP
-A INPUT -s 192.64.236.0/22 -j DROP
-A INPUT -s 212.70.149.0/24 -j DROP
-A INPUT -s 45.133.1.0/24 -j DROP
-A INPUT -s 78.128.113.0/24 -j DROP
-A INPUT -s 77.40.2.0/23 -j DROP
-A INPUT -s 5.188.206.0/24 -j DROP
-A INPUT -s 45.144.225.0/24 -j DROP
-A INPUT -s 45.133.1.0/24 -j DROP
-A INPUT -s 37.0.8.0/24 -j DROP
-A INPUT -s 31.210.21.0/24 -j DROP
-A INPUT -s 212.192.241.0/24 -j DROP
-A INPUT -s 2.56.56.0/22 -j DROP
-A INPUT -s 195.133.40.0/24 -j DROP
-A INPUT -s 188.162.192.0/21 -j DROP
-A INPUT -s 136.144.41.0/24 -j DROP
-A INPUT -s 167.114.88.80/28 -j DROP
-A INPUT -s 37.0.10.0/24 -j DROP
-A INPUT -s 31.210.20.0/24 -j DROP
-A INPUT -s 212.192.241.0/24 -j DROP
-A INPUT -s 136.144.41.0/24 -j DROP
-A INPUT -s 37.0.11.0/24 -j DROP
-A INPUT -s 188.162.32.0/19 -j DROP
-A INPUT -s 5.188.206.0/24 -j DROP
-A INPUT -s 95.130.124.0/22 -j DROP
-A INPUT -s 103.207.36.0/22 -j DROP
-A INPUT -s 37.98.160.0/19 -j DROP
-A INPUT -s 77.247.110.0/24 -j DROP
-A INPUT -s 193.56.29.0/24 -j DROP

Die Bereiche sind anhand dieser Commands herausgefunden worden:

grep -A1 "failed mail authentication attempt for user" /var/log/maillog |grep "authentication fail" | perl -pe 's#.*unknown\[([^\]].*?)\].*#\1#' |uniq
whois ...

Die Bereich stammen aus Russland, Vietnam und sehr viel kommt auch aus den Niederlanden.

 

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ß!

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.

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

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