Suchergebnisse

Mein Blog beschäftigt sich u. a. mit verschiedenen Artikeln, Code-Beispielen und auch eigenen Anwendungen rund um das Thema Webservices auf Basis von "JSON / REST". Diese Seite hier im Speziellen dient als Inhaltsverzeichnis zu diesem Thema. Rest Service - Backend Java, SpringBoot (online) (download) (code) Rest Service - Frontend Web Client: Wix, JavaScript (online) (download) (code) JQuery, JavaScript (download) (code) Fat Client: Java Swing (download) (code) Console: curl (download) (code) Die Front- und Backend Anwendungen dienen für jeden Leser zum ... Testen (siehe Online Dienste / Webseiten) Runter laden (siehe Download Verzeichnis) Code-Beispiele (siehe Subversion Repository) Weitere Artikel, Tools, Codes, usw. Open Api / Swagger Editor (Artikel) (online) (download) (code) Linux Root Server Debian Server 11 - Teil 1 - Installation (Artikel) Debian Server 11 - Teil 2 - Nacharbeiten (Artikel) Debian Server 11 - Teil 3 - FritzBox (Artikel) Debian Server 11 - Teil 4 - SQL Datenbank Server (Artikel) Debian Server 11 - Teil 5 - Webserver, Java JDK und Tomcat (SpringBoot) (Artikel)

Liste von nützlichen Tools für die Linux Konsole Dateisystem: Anzeige der Verzeichnisgrößen: # df -h # du -h -d 1 # apt install ncdu # ncdu Anzeige der Verzeichnisstruktur # apt install tree # tree Verzeichnis und Dateiverwaltung (inkl. Editor, zip/tar.gz-Support) ### Midnight Commander (Norton clone) ### # apt install mc # mc

Nachfolgend wird beschrieben, wie man den SVN-Deamon absichert, sprich die Verschlüsselung der Kommunikation zw. dem SVN-Client und dem SVN-Deamon mit SASL und DIGEST-MD5 aktiviert. Zuerst muss man SASL per APT installieren # apt install sasl2-bin libsasl2-modules libsasl2-2 Dann öffnen und editieren wir die Datei "/etc/default/saslauthd" START=yes OPTIONS="-c -m /var/run/saslauthd -V" Durch die Option -V werden SASL Informationen zukünftig in die LOG-Datei "/var/log/auth.log" geschrieben. Allerdings hat SASL einen uralten BUG, der auch nicht mehr gefixed wird und die LOG-Datei mit dem Eintrag "svnserve: DIGEST-MD5 common mech free" zuspammt! Um das zu verhindern, ersetzen wir in der Datei "/etc/logcheck/ignore.d.server/libsasl2-modules" den bestehenden Eintrag, durch folgende Zeile: ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ svnserve: DIGEST-MD5 common mech free Durch die Installation von SASL wird u. a. auch eine SASL-Benutzerdatenbank "/etc/sasldb2" erstellt. Wir müssen nun "svnserve", welche unter dem Benutzernamen SVN läuft, den Zugriff auf die SASLDB2 ermöglichen. Wir fügen daher den SVN User der SASL Gruppe hinzu. # usermod -aG sasl svn Nun aktivieren wir SASL in der Repository-Konfiguration. In Teil 2 haben wir das Repository "repo01" erstellt und diesem den Realm-Namen "SvnRep01" gegeben. Wir öffnen nun daher die Datei "/var/lib/svn/repo01/conf/svnserve.conf" und fügen dieser folgenden Text hinzu: [sasl] use-sasl = true min-encryption = 128 max-encryption = 2048 pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /etc/sasldb2 mech_list: DIGEST-MD5 SASL verwendet, wie bereits erwähnt eine eigene Benutzerdatenbank. Wir müssen daher nun in dieser die Login-Informationen für alle User und den Realm eintragen, die sich zukünftig per SASL in den SVN-Deamon einloggen wollen. Wichtig hierbei ist jedoch, das der Realm-Name exakt mit den Realm-Namen übereinstimmt, welchen wir in der Datei "svnserve.conf" definiert haben! Aufgrund der Einschränkungen von SASL darf dieser Name nur aus einem Wort bestehen, welches nur aus Buchstaben und Zahlen besteht und mit einem Buchstaben beginnen muss. Sonder- und Leerzeichen werden nicht unterstützt. Wir definieren nun die SASL-Logindaten mit folgendem Befehl: saslpasswd2 -c -f /etc/sasldb2 -u [realm] [username] Also für unser Beispiel saslpasswd2 -c -f /etc/sasldb2 -u SvnRep01 testuser01 password: testpass01 Wir machen das jetzt aber nur für den "testuser01", nicht aber für den "testuser02"! Den Realm-Namen und die 2 Test-User haben wir bereits in Teil 2 erstellt und den Login bzw. den Checkout bereits ohne SASL getestet. Nachdem wir nun alle erforderlichen Konfigurationen durchgeführt haben, aktivieren und starten wir nun SASL und den SVN-Deamon. # systemctl enable saslauthd # systemctl restart saslauthd # systemctl restart svn.service Und zuletzt testen wir das Auschecken des Repository mit SASL mit dem "testuser01", für welchen wir den Befehl "saslpasswd2" verwendet haben. cd ~/temp svn checkout --username test01user svn://locahost/repo01 repo01 Wenn alles korrekt konfiguriert wurde, dann hat der "checkout" nun funktioniert. Wir löschen nun das Unterverzeichnis "repo01" und versuchen das Gleiche nun mit dem "testuser02", für welchen wir den Befehl "saslpasswd2" nicht verwendet haben, welcher aber ohne SASL in Teil 2 den "checkout" erfolgreich durchgeführt hat. svn checkout --username test02user svn://locahost/repo01 repo01 Wenn alles korrekt konfiguriert wurde, dann hat der "checkout" nun nicht funktioniert! Das ist der Nachweis, dass der Login in den SVN-Deamon nur noch mit SASL funktioniert, wenn der Benutzer in die SASL-Datenbank eingetragen wurde, welche nur von SASL verwendet wird! Wichtiger Hinweis: Fehlermeldung: Konnte die Liste der SASL-Mechanismen nicht erhalten Diese Meldung erscheint, wenn der Wert von "min-encryption" bei der SASL-Konfiguration größer als 128 ist! Weitere SASL Befehle: "# sasldblistusers2": zeigt alle Benutzer der SASLDB2 an "# saslpluginviewer": zeigt alle installierten und verfügbaren Module an

