Slave DNS verwalten
Slave DNS verwalten
Ich hatte ja angekündigt, dass ich mir was bastel um das DNS-System mit so wenig wie möglich Aufwand zu pflegen.
Ich habe vor, das hier häppchenweise zu dokumentieren.
Das Tool, ich habe es schlicht bindAPI genannt, besteht aus einem CLI Client, der auf jedem DNS Server installiert wird.
Dieser hat Kenntnis über alle Keyhelp-Server in eigener Verantwortlichkeit und alle Nameserver.
Zusätzlich weiß der Client, für welche Domains der Server verantwortlich ist, und managed API-Keys für andere Clients, die sich mit ihm verbinden können.
So zeigt sich aktuell das CLI tool: check:permissions (offen): Prüft die Zugriffsrechte unter dem Ordner /etc/bind
Der User unter dem die API auf dem Webserver läuft, und der CLI nutzer ist, muss in der Gruppe bind sein, und die Gruppe muss ein paar Schreibrechte bekommen.
check:panel (angefangen, noch nicht commited): Prüft für ein oder alle Panel (Keyhelp-Instanzen) für welche Domains sie verantwortlich sind, und ob alle Nameserver auf aktuellem Stand sind.
Wenn man alle gleichzeitig prüfen lassen will, muss man den jeweiligen APIkey in der Datenbank hinterlegen.
Wer das nicht möchte, kann einzeln prüfen und den Key an den CLI-Client pipen.
check:domains (offen): Prüft alle Zonen, für die der Server zuständig ist.
Die restlichen Sachen sind eigentlich selbsterklärend, hoffe ich, die üblichen CRUD Aktionen auf Datenbanken.
Bei apikeys gibt es kein Update, macht keinen Sinn, weil der Key verschlüsselt gespeichert wird.
Wenn, dann löschen und neu anlegen.
Ausser nameserver ist das fertig.
Die REST-Api orientiert die an der von Keyhelp, man muss also für Client einen Key anlegen, und den als X-API-Key Header mitsenden, und die API ansprechen zu können.
Über die API kann man Domains anlegen, bearbeiten, anzeigen lassen und löschen.
Unterstützt werden GET, POST, PUT und DELETE.
Ich spiele mit dem Gedanken, noch eine OpenAPI/Swagger Dokumentation anzuflanschen.
Die Daten existieren für jeden DNS-Server einzeln. Ich bin mir noch unschlüssig, ob es schöner wäre, die Daten nur 1x zentral zu halten, aber dafür mehr Daten synchronisieren zu müssen.
Einsatzbereit ist es wie gesagt noch nicht, aber falls jemand neugierig ist, kann er ja schon mal einen Blick drauf werfen.
https://git.24unix.net/tracer/bindAPI
Wenn ich die Dokumention hier fertig habe werde ich sie (in Englisch) als README in Git übernehmen.
Ich habe vor, das hier häppchenweise zu dokumentieren.
Das Tool, ich habe es schlicht bindAPI genannt, besteht aus einem CLI Client, der auf jedem DNS Server installiert wird.
Dieser hat Kenntnis über alle Keyhelp-Server in eigener Verantwortlichkeit und alle Nameserver.
Zusätzlich weiß der Client, für welche Domains der Server verantwortlich ist, und managed API-Keys für andere Clients, die sich mit ihm verbinden können.
So zeigt sich aktuell das CLI tool: check:permissions (offen): Prüft die Zugriffsrechte unter dem Ordner /etc/bind
Der User unter dem die API auf dem Webserver läuft, und der CLI nutzer ist, muss in der Gruppe bind sein, und die Gruppe muss ein paar Schreibrechte bekommen.
check:panel (angefangen, noch nicht commited): Prüft für ein oder alle Panel (Keyhelp-Instanzen) für welche Domains sie verantwortlich sind, und ob alle Nameserver auf aktuellem Stand sind.
Wenn man alle gleichzeitig prüfen lassen will, muss man den jeweiligen APIkey in der Datenbank hinterlegen.
Wer das nicht möchte, kann einzeln prüfen und den Key an den CLI-Client pipen.
check:domains (offen): Prüft alle Zonen, für die der Server zuständig ist.
Die restlichen Sachen sind eigentlich selbsterklärend, hoffe ich, die üblichen CRUD Aktionen auf Datenbanken.
Bei apikeys gibt es kein Update, macht keinen Sinn, weil der Key verschlüsselt gespeichert wird.
Wenn, dann löschen und neu anlegen.
Ausser nameserver ist das fertig.
Die REST-Api orientiert die an der von Keyhelp, man muss also für Client einen Key anlegen, und den als X-API-Key Header mitsenden, und die API ansprechen zu können.
Über die API kann man Domains anlegen, bearbeiten, anzeigen lassen und löschen.
Unterstützt werden GET, POST, PUT und DELETE.
Ich spiele mit dem Gedanken, noch eine OpenAPI/Swagger Dokumentation anzuflanschen.
Die Daten existieren für jeden DNS-Server einzeln. Ich bin mir noch unschlüssig, ob es schöner wäre, die Daten nur 1x zentral zu halten, aber dafür mehr Daten synchronisieren zu müssen.
Einsatzbereit ist es wie gesagt noch nicht, aber falls jemand neugierig ist, kann er ja schon mal einen Blick drauf werfen.
https://git.24unix.net/tracer/bindAPI
Wenn ich die Dokumention hier fertig habe werde ich sie (in Englisch) als README in Git übernehmen.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
- space2place
- Posts: 494
- Joined: Tue 24. Mar 2020, 11:02
- Contact:
Re: Slave DNS verwalten
Klasse Arbeit. Und Danke das Du es hier zur Verfügung stellst.
Gruß
Sascha
Gruß
Sascha
i-MSCP => KeyHelp Migration: https://github.com/TheCry/i-mscp-keyhelp-migration
Re: Slave DNS verwalten
So, gestern kam mir ein anderer Job dazwischen, heute gings weiter.
Der erste Check ist fertig. Also, naja, programmiertechnisch schon, aber irgendwas klemmt da noch.
Ich verzichte mal aufs anonymisieren, die Server sind eh alle im Netz und per DNS herauszufinden.
Ich habe hier eine Liste meiner Keyhelp-Server:
Mit dem Befehl ./bin/console panels:apiping <ID> kann ich ein einzelnes Panel pingen, ohne ID nimmt er alle die konfiguriert sind.
Leider klappt der Api-Ping bei einigen nicht via IPv4, da muss ich nun rausbekommen, warum.
ICMP Ping klappen auch über IPv4.
Das Timemout habe ich auf 1000ms gesetzt, sonst wartet er gefühlt eine Minute …
Edit, weiter gehts.
Wie sich hier: viewtopic.php?f=6&t=11118 gezeigt hat, scheint das ein lokales Problem zu sein, ich teste erst mal von anderen Rechnern aus.
Also, auf dem NS, in diesem Fall ein pure Debian ohne Keyhelp, den Apache installieren, und PHP von Sury.
Erst mal in /var/www/html gehen,, wir wollen weder die default Seite von Debian ausliefern noch sonst etwas (für den Moment), lieber eine weiße Seite.
Dann
Dann
habe ich nicht wirklich clever gemacht, dass mit den zwei Verzeichnissen, aber ich lasse es erst mal so …
Habe es angepasst, cd bindAPI reicht nun
So, die Zeile mit dem Shebang ist auf ein KeyHelp System ausgelegt.
Einfachste Lösung ist es, einen entsprechenden Symlink anzulegen:
Wenn noch nicht erfolgt:
Wir brauchen den Composer:
Ich installiere ihn fürs ganze system unter /usr/local/bin, dann ist er auch im Pfad, alternativ kann man ihn auch unter bin im bindAPI verzeichnis packen.
Oups
Recht hat er, ab hier können wir erst mal ganz entspannt als nicht privilegierter user arbeiten, bis wir uns dem Apachen widmen.
Schauen, ob die gewünschte Shell verfügbar ist, in meinem Fall zsh:
Dann können wir die Shell mit chsh ändern, oder halt direkt in der /etc/passwd.
Ich habe jetzt zwei shells offen eine als root eine als www-data.
Als root müssen wir noch php8.1-curl, php8.1xml und php8.1-mbstring installieren.
Die werden für PHPUnit benötig, ich habe noch gar keine Tests eingecheckt, aber die Abhängigkeiten sind halt schon in der composer.json.
Im anderen Fenster nun:
Ich habe jetzt eine leere config.json anlegen lassen, alternativ hätte man auch die config.json.sample manuell kopieren können.
Hier legt ihr nun eure gewünschten Parameter fest.
Auf ein neues:
Genau das mache ich, wenn ihr die APi auf einen Keyhelp Server installiert solltet ihr die DB besser in KeyHelp direkt anlegen.
Und, endlich …
Jetzt kann man mit ./bin/console panel:create die zu befragenden Panels hinzufügen.
Derzeit muss man die Apikeys mit angeben, übernahme von stdin habe ich noch nicht für alle Befehle implementiert.
Erst mal eine eingeben:
Und testen …
Sieht besser aus als auf NS2.
Für heute habe ich genug, morgen geht es mit den Nameservern weiter.
Der erste Check ist fertig. Also, naja, programmiertechnisch schon, aber irgendwas klemmt da noch.
Ich verzichte mal aufs anonymisieren, die Server sind eh alle im Netz und per DNS herauszufinden.
Ich habe hier eine Liste meiner Keyhelp-Server:
Mit dem Befehl ./bin/console panels:apiping <ID> kann ich ein einzelnes Panel pingen, ohne ID nimmt er alle die konfiguriert sind.
Leider klappt der Api-Ping bei einigen nicht via IPv4, da muss ich nun rausbekommen, warum.
ICMP Ping klappen auch über IPv4.
Das Timemout habe ich auf 1000ms gesetzt, sonst wartet er gefühlt eine Minute …
Edit, weiter gehts.
Wie sich hier: viewtopic.php?f=6&t=11118 gezeigt hat, scheint das ein lokales Problem zu sein, ich teste erst mal von anderen Rechnern aus.
Also, auf dem NS, in diesem Fall ein pure Debian ohne Keyhelp, den Apache installieren, und PHP von Sury.
Erst mal in /var/www/html gehen,
Code: Select all
echo "<!DOCTYPE html>" > index.html
Dann
Code: Select all
git clone https://git.24unix.net/tracer/bindAPI.git
Code: Select all
cd bindAPI/bindAPI
Habe es angepasst, cd bindAPI reicht nun
Code: Select all
chmod +x bin/console
Code: Select all
╰─➤ cat bin/console|head -n 1 127 ↵
#!/usr/bin/keyhelp-php81
Einfachste Lösung ist es, einen entsprechenden Symlink anzulegen:
Wenn noch nicht erfolgt:
Code: Select all
apt install php8.1-cli
Code: Select all
╰─➤ php -v 130 ↵
PHP 8.1.1 (cli) (built: Dec 20 2021 21:33:24) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.1, Copyright (c) Zend Technologies
with Zend OPcache v8.1.1, Copyright (c), by Zend Technologies
Code: Select all
ln -s /usr/bin/php /usr/bin/keyhelp-php81
Code: Select all
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
Code: Select all
php composer-setup.php --install-dir=/usr/local/bin --filename=composer
chmod +x /usr/local/bin/composer
Code: Select all
composer update
Code: Select all
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Code: Select all
chown -R www-data:www-data /var/www/html
Code: Select all
─➤ grep zsh /etc/shells
/bin/zsh
/usr/bin/zsh
Ich habe jetzt zwei shells offen eine als root eine als www-data.
Als root müssen wir noch php8.1-curl, php8.1xml und php8.1-mbstring installieren.
Die werden für PHPUnit benötig, ich habe noch gar keine Tests eingecheckt, aber die Abhängigkeiten sind halt schon in der composer.json.
Im anderen Fenster nun:
Code: Select all
su - www-data
cd html/bindAPI/bindAPI
composer update
$ ./bin/console
Missing config file
Should I create a new config based on config.json.sample? (y/N): y
Config file has been generated. Adjust it to your needs, then proceed to database setup.
Code: Select all
{
"dbHost": "localhost",
"dbPort": 3306,
"dbDatabase": "sampledb",
"dbUser": "sampleuser",
"dbPassword": "secret",
}
Auf ein neues:
Code: Select all
xen1% ./bin/console
SQLSTATE[HY000] [2002] No such file or directory
Did you create the database and adjust the config file?
You can create database an user via a panel or manually in mysql shell:
CREATE DATABASE databasename;
CREATE USER 'user'@'localhost' IDENTIFIED BY 'secret';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, INDEX, DROP, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON databasename.* TO 'user'@'localhost';
There is no need to run FLUSH PRIVILEGES when using GRANT!
Und, endlich …
Code: Select all
xen1% ./bin/console
Usage
check health checks the system can perform
check:permissions
check:panels {ID}
check:domains {ID}
panels all Keyhelp systems configured
panels:list
panels:create <name> {A=<IPv4>} {AAAA=<IPv6>} {apikey=<API-Key>}
panels:update <ID> {name=<name>} {A=<IPv4>} {AAAA=<IPv6>} {apikey=<API-Key>}
panels:delete
panels:apiping {<ID>}
nameservers available nameservers
nameservers:list
nameservers:create <name> {A=<IPv4>} {AAAA=<IPv6>} {apikey=<API-Key>}
nameservers:update <ID> {name=<name>} {A=<IPv4>} {AAAA=<IPv6>} {apikey=<API-Key>}
nameservers:delete <ID>
nameservers:apiping {<ID>}
domains domains this server is responsible for
domains:list
domains:create <name> {A=<IPv4>} {AAAA=<IPv6>}
domains:update <ID> {name=<name>} {A=<IPv4>} {AAAA=<IPv6>}
domains:delete <ID>
apikeys API keys for other nameservers
apikeys:list
apikeys:create
apikeys:update <ID>
apikeys:delete <ID>
e.g. ./bin/console apikeys:list
Derzeit muss man die Apikeys mit angeben, übernahme von stdin habe ich noch nicht für alle Befehle implementiert.
Erst mal eine eingeben:
Code: Select all
xen1% ./bin/console panels:list
All available panels:
+------+--------------------------+------------------+---------------------------------------+------------+
| ID | Name | A | AAAA | API Key |
+------+--------------------------+------------------+---------------------------------------+------------+
| 28 | executor.24unix.net | 176.9.165.128 | 2a01:4f8:161:12cd::128 | Lo7jsXYQ |
| 29 | shadow.24unix.net | 37.120.185.117 | 2a03:4000:f:5e2:a80c:2dff:fed1:e109 | o2CtvTQh |
| 30 | tector.24unix.net | 176.9.165.137 | 2a01:4f8:161:12cd::137 | HJwrfMd7 |
| 31 | paz.24unix.net | 176.9.165.134 | 2a01:4f8:161:12cd::134 | DquWO8vf |
| 32 | interdictor.24unix.net | 176.9.165.131 | 2a01:4f8:161:12cd::131 | qsrlTNIu |
+------+--------------------------+------------------+---------------------------------------+------------+
Code: Select all
xen1% ./bin/console -V panels:apiping
executor.24unix.net 176.9.165.128 pong 2a01:4f8:161:12cd::128pong
shadow.24unix.net 37.120.185.117 pong 2a03:4000:f:5e2:a80c:2dff:fed1:e109pong
tector.24unix.net 176.9.165.137 pong 2a01:4f8:161:12cd::137pong
paz.24unix.net 176.9.165.134 pong 2a01:4f8:161:12cd::134pong
interdictor.24unix.net 176.9.165.131 pong 2a01:4f8:161:12cd::131pong
Für heute habe ich genug, morgen geht es mit den Nameservern weiter.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Slave DNS verwalten
So hier geht es auch weiter.
Nameserverliste ist fertig:
Auf dem ersten ist es schon installiert und eingebunden:
Erster Nameserver ist konfiguriert, ist ein Keyhelp Panel. Klappt:
Jetzt machen wir ns1 fertig, das nackte debian.
Ich hatte oben ja geschrieben, Document root ist
/var/www/html/
Konfiguration ist straightforward:
Port 80 macht nichts, nur ne Weiterleistung auf 443
Und der ssl host sieht so aus:
Check mit Postman:
Oder mit curl, je nach Gusto:
Und nun auf dem ns2 testen:
Reicht für heute
TODO:
check:permission
check:domains
- forward (ist in DB, sind includes und Zone vorhanden?
- reverse (ist in Includes, ist in DB vorhanden?
check:panels
- alle domains müssen bekannt sein
Edit:
Ich werde noch was ändern.
Domains auf Keyhelp-Panels brauchen keine IP in der Config, die IPs sind ja in der Panel-Tabelle, ich brauche nur die ID des Panels.
Und die Option, externe Domains aufzunehmen, die nicht auf einem Keyhelp-Panel laufen.
Werde ich morgen mal zum Wachwerden umbauen … Ein extra Feld, panel_id, wenn das befüllt ist, guckt er in der Panel-Tabelle, sonst nutzt er die IP.
Update der Tabelle: ALTER TABLE `domains` ADD `panel_id` INT NULL AFTER `id`;
Nameserverliste ist fertig:
Code: Select all
$ ./bin/console nameservers:list
All available nameservers:
+------+------------------+------------------+---------------------------------------+-----------------+
| ID | Name | A | AAAA | API Key |
+------+------------------+------------------+---------------------------------------+-----------------+
| 20 | ns1.24unix.net | 5.9.30.194 | 2a01:4f8:161:12cd::2 | |
| 22 | ns2.24unix.net | 176.9.165.128 | 2a01:4f8:161:12cd::128 | 61eec33c8829a |
| 23 | ns3.24unix.net | 37.120.185.117 | 2a03:4000:f:5e2:a80c:2dff:fed1:e109 | |
+------+------------------+------------------+---------------------------------------+-----------------+
Code: Select all
% curl https://ns2.24unix.net/api/ping -H "X-Api-Key:61eec33c8829a.[..]e272"
ping{"status":"pong"}%
Code: Select all
% ./bin/console -V nameservers:apiping 22
ns2.24unix.net 176.9.165.128 pong 2a01:4f8:161:12cd::128 pong
Ich hatte oben ja geschrieben, Document root ist
/var/www/html/
Konfiguration ist straightforward:
Port 80 macht nichts, nur ne Weiterleistung auf 443
Code: Select all
cat ns1.24unix.net.conf
<VirtualHost *:80>
ServerName ns1.24unix.net
ServerAdmin tracer@24unix.net
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/ns1.24unix.net/error.log
CustomLog ${APACHE_LOG_DIR}/ns1.24unix.net/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =ns1.24unix.net
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
Code: Select all
cat ns1.24unix.net-le-ssl.conf 130 ↵
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName ns1.24unix.net
ServerAdmin tracer@24unix.net
Protocols h2 h2c http/1.1
DocumentRoot /var/www/html/bindAPI/public
ErrorLog ${APACHE_LOG_DIR}/ns1.24unix.net/error.log
CustomLog ${APACHE_LOG_DIR}/ns1.24unix.net/access.log combined
SSLCertificateFile /etc/letsencrypt/live/ns1.24unix.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/ns1.24unix.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
<FilesMatch \.php$>
SetHandler "proxy:unix:/run/php/php8.1-fpm.sock|fcgi://localhost"
</FilesMatch>
<Directory /var/www/html/bindAPI/public>
Options -Indexes +FollowSymLinks +MultiViews
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
</IfModule>
Check mit Postman:
Oder mit curl, je nach Gusto:
Code: Select all
curl https://ns1.24unix.net/api/ping -H "X-Api-Key:61eee98b821c7.[..]55d"
{"response":"pong"}%
Code: Select all
$ ./bin/console -V nameservers:apiping
ns1.24unix.net 5.9.30.194 pong 2a01:4f8:161:12cd::2 pong
ns2.24unix.net 176.9.165.128 pong 2a01:4f8:161:12cd::128 pong
ns3.24unix.net 37.120.185.117 pong 2a03:4000:f:5e2:a80c:2dff:fed1:e109 pong
TODO:
check:permission
check:domains
- forward (ist in DB, sind includes und Zone vorhanden?
- reverse (ist in Includes, ist in DB vorhanden?
check:panels
- alle domains müssen bekannt sein
Edit:
Ich werde noch was ändern.
Code: Select all
% ./bin/console domains:list
All available domains:
+------+-----------------+-----------+--------+
| ID | Name | A | AAAA |
+------+-----------------+-----------+--------+
| 2 | aussempott.de | 1.2.3 | |
| 3 | fairdns.de | 1.2.3 | |
| 4 | tzazicke.de | 1.2.3 | |
| 13 | test.de | 1.2.3.4 | ::1 |
| 14 | test2.de | 123 | |
| 15 | test3.de | 123 | |
| 16 | test4.de | 123 | |
| 17 | test5.de | 123 | |
| 18 | test6.de | 123 | |
| 19 | test7.de | 123 | |
+------+-----------------+-----------+--------+
Domains auf Keyhelp-Panels brauchen keine IP in der Config, die IPs sind ja in der Panel-Tabelle, ich brauche nur die ID des Panels.
Und die Option, externe Domains aufzunehmen, die nicht auf einem Keyhelp-Panel laufen.
Werde ich morgen mal zum Wachwerden umbauen … Ein extra Feld, panel_id, wenn das befüllt ist, guckt er in der Panel-Tabelle, sonst nutzt er die IP.
Update der Tabelle: ALTER TABLE `domains` ADD `panel_id` INT NULL AFTER `id`;
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Slave DNS verwalten
Ich überlege gerade, da man alles über die beiden APIs erschlagen kann, reicht es, wenn einer der Nameserver die DB mit den benötigten Daten vorhält.
Sollte eigentlich reichen.
Evtl. splitte ich API und CLI noch mal auf …
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Slave DNS verwalten
so, auf der CLI ./bin/console check:panels fragt nun brav alle Keyhelp-Instanzen via API nach Domains ab und und via API auf allen Nameservern an.
Bin recht zufrieden.
Bin recht zufrieden.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Slave DNS verwalten
Da ich aus dem Edit-Fenster raus bin, muss ich meinen Monolog fortführen
Morgen folgt dann check:domains …
Morgen folgt dann check:domains …
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Slave DNS verwalten
Habe mich umentschieden, heute Code-Neustrukturierung.
Und PHP-DI (Dependency Injection) eingebunden.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Slave DNS verwalten
Da ich mitbekommen habe, das mindestens ein User hier interessiert liest, mache ich einfach mal mein tägliches Update.
- Controller entschlackt
- Repositories angelegt
- Entities in eigene Klassen ausgelagert
CLI ist zu 90% fertig, würde ich sagen.
Bei der API binde ich aktuell noch die Dependency Injection ein, ansonsten steht die. Ausser ich mache noch eine Swagger-Doku.
Morgen werde ich entweder mal wieder etwas Geld verdienen oder mit Unit-Tests anfangen …
- Controller entschlackt
- Repositories angelegt
- Entities in eigene Klassen ausgelagert
CLI ist zu 90% fertig, würde ich sagen.
Bei der API binde ich aktuell noch die Dependency Injection ein, ansonsten steht die. Ausser ich mache noch eine Swagger-Doku.
Morgen werde ich entweder mal wieder etwas Geld verdienen oder mit Unit-Tests anfangen …
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
-
- Posts: 579
- Joined: Tue 9. Feb 2016, 16:44
Re: Slave DNS verwalten
Es sind mindestens zwei User, die hier interessiert mitlesen.
Viele Grüße, Christian
- Jolinar
- Community Moderator
- Posts: 3596
- Joined: Sat 30. Jan 2016, 07:11
- Location: Weimar (Thüringen)
- Contact:
Re: Slave DNS verwalten
Sogar dreiselect name from me; wrote: ↑Tue 1. Feb 2022, 10:55 Es sind mindestens zwei User, die hier interessiert mitlesen.
Wenn jemand inkompetent ist, dann kann er nicht wissen, daß er inkompetent ist. (David Dunning)
Data Collector für Community Support
___
Ich verwende zwei verschiedene Schriftfarben in meinen Beiträgen /
I use two different font colors in my posts:
Data Collector für Community Support
___
Ich verwende zwei verschiedene Schriftfarben in meinen Beiträgen /
I use two different font colors in my posts:
- In dieser Farbe schreibe ich als Moderator und gebe moderative Hinweise oder begründe moderative Eingriffe /
In this color, I write as a moderator and provide moderative guidance or justify moderative interventions - In dieser Farbe schreibe ich als Community Mitglied und teile meine private Meinung und persönlichen Ansichten mit /
In this color, I write as a community member and share my personal opinions and views
Re: Slave DNS verwalten
Das motiviert auf jeden Fall
Und, ja, heute noch keine Unit-Tests …
Und, ja, heute noch keine Unit-Tests …
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Slave DNS verwalten
Leider habe ich keine wirklich befriedigende Lösung in Sachen DarkMode gefunden
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Slave DNS verwalten
Heute leider nicht so viel geschafft.
Ich hatte die Config für Swagger erst via Annotations gemacht, aber das finde ich unschön.
Habe dann angefangen, es auf Attributes (seit PHP 8.0) umzusetzen, aber anscheinend ist das bei swagger-php noch in Arbeit, und die Dokumentation ist spärlich.
Bin jetzt erstmal mit einer handgeschriebenen openapi.json verblieben.
Edit: Oups, sehe gerade, der Post-Endpoint ist verschwunden, muss wohl noch was tun
Edit2: Der Autor von swagger-php hat auf MS-Github zügig geantwortet, mir geholfen, und es ist ein PR für die Doku in der Pipeline.
Ich werde morgen nochmal einen dynamischen Ansatz probieren, finde ich irgendwie cooler.
Ich hatte die Config für Swagger erst via Annotations gemacht, aber das finde ich unschön.
Habe dann angefangen, es auf Attributes (seit PHP 8.0) umzusetzen, aber anscheinend ist das bei swagger-php noch in Arbeit, und die Dokumentation ist spärlich.
Bin jetzt erstmal mit einer handgeschriebenen openapi.json verblieben.
Edit: Oups, sehe gerade, der Post-Endpoint ist verschwunden, muss wohl noch was tun
Edit2: Der Autor von swagger-php hat auf MS-Github zügig geantwortet, mir geholfen, und es ist ein PR für die Doku in der Pipeline.
Ich werde morgen nochmal einen dynamischen Ansatz probieren, finde ich irgendwie cooler.
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
Re: Slave DNS verwalten
Mal wieder das Update:
Heute mit Unit-Tests weitergemacht.
Die openapi.json fertiggestellt. (Dynamisch über Attribute generieren mache ich, wenn die Doku für swagger-php auf Attribute aktualisiert wurde).
Das CLI finalisiert:
Heute mit Unit-Tests weitergemacht.
Die openapi.json fertiggestellt. (Dynamisch über Attribute generieren mache ich, wenn die Doku für swagger-php auf Attribute aktualisiert wurde).
Das CLI finalisiert:
mfg Micha
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.
--
If Bill Gates had a nickel for every time Windows crashed …
… oh wait, he does.