Workaround:
subdomain www nehmen und dann eine Weiterleitung von domain auf http://www.domain einrichten.
Hab ich gerade auch in der Doku gefunden 
Aber reicht die Weiterleitung, dass ich mich bei example.com anmelden kann? Nein, oder? Das bringt mir ja nur für die Browser-Anmeldung etwas?
Aber reicht die Weiterleitung, dass ich mich bei example.com anmelden kann?
Welche Art von Anmeldung meinst du? Also die Clients machen bei der Anmeldung vorher immer einen Request und bemerken dann die Umleitung. Und dann wird die Zieladresse gespeichert (also die www-Variante).
Welche Art von Anmeldung meinst du? Also die Clients machen bei der Anmeldung vorher immer einen Request und bemerken dann die Umleitung. Und dann wird die Zieladresse gespeichert (also die www-Variante).
Client für Windows, App für iOS
Aber ich probiere es gleich einfach mal aus...
Bud Oder Du schreibt Dir ein kurzes Script mit der DNS-API. Einfach A/AAAA Records des Ziel-Hostnamens auslesen und bei der eigenen Domain aktualisieren. Da könnte man sich sicher mit den bestehenden Lösungen schnell etwas basteln.
Client für Windows, App für iOS
Aber ich probiere es gleich einfach mal aus...
Die sollten mit Weiterleitungen klarkommen.
Client für Windows, App für iOS
Was spricht denn dagegen dort einfach die url des Storageshares zu nehmen? Also host#####.your-storageshare.de
Oder wie bereits vorgeschlagen einfach irgendeine Subdomain box.ente.tld. Dank CNAME-Unterstützung viel angenehmer und kommt so auch keinen MX in die Quere.
Ja, ich mag's schlicht und einfach ... manchmal zumindest 
KBs Vorschlag mit der Netcup-API gefällt mir hingegen auch (ich nutze die API für mein DynDNS). 
KBs Vorschlag mit der Netcup-API gefällt mir hingegen auch (ich nutze die API für mein DynDNS).
Da kenne ich mich aktuell noch zu wenig aus und habe zu wenige Ressourcen mich damit zu beschäftigen...
Ist es so hochwichtig, dass die Hauptdomain example.com selbst zum Aufruf verwendet wird? Ich habe mehrere Clouds am Laufen, aber alle (z.B.) über cloud.example.com, also eine Subdomain. So mache ich das jetzt auch beim roten H, so ist das ja auch dort explizit vorgesehen. Das funktioniert dann auch einwandfrei, wenn man es einrichtet wie beim roten H dokumentiert. Hierzu wird dann ein CNAME von cloud.example.com auf die kryptische Subdomain des Storage Share gesetzt. Zusätzlich muss die eigene Subdomain in der Verwaltungsseite der Storage Share eingetragen werden. Bei der kleinen Variante sind - glaube ich - drei verschiedene Subdomains möglich. Ich vermute mal, die erzeugen dann einfach jeweils einen passenden vHost für die Subdomain auf ihrem Server. In der URL des Browsers steht dann (z.B.) https://cloud.example.com/apps/dashboard/#/. Geht natürlich auch mit jeder anderen Subdomain.
Klappt bei mir wunderbar. Ziehe grade meine Cloud-Daten von meinem gekündigten Strota-Server dahin um. Ein wenig Sorgen mache ich mir nur was passiert, wenn ich dann die dort verwendete cloud-Subdomain per CNAME auf die Storage Share verweise. Ich mache mich vorsichtshalber auf ein paar Stunden Downtime bzw Probleme mit der Erreichbarkeit gefasst. Down ist die Storage Share ja deswegen nicht, nur eben noch nicht über die neue Subdomain erreichbar bis das rote H den gesetzten CNAME-Eintrag erkennt und den Zugriff über die Subdomain ermöglicht.
Ein wenig Sorgen mache ich mir nur was passiert, wenn ich dann die dort verwendete cloud-Subdomain per CNAME auf die Storage Share verweise. Ich mache mich vorsichtshalber auf ein paar Stunden Downtime bzw Probleme mit der Erreichbarkeit gefasst. Down ist die Storage Share ja deswegen nicht, nur eben noch nicht über die neue Subdomain erreichbar bis das rote H den gesetzten CNAME-Eintrag erkennt und den Zugriff über die Subdomain ermöglicht.
Da brauchst du dir keine Sorgen machen. Den Cname Eintrag kannst du jetzt schon setzen, dauert ja ggf. Etwas, bis überall bekannt. Aktiv wird er dann erst, wenn du die Subdomain bei H anlegst, dann aber sofort.
Ja, dann muss ich aber einen andere Subdomain für die Cloud benutzen als bisher, und cloud gefällt mir halt am Besten für eine Cloud. Ansonsten ist die alte Cloud ja sofort weg. Naja, muss ich wohl sowieso mit leben, ob so oder so. Ich ziehe jetzt alles noch in Ruhe um, schalte die Synchronisiation der Clients auf dem Desktop und Notebook um, das Smartphone wird auch noch stillgelegt werden müssen. Dann CNAME und die Subdomain beim roten H anlegen und warten, bis die Subdomain auch auf die Storage Share läuft. Dann alles wieder aktivieren. Muss ich versuchen möglichst alles vollständig zu planen vor der Aktion.
Ist eben kein "normaler" Umzug von einem Server auf einen anderen, was die Cloud schon mehrfach hinter sich hat. Das hat beim letzten Umzug einer anderen Cloud aber heftig geknirscht im Vergleich zu früher. Obwohl, wenn ich es gut vorbereite vielleicht doch. Das Passwort ist derzeit noch unterschiedlich auf den Clouds, das werde ich definitiv vorher noch anpassen. Vielleicht kann ich dann auch einfach so die alte Cloud vom Netz nehmen, den CNAME und die Subdomain setzen und warten. Hmm, lese gerade zwischendurch das Nextcloud Manual zum Thema Umzug, da bin ich ja froh, dass die Clouds bisher immer den Umzug auf meine Weise überstanden haben, auch wenn sie das Logfile mit Fehlern zugemüllt haben. Andererseits, das was da alles steht, kann ich ja in dem Fall hier gar nicht machen. Die Instanzen sind ja nicht 1:1 identisch, die Datenbank kann ich auch nicht übertragen. Da müssen sich halt die Clients warm anziehen. Aber deswegen mache ich den Umzug ja auch im Sommer.
Du kannst doch bud.example.com für die neue Cloud initial und übergangsweise nutzen, dann die Daten umziehen, und danach cloud.example.com hinterher. So hast du dauerhaft Zugriff auf dir Daten…
Ja, ich habe schon eine weitere Subdomain derzeit im Gebrauch, notfalls ginge das ja auch ohne eigene Subdomain mit der Originalsubdomain vom roten H. Wird schon irgendwie gutgehen. Im Notfall existiert die alte Cloud ja immer noch unverändert, die werde ich vorher auch noch über eine zweite Subdomain zugreifbar machen. Ein Vorteil der Geschichte ist, ich finde da immer noch Dinge, die gar nicht richtig funktioniert haben bei der Synchronisierung des Smartphone Kalenders und der Kontakte. Das ist bei den vorhergehenden Umzügen nicht aufgefallen, weil die Cloud ja als Ganzes kopiert wurde und ich nicht alles im Detail überprüft habe. Jetzt kopiere ich alles vorab von Cloud zu Cloud und merke erst, dass da schon immer ein (kleiner) Teil der Kontakte fehlt. Die ältesten sind nur lokal in der Android App auf dem Smartphone gespeichert. 
Ein wenig Sorgen mache ich mir nur was passiert, wenn ich dann die dort verwendete cloud-Subdomain per CNAME auf die Storage Share verweise. Ich mache mich vorsichtshalber auf ein paar Stunden Downtime bzw Probleme mit der Erreichbarkeit gefasst.
Ja, dann muss ich aber einen andere Subdomain für die Cloud benutzen als bisher, und cloud gefällt mir halt am Besten für eine Cloud. Ansonsten ist die alte Cloud ja sofort weg.
Du kannst doch bud.example.com für die neue Cloud initial und übergangsweise nutzen, dann die Daten umziehen, und danach cloud.example.com hinterher.
Sowas habe ich zwar noch nie gemacht, aber als Vorschlag für eine Diskussion schreib' ich das trotzdem mal:
Ausgangsituation scheint folgende zu sein:
cloud.tab.tld > CNAME auf nextcloud.stratru.tld
Gewünschte Zielsituation wäre demnach:
cloud.tab.tld > CNAME auf nextcloud.hotzenplotz.tld
Meine Idee wäre eine temporäre selbst betriebene Zwischenstufe:
cloud.tab.tld > CNAME auf tab.bud01flare.tld > CNAME nextcloud.stratru.tld
Nach Aktivierung dieser Änderung dürfte es doch eigentlich erstmal nicht zu Ausfällen auf den aktiven stratru-Server kommen? Schnelle DNS-Server führen über bud01flare.tld auf den noch laufenden stratru-Server, während langsame DNS-Server den direkten Weg auf stratru-Server weisen.
Nach einer Wartezeit bis alle DNS über bud01flare zeigen, kann der hotzenblotz-Server nach der Daten-Synchronisation nun in Betrieb gehen.
Da der bud01flare-DNS-Server unter eigener Kontrolle läuft (habe aber keine Ahnung was es bedeutet einen eigenen DNS-Server zu betreiben) kann hier das TTL selbst verringert und gesteuert werden.
Daher folgt nun die Änderung auf den neuen Zielserver:
cloud.tab.tld > CNAME auf tab.bud01flare.tld > CNAME nextcloud.hotzenplotz.tld
Soll der Zwischenschritt über bud01flare.tld entfallen, kann auch gleich diese Zusatzumleitung im ersten CNAME-DNS-Server rausgenommen werden:
cloud.tab.tld > CNAME nextcloud.hotzenplotz.tld
Auch hier wäre es (in meiner naiven Vorstellung) so, dass langsame DNS halt noch eine gewisse Zeit über bud01flare gehen (welcher aber nahezu unterbrechungsfrei auf hotzenplotz zeigt - da der bud01flare-DNS-Server selbst betrieben wird), während schnelle externe DNS-Server zügig den direkten Weg weisen.
Sollte das nicht gehen, gibt es alternativ vielleicht auch die Möglichkeit bud01flare nicht als DNS-Server zu verwenden sondern ihn einfach (vorrübergehend) als endgültiges Ziel zu definieren, so dass er alles als "Proxy" auf die eigentliche Nextcloud-Domain leitet.
In jedem Fall wäre Clientseitig stets cloud.tab.tld aktiv.
Da kenne ich mich aktuell noch zu wenig aus und habe zu wenige Ressourcen mich damit zu beschäftigen...
Ich hab da mal was runtergehackt:
<?php
define('CUSTOMER_NUMBER', ''); // Kundennummer
define('API_KEY', ''); // API-Key
define('API_PASSWORD', ''); // API-Passwort
define('DOMAIN', ''); // Domain, die geupdatet werden soll (z.B. example.com), muss eine Apex-Domain sein
define('TARGET_DOMAIN', ''); // Domain, dessen Records verwendet werden sollen (z.B. dyndns.example.com)
$sessionId = login();
$currentDnsRecords = filterApexDnsRecords(
infoDnsRecords($sessionId)
);
$targetDnsRecords = dns_get_record(TARGET_DOMAIN, DNS_A | DNS_AAAA);
if (recordsChanged($currentDnsRecords, $targetDnsRecords)) {
$updateDnsRecords = getUpdateDnsRecords($currentDnsRecords, $targetDnsRecords);
updateDnsRecords($sessionId, $updateDnsRecords);
}
logout($sessionId);
// Functions
function getUpdateDnsRecords($currentDnsRecords, $targetDnsRecords)
{
$updateDnsRecords = [];
foreach ($currentDnsRecords as $record) {
$record['deleterecord'] = true;
$updateDnsRecords[] = $record;
}
foreach ($targetDnsRecords as $record) {
$updateDnsRecords[] = [
'hostname' => '@',
'type' => $record['type'],
'destination' => $record['type'] === 'A' ? $record['ip'] : $record['ipv6'],
];
}
return $updateDnsRecords;
}
function login()
{
$request = [
'action' => 'login',
'param' => [
'customernumber' => CUSTOMER_NUMBER,
'apikey' => API_KEY,
'apipassword' => API_PASSWORD,
],
];
['apisessionid' => $sessionId] = sendRequest($request);
return $sessionId;
}
function filterApexDnsRecords($dnsRecords)
{
$result = [];
foreach ($dnsRecords as $dnsRecord) {
if ($dnsRecord['hostname'] !== '@') {
continue;
}
if ($dnsRecord['type'] === 'A' || $dnsRecord['type'] === 'AAAA') {
$result[] = $dnsRecord;
}
}
return $result;
}
function recordsChanged($currentDnsRecords, $targetDnsRecords)
{
$current = array_map(fn ($record) => $record['destination'], $currentDnsRecords);
$target = array_map(fn ($record) => $record['ip'] ?? $record['ipv6'], $targetDnsRecords);
sort($current);
sort($target);
return $current !== $target;
}
function infoDnsRecords($sessionId)
{
$request = [
'action' => 'infoDnsRecords',
'param' => [
'domainname' => DOMAIN,
'customernumber' => CUSTOMER_NUMBER,
'apikey' => API_KEY,
'apisessionid' => $sessionId,
],
];
['dnsrecords' => $dnsRecords] = sendRequest($request);
return $dnsRecords;
}
function updateDnsRecords($sessionId, $dnsRecords)
{
$request = [
'action' => 'updateDnsRecords',
'param' => [
'domainname' => DOMAIN,
'customernumber' => CUSTOMER_NUMBER,
'apikey' => API_KEY,
'apisessionid' => $sessionId,
'dnsrecordset' => ['dnsrecords' => $dnsRecords],
],
];
sendRequest($request);
}
function logout($sessionId)
{
$request = [
'action' => 'logout',
'param' => [
'customernumber' => CUSTOMER_NUMBER,
'apikey' => API_KEY,
'apisessionid' => $sessionId,
],
];
sendRequest($request);
}
function sendRequest($requestData)
{
$ch = curl_init('https://ccp.netcup.net/run/webservice/servers/endpoint.php?JSON');
curl_setopt_array($ch, [
CURLOPT_POSTFIELDS => json_encode($requestData),
CURLOPT_HTTPHEADER => ['Content-Type:application/json'],
CURLOPT_RETURNTRANSFER => true,
]);
$rawResult = curl_exec($ch);
curl_close($ch);
$result = json_decode($rawResult, true);
if ($result['status'] !== 'success') {
throw new Error("Error calling action \"{$result['action']}\": {$result['longmessage']}");
}
return $result['responsedata'];
}Habe gerade meine Theorieprüfung bestanden 🥳
Habe gerade meine Theorieprüfung bestanden
Fachinformatiker? Auf jeden Fall herzlichen Glückwunsch, weiter so!
Wir fangen im September an, bei uns auszubilden. Wenn es Dinge gibt, die Du mir mit auf den Weg geben willst, damit es gut wird: Immer her damit, jetzt ist ein guter Zeitpunkt. (Die Ausbilderin ist frisch zertifiziert, hat aber Unterstützung von allen Seiten und erfahrene Ausbilder in direkter Reichweite.)
Na dann herzlichen Glückwunsch RAD750! 🥳
Möge die mündliche praktische Prüfung auch gut verlaufen.
Edith: ach Führerschein...dachte auch Ausbildung 😅
Fachinformatiker?
Nein, Führerschein! 
Der Ausbilder Titel ist ja nur ein Stück Papier und ziemlich irrelevant meiner Erfahrung nach. Mit meinem Ausbilder hatte ich in der Ausbildung gar nichts zu tun und auch in der jetzigen Firma hat der eigentliche Ausbilder den wenigsten Kontakt zu unseren Azubis 
Die wichtigste Vorraussetzung ist, finde ich, dass der Azubi auch richtig Bock hat. Wir haben nämlich einen, den müssen wir laut Geschäftsführung durchziehen und wir bezweifeln, dass er die Endprüfung schaffen wird.
Der andere Azubi hat richtig Lust neues Zeug kennenzulernen und beschäftigt sich auch privat mit vielen Themen. Es hat sich einfach so ergeben, dass ich ihm fast alles beibringe und bei ihm sehe ich das selbe Muster wie bei mir damals. Je nachdem was für eine Bude ihr seid, lasst dem Azubi auch mal viele Freiheiten und Zeit zum rumspielen. Ich habe mit unserem beispielsweise alte Server ausgeschlachtet und zu zwei größeren Servern vereint und ihm gesagt, dass er da mal einen ESXi, Proxmox, ... installieren kann. Das hat er auch gerne übernommen, weil es dann sozusagen sein eigenes Reich wurde und mittlerweile laufen genau diese Systeme als unser Test Cluster für alles mögliche und er ist gefühlt schon ein kleiner Experte in Proxmox, OPNsense und anderen Tools, weil er sie so oft aufgesetzt hat
Ich bin ja kein Pädagoge oder so, aber das hat schon einen echt guten Lerneffekt:
Meistens machen wir zuerst etwas zusammen und ich versuche nicht alles vorweg zu nehmen. Er soll selber ein kleines bisschen nachdenken und rumtesten.
Daraufhin sage ich ihm "hau weg" und er soll es nochmal alleine aufsetzen und gegebenfalls etwas anders konfigurieren. Da helfe ich dann nur noch, wenn er Fragen hat oder nicht mehr weiter weiß.
Anschließend wird er etwas geärgert und ich sage ihm wieder "hau weg", woraufhin er sich immer lachend beschwert, aber dieses mal muss er es "production ready" aufsetzen mit vernünftigen Bezeichnungen und allem. Danach nehme ich es dann ab und wir können es einsetzen.
Dadurch kennt er sich mittlerweile ganz gut mit OPNsense aus und hat Spaß daran. Das selbe hatten wir bei Proxmox gemacht und plötzlich hat er sogar Zuhause 2 Server am laufen 