Nachfolgend wird beschrieben, wie man ein SVN-Repository erstellt und die Rechte von Benutzern / Gruppen konfiguriert. Hierfür wird das Tool "svnadmin" verwendet, das bereits im Teil 1 per APT installiert wurde. Um ein neues SVN-Repository zu erstellen, verwendet man den Befehl "svnadmin create" und setzt rekursiv die Besitzrechte auf den SVN User. # svnadmin create /var/lib/svn/repo01 # chown -R svn:svn /var/lib/svn Nun hat man ein SVN-Repository mit folgender Struktur erstellt Benutzer, Gruppen und Rechte verwalten Grundsätzlich wurden bei der Erstellung des SVN-Repository auch bereits alle notwendigen Dateien (svnserv.conf, passwd, authz, usw.) erstellt und mit Beispiel-Kommentaren beschrieben. Die Zugriffsverwaltung kann entweder sehr pauschal für das gesamte Repository auf Benutzerebene oder aber auch feingranuliert für Benutzer, Gruppen und Verzeichnisse erfolgen. A) Namensdefinition für das Repository (realm) Jedes Repository benötigt eine Namensdefinition. Diese wird für die Rechteverwaltung benötigt. Sollen bspw. für 2 Repository nur 1 Rechtemanagement verwendet werden, müssen diese unterschiedlichen Repository den selben Realm-Namen verwenden. Editieren sie hierzu die Datei "svnserv.conf" und entfernen Sie das Kommentarzeichen '#' von der folgenden Zeile, unterhalb von [general] und vergeben Sie einen Namen für ihr Repository: realm = SvnRep01 B) Pauschale Rechtevergabe für Benutzer und das gesamte Repository Editieren sie hierzu die Datei "svnserv.conf" und entfernen Sie das Kommentarzeichen '#' von den folgenden Zeilen, unterhalb von [general]: anon-access = read auth-access = write password-db = passwd Als pauschale Rechte für das gesamte Repository können Sie folgende Werte definieren none: gar keine Rechte read: nur Leserechte write: Lese- und Schreibrechte Des weiteren wird unterschieden zw. Benutzern, die ohne Login (anon-access) oder Benutzern, die nach einem erfolgreichen Login (auth-access) auf das Repository zugreifen wollen. Die Login-Konfiguration für die Benutzer erfolgt in der Datei "passwd" unterhalb von [users] nach dem Schema [Benutzer] = [Passwort im Klartext]. 2 Beispiel-Benutzer sind in der Datei "passwd" bereits auskommentiert definiert. [users] # harry = harryssecret # sally = sallyssecret Für unser Beispiel fügen wir nun einen Testuser der Datei hinzu: [users] # harry = harryssecret # sally = sallyssecret testuser01 = testpass01 testuser02 = testpass02 C) Feingranulierte Rechtevergabe für Benutzer, Gruppen und Verzeichnisse Editieren sie hierzu die Datei "svnserv.conf" und entfernen Sie das Kommentarzeichen '#' von den folgenden Zeilen, unterhalb von [general]: authz-db = authz In der Datei "authz" werden dann die Gruppen definiert, den Gruppen die Benutzer und den Verzeichnissen die Gruppen und Rechte zugewiesen. Auch in dieser Datei sind bereits Beispiel-Konfigurationen auskommentiert enthalten. [aliases] # joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average [groups] # harry_and_sally = harry,sally # harry_sally_and_joe = harry,sally,&joe # [/foo/bar] # harry = rw # &joe = r # * = # [repository:/baz/fuz] # @harry_and_sally = rw # * = r [groups] enthält die Gruppendefinitionen und die Zuweisung der Benutzer zu den Gruppen [/foo/bar] ist die Definition eines Verzeichnisses innerhalb des Repository und die Zuweisung von Rechten auf Benutzerebene. '* =' gilt auch für anonyme Zugriffe. Wenn nach dem '=' nichts definiert wurde, ist das gleichbedeutend mit der Zugriff hat gar keine Rechte. [repository:/baz/fuz] ist die Definition eines Verzeichnisses innerhalb des Repository und die Zuweisung von Rechten auf Gruppenebene. [aliases] enthält ein Beispiel für einen LDAP / Active Directory Pfad. Hierzu müsste man dann aber auch noch weitergehende Konfigurationen, bspw. mit SASL und der Datei "groups-db" durchführen. Das würde aber den Umfang für diesen Artikel sprengen. Details hierzu findet man in der unten verlinkten Original-Dokumentation von Apache und RedBean. Für unser Beispiel erlauben wir unserem "testuser01" nun den Lese- und Schreibzugriff auf das root-Verzeichnis unseres Test-Repository und fügen der Datei "authz" folgenden Eintrag hinzu. Der 2te Eintrag "* =" bedeutet alle andere Benutzer oder auch anonyme Login-Versuche sind für das root-Verzeichnis gesperrt. [/] testuser01 = rw testuser02 = rw * = Zuletzt testen wir, ob wir das Repository mit beiden Testusern "auschecken", sprich eine physikalische Kopie auf unseren eigenen PC in ein temporäres Verzeichnis kopieren können. # mkdir -p ~/temp # cd ~/temp # svn checkout --username testuser01 svn://localhost/repo01 repo01 ... wenn das funktioniert hat # rm -R ./repo01 # svn checkout --username testuser02 svn://localhost/repo01 repo01 Wir haben nun mit 2 Testusern das Repository "aus-checken" können. Wichtige Hinweise: [repository:] hat keine Auswirkungen für anonyme Konfigurationen, da [repository:] nur für Gruppen gilt, welche wiederum nur für Benutzer und somit nur für authentifizierte Logins gelten. [Pfad] ohne "repository:" gilt für Benutzer aber auch für anonyme Zugriffe Der SVN-Deamon muss nach Änderungen der Konfigurationsdateien normalerweise nicht neu gestartet werden, es schadet aber auch nicht, wenn gerade kein Entwickler mit dem Repository arbeitet. Die Datei "authz" hat vor der Datei "svnserve.conf" Vorrang Fehlermeldung: Verbindungsprobleme, wenn man die SVN-Historie sehen will Lösung: folgende Rechte setzen anon-access = none auth-access = write Dieser Artikel beschreibt nur die wichtigsten Punkte. Eine ausführliche Dokumentation zu Subversion findet man im offiziellen Buch "Subversion" von RedBean, das auch kostenlos online verfügbar ist. Weitere Informationen findet man auch auf der offiziellen Subversion Webseite von Apache, welches Subversion entwickelt und verwaltet.

Nachfolgend wird beschrieben, wie man einen Subversion Server (svnserve) als eigenständigen Deamon installiert (ohne Apache Webserver). Diese Art der Installation wird idR. innerhalb von Unternehmenskonfigurationen verwendet, ua. weil sich der SVN-Deamon dann speziell auf die Server-Hardware anpassen lässt (Stichwort Thread-Management) und weil man den SVN-Deamon so auch an LDAP bzw. Active Directory Server anbinden kann. Des weiteren kann man auch bzgl. der Verschlüsselung zw. SVN-Clients und SVN-Server per "SASL" sehr umfangreiche Konfigurationen definieren und man spart sich die Installation und Konfiguration des Apache Webservers. Subversion (Client und Server) runterladen # apt install subversion Danach sollten folgende Dateien vorhanden sein: Service-User erstellen # adduser --system --no-create-home --group svn SVN Home-Verzeichnis erstellen und Rechte vergeben # mkdir /var/lib/svn # cd /var/lib/svn # chown -R svn:svn /var/lib/svn # chmod -R g+rws /var/lib/svn SVN Server zum Testen manuell starten # svnserve -d -r /var/lib/svn Default Port 3690 überprüfen # ss -ltn SVN Deamon Prozess manuell beenden # pkill svnserve Im Service-Verzeichnis die Datei "/etc/systemd/system/svn.service" erstellen und den folgenden Text hinzufügen: [Unit] Description=Subversion daemon After=syslog.target network.target [Service] Type=forking RuntimeDirectory=svnserve PIDFile=/run/svnserve/svnserve.pid EnvironmentFile=/etc/default/svnserve ExecStart=/usr/bin/svnserve $DAEMON_ARGS User=svn Group=svn KillMode=control-group Restart=on-failure [Install] WantedBy=multi-user.target Datei "/etc/default/svnserve" erstellen und folgenden Text hinzufügen # svnserve options DAEMON_ARGS="--daemon --pid-file /run/svnserve/svnserve.pid --root /var/lib/svn --log-file /var/log/svnserve/svnserve.log" Rechte für Default-Datei setzen # chown -R svn:svn /etc/default/svnserve Verzeichnisse für das Logging und die Prozess ID Datei erstellen # mkdir -p /var/log/svnserve; chown -R svn:svn /var/log/svnserve # mkdir -p /run/svnserve; chown -R svn:svn /run/svnserve Datei "/etc/logrotate.d/svnserve" erstellen und folgenden Text hinzufügen /var/log/svnserve/*.log { daily missingok rotate 14 compress notifempty create 640 svn adm sharedscripts postrotate if /bin/systemctl status svnserve > /dev/null ; then \ /bin/systemctl restart svnserve > /dev/null; \ fi; endscript } Um den SVN-Dienst beim Serverstart automatisch zu starten, gibt man einmalig folgenden Befehl ein: # systemctl enable svn.service Mit folgenden Befehlen kann man den Dienst manuell kontrollieren # systemctl start svn.service # systemctl stop svn.service # systemctl restart svn.service In der Firewall den Port 3690 freischalten # ufw allow 3690 # ufw status Zum Abschluss nochmal den Port 3690 überprüfen # ss -ltn Dieser Artikel beschreibt nur die wichtigsten Punkte. Eine ausführliche Dokumentation zu Subversion findet man im offiziellen Buch "Subversion" von RedBean, das auch kostenlos online verfügbar ist. Weitere Informationen findet man auf der offiziellen Subversion Webseite von Apache, welches Subversion entwickelt und verwaltet.

In diesem Artikel zeige ich, wie man den Swagger Editor lokal installiert. Grundsätzlich handelt es sich bei dem Swagger Editor um eine kostenlose Webanwendung. Wir benötigen somit einen Webserver auf welchem wir den Swagger Editor Installieren können. Ich verwende hierzu einen lokal installierten Apache 2 Webserver. Wie man einen Apache 2 unter Ubuntu installiert, wird in hier beschrieben. Zuerst erstellen wir einen neuen virtuellen Webserver im Verzeichnis ... => /etc/apache2/sites-available/001-swagger.conf hier tragen wir folgenden Text ein: ServerName swagger-editor.local ServerAdmin webmaster@localhost DocumentRoot /var/www/swagger ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined Dann erstellen wir das Verzeichnis ... => /var/www/swagger Jetzt holen wir uns die Swagger Zip Datei vom Swagger Git Server Wir haben nun im Download Verzeichnis die Datei swagger-editor-master.zip. Diese entpacken wir und kopieren den Inhalt in das Verzeichnis /var/www/swagger. Jetzt tragen wir den Servernamen für den Swagger Editor in die hosts-Datei ein => /etc/hosts 127.0.0.1 swagger-editor.local Zuletzt müssen wir noch den neuen virtuellen Webserver aktivieren und den Apache neu starten. # a2ensite 001-swagger.conf # systemctl restart apache2 Jetzt können wir den Swagger Editor im Webrowser starten.

In diesem Teil geht es darum, den Debian Server mit weiteren Produkten zu einem einfachen JSON/Rest Backend Server zu erweitern. Die Datenbank wurde bereits installiert. Nun folgen die Installation von Apache Webserver und Tomcat in Form von SpringBoot auf Basis des Java Developement Kits (JDK) Dieser JSON/Rest Backend Server wird in diesem Teil als "einfacher", kleiner Backend Server konfiguriert. Daher verzichte ich hier auf eine komplexere Konfiguration / Installation mit Docker, Kubernetes, Cluster Konfiguration, Helm Charts, usw. Des Weiteren soll dieser Server "nur" als öffentlicher JSON/Rest Backend Server dienen. Die eigentliche Software Entwicklung findet auf einem anderen Server statt. Daher werden hier auch keine CD/CI Entwicklungstools installiert, wie bspw. GitHub, Git als Repository, Maven, Ant, Python, Nexus, usw. Apache 2 Webserver Es gibt mittlerweile jede Menge schnelle und schlanke Webserver. Ich bleibe allerdings beim "Klassiker", dem Webserver 2 von Apache. Die Installation erfolgt einfach als root per APT: # apt update # apt install apache2 # systemctl restart apache2 (Webserver neu starten) # systemctl status apache2 (Webserver überprüfen) # ufw allow 80 (Firewall für den Webserver freischalten) # ufw allow 443 (Firewall für https:// freischalten) # ufw enable # ufw status Die Default Webseite vom Apache 2 Webserver löschen bzw. durch eine eigene (leere) Webseite ersetzen: # cd /var/www/html/index.html Über Webmin kann man dann den Server bequem konfigurieren SSL/TLS (https://) Grundsätzlich sollte man seine Webseiten mit https:// absichern. SSL/TLS Zertifikate gibt es von "LetsEncrypt" mittlerweile kostenlos! Die Erstellung und Installation erfolgt ganz einfach mit 2 Befehlen. Davor sollte man allerdings in allen Webseiten-Konfigurationen von Apache, die auf Port 80 konfiguriert wurden, unbedingt darauf achten, dass der ServerName eingetragen wurde und die Firewall abgeschaltet wurde! Datei: /etc/apache2/sites-available/000-default.conf ServerName my.testserver.com SSL/TLS installieren # apt install certbot python3-certbot-apache # certbot --apache Das Zertifikat ist zwar nur 90 Tage gültig, der CertBot erneuert das Zertifikat allerdings automatisch selbst! Man muss sich also um nichts kümmern! Die Neugenerierung kann man auch mit folgendem Befehl simulieren: # certbot renew --dry-run MIt dem nachfolgenden Befehl kann man seine Mailadresse nachträglich ändern: # certbot update_account --email mynewmail Danach schaltet man die Firewall wieder ein und gibt den Port für https:// (443) frei, falls nicht schon erledigt. # ufw enable # ufw allow 443 # ufw status OpenJDK OpenJDK ist der "fork" vom offiziellen Oracle Java JDK. Die Installation erfolgt mit folgendem Befehl: # apt install openjdk-17-jdk Oracle Java Developement Kit (JDK) Alternativ zu OpenJDK kann man natürlich auch das originale Java JDK vom Hersteller Oracle installieren. Ab Version 17 darf das Oracle Java JDK auf öffentlichen Repositories liegen und kostenlos ausgeliefert werden. Mit den nachfolgenden Befehlen wird das APT-Repository auf dem Debian Server erweitert und das Oracle Java JDK 17 installiert. # cd ~ (Tilde nicht vergessen!) # apt install software-properties-common # add-apt-repository ppa:linuxuprising/java # ./files/scripts/migrate-keys/migrate-apt-keys.sh # apt update # su - (Minus nicht vergessen!) # echo "deb http://ppa.launchpad.net/linuxuprising/java/ubuntu focal main" | tee /etc/apt/sources.list.d/linuxuprising-java.list # apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 73C3DB2A # apt update # apt install oracle-java17-installer --install-recommends Auswahl des Default Java JDK Mit folgenden Befehlen kann man das Standard Java auswählen: # update-alternatives --config java # update-alternatives --config javac JAVA_HOME Umgebungsvariable Definition der JAVA_HOME Umgebungsvariable. Öffnen Sie dazu die Datei "/etc/environment" und fügen sie folgenden Eintrag hinzu JAVA_HOME="/usr/lib/jvm/java-17-oracle" (bzw. das JDK, das man vorher als Default ausgewählt hat) ... anschließend booten wir den Debian Server. Danach kann man mit folgendem Befehl den Eintrag überprüfen: # env SpringBoot als Server (systemd) SpringBoot produziert eine ausführbare jar-Datei. Darin enthalten ist dann u. a. auch der Apache Tomcat Servlet Server. Die jar-Datei kann man natürlich auch manuell als User starten, nur läuft die Software dann nicht im Hintergrund und startet nicht automatisch bei jedem Serverstart. Wir wollen aber einen eigenständigen Serverdienst und diesen erstellen wir uns nun. jar-Datei ausführbar machen (rwx-rx-rx) prüfen, ob die eigene jar-Datei euch wirklich läuft prüfen, ob die Ports offen sind. # chmod +rx /var/lib/spring-boot/rest-service.jar # /usr/bin/java -jar /var/lib/spring-boot/rest-service.jar # ss -ltn Als nächstes erstellen wir einen Service-User. # adduser --system --no-create-home --group springboot Seit Version 8 verwenden alle Debianserver das sog. SystemD zum Starten und Stoppen von Serverdiensten. Hierzu erstellen wir nun eine kleine Konfigurationsdatei. Verzeichnis "/var/lib/spring-boot/" für die eigene SpringBoot jar-Datei erstellen die eigene jar-datei, bspw. "rest-service.jar" dort hinein kopieren Im Service-Verzeichnis die Datei "/etc/systemd/system/rest.service" erstellen in dieser Datei den folgenden Text hinzufügen: [Unit] Description=Own SpringBoot Service After=syslog.target network.target [Service] SuccessExitStatus=143 User=springboot Group=springboot WorkingDirectory=/var/lib/spring-boot Type=simple Restart=always RestartSec=30s ExecStart=/usr/bin/java -jar /var/lib/spring-boot/rest-service.jar [Install] WantedBy=multi-user.target 6. um den SpringBoot Dienst beim Serverstart automatisch zu starten, gibt man folgenden Befehl ein: # systemctl enable rest.service Mit folgenden Befehlen kann man den Dienst manuell kontrollieren # systemctl start rest.service # systemctl stop rest.service # systemctl restart rest.service Verbindung zw. Apache 2 und SpringBoot (Tomcat) Nun verbinden wir den Apache 2 Webserver mit dem embedded Tomcat Servlet Server von SpringBoot. Dies erfolgt in 3 Schritten. Aktivierung der Proxy Module für den Apache 2 Webserver Konfiguration des Apache 2 Webservers Konfiguration des Tomcat Servers innerhalb von Springboot. Aktivierung der Proxy Module für den Apache 2 Webserver Virtuelle Links für die 3 Module "proxy.conf", "proxy.load" und "proxy_ajp.load" im Verzeichnis mods-enabled erstellen. Konfiguration des Apache 2 Webservers Als root die folgende Datei öffnen und wie folgt konfigurieren: => /etc/apache2/sites-available/000-default-le-ssl.conf ServerName my.testserver.com ServerAdmin admin@mytestserver.com DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined # secret without ""! ProxyPass /rest/ ajp://localhost:8009/ retry=0 ttl=600 secret=myajpsecret ProxyPassReverse /rest/ ajp://localhost/ ProxyPass /rest/* ajp://localhost:8009/* retry=0 ttl=600 secret=myajpsecret ProxyPassReverse /rest/* ajp://localhost/* SSLCertificateFile /etc/letsencrypt/live/rest.datingtest.social/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/rest.datingtest.social/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf Konfiguration des Tomcat Servers innerhalb von Springboot. import org.apache.catalina.connector.Connector; import org.apache.coyote.ajp.AjpNioProtocol; import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; import org.springframework.beans.factory.annotation.Value; import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory; import org.springframework.boot.web.server.WebServerFactoryCustomizer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; /* * @Author Oliver Schwerttner, www.inter-net.de */ @Configuration() public class TomcatConfiguration { private static final Logger LOG = LogManager.getLogger(TomcatConfiguration.class); private static final String PROTOCOL = "AJP/1.3"; @Value("${tomcat.ajp.port:8009}") private int ajpPort; @Value("${tomcat.ajp.redirectport:8443}") private int ajpRedirectPort; @Bean public WebServerFactoryCustomizer connectorCustomizer() { try { return (tomcat) -> tomcat.addAdditionalTomcatConnectors(createConnector()); } catch (Exception e) { LOG.equals(e); return null; } } private Connector createConnector() { try { Connector ajpConnector = new Connector(PROTOCOL); /* * the secret has to be defined here and additional equal in the Apache 2 config file * for the by the ProxyPass! * * Example: * -------- * secret in the Apache 2 Server config without ""! * * ProxyPass /rest/ ajp://localhost:8009/ retry=0 ttl=600 secret=myajpsecret * ProxyPassReverse /rest/ ajp://localhost/ * ProxyPass /rest/* ajp://localhost:8009/* retry=0 ttl=600 secret=myajpsecret * ProxyPassReverse /rest/* ajp://localhost/* */ AjpNioProtocol protocol = (AjpNioProtocol) ajpConnector.getProtocolHandler(); protocol.setSecret("myajpsecret"); protocol.setSecretRequired(false); // will be ignored! ajpConnector.setSecure(false); ajpConnector.setAllowTrace(false); ajpConnector.setScheme("http"); ajpConnector.setPort(ajpPort); ajpConnector.setRedirectPort(ajpRedirectPort); return ajpConnector; } catch (Exception e) { LOG.equals(e); return null; } } } Abschluß 1. SpringBoot Dienst neu starten und offene Ports überprüfen # systemctl restart rest.service # ss -ltn 2. Apache Webserver neu starten und Rest-Service im Webbrowser aufrufen # systemctl restart apache2 => https://my.testserver.com/rest/[eigener Rest Link] Nun haben wir einen funktierenden Json/Rest-Backend Server. Die Verbindung vom Tomcat zur MySQL Datenbank erfolgt innerhalb von SpringBoot über die Java Persistence Api (JPA).

MariaDB MariaDB ist der "fork" der Oracle MySQL Datenbank, sprich die Kopie / Überführung der kostenlosen OpenSource Version der Oracle MySQL Datenbank (Community Version) MariaDB hat gegenüber der Oracle MySQL Datenbank (Community Version) Vor- und Nachteile. Die Unterschiede hier zu nennen, würde den Umfang dieses Artikels sprengen. Eine Übersicht der Unterschiede findet man bei db-engines.com MariaDB ist allerdings in Debian die Standard DB, neben der Postgres DB, wenn man eine relationale SQL Datenbank verwenden will. Unterschiede zw. MariaDB und Postres findet man ebenfalls bei db-engines.com. Die Installation der MariaDB erfolgt als root per APT: # sudo apt update # sudo apt install mariadb-server # sudo mysql_secure_installation # sudo systemctl status mariadb # mysqladmin version -p Oracle MySQL Community Version Die Oracle MySQL Community Version ist ebenfalls kostenlos und OpenSource, kommt im Vergleich allerdings direkt vom Hersteller und kann ggf. später auch zur kostenpflichtigen Enterprise Version hochgestuft werden, welche u. a. auch einen kostenpflichtigen Support enthält, was wiederum bei Konzernen häufig durch die konzern-internen Sicherheitsbestimmungen (SLAs) Pflicht ist. Des weiteren arbeitet die originale MySQL Datenbank auch besser mit den zusätzlichen Tools (Webmin, Oracle MySQL Workbench) und Treibern (MySQL Connector für Java, jdbc) von Oracle, besser zusammen, als mit der MariaDB. Die Installation erfolgt daher wie folgt: Kostenlosen Oracle Account erstellen und einloggen Alle notwendigen Dateien kostenlos runterladen MySQL APT Config MysQL Connector für Java (jdbc-Treiber) als zip-Datei Webmin aufrufen und per Dateimanager die MySQL Dateien auf den Debian Server hochladen in Webmin in das Terminal wechseln und folgende Befehle aufrufen. Der Vorteil ist, dass man hier mit Copy/Paste arbeiten kann. # apt install gnupg -y # dpkg -i mysql-apt-config_0.8.24-1_all.deb ... das installiert das APT-Repository für Oracle MySQL und zeigt uns die Installations-Konfiguration an. Wir wählen hier nur den MySQL Server aber nicht die Tools. Allerdings arbeitet das Oracle Konfigurationsmodul noch mit dem veralteten Key-System, welches in das neue Schlüsselsystem migriert werden muss. Glücklicherweise gibt es hierfür ein kleines bash-Script. Runterladen und ausführen. # migrate-apt-keys.sh Jetzt können wir den MySQL Server über APT installieren # apt update # apt install mysql-server Überprüfung mit ... # systemctl is-enabled mysql # systemctl status mysql # mysqladmin version -p Absicherung mit ... # mysql_secure_installation Die Installation von MySQL auf dem Debian Server ist nun abgeschlossen. Wir könnten nun auch den Standard-Port (3306) von MySQL ändern. Da wir aber eine aktive Firewall haben, ist der Port von außen aber auch so schon geschützt. Per Webmin (Bereich "un-used modules / MySQL) kann man den MySQL Server nun administrieren. Beim 1. Aufruf der Administrationsseite wird unten ein Hinweis mit einem Link zur Installation von zusätzlichen PERL Modulen angezeigt. Diesen sollte man anklicken!

Wenn man den Debian 11 Server in VMWare mit einer FritzBox verwendet, sollte man noch ein paar Dinge beachten / konfigurieren. Feste IP-Adresse zuweisen Damit der Debian Server sich eine IP-Adresse von der FritzBox holt, muss diesem vorher eine MAC-Adresse zugewiesen werden und das Netzwerk muss auf "bridged + replicate" konfiguriert worden sein. Wenn der Debian Server sich erstmals per DHCP eine beliebige IP-Adresse gezogen hat, geht man in die Netzwerk Konfiguration der Fritzbox und weißt dem Debian Server eine vernünftige, feste iP-Adresse zu. Anschließend bootet man die virtuelle VMWare mit dem Debian Server neu. Danach erhält er die fixierte, selbst definierte IP-Adresse. Fritzbox als Zeitserver Die Fritzbox fungiert per Default grundsätzlich auch als Zeitserver und sollte im Debian Server integriert werden. Hierzu muss die Fritzbox im Debian Server als NTP-Server eingetragen werden und der NTP-Client Daemon neu gestartet werden. Die Fritzbox muss als NTP-Server konfiguriert worden sein. Das ist aber normalerweise der Standard, sollte aber überprüft werden und im Debian Server muss die Fritzbox in der Datei "/etc/systemd/timesyncd.conf" eingetragen und der Dienst neu gestartet werden. # cd /etc/systemd/ # mc ... mit F4 die Datei "timesyncd.conf" öffnen, die fritz.box eintragen, mit F2 speichern und den NTP Client Dienst neu starten. # systemctl restart systemd-timesyncd Die Zeit-abfrage kann man sich dann bspw. per Webmin im LOG-Viewer anzeigen lassen.

Tool "sudo" installieren Tool "Midnight Commander" (MC) installieren und internen Editor aktivieren APT Quellen aufräumen / optimieren MC starten (Befehl mc) und Datei /etc/apt/sources.list mit F4 öffnen und überall main contrib non-free hinzufügen und mit F2 speichern. Die DVD mit # auskommentieren. Danach APT aktualisieren. (per root) # apt update # apt upgrade Benutzer zu "sudo" hinzufügen # su - (Minuszeichen nicht vergessen!) # usermod -aG sudo Benutzername Dann muss man nicht dauernd auf den "root" Benutzer wechseln, um bspw. die folgenden Befehle auszuführen: # sudo apt update # sudo mc (um als root Dateien bearbeiten zu können) SSH Port ändern Per Voreinstellung liegt der Port vom SSH-Server auf Port 22 und ist somit ein typisches Standardziel für Hacker. Ich empfehle daher den Port auf eine andere, unbenutzte Adresse zu legen. Aktuell verwendeten Ports anzuzeigen, SSH Port mit MC ändern, SSH neu starten und Port-Änderung überprüfen: # lsof -i -P -n # mc ... mit MC Datei /etc/ssh/sshd_config mit F4 öffnen und Port ändern, mit F2 speichern und neue Portbelegung prüfen. # /etc/init.d/ssh restart # lsof -i -P -n WebMin installieren WebMin ist ein kostenloses, open-source Konfigurations-Tool für Linux Server. Die Installation erfolgt über ein paar Befehle als root User. # apt install curl # curl -o setup-repos.sh https://raw.githubusercontent.com/webmin/webmin/master/setup-repos.sh # sh setup-repos.sh # apt-get install webmin # cd /etc/webmin # ./start Das WebMin Tool kann dann mit einem Webbrowser über Port 10000 aufgerufen werden. Der Login erfolgt mit dem root Account. https://debian-srv-11:10000/ WebMin Port ändern Genau, wie bei SSH, sollte man auch den Standard Port von Webmin ändern, bspw. auf Port 14711. Die Änderung kann direkt über das Webmin Tool erfolgen: UFW-Firewall installieren Zum Schluss sollte man noch eine Firewall installieren. # apt-get install ufw # ufw allow 45 (geänderten SSH Port beachten!) # ufw allow 14711 (geänderten Port für Webmin beachten!) # ufw allow 80 (für http:// Webseiten, kann man später auch wieder löschen) # ufw allow 443 (für https:// Webseiten) # ufw enable # ufw status 1. Teil ist abgeschlossen! Wir haben nun eine Grund-Installation eines Debian Servers Version 11 erfolgreich abgeschlossen!

Ziel dieser Artikelreihe ist es einen kompletten Json/Rest Backend Server aufzusetzen Im 1. Schritt installieren wir einen Debian 11 Linux Server Debian DVD ISO Datei runterladen und brennen oder in VMWare einbinden. debian-11.6.0-amd64-DVD-1.iso VMWare konfigurieren System: Linux, Debian 10, 64 bit (11er gibt es noch nicht in VMWare) RAM: 8 GB HD: 20 GB CD: mit ISO Datei verbinden Netzwerk: Optionen: bridged + replicate, Advanced Button: MAC Adresse erzeugen (generate) VMWare starten und Debian Installation aufrufen Da wir einen Server installieren, verzichten wir auf die Desktop Umgebung und auf GNome. Stattdessen aktivieren wir SSH.

Wer mit seiner eigenen Webseite Geld über die Anzeige von Werbung verdienen will, verwendet häufig "AdSense" von der Firma Google (Alphabet), sofern er das überhaupt kann, denn Google ist im Umgang mit der Auswahl von Kunden und Webseiten, gelinde gesagt, ziemlich zickig! Viele Webseiten werden einfach pauschal von Google abgelehnt, mit Verweis auf ebenfalls sehr pauschale Richtlinien von Google. Wer abgelehnt wird, erhält aber keinen klaren Hinweis, warum er abgelehnt wurde und gegen welche Richtlinie man denn angeblich verstoßen hätte. Und wer nun bei Google einen realen Support sucht, sucht bei Google vergeblich! Google verweist maximal auf das Google Forum, wo sich die Google Fans dann gegenseitig mit irgendwelchen Spekulationen übertrumpfen, was denn das Problem sein könnte (konjunktiv). Wirkliches Wissen und reale Antworten sucht man auch dort vergeblich! Ein weiteres Manko von Google "AdSense" ist, dass, selbst wenn man zugelassen wird, man nicht über die Einnahmen reden darf und auch sonst ist Google "AdSense" sehr restriktiv! So ist es bspw. nicht erlaubt, Google "AdSense" auf Download PopUp Seiten einzublenden, um bspw. seine eigene kostenfreie Open Source Software zu monetisieren! Des weiteren akzeptiert Google keine anderen Anbietern von Werbebannern auf Webseiten, die "AdSense" verwenden wollen. Es wird daher Zeit, die Alternativen zu Google "AdSense" zu nennen. Und davon gibt es jede Menge! Nachfolgend die Liste von Anbietern für die Einbindung von Werbung und zur Monetisierung auf der eigenen Webseite. Die anderen Anbieter nennen das natürlich nicht "AdSense", sondern dort ist man dann ein "Publisher". Des weiteren muss man unterscheiden zwischen ... Gesponserte Anzeige von Werbung in Form von Werbebannern oder PopUps. Das sind dann die "wirklichen" Alternativen zu Google "AdSense" Gesponserte Produkt Links, sogenannte "Affiliate Links", wie man sie bspw. auch von Amazon kennt. Deutsche Anbieter für Werbungs Publisher (Banner, PopUp) Schaltplatz: scheint "offline" zu sein. Telefon und Mail sind nicht erreichbar. Mehrere schlechten Kritiken im Web. Internationale Anbieter für Werbungs Publisher (Banner, PopUp) Adbuffs: nur englische Webseiten und min. 2000 eindeutige Besucher pro Monat Adcash AdRecover: arbeitet mit AdBlocker zusammen! AdBlocker verhindert Werbeanzeigen aber mit AdRecover verdient auch AdBlocker an Werbung und lässt die Banner von AdRecover wieder zu! Mit einfachen Worten, AdBlocker + AdRecover ist, wie Feuer mit Benzin zu löschen! Finger weg! Adsterra Adversal: min 50.000 PageViews pro Monat und eine eigene Domain Bidvertiser BuySellAds: nur für englischsprachige Websites mit mindestens 100.000 Pageviews pro Monat ClickAdu Evadav InfoLinks Media.net: Das ist der direkte AdSense-Wettbewerber von Yahoo und Bing. Allerdings auch genau so "abgehoben". Man kommt vom Regen in die Traufe. Monumetric: min 10.000 Views/Monat + Einrichtungsgebühr! PopAds PopCash PropellerAds (Monetag) RevContent (sehr gute Deutsche Webseite, obwohl es ein ausländisches Unternehmen ist) RevenueHits by Intango (arbeitet mit PropellerAds und ClickAdu zusammen) SunAdNetwork (früher AdClickMedia) ylliX Deutsche Anbieter für Affiliate Link Publisher Skimlinks (Taboola): obwohl die Firma in Berlin sitzt, ist die Webseite nur in Englisch verfügbar. Zur tatsächlichen Qualität der "Affiliate Links" kann ich derzeit nichts sagen. Ich werde es aber später testen und meine Erfahrungen hier aktualisieren. Internationale Anbieter für Affiliate Link Publisher Adcash Adsterra Amazon Partner Net Amazon Native Shopping Ads eBay Partner Network Sovrn //Commerce SunAdNetwork (früher AdClickMedia) noch ungeprüft plista: Deutsches Unternehmen. Ich habe aber aktuell noch keine Rückmeldung, ob es eine AdSense-Alternative ist